Estimación de póquer: Difference between revisions

Revision as of 10:08, 20 October 2013

Es una de las metodologías de estimación ágil más utilizada. Fue desarrollada por James Groenning, quien ideó este juego de planificación como ayuda para conducir la reunión de estimación.

El modelo inicial de Groenning consta de 8 cartas, con los siguientes valores: ½, 1, 2, 3, 5, 6, 7 e infinito. Las mismas fueron desarrolladas para dar soporte a las estimaciones de versión en eXtreme Programming, con equipos que:

emplean como unidad de esfuerzo los “días de trabajo” de cada par de programadores (entendiendo que XP trabaja con programación en pareja); y
trabajan con tareas de tamaño máximo de 10 horas (las tareas de mayor tamaño se descomponen en subtareas de menos de 10 horas).

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.

Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”.

Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.

Variante: sucesión de Fibonacci

Basado en el hecho de que al aumentar el tamaño de las tareas aumenta también el margen de error, surgió una variante que consiste en emplear números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:

El juego de cartas está compuesto por números de la sucesión de Fibonacci.
La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.

En particular, los números de esta variación del Planning Póquer son: 0, ½, 1, 2, 3, 5, 8, 13, 21, infinito.

Si se quiere emplear la planificación de póquer para estimar requisitos a nivel de producto o de versión (funcionalidades, temas) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144, etc.)

Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación.

También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso; así como otra carta con “infinito” para representar tareas “demasiado grandes”, que requieren ser divididas en tareas más pequeñas.

Funcionamiento

Cada participante de la reunión tiene un juego de cartas.
Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el propietario del producto expone la descripción.
Cada participante selecciona la carta y las separa del resto, boca abajo.
Cuando todos han hecho su selección, se muestran boca arriba.
Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea debe dividirse en subtareas de menor tamaño.
Si las estimaciones resultan muy dispares, el moderador de la reunión, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar, puede optar por:
- Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimación.
- Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
- Pedir al propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
- Tomar la estimación menor, mayor, o la media.

Este protocolo de reunión evita los 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.

@@ Line 2: / Line 2: @@
-El modelo inicial de Groenning consta de 8 cartas, con los siguientes valores: ½, 1, 2, 3, 5, 6, 7 e infinito. Las mismas fueron desarrolladas para dar soporte a las estimaciones de versión en eXtreme Programming, con equipos que:
+El modelo inicial de Groenning consta de 8 cartas, con los siguientes valores: ½, 1, 2, 3, 5, 6, 7 e infinito. Las mismas fueron desarrolladas para dar soporte a las estimaciones de versión en [[Extreme programming|eXtreme Programming]], con equipos que:
-*emplean como unidad de esfuerzo los “días de trabajo” de cada par de programadores (entendiendo que XP trabaja con programación de a pares); y
+*emplean como unidad de esfuerzo los “días de trabajo” de cada par de programadores (entendiendo que [[Extreme programming|XP]] trabaja con [[programación en pareja]]); y
-*trabajan con tareas de tamaño máximo de 10 días (las tareas de mayor tamaño se descomponen en sub-tareas hasta que éstas tienen estimaciones máximas de 10 días).
+*trabajan con tareas de tamaño máximo de 10 horas (las tareas de mayor tamaño se descomponen en subtareas de menos de 10 horas).
 El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.
-Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “¥”.
+Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”.
 Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.
-Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo que el equipo considera más apropiado, respetando los principios siguientes:
-*No definir tareas demasiado grandes, porque entorpece la precisión de las estimaciones y la identificación de riesgos.
-*No definir tareas cuya duración (en puntos o tiempo) resulte inferior a medio día ideal de trabajo.
-*Utilizar la misma unidad de medida (puntos de historias, días u horas) en todos los gráficos y pilas.
 ===Variante: sucesión de Fibonacci===
-Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:
+Basado en el hecho de que al aumentar el tamaño de las tareas aumenta también el margen de error, surgió una variante que consiste en emplear números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:
 *El juego de cartas está compuesto por números de la sucesión de Fibonacci.
 *La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.
-En particular, los números de esta variación del Planning Póquer son: 0, ½, 1, 2, 3, 5, 8, 13, 21, ¥.
+En particular, los números de esta variación del Planning Póquer son: 0, ½, 1, 2, 3, 5, 8, 13, 21, infinito.
 Si se quiere emplear la planificación de póquer para estimar requisitos a nivel de producto o de versión (funcionalidades, temas) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144, etc.)
@@ Line 39: / Line 33: @@
 *Cada participante selecciona la carta y las separa del resto, boca abajo.
 *Cuando todos han hecho su selección, se muestran boca arriba.
-*Si la estimación resulta “infinito”, por sobre¬pasar el límite máximo establecido, la tarea debe dividirse en sub-tareas de menor tamaño.
+*Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea debe dividirse en subtareas de menor tamaño.
 *Si las estimaciones resultan muy dispares, el moderador de la reunión, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar, puede optar por:
 **Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimación.
-**Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan que-dado pendientes.
+**Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
 **Pedir al propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
 **Tomar la estimación menor, mayor, o la media.
-Este protocolo de reunión evita los 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 alcan¬zar consensos sin discusiones, y además resulta divertido y dinamiza la reunión.
+Este protocolo de reunión evita los 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.
 [[Category:Scrum I]]
 [[Category:Glosario de términos]]