“Es un mal plan
aquel que no admite modificación”
Publio Sirio,
siglo I a.C.
Presentación
Ya sabemos que “el
trabajo a realizar durante el Sprint se planifica en la Reunión de
Planificación de Sprint.” [1] Es durante esta reunión a la que asiste el Equipo
Scrum en pleno que se responden estas dos cuestiones:
- ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
- ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento? [2]
Durante la reunión
se propone un Objetivo a alcanzar en el sprint que inicia y se discuten los
elementos de la Lista de Producto que, una vez terminados, dan como resultado
el logro del objetivo propuesto.
Durante la primera
parte de la reunión el Dueño de Producto propone los elementos de la Lista de
Producto que quiere ver terminados hacia el final del sprint. En la práctica,
el Equipo de Desarrollo realiza todas las preguntas necesarias al Dueño de
Producto con el fin de clarificar aspectos de los elementos de la Lista de
Producto, por ejemplo, de las historias de usuario seleccionadas para el
sprint. Esta parte de la reunión es un evento típico de recolección de
información, se establecen los criterios de aceptación de las historias de
usuario, los pormenores funcionales y no funcionales de las mismas y todo lo
que haga falta para que el equipo pase luego a decidir cómo se conseguirá
terminar el trabajo del sprint.
En principio, el
equipo debe estimar el esfuerzo necesario que le tomará terminar cada historia
de usuario según lo establecido en la Definición de Terminado. Para ello, el equipo
debe poner de manifiesto su experiencia en el ciclo de vida del desarrollo del
software, desde el análisis, pasando por el diseño, la implementación, las
pruebas, la documentación, hasta el despliegue del producto funcional. La
estimación puede hacerla entonces usando técnicas ágiles como Planning Poker, que permite fijar los
puntos de historia de cada una de las historias de usuario y que servirán luego
para calcular la Velocidad del equipo y evaluar aspectos de productividad y
calidad.
Al final de la
reunión el equipo tiene definidos:
- Un Objetivo del Sprint y
- Una Lista de Pendientes del Sprint
- Implementar la creación básica de blogs, adición básica y publicación de entadas a los blogs y publicación de comentarios a esas entradas.
- Implementar la gestión básica de usuarios, el ingreso a la aplicación y el recordatorio de contraseñas.
Algunas malas prácticas en la reunión de Planificación y
cómo evitarlas
A la reunión de
Planificación del Sprint asiste el equipo Scrum en pleno, incluyendo el Scrum
Master y el Dueño de Producto, responsable de direccionar el trabajo del Equipo
de Desarrollo. Incluso es posible que asistan algunos interesados que apoyen al
Dueño de Producto en la clarificación de los elementos de la Pila de Producto.
El Equipo debe planear muy bien la reunión, el Scrum Master debe velar porque
se haga en el bloque de tiempo establecido por las reglas de Scrum, por
ejemplo, 4 horas para un Sprint de 2 semanas. El Dueño de Producto debe estar
preparado para responder las cuestiones que surjan de la selección de elementos
de la Lista de Producto que serán seleccionados para el sprint.
El Equipo de
Desarrollo debe estar completo, ser multifuncional, preparado física y
anímicamente para enfrentar un nuevo sprint, los sprints anteriores son cosas
del pasado, las acciones de mejoramiento se tomaron y se llevaron a la Lista de
Producto para su implementación efectiva, de acuerdo con la prioridad del Dueño
de Producto y del Equipo en general. El Equipo está conformado por personas, no
por súper héroes que trabajan 16 o más horas al día o con capacidades por
encima del promedio (esto último apenas es una ganancia pero no debe tomarse como
fundamento para sobrecargar al equipo con tareas que van más allá de su
esfuerzo normal).
Aun así debemos
tener cuidado: una reunión de planificación mal ejecutada terminará con un mal
plan, con elementos de la Lista de Producto pobremente entendidos (por ejemplo,
requisitos incompletos o ambiguos), con sobrecarga de trabajo para el equipo,
con “sprints individuales”, es decir, iteraciones planeadas para cada miembro
del equipo en vez de una sola para todo el equipo; sin la definición de
“terminado” o sin el objetivo del sprint claro. Por ello tengamos en cuenta lo
siguiente.
Esto es lo que
hemos aprendido de las reuniones de planificación del sprint:
No empiece sin el Dueño de Producto. El Dueño del Producto está ausente o remoto. En
Ágil/Scrum promulgamos y valoramos más la interacción entre las personas que
los procesos y las herramientas. “El método más eficiente y efectivo de
comunicar información al equipo de desarrollo y entre sus miembros es la
conversación cara a cara” [3], dice uno de los principios del Manifiesto Ágil.
Así que es primordial que el Dueño de Producto esté disponible y presencial
durante toda la reunión.
Además, el Dueño de
Producto debe estar cuando se realice la estimación y la planeación de tareas.
En ocasiones, el Dueño de Producto ayuda a bajar la tensión y las expectativas
que se hace el Equipo cuando de construir un incremento del producto. El Dueño
de Producto quizás insista en hacer las cosas de otra manera, sencilla o más
liviana, pero de valor para el negocio. O al contrario, el Equipo de Desarrollo
o el Scrum Master pueden motivar al Dueño de Producto a disminuir su interés en
ciertos aspectos del producto pero a fijarse en otras características de mucho
más valor y rendimiento para la organización. Recordemos “la simplicidad, o el
arte de maximizar la cantidad de trabajo no realizado, es esencial.” [4]
No permita que el Dueño de Producto sea quien decida
sobre la cantidad de trabajo que el equipo debe realizar. En otras palabras, que el Dueño de Producto proponga
(imponga) la cantidad de elementos de la Lista de Producto a construir durante
el sprint, sin tener en cuenta la Velocidad del equipo o el esfuerzo total que
el equipo puede acometer durante la iteración. A medida que el Dueño de
Producto propone elementos de la lista, el equipo estima su implementación y
resta el estimado del tiempo total efectivo del sprint. Recordemos que “los
procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores
y usuarios debemos ser capaces de mantener un ritmo constante de forma
indefinida.” [5]
El Dueño del Producto no está listo para el Sprint. O la Lista de Producto no está lista. Muy bien,
estamos todos los que somos para la reunión pero a las primeras de cambio el
Dueño de Producto nos empieza a decir que no tiene las respuestas, que
desconoce tal o cual característica, que debe consultar dentro de tres o más
días con alguien más, incluso externo a la organización, que no está seguro si
las cosas son así o de otra forma, en fin, esa serie de respuestas que
finalmente nos llenan de requisitos incompletos y, por consiguiente, de
supuestos. Nuestro cerebro tiende a llenar los vacíos con conjeturas que le
pueden hacer mucho daño al proyecto.
En el caso de las
consultas para más tarde o para días posteriores, le debemos aclarar al Dueño
de Producto (y por “debemos” quiero decir el Scrum Master), que dado que el
sprint tiene una duración muy corta (2 semanas, por ejemplo), no es posible
esperar tanto tiempo por sus respuestas y pasamos así al siguiente elemento de
la lista. Precisamente, para evitar estas anomalías, recurrimos a prácticas de
refinamiento de la Lista de Producto que consisten en que, en medio del sprint
actual, nos reunimos con el Dueño de Producto para agregar detalles, lo mismo
que priorizar y estimar los elementos de la lista de los próximos dos sprints.
Así cuando llegue el momento de la planificación, el Dueño de Producto esté lo
suficientemente preparado como para iniciar la nueva iteración sin
contratiempos.
Planear un esfuerzo total que sobrepasa los límites del
Equipo, por ejemplo, planear
tareas del ciclo de vida del software en tiempos de reunión de Revisión o de Retrospectiva.
Si el equipo es de 5 personas y estamos haciendo sprints de 2 semanas, debemos
restar 15 horas de esfuerzo total por estas 2 reuniones (10 por la reunión de
revisión y 5 por la de retrospectiva), además unas 12 horas de esfuerzo por reuniones diarias y 20
horas por la reunión de Planificación del Sprint, esta de la que estamos
hablando. Es decir, unas 47 horas menos, con lo que el esfuerzo real sería de
353 horas para ese equipo de 5 personas.
Incluso deberíamos
planear jornadas efectivas de menos de 8 horas, por ejemplo 6 o 7, máximo. Con
7 horas, por ejemplo, el esfuerzo total del equipo de 5 personas sería de unas
300 horas. Algo realista y que, a la larga, contribuye a aumentar la
productividad, la energía de las personas del equipo, la motivación y,
como consecuencia, mejora la calidad de
los productos que construyen. “Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software con valor.” [6]
Otras cosas que no debemos hacer antes, durante o
después de la reunión de Planificación del sprint
- La reunión tarda más de lo debido. El Scrum Master debe estar atento a ello. Puede ser un indicativo de falta de productividad o de que estamos sobre-planificando el sprint.
- Cada miembro del equipo planea su “sprint individual”. O se hace una planeación para alguien en particular, “alguien adicional”.
- No planear de manera colaborativa. Va de la mano con la anterior práctica errónea.
- No planear la reunión con anticipación. Vale para todo el Equipo Scrum. Si hicimos Refinamiento deberíamos tener el suficiente apresto para realizar una reunión dinámica y efectiva.
- No definir un Objetivo del Sprint. ¿Entonces hacia dónde vamos? El Objetivo es la brújula que nos orienta.
- Planear tareas de 8 horas o más para un miembro del equipo. Se deben planear 2, 3 o más tareas cuya suma de esfuerzos individuales sume el tiempo total de esfuerzo diario de cada miembro del equipo.
- Permitir que alguien, por ejemplo el Dueño de Producto o el Scrum Master, incluso alguien externo, asigne las tareas al resto del equipo.
- Ausencia física del Scrum Master en la reunión de planificación. Puede estar virtual pero seguramente el valor de su participación será mucho menor.
Referencias
[1], [2] La Guía de Scrum.
http://www.scrumguides.org/download.html
[3], [4], [5], [6] El Manifiesto Ágil. http://www.agilemanifesto.org/iso/es
