Estimando con Planning Poker


Planning Poker

Estimar es la tarea más difícil del proceso de desarrollo. Nunca se tiene menos información que al momento de estimar y por otro lado, las decisiones tomadas marcan el futuro del proyecto. Si bien todos sabemos que son estimaciones, usualmente estos números (generados a partir de no conocer el problema) llegan al cliente y vuelven al equipo de desarrollo en forma de deadlines estrictos e inquebrantables. Hace poco, leyendo más que nada sobre la metodología SCRUM, me encontré con un método de estimación llamado “Planning Poker” que parece muy prometedor.

Mazo para planning poker

Introducción

Para poder comenzar con Planning Poker se necesita en una lista de funcionalidades o tareas a realizar y un mazo de cartas con los números: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. El valor que se le asigna a cada número se puede definir como: días de trabajo, días ideales o simplemente puntos. Es el líder de grupo quien debe indicar esto dependiendo del proyecto antes de comenzar el proceso de estimación.

Durante la reunión de estimación, se le da a cada persona un mazo de cartas. La reunión se planifica de la siguiente manera:

  1. Se define un cliente. Esta persona es la voz del cliente dentro de la organización. Es la que debe conocer que es lo que quiere el cliente para cada funcionalidad o tarea que se va a estimar. Tiene que poder responder a las preguntas del equipo. Si no se tiene esta posición, puede ser cubierto por un analista funcional o en el peor de los caso por un desarrollador senior que conozca la cuenta.
  2. Se define un moderador, el cual no va a estimar. Puede ser el perfil del Líder de Equipo o Líder de Proyecto.
  3. El moderador escoge una funcionalidad de la lista. El cliente da una pequeña introducción al tema. Es la oportunidad que tiene el equipo para hacer preguntas y clarificar puntos oscuros y/o riesgos de la tarea a realizar. A su vez, el moderador escribe un resumen de lo que surja durante esta charla.
  4. Cada persona escoge una carta de su mazo (sin mostrarla).
  5. Todos al mismo tiempo muestran sus cartas.
  6. El moderador entrevista a la gente que haya realizado las estimaciones más altas y bajas (con respecto al promedio) para averiguar de dónde surge la diferencia. También se invita a estas personas a discutir entre ellas para llegar a un acuerdo. La idea es entender que cosas hicieron que una estimación sea tan baja (tal vez la persona se olvido de algo, pero también puede haber pasado que haya pensado alguna mejor manera de resolver el problema) o tan alta (¿visión pesimista? ¿tuvo en cuenta casos que otros olvidaron?). La idea que este tipo de discusiones no dure más de 15 minutos. El moderador y/o el cliente pueden intervenir para dirimir algún punto de la discusión. Si bien los demás participantes (con estimaciones cercanas al promedio) pueden participar de la discusión; para que la discusión sea más ordenada se recomienda tratar de enfocar la charla con los que tuvieron estimaciones diferentes y  que los demás se dediquen principalmente a escuchar.
  7. Una vez terminada la discusión (el moderador debe determinar cuándo se pusieron suficientemente de acuerdo, no es necesario que piensen igual en todo), se repite nuevamente el proceso de estimación (a partir del punto 4). Cuando las estimaciones de todos están cerca del promedio, el moderador negocia con los participantes el consenso (por ej.: ¿Estás dispuesto a bajar tu estimación de 5 a 4? ¿Por qué no?). Si logra el consenso, se da por terminada la ronda de estimación. El moderador toma nota de dicho rango de estimación (peor-mejor) y se procede a la siguiente funcionalidad.
  8. Cuanto mayor es el número estimado, mas error acarrea (esa es la razón por la que las cartas son menos especificas a medida que aumenta el número). Se sugiere no aceptar estimaciones altas y en caso que aparezcan dividir la funcionalidad en partes de manera que cada parte se pueda estimar en menos de 5 días (1 semana laboral). Estimaciones por arriba de esto, indican el poco conocimiento de lo que se está realizando y, como dije antes, muy propensas a desviarse.
  9. Es importante no extender las reuniones demasiado. Terminar las discusiones por consenso o por tiempo, siempre se puede dejar una funcionalidad sin consenso y volver luego de seguir con las demás (tal vez analizando otra funcionalidad sirvió para entender mejor la primera). Llegado el caso, también se puede dejar alguna funcionalidad con un rango amplio (poco conocimiento de lo que hay que hacer, estimación con mucho error); siempre y cuando sea un porcentaje muy bajo respecto al total de funcionalidades estimadas. En el caso hipotético que no se pueda estimar correctamente muchas funcionalidades, hay que definir mejor las tareas. Algunas ideas son: El cliente debe proveer mas información, Dividir las tareas en dos o más partes para disminuir la complejidad, Posponer la reunión de estimación y asignar X tiempo a investigación sobre el tema, etc.

Ventajas

  • Se puede implementar sin ningún problema en equipos distribuidos
  • Soluciona el problema típico donde el que habla primero gana:
    • Líder: Bueno, entonces: ¿Cuándo estimamos esta tarea?
    • La mayoría piensa. Otros simplemente no lo hacen y están pensando en cualquier otra cosa. Dentro de los que piensan, algunos estiman muy alto, otros muy bajo.
    • De repente, uno decide que está seguro y dice su número (supongamos que es muy bajo, por ej.: 2). Los demás sin entender muy bien por qué eligió un número tan bajo, cambian su estimación a algo similar, para no quedar mal. Los que estaban distraídos, simplemente dicen el mismo número, sin saber siquiera a que se refiere.
    • Al final de la ronda de estimación todos llegan a un consenso, pero sin saber exactamente por qué.
  • Las personas influyentes del equipo, no pueden influyen en la estimación de los mas tímidos. Si esta persona influyente estima muy distinto a los demás, tendrá que convencer a todos de su estimación, lo cual es altamente improbable que ocurra a menos que realmente este en lo cierto.
  • Mejora la comunicación dentro del equipo y entre el equipo de desarrollo y el cliente. El desarrollador tiene una buena oportunidad de discutir con el cliente y entender exactamente a que se refiere cada funcionalidad.
  • El equipo de desarrollo pasa a ser el dueño de la funcionalidad. Como todos lo estimaron, con consenso, todos se sienten dueños de la tarea y cualquier se siente cómodo para realizarla ya que está de acuerdo en la duración.
  • Se evita el caso: “Juan dijo que se hacía en 2 días, yo en 2 días no llego; que lo haga el” al momento de desarrollo y se fuerza a que ocurra durante la estimación.
  • La estimación deja de ser algo traumático donde todo el mundo piensa que se está estimando a favor del cliente o de explotar a la gente con estimaciones bajas. Las reuniones de estimación deben ser amenas, todos deben participar y la idea es tener estimaciones reales con las cuales la gente se sienta segura y motivada a hacer su trabajo.

Desventajas

  • La estimación es un proceso que lleva más tiempo e involucra más gente, por lo tanto es más costoso para la empresa.
  • Se necesita un cliente o alguien que lo represente durante la estimación (este no puede dejar documentos explicando las tareas, debe ser parte de la estimación)
  • Todos los desarrolladores deben participar, esto puede ser una ventaja en equipos donde haya gente que no esté interesada en estimar y solamente en recibir tareas y tiempos.
  • Si los equipos son muy grandes, las discusiones pueden no terminar nunca (la estimación con converge). Se recomienda en estos casos achicar los equipos o, si esto no es posible, que cada iteración sea estimada por un grupo representativo de personas, pero no por todo el equipo. (dicho grupo debe cambiar entre iteraciones de forma que todos alguna vez participen de una ronda de estimación)

Referencias

http://en.wikipedia.org/wiki/Planning_poker
http://www.crisp.se/planningpoker/
http://www.codinghorror.com/blog/archives/000981.html

.

Anuncios

2 comentarios en “Estimando con Planning Poker

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s