Diferencia entre revisiones de «Planificacion De Poker»
(Página nueva: La Planificación de Poker (o Planning Poker, en inglés) es una Tecnica De Estimacion usada en conjunción con Wideband Delphi, para lograr consensuar estimaciones de tamaño...) |
(→Funcionamiento) |
||
Línea 64: | Línea 64: | ||
* 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 elementos pendientes de evaluar… puede optar por: | * 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 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. | ** 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 | + | ** Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes. |
− | quedado pendientes. | + | ** Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes. |
− | ** Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de | ||
− | las funcionalidades resultantes. | ||
** Tomar la estimación menor, mayor, o la media. | ** 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... | 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. | resulta divertido y dinamiza la reunión. | ||
− | |||
==La unidad de estimación: el día ideal== | ==La unidad de estimación: el día ideal== |
Revisión del 21:41 26 jul 2008
La Planificación de Poker (o Planning Poker, en inglés) es una Tecnica De Estimacion usada en conjunción con Wideband Delphi, para lograr consensuar estimaciones de tamaño de los requisitos de un proyecto de una manera rápida y ágil. Es una práctica ágil, que resulta útil para conducir las reuniones en las que el equipo estima el esfuerzo y la duración de tareas. Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ideó este juego de planificación como ayuda para conducir la reunión.
Contenido
El proceso
El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripción de los mismos. Luego se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas (que estan numeradas según la serie de Fibonacci) la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo.
Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas (esto es así para evitar que las estimaciones de unas personas sesgen las de otras). Si la dispersión entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación.
Generalmente la dispersión en las estimaciones es sintoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos oscuros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimación, la dispersión de las estimaciones será mucho menor y se podrá llegar facilmente a un consenso.
De esta manera es facil estimar los requisitos de una manera democrática, agil y rápida y que nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetará.
Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimación se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo están distribuidos geográficamente.
Las cartas
Este método se basa en un juego de cartas que tiene cada persona que estima. El modelo inicial de James Grening consta de 8 cartas con los números representados mas abajo, porque James lo ideó para las estimaciones de versión en Extreme Programming, con equipos que emplean como unidad de esfuerzo: días de trabajo de cada par de programadores y trabajan con tareas de tamaño máximo de 10 días.
- ½, 1, 2, 3, 5, 6, 7, 8, infinito
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.
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 más apropiado al equipo, respetando los principios siguientes:
- No definir tareas demasiado grandes, porque dificulta la precisión de las estimaciones y la identificación de riesgos. Un criterio válido, si el equipo no dispone de experiencia previa, es descomponer en otras menores las que tengan una duración mayor de 7 días ideales de trabajo.
- No definir tareas con duraciones inferiores a medio día ideal de trabajo.
- Utilizar al misma unidad de medida (story points, días, horas…) en todos los gráficos y backlogs.
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:
- 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.
Para estimar tareas puede ser válido un juego de cartas como éste:
- 0, ½, 1, 2, 3, 5, 8, 13, 20, infinito
Si se quiere emplear la planificación de póker 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…)
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.
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 cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
- Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
- Cada participarte selecciona la carta o cartas que representan su estimación y las separa del resto, boca a bajo.
- 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 para estimar, la tarea debe dividirse en sub-tareas de menor tamaño.
- 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 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 cliente o 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 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.
La unidad de estimación: el día ideal
Los números que se muestran en las cartas pueden representar distintas unidades. Uno de los enfoques más utilizados es el de "día ideal de trabajo". Esto es, la unidad representa un día ideal y perfecto de trabajo, sin interrupciones, interferencias o distracciones de ningún tipo.
Dicho de otra manera: "si estuviera yo solo encerrado en una habitación, con alimento ilimitado y trabajando 6 horas perfectas, inspirado y totalmente concentrado, ¿cuánto tardaria en desarrollar la funcionalidad X de forma completa y con calidad productiva?".
Por ejemplo, la carta "5" representa que quien estimó podría completar la funcionalidad estimada en 5 días "ideales" de trabajo.
Cartas para imprimir
Ver también