El proceso de planificación de lanzamiento ágil

Planificación de lanzamiento ágil

No es sorprendente que la mayoría de los gerentes tengan problemas para lidiar con la incertidumbre en sus operaciones. Después de crear un plan de negocios y tomar decisiones de inversión clave basadas en esos planes, los gerentes quieren comprender cómo se comparan sus operaciones actuales con ese plan. Por otro lado, la filosofía de desarrollo ágil adopta la incertidumbre como parte del desarrollo de software y sugiere que planificar con demasiada anticipación conduce a recompensas decrecientes. Las organizaciones de software que utilizan una metodología ágil suelen depender de algunos procesos de planificación de versiones para intentar cerrar esta brecha.

Velocidad del equipo y planificación de lanzamientos

La métrica de planificación clave para cualquier equipo ágil iterativo es su velocidad . La velocidad de un equipo es simplemente la cantidad promedio de puntos de historia que ha demostrado que puede entregar en una sola iteración. Si bien la velocidad de un equipo puede cambiar con el tiempo, por ejemplo, debido a cambios en la composición del equipo, se puede intentar la planificación a más largo plazo utilizando la velocidad conocida o estimada de cada equipo que trabaja en un lanzamiento.

Para utilizar la velocidad de cada equipo en la planificación de lanzamientos, también es importante considerar algunos problemas básicos de programación. Por ejemplo, algunas dependencias entre equipos pueden requerir que se trabaje en un equipo antes de que pueda comenzar a trabajar en otro equipo. Estas dependencias del cronograma, así como los factores externos, como los compromisos de las próximas ferias comerciales, deben tenerse en cuenta al intentar utilizar las velocidades de los equipos individuales como parte de la planificación del lanzamiento.

Alcance, cronograma y recurso

Al elaborar un plan de lanzamiento, la mayoría de las organizaciones se basarán en algún tipo de análisis basado en las limitaciones de Alcance, Programación y Recursos . Comprender cuál de estos se considera el menos o el más flexible formará un punto de partida para programar las discusiones y ayudará a impulsar las compensaciones de planificación que puedan ser necesarias.

Para determinar su alcance de lanzamiento planificado, a cada propietario de producto normalmente se le pedirá que proporcione una lista de deseos priorizada de características. Dado que varios equipos generarán listas potencialmente competitivas, es útil incluir una valoración común de las características que se están discutiendo, que se puede utilizar para comparaciones relativas al determinar el alcance de la versión final.

Si se ha exigido un cronograma de lanzamiento, entonces cada equipo puede usar su propia velocidad para proporcionar una lista de su alcance que se ajuste al cronograma. Si el programa es realmente flexible, es útil compilar una lista de características por encima y por debajo de una línea de corte para el lanzamiento. La lista completa de funciones por encima de la línea de corte se puede utilizar para garantizar que se entregue un nivel mínimo de funcionalidad que cumpla con los objetivos generales de lanzamiento.

En esta fase de planificación preliminar, a menudo se supone que existe una estructura de equipo conocida. Si los equipos se están reformando, será más difícil determinar la velocidad de cada equipo a los efectos de la planificación. Deben hacerse estimaciones de la velocidad, pero esas estimaciones deberán ser monitoreadas contra las cifras reales a medida que avanza el programa.

Reuniones de planificación de lanzamientos

Toda esta información se revisará en una reunión de planificación de lanzamiento . En la reunión inicial, cada equipo presentará sus expectativas de alcance clave y posiblemente un mapeo inicial de la funcionalidad que se planea entregar a través de las primeras dos iteraciones.

La parte más importante de la reunión es la comunicación, y uno de los resultados clave de la reunión de planificación inicial será garantizar que se comprenda bien cualquier dependencia entre los equipos. A menudo ocurre que el acuerdo sobre el plan de liberación completo no puede ocurrir en una sola reunión. Es probable que los planes iniciales requieran algunos ajustes a medida que las discusiones en la reunión de planificación descubran problemas, y se les pedirá a los equipos que revisen sus planes según sea necesario para manejar esas modificaciones.

Entonces se necesitarán una o más reuniones de planificación de lanzamientos para revisar y poner en marcha un plan final. Es importante que la última reunión cierre por completo los acuerdos del plan de lanzamiento. Por lo general, esto se hace de manera similar a los acuerdos realizados en una reunión de iteración. Se pide a cada equipo que se comprometa con el plan general, y la reunión debe finalizar solo cuando los problemas pendientes de cualquier equipo se hayan abordado a satisfacción de ese equipo.

Qué sucede después

Algunas organizaciones pueden estar bastante contentas si el plan de lanzamiento inicial tiene los detalles suficientes para que todos comiencen. Esas organizaciones asumen que las correcciones del curso se realizarán continuamente durante el ciclo de lanzamiento real y se asegurarán de que esos cambios se comuniquen a todos los equipos. Esto suele suceder en una reunión de Scrum of Scrums en curso , que normalmente se lleva a cabo con scrum masters o propietarios de productos de cada equipo. Es posible que el plan de lanzamiento en sí deba modificarse después de cada iteración para tener en cuenta los problemas sustanciales que se hayan encontrado. Cualquier cambio en el plan de lanzamiento debe comunicarse a las partes interesadas clave de manera oportuna.

El plan de lanzamiento también debe tener en cuenta los elementos que no son manejados por un solo equipo. Por ejemplo, es posible que se necesiten esfuerzos entre equipos para garantizar que las pruebas en todo el sistema se realicen con toda la funcionalidad presente, o se puede necesitar tiempo para garantizar que los materiales de marketing finales se alineen con el alcance que realmente se entregó.

Por último, al igual que en una retrospectiva de equipo individual, es importante tener una Retrospectiva de lanzamiento después de que se entrega el lanzamiento final. Aquí, todo el proceso de planificación y desarrollo se puede refinar en función de las lecciones aprendidas durante el lanzamiento.

Resumen de la lección

La planificación de la versión es una forma de garantizar que todas las partes asociadas con una versión tengan un entendimiento común. La planificación se basa en la velocidad del equipo conocida o estimada . Las líneas generales y los acuerdos sobre el alcance, el cronograma y los planes de recursos se comprometen en una o más reuniones de planificación de versiones . Los equipos trabajarán para lograr sus objetivos individuales durante el lanzamiento y participarán en Scrum of Scrum o un proceso similar para garantizar que cualquier cambio en el plan de lanzamiento se comunique a todas las partes interesadas de manera oportuna. Se debe realizar una retrospectiva de lanzamiento después de que se realice la entrega final.

Rodrigo Ricardo Editor y fundador