Inicio arrow Artículos - apuntes arrow Método ágil de estimación: Planificación de póquer. Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Método ágil de estimación: Planificación de póquer.
02.01.2007

pokerEn las metodologías ágiles es habitual desarrollar dos niveles de planificación:  una general, planificación de la versión, y otra más detallada, planificación de la iteración.

El objetivo de la planificación de la versión es calcular la dimensión del proyecto. Saber si estamos hablando de 10 o de 100, y tanto en Extreme Programming (Release planning) como en Scrum (estimación del product backlog) se realiza en una reunión en la que participa todo el equipo.

En ella el cliente, o el propietario de producto expone una a una las historias o funcionalidades que necesita y el equipo determina el tiempo que llevará su desarrollo.
Este proceso no es ajeno a los problemas típicos de dinámica de reuniones, y aunque tiene un guión concreto y conocido por todos los participantes, es habitual entrar en atascos de "parálisis por análisis", en los que los minutos van pasando sin que los participantes terminen de decidir entre las posibles soluciones para una determinada funcionalidad y fijen una estimación; y el moderador ve con impotencia cómo ha consumido ya 15 ó 20 minutos sin poder cerrar la primera funcionalidad, y la lista de las que aún están pendientes de valorar.

Una aportación muy valiosa de las prácticas ágiles es la tendencia a definir protocolos concretos para conducir las reuniones; y para  las que tienen como objetivo obtener valoraciones cuantitativas consensuadas por un grupo de personas, el protocolo definido por James Grenning para las planificaciones de versión de extreme programming, y que denomina "Planificación de póquer" (Planning Poker), es el mejor que conozco.

Planificación de póquer

(Descripción para planificaciones de versión de extreme programming, en las que la "granularidad" del esfuerzo requerido para cada historia de usuario debe estar comprendida entre 1/2 día y 10 días de trabajo.
El mismo protocolo resulta muy útil para estimaciones en rangos de horas en lugar de días, modificando los valores de las cartas; o incluso para otro tipo de estimaciones y acuerdos).

  • Cada participante de la reunión tiene un juego con las 8 cartas de la figura.

cartas


  • Para cada historia de usuario o funcionalidad de la pila del producto (product backlog) el cliente, moderador o propietario del producto (según sea) lee o expone la descripción empleando un tiempo máximo (No son aconsejables más de 2 minutos).

  • Se da un tiempo para que el cliente o propietario del producto responda a las preguntas que puedan tener los estimadores.

  • Terminadas las preguntas, cada participante selecciona, sin mostrarlas, una o dos cartas que suman el nº de días de trabajo necesarios. Si se estima que la funcionalidad necesita más de 10 días, se selecciona la carta "infinito". Cuando todos han hecho ya su elección, se ponen boca arriba en la mesa.

  • Si no hay gran diferencia entre las estimaciones de cada participante, se toma como resultado la media.

  • Si la estimación resulta "infinito", la funcionalidad debe dividirse para ajustarla a los criterios de tamaño de la metodología que se esté empleando (en este supuesto 10 días).

  • Si las estimaciones resultan muy dispares el moderador con su criterio de gestión y basándose en las características del proyecto, equipo, reunión, nº de funcionalidades a evaluar. puede optar por:
  • Preguntar a las personas de estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿Por qué crees que es necesario tan poco tiempo?. Tras oir las razones, repetir la estimación.
  • Dejar a un lado la estimación de esa funcionalidad y retomar al final o en otro momento las funcionalidades que no alcanzan consenso.
  • Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las nuevas funcionalidades resultantes.
  • Tomar la estimación menor, mayor o la media.

Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además... resulta divertido y dinamiza la reunión.

Trackback(0)
Comentarios (1)Add Comment
...
escrito por Guti, May 29, 2008
No conocía el método del Poker, la verdad que aunque infantil a primera vista, tiene pinta de ser eficaz en algunas circunstancias.

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative