Planeamiento de iteracion

Guía de planificación de la iteración.
¿Qué es?
El propósito de la reunión de planificación de la iteración es para que el equipo se comprometa a la realización de los ítems de mayor importancia
(mas rankeados) del Product backlog. Este compromiso deja establecido el backlog de la iteración y se basa en la velocidad o capacidad del
equipo y la duración del Timebox de la iteración.
¿Quién lo hace?
La planificación de la iteración es un esfuerzo de colaboración entre estos roles:
- ScrumMaster - facilita la reunión.
- Product Owner - representa el detalle de los ítems del product backlog y sus criterios de aceptación.
- Equipo de entrega / Agile Team - define los Tasks y los esfuerzos necesarios para cumplir con el compromiso.
Antes de comenzar.
Antes de comenzar debemos garantizar:
- Los ítems del product backlog han sido diseñados por el equipo y le han asignado puntos con un valor estimado a los stories.
- El product backlog esta rankeado y ordenado para reflejar las prioridades del líder de producto.
- Existe una comprensión general de los criterios de aceptación para los ítems del backlog rankeado.
Backlog con igualdad de oportunidades.
El product backlog se encarga de las revisiones de las funcionalidades existentes y nuevas funciones. El orden en el cual el product backlog está
organizado es completamente independiente de su pasado.
También podemos generalizar y decir que, con el propósito de la planificación de la iteración, los atributos importantes de un ítem del product
backlog son:
- Es lo suficientemente pequeño para ser completado en la iteración.
- Podemos comprobar que se ha aplicado correctamente.
Buena estimación y diseño de los ítems del backlog.
Ítems del product backlog demasiado grandes para ser completados en una iteración necesitan ser divididos en piezas más pequeñas. La mejor
manera de dividir los ítems del product backlog es por el valor y no por el proceso que conllevan.
Si se puede dividir un ítem del product backlog de modo que sus hijos ofrecen valor agregado, entonces nuestras iteraciones ofrecerán
incrementos de valor.
Si dividimos por el proceso, entonces obtendremos un impacto en la (“time to market”) salida al mercado porque el valor no se entrega hasta que
todos los hijos no están completos.
Stories compuestos pueden dividirse fácilmente a través de desagregación.
Stories complejos representan un desafío distinto. Bill Wake enumera veinte técnicas en:
http://xp123.com/xplor/xp0512/index.shtml
Plan basado en la capacidad.
Puede utilizar los equipos de mayor velocidad para determinar en qué ítems del product backlog se comprometerán durante la iteración.
Los nuevos equipos pueden no conocer su velocidad, o puede que no sean lo suficientemente estables como para utilizarlos como base para la
planificación de la iteración.
Un enfoque para los nuevos equipos es hacer compromisos basándose en la capacidad del equipo.
Determinando la capacidad.
La capacidad del equipo deriva de tres medidas simples para cada miembro del equipo:
- Número ideal de horas en el día de trabajo.
- Días de la iteración en los cuales la persona estará disponible.
- Porcentaje de tiempo que la persona va a dedicar a este equipo.
Pasos de la planificación.
1. El líder de producto describe como estarán rankeados los ítems del product backlog.
2. El equipo determina los TASKS necesarias para completar cada ítem del product backlog.
3. Los miembros del equipo se postulan como voluntarios para ser owners de los TASKS.
4. Los owners de TASKS estiman la cantidad ideal de horas que necesitan para finalizar su TASK.
5. La planificación continúa, mientras que el equipo puede comprometerse a la entrega sin exceder la capacidad.
Si cualquier persona excede su capacidad durante la planificación de la iteración, el equipo colaborara para distribuir mejor la carga.
Agenda de planificación de la iteración.
1. Apertura
Bienvenida, propósito de revisión, Agenda, y herramientas de organización.
ScrumMaster
2. Visión del Producto y Plan de trabajo (RoadMap).
Recuerde al equipo ver el escenario completo.
Product Owner
3. Estado de desarrollo, estado de la arquitectura, resultado de las iteraciones anteriores.
Discuta cualquier nueva información que pueda afectar el plan.
Product Owner
4. Nombre de Iteración y tema.
Colaboración en la decisión del nombre y tema.
ScrumMaster
5. Velocidad en la iteración(es) anterior.
Presente la velocidad que se utilizará para esta versión.
ScrumMaster
6. Timebox de la iteración (fechas, días laborables).
Determinar el Timebox y el total de días de trabajo (restar días de vacaciones o de otros hechos que afecten a equipo).
ScrumMaster
7. Capacidad de los equipos (disponibilidad).
Cada miembro del equipo calcula su capacidad basándose en su disponibilidad personal, la asignación a este y otros proyectos, tiempo
productivo en las tareas en esta iteración cada día.
Agile Team
8. Problemas y preocupaciones.
Tener en cuenta cualquier inconveniente o preocupación actual conocido y registrarlo, según corresponda.
ScrumMaster
9. Revisión y actualización de la definición de “Hecho”.
Revise la definición de “Hecho” y realice los cambios apropiados basados en la tecnología, la habilidad, o cambios de la estética del equipo
desde la última iteración.
Agile Team
10. Stories / ítems del product backlog a considerar.
Presente los ítems del product backlog propuestos para ser considerados para el backlog de la iteración.
Product Owner
11. Tareas a llevar a cabo.
El Delivery Team determina las Tasks, se apunta para un trabajo, y estima las tareas de las cuales es owner; el Product Owner responde
aclarando preguntas y elabora criterios de aceptación según corresponda; ScrumMaster facilita la colaboración.
a. Tareas, B. Estimaciones, c. Propietarios (owners)
Agile Team
12. Nuevos problemas y preocupaciones.
Tener en cuenta los nuevos problemas y las preocupaciones en base a las tareas y el registro, según corresponda.
ScrumMaster
13. Dependencias y supuestos.
Registrar cualquier dependencia o supuesto determinado durante la planificación y grabarlo/documentarlo según corresponda.
ScrumMaster
14. ¡Comprométase!
El ScrumMaster llama para un “fist of FIVE" en el plan; el equipo Agile y el Líder de producto dan el “ok” si éste es el mejor plan que puede
hacer teniendo en cuenta lo que sabemos hasta ahora y se comprometen a pasar al siguiente nivel de planificación (diariamente).
Agile Team
15. Comunicación / plan de logística.
Revisión y actualización de la comunicación y plan de logística para esta iteración.
ScrumMaster
16. Estacionamiento.
Proceso de Parking Lot (estacionamiento) - todos los ítems o bien deben resolverse o se convirtieron en ítems que serán resueltos.
ScrumMaster
17. Ítems / plan de acción.
Proceso de Plan de Acción - distribuir los elementos de acción a los propietarios (owners).
ScrumMaster
18. Retrospectiva de la Reunión.
Porque queremos que estas reuniones sean útiles para todos, solicitamos información sobre la reunión misma.
ScrumMaster
Cerrar - ¡Celebración! Celebrar una reunión de planificación exitosa!
Agile Team
www.rallydev.com © 2009 Rally de Desarrollo de Software, Inc.
Referencias:
Fist of five
http://www.agileiq.org/2009/07/07/fist-of-five-what-does-that-mean/