Documentación Front-End

Explore

Gallery

Documentación Front-End

Lineamientos Generales Front-end

Planning Poker

Entrar en el tema de

si se debe estimar o no en el desarrollo de software⁠

, es cierto que, tener una estimación, aunque sea a alto nivel, nos será útil para tomar mejores decisiones a la hora de ordenar y priorizar el backlog. Por ejemplo si tenemos historia A y B, y la historia A aporta valor 100 con esfuerzo 100 y la historia B aporta valor 90 pero esfuerzo 10, seguramente sea más interesante hacer primero B antes que A.

La estimación ágil

En la estimación ágil perseguiremos los siguientes objetivos:

Tener diferentes puntos de vista. Está claro que 7 pares de ojos ven más que uno. En la estimación ágil se busca la democracia, que todo el mundo participe y diga la suya. Si hay discusión mejor, ya que de lo que se trata es de avanzar todo lo posible los problemas y tenerlos en cuenta desde el inicio. No debería haber personas con una voz y voto más fuertes que los demás.

Detectar posibles tareas ocultas y posibles obstáculos. La sesión de estimación es una de las primeras oportunidades de detectar riesgos que pueden comenzar a tratarse para que no se conviertan en impedimentos.

Tener una visión compartida de la que se viene encima. Es muy útil haber participado en las estimaciones para después hacer las planificaciones. Si conoces el tamaño de las historias y tareas es mucho más sencillo comprometerte con un plan de trabajo que si las estimaciones te vienen “impuestas”.

Tener estimaciones más realistas (no más precisas). La idea es que entre todos el numerito que salga sea lo más cercano a la realidad posible. Para ello necesitas eliminar la presión contractual, esto es, dejar margen para equivocarse y evitar así introducir buffers “inconscientes” por si acaso. Lo que buscamos es realismo, no precisión, es decir, quiero saber si una historia serán 3 o 5 días, si me dices que tardarás 26,5 horas dudaré de que hayas hecho un buen ejercicio de estimación.

Planning Poker

Una de las técnicas más efectivas y conocidas del mundillo ágil para estimar es el Planning Poker. Se trata de una dinámica ágil en la que se reúne el equipo con una baraja de Poker modificada y se hacen rondas de estimación con ayuda de estas cartas.

⁠

Material necesario

Para una sesión de estimación ágil será necesario que cada participante tenga una baraja de

Planning Poker⁠

. Puedes descargar e imprimir tu propia baraja en este enlace. También puedes utilizar una app móvil si todos se llevan el teléfono, aunque le quita algo de glamour a la sesión.

En cada baraja hay una pseudo-secuencia de Fibonacci modificada. Yo recomiendo quedarme con solo las primeras cartas para evitar estimar tareas demasiado grandes. Así cada participante tendrá las siguientes cartas: 0,1/2, 1, 2, 3, 5, ? e infinito. El cero significa que la historia ya está hecha o no requiere ningún esfuerzo, el interrogante significa que nos falta información para estimar esa historia o tarea y el infinito es que es demasiado grande y hay que trocearla.

Trabajo previo

Además del material, antes de iniciar la sesión tendrás que tener claro en qué unidades vas a estimar. Es posible que para estimaciones alto nivel o de épicas o historias prefieras estimar en semanas ideales, mientras que para historias más pequeñas y tareas de bajo nivel prefieras estimar en días ideales. Un día ideal es el trabajo que consigue una persona en un día en el que no tiene interrupciones de ningún tipo y todo le sale a la primera. También es posible que decidas estimar en una medida relativa como

puntos historia⁠

. En cualquier caso, lo importante es que todos sepan en qué medida se estima.

También será importante que todos sepan qué se incluye y qué no en la estimación, si se incluye alguna documentación, tests unitarios, tests de integración y cualquier otra cosa que forme parte del desarrollo. Yo personalmente recomiendo incluirlo todo en la estimación de las historias y separar solo la documentación (no los tests) al desglosarlo en tareas.

⁠

⁠

Dinámica de la sesión

Una vez tenemos al material necesario la sesión contiene la siguiente dinámica:

Todo el equipo “se encierra” para estimar, y todos conocen lo que se va a estimar. Si hay gente que no está al tanto de lo que se va a estimar la sesión debe comenzar con una explicación y una sesión de preguntas para despejar cualquier duda sobre las historias que se van a estimar.

Una por una se leen y discuten las historias de usuario. Una vez todos tienen claro en qué consiste cada uno elige una carta en función del esfuerzo que prevé requerirá esa historia. No es posible seleccionar un valor no incluido en la baraja. Solo estiman los que después desarrollan (ni el Scrum Master ni el Product Owner estiman, solo resuelven dudas).

Si no hay consenso (lo normal con más de 2 participantes) se abre la discusión. No muy larga, por ejemplo se puede hacer que explique su elección el que tiene la puntuación más baja y más alta. Se repite la estimación nuevamente en busca de consenso. Si no se consigue a la segunda se vuelve a discutir. A la tercera si no hay consenso se escoge o bien la media o bien el máximo (mejor el máximo).

Al final de la sesión el resultado es una estimación consensuada y validada por todo el equipo para cada una de las historias o tareas seleccionadas. Si se trabaja con Sprints lo habitual es estimar alto nivel cuando los elementos entran en el backlog, y nuevamente cuando se realiza el sprint planning o backlog grooming si se hace por separado para estimar las tareas a bajo nivel.

⁠

El objetivo de Planning Poker es obtener una estimación consensuada y validada por todo el equipo⁠

⁠

Conclusión

Si bien es cierto que la estimación de tareas de desarrollo de software es una ciencia infusa, es posible mejorar notablemente la calidad de nuestras estimaciones con técnicas como Planning Poker. ¿Que por qué funciona Planning Poker? Porque unifica la opinión de varios expertos en lugar de depender de uno, ayuda a identificar más riesgos más pronto, define una visión única del trabajo por hacer, y obliga a defender las estimaciones dadas ante los compañeros.

Ni siquiera es necesario trabajar en un entorno ágil para aprovechar las ventajas de Planning Poker. Si estás trabajando en proyectos de software y necesitas cuantificar el trabajo pendiente, prueba a utilizar esta técnica y comprueba por ti mismo su eficacia.

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.