¿Qué opinas de "Planning Poker"? [cerrado]


22

Planning Poker

Resumen, en caso de que no quiera leer el artículo wiki:

  1. Obtenga una lista de tareas que desea realizar para la próxima iteración
  2. Para cada tarea:
    2.1 Discuta con el grupo lo que implica
    2.2 Todos escriben / seleccionan una estimación de cuánto esfuerzo se requiere para la tarea
    2.3 Todos revelan su estimación
    2.4 Los valores atípicos más altos y más bajos explican su razonamiento
    2.5 Repita hasta llegar a un consenso

Por lo general, algo similar a los números de la secuencia de Fibonacci como 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 son los valores permitidos, por lo que no obtienes argumentos largos sobre valores cercanos como 23 vs 27)

Además, los números representan un valor de esfuerzo sin unidad, cuyo valor está determinado por una tarea de referencia que todos acuerdan que es igual a un 1, y todo lo demás es relativo a eso.

En última instancia, el objetivo es tener una buena idea de la "velocidad" de un equipo determinado, que es el número de estos puntos que se pueden completar en una iteración determinada. Con eso, es posible hacer estimaciones razonablemente precisas de cuánto tiempo llevará una característica determinada.


Hicimos esto en las reuniones de planificación iterativa en una compañía en la que trabajé, y pensé que era una de las pocas cosas buenas de esa compañía en particular. Entonces, lo que me pregunto es, ¿alguien ha usado esto? ¿Crees que es una herramienta útil para la estimación? ¿Funciona en todas las situaciones, o se presta a ciertos equipos, proyectos, etc.?


Me gusta la idea, simplemente nunca he podido hacer que funcione de manera eficiente.
Pap

Lástima que esto se cerró como no constructivo, me encantaría verlo convertido en un wiki de la comunidad.
Jeremy Thompson

@pap Tampoco pudimos usar PP de manera eficiente (debido a que nuestro equipo se distribuyó). Por lo tanto, probamos el método Team Estimation Game de Steve Bockman, y funcionó bien para nosotros. Más tarde, encontramos este complemento de Jira
Vitalii Zurian el

Respuestas:


13

Lo usamos en nuestra empresa para el proyecto en el que estoy involucrado. Algunas notas sobre la planificación del póker se expresan en mi reciente publicación de blog , y aquí hay una lista más grande de por qué es genial:

  1. Hace que todos estén de acuerdo . Las personas no están obligadas a aceptar ningún resultado; en cambio, se ven obligados a hacer su propia estimación El tiempo para defender sus propias estimaciones también se asigna, si es necesario.

  2. Se mantiene a todos ocupados . No puedes relajarte durante la reunión, mientras intentas demostrar que estás tan involucrado. Además, la necesidad de mover las manos constituye un buen ejercicio físico para evitar dormir.

    Sin embargo, una desventaja de esto es que a veces es necesario hacer algo más (por ejemplo, tomar algunas notas y anotar los detalles del acuerdo que acaba de llegar).

  3. Se mantiene reuniones más rápido . No hay necesidad de una participación constante de un líder de la reunión para mantener todo en ritmo. El juego con reglas claras es mucho mejor para eso. Sí, debes hacer algunos movimientos adicionales para poner cartas, revelarlas, etc., pero estos pagan su camino.

  4. A mucha gente le gusta jugar a las cartas , especialmente el póker :-) Esto aumenta la motivación.

Una compañía que vende barajas de esas tarjetas acompañó a su sitio con un artículo sobre Planning Poker , que también vale la pena leer.


3
Generalmente lo hicimos en línea con planningpoker.com
Fishtoaster

@Fishtoaster, y solo imprimimos cartas por nuestra cuenta, y lo jugamos sentados en la mesa. Scrum alienta a todo el equipo a reunirse en un solo lugar para tales actividades de todos modos, y si tiene esa oportunidad, no necesita ningún servicio en línea.
P Shved

@Fishtoaster, gracias por el enlace. Supongo que debería ser útil para los equipos distribuidos
Armand

8

Lo usamos ampliamente. Creo que tiene varias ventajas sobre los métodos tradicionales:

  1. El equipo se apropia más de las estimaciones.
  2. A menudo, los arquetipos de programadores favorecen a los introvertidos: este método los alienta a contribuir donde de otro modo podrían diferir a personalidades más extrovertidas
  3. Cuando una característica tiene una amplia distribución de estimaciones, es un buen indicador de riesgo
  4. Simplemente haciendo la estimación, aprende más sobre las tareas
  5. No hay nada mejor que poner a las personas en una habitación comunicando efectivamente

6

Estoy de acuerdo con los puntos de Pavel. También hay otra cosa que es valiosa. Nivela el campo de juego para la discusión. A menudo, las personas tranquilas son ahogadas por más personas verbales en una discusión grupal. Planificar el póker les da a todos la oportunidad de tomar una decisión antes de que comience la discusión activa. Y si es la persona callada la que brinda la opinión "atípica", tiene el escenario completo para presentar su caso. Por lo tanto, la técnica permite a los contribuyentes más silenciosos y garantiza la participación total del equipo.


5

Después de haber usado la planificación de póker para algunos sprints, la gerencia finalmente se dio cuenta de lo que todos los desarrolladores habíamos sabido durante meses, no terminaremos a tiempo.

La planificación del póker, o más exactamente, la estimación basada en el punto de historia, es mucho más precisa que las prácticas de estimación tradicionales porque combina una manera fácil de estimar la complejidad combinada de todo el conjunto de características con mediciones reales de la capacidad real de los equipos.


4

Ya hay muchas buenas respuestas aquí, solo quería señalar otra característica.

Cuando usas el poker de planificación, obtienes una medida instantánea de los grandes desacuerdos sobre el tamaño del trabajo. Si creo que es un 2, y crees que es un 3, podemos llamarlo un 3 y seguir adelante. Pero si creo que es un 1 y crees que es un 5, será mejor que discutamos.


3

Hace que todos hablen y piensen en lo que se está haciendo. Incluso si no voy a trabajar en ello, tengo que prestar atención para estimar. Eso me ayuda cuando dentro de 2 meses necesito trabajar en algo que toque esa área.

También es fácil de entender. Muestre a la gente una estructura de desglose del trabajo y sus ojos se vuelven vidriosos y comienzan a babear mientras duermen. Muéstreles una lista de tareas para las próximas 2-4 semanas y pueden entenderlo.


3

Otra cosa buena: las discusiones sobre si la tarea X es un '3' o un '8' ayudan al equipo a determinar exactamente cuál es el alcance, por lo que más adelante, no hay una discrepancia sobre qué tarea X conlleva.


1

Me gustan los puntos de Pavel y me gustaría agregar que realmente ayuda a los desarrolladores junior o novatos a aprender mucho más rápido. No pueden simplemente sentarse y dejar que los desarrolladores principales gobiernen. Su voto cuenta igual y si realmente se enfocan en hacer que sus estimaciones sean precisas, aprenderán mucho de los desarrolladores senior.


1

No me gusta en mi equipo actual, principalmente porque tenemos personas que fundamentalmente no compran. Dedicamos una parte importante de cualquier sesión de preparación a debatir si vale la pena señalar, y el propietario de nuestro producto nunca desglosa las epopeyas, por lo que generalmente terminamos con estimaciones o historias increíblemente fuera de lugar donde los puntos indican que la cosa solo necesita ser desglosada .

¡Nada como tener un 40 y dos 20 en un solo sprint!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.