¿Planificas sobre la realidad? el poker plan te ayudará!

¿Planificas sobre la realidad? el poker plan te ayudará!

En cualquier proyecto de software destinamos un buen número de horas en su planificación. La gestión de las tareas y las estimaciones de tiempo de cada una de ellas las utilizamos para fijar metas de objetivos en función de los recursos. Cuanto más grande es el equipo de developers más trabajo de planificación existe.

Gestionar la incertidumbre

Una práctica habitual en la planificación es que una persona del equipo, muchas veces una de las que conoce mejor el proyecto tecnicamente, hace esta estimación de horas. A parte es quien asigna las tareas entre los otros miembros del equipo y las enlaza en el tiempo. A partir de este trabajo de definición se deinen los objetivos de cada una de las entregas.

En cualquier proyecto donde existe un trabajo de planificación uno de los mayores retos es la gestión de la incertidumbre. Las estimaciones iniciales acerca de un trabajo pueden oscilar entre un 400% por encima de lo estimado y un 25% sobre el total inicial. Nos movemos en un rango de error de 8 veces sobre la planificación inicial.

¿Quieres empezar a usar un método de planifación y estimación mucho más científico? ¿Te gustaría conocer la cantidad de trabajo que puede hacer un equipo durante un sprint? Mide la velocidad de trabajo de tu equipo y trabaja para mejorarla. Para medir el trabajo hecho usaremos el Poker Plan.

Dimensionamiento relativo

Antes de entrar a explicar en qué consiste el juego de las cartas, nos centraremos en explicar su razón de ser. Por definición las personas somos malas haciendo predicciones. Cuando respondes la pregunta ¿cuántas horas tardaré en realizar esta tarea? estás haciendo una predicción. Aunque somos malos haciendo estas predicciones somos buenos comparando.

Si pensamos en nuestra vida personal nos sería relativamente fácil ordenar camisetas según sus tallas (S, M, L, XL). Conociendo y difernciando estas tallas si nos ponemos a acertar las tallas de la gente que pasa por la calle nos daremos sorpresas como fallamos al inicio. En cambio, si vamos conociendo las tallas reales, por comparación podremos acertar de una forma más fácil a medida que se vaya aprendiendo continuamente. Ahora imagina que cada una de las tareas las tienes que clasificar según estas 4 etiquetas. Seguramente te resultará muchos más fácil y gracias a la comparación con las puntuaciones anteriores clasificar todas estas tareas en uno de los 4 grupos. Es probable que alguna de las tareas consideres que es mucho más grande que las otras XL, divide y vencerás.

Poker plan

Estás a punto de empezar, tienes escritas y priorizadas las historias de usuario en tu backlog? Puedes empezar con el poker plan. Si no estás familiarizado con el Scrum, te recomendamos leer nuestros artículos acerca de cómo escribir historias de usuario y cómo empezar a implementar Scrum.

Para poder obtener unas métricas acerca de la cantidad de trabajo en el poker plan se utilizan cartas que representan la serie de Fibonacci un poco modificada. Se utilizan los números de la serie de Fibonacci porqué están suficientemente separados entre ellos para poder ver fácilmente la diferencia. Podemos percibir la diferencia que hay entre un 5 y un 8.

El poker plan es una reunión de trabajo en la que todo el equipo avalua cada una de las historias de usuario y la puntuan en función de su volumen de trabajo. Los números mostrados no indican horas, no indican días, no evaluan la dificultad... sólo puntuan sobre la cantidad de trabajo que supone el desarrollo de una historia de usuario. Cada uno de los developers dispone de una baraja de cartas y la dinámica es la siguiente:

  1. Se explica cada una de las historias de usuario
  2. A medida que cada uno va resolviendo sus dudas selecciona una carta con el valor que cree oportuno
  3. Cuando todos los developers han seleccionado su carta se giran a la vez.

La jugada se considera buena si todas las cartas están a una carta de distancia de las otras. En este caso se suman todos los valores y se hace la media. Una jugada no es buena cuando la separación de las cartas es superior a una carta. Algunos equipos incorporan la norma que admés como máximo pueden haber X cartas con valores distintos. En este caso tienen la palabra el que ha sacado la carta más alta y el de la más baja. En este punto todo el equipo puede participar para que todos entiendan mejor en qué consiste realmente esta historia de usuario. Una vez han hablado se vuelve a votar, repitiendo el proceso hasta llegar a una jugada buena.

Cartas de poker plan.

Puedes bajarte esta baraja en este link.

Si comparamos los valores de una baraja de poker plan y la serie de Fibonacci veremos las siguientes diferencias:

  • Poker Plan: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, infinito.
  • Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...

Cada equipo define las normas concretas en algunos valores, un ejemplo sería:

  • 0: Eliminar historia de usuario
  • 0,5: Prácticamente hecha
  • 1-20: Estimación de trabajo
  • 40: Separar en dos historias
  • 100: Se debe definir mejor y separar en múltiples historias de usuario
  • ?: No sabe / No contesta
  • Infinito: No lo terminaríamos nunca!!

Velocidad de trabajo

Para aportar el máximo valor en cada uno de los sprint, el backlog siempre debe estar formado por historias de usuario. A su vez estas historias de usuario deben estar priorizadas según el valor que aportan al usuario o cliente. Cuano terminamos el primer sprint dónde hemos jugado al poker, sumaremos todos los puntos hechos durante es periodo de trabajo. Esta es la velocidad del equipo. En este momento debemos buscar alguna pequeña mejora, aplicable al siguiente sprint, para mejorar esta métrica.

Con este valor inicial podemos hacer una estimación de cuanto tardaremos a completar el proyecto, gracias a la suma de todos los puntos de las historias de usuario del backlog. Con esta métrico podrás conocer el rendimiento y la productividad del equipo. Normalmente se muestra en un formato de gráfica para poder comparar sprint a sprint como evoluciona la cantidad de trabajo y poder atacar los problemas o proponer mejoras.

También te puede interesar leer este post acerca de las ventajas de utilizar las historias de usuario como unidad mínima de trabajo.

Te ha gustado el post? Entonces comparte este post en la redes sociales o con alguien a quien también le pueda interesar. Gracias!

 

También te puede interesar...
Pitu Sabadí
Pitu Sabadí
TDD and Agile enthusiast - CEO at Pease Networks

CEO en Please Networks. Fullstack developer y believer en la vida real. Me gusta el trabajo en equipo y conseguir objetivos colectivos. Desarrollando con PHP y AngularJS. AWS para la infraestructura. Amante del agile y el TDD. Training Cloud y Scrumízate mis proyectos personales.