10 formas de mejorar la Planificación de Poker
- Detalles
- Publicado: Domingo, 05 Abril 2009 11:23
- Escrito por Leonardo De Seta
Quienes promueven el uso de la Planificación de Poker comprenden varios de los motivos de su éxito. Hay muy buenas razones por lo cuales la mayoría de los coach ágiles la utilizan y enseñan a sus equipos.
Los 3 motivos más importantes para del éxito de la Planificación de Poker son:
- Fomenta la colaboración a través de todo el equipo.
- Crea estimaciones por consenso en vez de tener a un único individuo que estime.
- Expone problemas de manera temprana, a través de discusiones sobre cada historia de usuario.
Con la popularidad de las metodologías ágiles para el desarrollo de software también aumento la popularidad del desarrollo iterativo, tanto en equipos ágiles como en los tradicionales. Una consideración clave en los procesos iterativos es definir qué tan larga deben ser las iteraciones. Las recomendaciones varian, desde 1 semana para equipos de Extreme Programming hasta 1 mes para equipos con Scrum. Algunos equipos también usan iteraciones más largas todavía, aunque la mayoría utiliza iteraciones de entre 1 semana y 1 mes.
En un artículo anterior sobre la 
Tengo una conferencia bien conocida sobre 
Los días 6 y 7 de Mayo de este año 2009 en Miami (Florida, EE.UU.) tendrá lugar la Conferencia de Kanban y Lean 2009, lo que será el primer evento internacional sobre el sistema Kanban y Lean aplicada al desarrollo de software.
Sí, estoy tratando de provocarlo deliberadamente. Y sí, de una forma mucho más específica, creo que la última mitad de la pregunta es la verdad.
Puede resultar algo dificil lograr que los equipos estimen utilizando Puntos de Historia. Cuando se explica el sistema de Puntos de Historia muchos no logran captar el concepto. Al estimar se suele pensar en días u horas, lo que complica más el cambio a una medida que parece tan oscura e ilógica. 
Es común que algunos equipos, durante la retrospectiva, tengan problemas en seguir y recordar los impedimentos que tuvieron y el contexto dentro del cual ocurrieron. Una forma de salvar esta situación es crear eventos clave e impedimentos diarios en el mismo gráfico de burndown. Este gráfico ya tiene una escala de tiempo, así que ¿por qué no aprovecharla?.
A veces veo algunos equipos obsesionados con la planificación del sprint, especialemente con la estimación de las tareas. Quiero decir, realmente obsesionados. ¿Dos días de planificación para un sprint de dos semanas? Aunque no lo crean, ocurre. Incluso aunque se quejan de pasar mucho tiempo en las reuniones de Scrum, insisten y discuten los detalles de la estimación de cada tarea. Por suerte, para aquellos equipos que quieran aprovechar su experiencia en Scrum y en las planificaciones, eliminar la estimación de tareas es una opción.
Creo que pasó la hora que los desarrolladores maduren un poco en cuanto a la necesidad de probar TODA y CUALQUIER aplicación que sea escrita, independientemente de su tamaño. Creo que ya pasó hace mucho la fase en la cual la arrogancia era suficiente para creer que su aplicación funcionaría sin tests (después de todo, ¡usted es el mejor programador del mundo!).
Este es un asunto un poco controvertido en la comunidad, tenemos defensores de los 2 abordajes, los libros de Ken Schawber y Mike Cohn, vemos la recomendación de estimar las tareas en horas, pero ya hace algún tiempo la idea de abrir mas las estimaciones de tareas está creciendo y ganando fans y yo soy uno de ellos en particular. Lo que suele ocurrir es que la planificación del sprint puede ser largo y cansador cuando el equipo tiene que estimar cada una de las tareas que considera son necesarias para desarrollar los temas del backlog, que normalmente se ve son interminables discusiones de si una tarea va a llevar 4 o 6 horas, cuando esta información no es realmente importante a la hora de entregar un elemento rápido.