Poker Planning o juguemos a estimar proyectos

Hace poco un compañero me pasó un link. Hablaba de un tipo de planificación usada en desarrollo agil. Acabo de encontrar el link de una pagina que habla solo de eso. La pongo para quien quiera profundizar pero voy a comentar como la realicé yo.

http://www.planningpoker.com/

El tema es sencillo. Se hacen unas tarjetas como cartas en las que ponga los numeros de la serie de Fiabonacci. 1-2-3-5-8-13-21 . Estos numeros es porque la imprecision va aumentando segun el tiempo de estimacion aumenta. Tambien se añade una carta que ponga NPI. NPI significa (no literalmente) que no se tiene suficiente informacion en ese momento para realizar una estimación concreta. El significado literal ya lo sabreis.

De esas cartas se hace un mazo por compontente del grupo de desarrollo. Yo actué como Scrum Master y no debia hacer estimaciones. Los que van a trabajar directamente en el proyecto son los que deben comprometerse con una estimacion.

Se va tarea por tarea haciendo una estimacion que debe ser consensuada entre todos los miembros del equipo de desarrollo. El procedimiento es el siguiente: cada uno pone una carta boca abajo con su estimacion. Todos le dan la vuelta y se busca el menor y mayor valor. Esos quien han hecho las estimaciones extremas deben explicar al resto el por qué piensan en ese valor. Despues de aclarar los puntos de vista se hace otra tirada y se repite el proceso hasta que se llega a un consenso (todos con el mismo valor)

Ventajas de este sistema:
– Toda la estimacion proviene del equipo que se compromete en ella
– Todos acaban entendiendo los pormenores de cada tarea.
– Se sacan a la luz codigos de ejemplo/ideas ya existentes que ayudaran a desarrollar más rapido.

Es importante tener toda la informacion posible para la estimacion. Un caso que ocurrió es que uno de los miembros hizo una estimacion alta. No sabia que uno de los compañeros de otra oficina tenia un codigo de ejemplo. Como no estabamos seguros de si el codigo era realmente tan iluminador como esperabamos el resto llamamos por telefono en ese momento al desarrollador de la otra oficina. Su llamada confirmo que aunque existia el ejemplo, era un codigo antiguo y no usado por lo que podia tener problemas.

Es importante hacer iguales todas las tarjetas. La ventaja de tirar todas las cartas boca abajo hace que todos pongan su punto de vista sin fijarse en algun desarrollador mas experimentado pero que quiza no tiene toda la informacion sobre la tarea en cuestion.Cuando yo lo hice, algunos se fijaban en el tamaño de las tarjetas del resto para adivinar cual era su estimacion.

Ventajas inesperadas:
– Más cohesion en el grupo. El compartir todos los puntos de vista hace que empiecen a trabajar más como equipo que como conjunto de individuos.
– No deja de ser un modo divertido de hacer estimaciones. Se empieza el proyecto con buen humor.
– Se trabaja de modo más comprometido ya que todos y cada uno han apoyado la estimacion. No se la han impuesto.

Ha sido una gran experiencia y se la aconsejo a todos los jefes de proyecto/Scrum Masters/jefes de desarrollo etc. Normalmente se ve asociado a desarrollo agil pero no es necesario que el proyecto sea agil sino que se puede hacer con proyectos con metodologia más lineal.

Espero vuestros comentarios.