Encabeza este artículo un esquema del marco de trabajo Scrum — Wikipedia.
El día 3 de diciembre la gente de Agile Canarias nos hizo el favor de darse un salto por la escuela para introducirnos en la metodología Scrum. De eso ya han pasado un par de semanas, pero no quiero perder la oportunidad de comentar la experiencia.
Asistimos cerca de 20 personas, de los cuales por parte de Agile Canarias vinieron Yeray Darias, Fran Reyes y Yurena García-Hevia. Yeray dio una pequeña charla de 15 minutos para explicar los roles, las reuniones y los documentos característicos de Scrum. Después vino lo divertido, porque pusimos en práctica lo aprendido.
Creamos dos equipos de desarrollo, nos repartimos los roles y Yeray sacó un taco de tareas con las que crear el backlog. La idea era muy sencilla, organizar el backlog según la dificultad de las tareas, para después acordar el siguiente sprint con nuestro product owner teniendo en cuenta también el valor de negocio. Al final de cada sprint hacíamos una retrospectiva, comparando los resultados esperados con los conseguidos y discutiendo las lecciones aprendidas. Las tareas ideadas por Yeray eran muy divertidas. Por ejemplo ordenar de manera determinada una baraja de cartas, inflar cierto número de globos con un diámetro determinado, hacer castillos de cartas o hacer barcos de papel. Algunas tareas estaban repetidas, mientras que otras tenían dependencias, tanto respecto a otras tareas como respecto al material que nos podía proporcionar Yeray —como si de nuestro hombre conseguidor de cosas de las películas carcelarias se tratara—.
Quien quiera saber más sobre esta actividad puede consultar un artículo del blog de Yeray donde describe un taller similar realizado en una ocasión anterior. Desde mi punto de vista fue muy entretenido y me permitió introducirme en esta metodología, que hace tiempo que vengo pensando como incluir en mis clases.
Respecto a las lecciones aprendidas:
- Es fundamental que haya buena comunicación con el product owner. En nuestro primer sprint fracasamos precisamente porque hacer lo que suponíamos que se nos pedía, sin dedicar el tiempo suficiente a negociar con el alcance de cada tarea ni los entregables con los que el product owner consideraría cada tarea completada.
- Es clave saber estimar el tiempo que lleva cada tarea, pero hacerlo no es sencillo, ya que depende de nuestra experiencia previa en el tipo de tareas del que estemos hablando.
En el segundo sprint, para compensar nuestro primer fracaso, nos lanzamos a asumir más tareas de las que podíamos hacer. Obviamente fracasamos por segunda vez al descubrir que algunas cosas no eran tan sencillas como suponíamos o que existían dependencias —por ejemplo solo teníamos una cinta métrica— que no nos permitían hacer las cosas tan rápido como pensábamos. Al final descubres que es importante darte cierto margen adicional en las primeras iteraciones, hasta que conoces bien el proyecto y eres capaz de estimar el tamaño de las tareas con mayor precisión. También aprendes que no vale de nada cargarte con más trabajo del que realmente puedes hacer, por muy dolido que esté tu amor propio.
Ahora lo que me queda es reflexionar sobre cuál es la forma más sencilla de introducir esta metodología en mis clases con el objeto de ayudar a mis alumnos a que se familiaricen con ella.