“Plans are useless, but planning is indispensable.”
Dwight D. Eisenhower
DEFINICIÓN: Un “release plan” o plan de proyecto es un conjunto de historias de usuario (normalmente épicas) agrupadas por “releases” o versiones del producto que se ponen a disposición de los usuarios incrementando el valor para estos respecto de la anterior.
También nos referimos a él como “plan de versiones” o “plan de entregas”.
Podemos imaginar que el producto en construcción es una cebolla a la que vamos añadiendo una capa con cada “release”. A la primera de esas versiones se le suele denominar MVP (o Producto Mínimo Viable).
¿Para qué sirve?
Elaborar un plan de proyecto es necesario porque:
- ayuda, al dueño de producto y al equipo, a decidir cuánto se debe desarrollar y cuánto tiempo se tardará antes de tener un producto entregable
- comunica las expectativas sobre lo que se puede desarrollar y en qué tiempo (para que el resto de la organización pueda hacerse una idea)
- sirve para tener una idea del progreso
El concepto de “release” ayuda al equipo a enfocarse, les da un contexto y evita moverse sin rumbo de una iteración a otra. El fin del “timebox” es la oportunidad para pararse, buscar oportunidades de mejora y revisar el plan incorporando lo aprendido, incluyendo el feedback de los usuarios, si es que ya lo tenemos.
¿Cómo se hace?
Para decidir cuáles deben ser las capas de nuestro producto podemos usar técnicas como el User Story Mapping o el Impact Mapping.
También tendremos que tener en cuenta la viabilidad de esas capas como producto acabado en el mercado, para ello necesitaremos hacer estimaciones de cuánto tardará en construirse cada “release”.
Se puede estimar a partir de una fecha y ver cuánto se puede hacer hasta entonces, o se puede empezar por un conjunto de historias de usuario y estimar cuándo se podrían terminar. En ambos casos es necesario tener una estimación de la velocidad del equipo. Si el equipo suele hacer 20 puntos por iteración y las iteraciones son de 2 semanas, para desplegar una “release” de 200 puntos serán necesarias 10 iteraciones, e.d., 20 semanas aproximadamente.
El compromiso del equipo no es con la fecha de entrega sino con la prioridad marcada por el dueño de producto y su búsqueda de un ritmo sostenible. Para ello el dueño de producto trabajará en el backlog de cada “release” para pasar de épicas a historias de usuario que se puedan planificar y construir. Refinar las épicas de “releases” muy lejanas puede llevarnos a trabajar en algo que luego decidamos no construir.
En general, cada “release” necesitará un número diferente de iteraciones para ser completada, pero siempre intentaremos que sean lo más pequeñas posibles para obtener el feedback de los usuarios lo antes posible.
Malas prácticas
- Considerar el plan como un contrato. Se construye en base a estimaciones.
- No tener un criterio de aceptación para cada “release”.
- No revisar nunca el plan.
- Dar mucha importancia al detalle de lo que habrá en todas las “releases”.
Bibliografía:
- “Agile Estimating and Planning” de Mike Cohn.
PUBLICIDAD:
Si estás interesado en contar con mi ayuda para dar formación o incluso construir vuestro plan de proyecto, puedes ponerte en contacto conmigo aquí.