El otro día estuvimos hablando de cómo podemos organizar los sprints de SCRUM, dejando en el aire el tema de las reuniones diarias (llamadas daily meeting)

Antes de entrar en harina, tenemos que presentar a la figura del Scrum Master.
SCRUM propone los roles de "product owner", "equipo de desarrollo" y "Scrum Master".
El Scrum Master es la persona que conoce la filosofía y el modo de aplicar SCRUM en una empresa. No se trata del clásico "jefe de proyecto", sino que es uno más del equipo, al mismo nivel que los demás, aunque con tareas distintas.
Como ya hemos dicho, en los proyectos típicos de SCRUM se trata de una persona que compagina esta actividad con otras (puede ser habitual que el Scrum Master sea también el "product owner", o un programador más), aunque en proyectos grandes quizá pueda haber un Scrum Master a tiempo completo.
Es importante que el Scrum Master sea una persona con cierta capacidad de decisión en la empresa, más que nada porque quizá tenga que tomar algunas decisiones difíciles para que el proyecto llegue a buen puerto.

Bien, hechas las presentaciones, podemos decir que el corazón de SCRUM es la reunión diaria, (también llamada "scrum" en referencia al movimiento típico de rugby). La reunión es un momento en que todo el equipo de desarrollo pone en común sus avances, sus dudas, pide ayuda, etc. Con una reunión diaria nos evitamos las desagradables sorpresas a punto de cerrar la versión, ya que se va viendo el avance (o el "no-avance") día a día.

En varios equipos de desarrollo que conozco desde dentro, el jefe de proyecto va mesa por mesa preguntando el típico "¿cómo vas?", o el programador avisa al jefe cuando ha terminado una tarea.
Recordemos que en SCRUM, no existe ese concepto de "el jefe revisa", sino que, como estamos hablando de equipos autogestionados, es el equipo al completo (programadores como tú y como yo) los que van revisando el trabajo de los demás.
Además es importante que el equipo vaya viendo los avances del proyecto al completo, y no sólo de su parte. Esto crea un sentimiento de pertenencia e identificación, y este sentimiento podemos decir que es la gasolina de la metodología SCRUM. Sin sentirse identificado, el proyecto SCRUM al final se parará igual que un coche se para sin gasolina.
Todo esto me lleva a recordaros una vez más la regla de oro: no intentes aplicar SCRUM en cualquier empresa y en cualquier equipo. Elige muy bien la gente y el ambiente de trabajo.

La reunión diaria no debe durar más de 10-15 minutos, para evitar las típicas reuniones interminables, donde nunca se saca nada en claro. En nuestro caso la reunión es muy informal y dura 2 minutos (: ya que sólo estamos dos programadores en el proyecto.
Así que no hay excusas del estilo: "no tengo tiempo para reunirme", porque seguro que estás perdiendo más tiempo leyendo esta página.

SCRUM define un modus-operandi más o menos establecido. Durante la reunión, cada integrante tiene que contestar tres cuestiones:

1. ¿Que hiciste ayer?
2. ¿Que vas a hacer hoy?
3. ¿Que necesitas para seguir?

En el blog del Jeff Sutherland (uno de los creadores de SCRUM), explica con detalle el porqué de estas preguntas:

¿Qué hiciste ayer?
Con esta pregunta se pretenden dos cosas:

1. Que todo el mundo este trabajando en las tareas que él mismo se asignó. Como ya hemos dicho, SCRUM no funciona del modo tradicional en que el jefe de proyecto dice: "Fulanito, para la semana que viene tienes que tener terminada la tarea X", sino que cada desarrollador se asigna las tareas que cree que puede hacer mejor. Es posible que alguien "se invente" lo que ha estado haciendo. Sinceramente: es su problema. Cuando llegue el fin del sprint quedará en evidencia al verse que sus tareas no están terminadas y se verá que ha estado mitiendo durante todas las reuniones.
2. Que todo el equipo vea como avanza el proyecto. Siempre viene bien para la moral ver como tus compañeros avanzan a buen ritmo en sus tareas, y el equipo se mueve a un ritmo constante hacia un objetivo común. Esto ayuda a que los rezagados se den más prisa y que los desmotivados se auto-motiven. Ojo, hay que distinguir cuando un programador está por debajo de su capacidad, tiene algún tipo de problema personal o cuando no le apetece trabajar más. Cada caso requiere de acciones distintas del Scrum Master.
   Hay veces en que los retrasos se deben a que el programador no es consciente de las consecuencias que acarrea un retraso en su código, y por eso se toma las cosas con más calma. Es natural y no suele ser culpa del programador: nadie se lo ha explicado y él no tiene porqué saberlo (típico en empresas con poca o nula comunicación). Con esta reunión se elimina este problema: todo el mundo es muy consciente cuando hay que correr porque se está esperando a que termine, o cuando las cosas se pueden tomar de una forma más relajada.

En este momento el programador actualiza el "sprint backlog" para reflejar el tiempo que queda para terminar la tarea con la que estaba (más adelante explicaremos cómo está organizado y cómo trabajar con el sprint backlog).

¿Que vas a hacer hoy?
En esta pregunta, cada integrante se asigna las tareas que más le gusten, dentro del sprint backlog. Ni el equipo, ni el Scrum Master deben obligar a nadie a hacer una tarea, sino que tiene que ser el propio programador el que elija la que quiere hacer. ¿Por qué? pues sencillamente porque nadie sabrá mejor que el programador las tareas que puede hacer mejor y más rápido. Por lógica, todo el mundo elegirá las tareas que le vayan mejor a sus habilidades y conocimientos, así que poco a poco las tareas se irán asignando de la forma más óptima sin intervención externa (teoría del caos en estado puro :)
Según avanza el sprint, van quedando pendientes las tareas que nadie ha elegido. En ese punto el Scrum Master pude sugerir, pero no obligar.
Hay metodologías que sugieren que las tareas con mayor riesgo deben hacerse antes que las de menor riesgo. Eso tiene su lógica, así que en caso de duda, deberíamos elegir siempre las tareas con mayor riesgo.

¿Que necesitas para avanzar?
Muchas veces, en las empresas tradicionales, las personas que están en puestos de responsabilidad olvidan su principal función: organizar y gestionar el entorno para que sus subordinados pueden trabajar en las mejores condiciones posibles (al fin y al cabo, se trata de maximizar el rendimiento del sueldo que se les paga). Sin embargo, muchos los jefes se quedan con la parte bonita, "organizar y gestionar", olvidándose de para qué se les ha dado ese "poder".

En esta pregunta, el programador lanza un aviso al equipo (y especialmente sobre los que más responsabilidad tienen en el equipo) sobre qué aspectos le tienen bloqueado o deben ser mejorados. El Scrum Master debe hacer lo posible por solucionar esos puntos críticos, aunque si algún otro programador tiene la solución al alcance de la mano, debería decirlo (siempre que haya un buen clima lo hará, pero si hay problemas entre miembros del equipo, no cuentes con que la ayuda surja espontáneamente).

Algunos problemas típicos son:

• temas de programación: "no sé como utilizar la aceleración gráfica en Java". Si estamos en un equipo multidisciplinar (cosa que recomienda SCRUM), es posible que otro programador pueda ayudar o al menos orientar.
• temas de dependencias: "para implementar esta nueva funcionalidad necesito que esté estable el motor de renderización". Normalmente son dependencias que se nos han escapado durante la fase de planificación. Resolverlo es tan sencillo como meter las nuevas tareas en el sprint backlog.
• temas de gestión: "no tengo acceso a la red" o "me estoy retrasando porque cada vez que compilo pierdo 30 minutos". En este caso el Scrum Master debería hacer las gestiones necesarias para solucionar el problema.
  

Algunos problemas puede que se resuelvan facilmente (por ejemplo, añadiendo nuevas tareas al sprint backlog), sin embargo, a veces las cosas se complican.

Si el proyecto está en apuros, lo habitual es que la lista de problemas sea cuando menos generosa. En ese momento, el Scrum Master debe ir recopilando esa lista en un "impediments backlog", o la "pila de problemas". A partir de ese momento, la prioridad del equipo no es avanzar en el "sprint backlog", sino hacer que ese "impediments backlog" desaparezca lo antes posible. Para ello se asignarán los distintos impedimentos a personas del equipo de desarrollo, o incluso a personas fuera del equipo (el administrador de red, el responsable de compras, etc.). Al día siguiente, se revisará tanto el "sprint backlog" como el "impediments backlog", eliminando aquellos impedimentos que se han solucionado, y pudiendose retomar las tareas del sprint que estaban bloqueadas.

Bien, y para terminar, pondremos un ejemplo más o menos gráfico de lo que sería una típica reunión diaria:

- Toñete: Bueno, que sepáis que ya he terminado con la refactorización de los renderizadores.
- Juancito: Perfecto, al final has tardado menos de que esperabas ¿no?
- Toñete: Sí, estaba inspirado y me ha salido de un tirón (:
- Perico (el Scrum Master): Genial, guardaremos esas horas sobrantes para el final del sprint, que nos harán falta.
- Toñete: Hoy voy a empezar a aplicar la aceleración por hardware, aunque la verdad es que no sé ni por donde cogerlo
- Juancito: Yo recuerdo haber leído algo en internet sobre el tema... dame un rato y esta tarde te envío algún código de ejemplo de la clase VolatileImage.
- Toñete: vale tío, muchas gracias. Cuando tenga tu código espero avanzar sin problemas.
- Juancito: Pues yo estoy atascado con el deshacer/rehacer. Está afectando a un montón de módulos y la verdad es que estoy un poco perdido entre tanta clase, herencia y métodos.
- Toñete: quizá te ayudaría usar alguna herramienta de modelado UML, más que nada para que veas las dependencias entre clases y cómo afectará tu cambio.
- Juancito: Sí, quizá sea buena idea... pero no sé cual usar ¿Rational Rose? ¿Together?
- Perico: Creo que en el otro departamento ya están usando alguna. Voy a preguntarles, y si vemos que nos viene bien, gestiono la compra de la licencia para nuestro departamento.
- Juancito: vale... pues entonces mientras consigues eso voy a intentar automatizar las pruebas en los teléfonos móviles.
- Perico: de acuerdo, voy a conseguirte unos cuantos teléfonos para que lo puedas probar en distintas marcas y modelos.
- Juancito: ok, entonces mañana os cuento a ver cómo me ha ido.

El próximo día trataremos el uso de la hoja de cálculo para gestionar el sprint backlog

Etiquetas: agile, SCRUM