Hablando de la Metodología Agile de desarrollo de software, un «release plan» o plan de lanzamiento es un diagrama de flujo evolutivo que describe qué características serán terminadas/entregadas en los lanzamientos (releases) próximos. Cada historia en un release plan tiene una estimación aproximada del tamaño asociado a ella.

La planificación y la estimación en la metodología agile (ágil) depende de una sola medida clave: la velocidad del equipo de desarrollo, que describe la cantidad de trabajo que el equipo puede llevar a cabo por iteración. Dada la velocidad conocida de un equipo por su último proyecto (si se conoce), un release plan representa la cantidad de características que el equipo tiene la intención de entregar en un plazo determinado.

 

Release Plan preliminar:

El objetivo del release plan inicial es estimar más o menos qué características serán entregadas en la fecha límite (suponiendo que la fecha límite es fija), o para elegir una fecha de entrega aproximada para un determinado conjunto de características (si el objetivo es fijo). Utilizamos esta información para decidir si el proyecto producirá suficiente retorno de ingresos para al menos pagar por sí mismo o no, y por lo tanto si debemos proceder o no.

El release plan inicial raramente satisface a todas las partes involucradas pero en el mundo ágil, el equipo ve estas difíciles verdades cara a cara y crea un plan de desarrollo de software alrededor de ellas (o no se entregarán suficientes funcionalidades o se tomará demasiado tiempo para desarrollar las funcionalidades deseadas). En este punto nadie cree en los objetivos milagro que satisfagan a todos.

En lugar de practicar la negación colectiva, el equipo utiliza métricas reales y negociación para tomar decisiones difíciles tan cerca del inicio del proyecto como sea posible.

 

Planear lanzamientos continuos.

Hay que resaltar algo: las planeaciones iniciales son duras.

Solamente deben ser lo suficientemente detalladas para empezar a trabajar, mediante la predicción de que el proyecto proporcionará suficiente retorno de la inversión como para pagar por el desarrollo y más. (Si el plan de lanzamiento inicial predice un retorno de ingresos que es demasiado bajo para justificar el proyecto, entonces podemos cancelar el proyecto antes de que desperdiciemos mucho dinero)

En los proyectos agile planificamos de forma continua, y corregimos nuestro curso a medida que avanzamos. Uno de los mecanismos principales para la corrección del curso es permitir que el release plan evolucione en respuesta a todo tipo de retroalimentación. Tomará por lo menos un par de iteraciones para poder establecer la velocidad de cada equipo.

Algunas veces, las iteraciones ofrecerán menos funcionalidades de las que tenían planeadas y otras veces, más. Muchos factores nos ayudarán a revisar y redefinir cada release plan, tales como: características de cada desarrollo, opciones de arquitectura digital, diseño, deciciones de framework o de tecnología que pueden ser demasiado arriesgadas o simplemente no se pueden trabajar, la interfaz de usuario puede necesitar ser revisada, podemos haber ganado o perdido a miembros de nuestro staff, etc.

Sabiendo todo lo anterior, nos puede quedar una duda fundamental:

 

¿Cómo inicio un release plan?

La respuesta a esta pregunta es bastante complicada. Muchos equipos «agile» planean entregar sólo una pequeña cantidad de funcionalidades en la primera iteración (a menudo llamada «La iteración 0»), con el fin de permitir explícitamente el arreglar los problemas técnicos y logísticos iniciales, y quizás también para estresar la arquitectura de extremo a extremo. Esto puede ser crítico para los equipos que tienen poca o ninguna experiencia ágil. Para un equipo sin una buena métrica de velocidad, esto podría significar que sólo al final de la segunda o tercera iteración su velocidad será considerada como estable y fiable.