Jesús Ramírez Guerrero

Uno de los programadores hace de moderador de la reunión y se le llama Scrum Master. Este NO es jefe de los demás, simplemente debe encargarse de que la reunión no dure más de un cuarto de hora/media hora y de que las ayudas/problemas que plantean los programadores se resuelvan a lo largo del día.

El Product Owner también debe colaborar en eso de «quitar obstáculos», estar disponible para consultas, etc.

La ayuda necesaria puede ser de cualquier tipo:

• «no conozco este tema y necesito alguien que me ayude»,
• «necesitaría tener datos en la base de datos para hacer pruebas»,
• «necesito tener mi pc conectado al osciloscopio», etc.

En resumen: cualquier cosa que uno de los programadores considere que le facilita el trabajo debe ser tratada aquí.

En esta reunión también se aprovecha para volver a estimar el tiempo de las tareas en curso. Puede que una tarea, el primer día, se dijera que se iba a tardar ocho horas. Resulta que hoy, después de haber trabajado el día de ayer en ella, emerge un problema inesperado y hoy decidimos que vamos a tardar 10 horas más en resolverla. No pasa nada, se apunta y listo.

Después de varios días de reuniones se verá rápidamente de esta forma si vamos según lo previsto o nos vamos a pasar en tiempo. Nuestro Product Owner, además, puede verlo, sobre todo si vamos registrando en alguna herramienta como Rally o CA-Agile Vision el día a día indicando cuantas horas suponemos que nos quedan para acabar en el eje vertical y los días en el eje horizontal.

Importante: Aunque en teoría Scrum dice que la lista de tareas a hacer (Sprint Backlog) NO se toca, hay mucha gente que decide añadir o quitar tareas en caso de ir adelantados o retrasados. Lo importante es entregar a final de la semana una versión con determinadas funcionalidades implementadas.

Sprint Review y Sprint Retrospective

Ya ha pasado el primer Sprint. Si estimamos bien, tenemos nuestra versión del programa con todas las funcionalidades del Sprint Backlog. Si estimamos mal, quizás esta versión tenga alguna funcionalidad menos o alguna de más.

Ahora se hace una reunión de aproximadamente un par de horas, llamada Sprint Review, a la que acude el Scrum Team, el Scrum Master, el Product Owner y cualquier otra persona interesada en el producto. En ella el Scrum Master enseña la versión a los demás. Los asistentes pueden dar opiniones, posibles mejoras, etc.

Inmediatamente después, se hace otra reunión, llamada Sprint Restropective, en la que el Scrum Master, el Scrum Team y el Product Owner analizan qué cosas pueden mejorarse a la hora de trabajar para el siguiente Sprint, si la comunicación ha sido bueno o debe mejorarse, si hay algún problema que deba subsanarse. En general, con un ambiente distendido y espíritu constructivo, ver cómo se puede mejorar la forma de trabajo en el Sprint Backlog del siguiente mes.

Y vuelta a empezar, otro Sprint Planning Meeting para ver qué funcionalidades va a tener la nueva versión del mes que viene, un nuevo Sprint Backlog.

Algunos detalles

Como vemos, Scrum no dice nada de si hacer o no hacer diseño, si hacer o no hacer Test Unitarios, si hacer o no hacer documentación, si trabajar en parejas o no, etc, etc.

Scrum únicamente nos indica cómo conseguir que todos trabajen con el mismo objetivo, a corto plazo y deja bastante visible como avanza el proyecto día a día.Lo ideal es complementarlo con una metodología de desarrollo software ágil, como la programación extrema (XP).