Release Los plazos de entrega suelen ser fijos, impuestos externamente por factores como ferias comerciales, presiones contables u obligaciones contractuales. Sin embargo, dado que el objetivo es que los usuarios dispongan de software funcional lo antes posible para poder realizar ajustes cuanto antes, se hace todo lo posible por mantener los ciclos de desarrollo de software lo más cortos posible. Los ciclos de lanzamiento ágiles deben ser inferiores a un año, y a menudo duran tan solo seis o tres meses. Un lanzamiento se compone, a su vez, de iteraciones. Para un proyecto determinado, la duración de cada iteración suele fijarse entre una semana y un mes. Si el lanzamiento se realiza en seis meses y las iteraciones duran dos semanas cada una, el lanzamiento constará de 13 iteraciones.
En algunos entornos, el software se entrega a los usuarios, o al menos a un subconjunto de ellos, de forma incremental al final de cada iteración o cada dos iteraciones. Tras identificar, priorizar y, posiblemente, estimar una lista inicial de funcionalidades, el equipo celebra una reunión de planificación de lanzamientos para establecer el cronograma general y determinar qué funcionalidades se pueden entregar. El plan de lanzamiento general, en términos de funcionalidades priorizadas, se utiliza directamente para alimentar los planes de cada iteración.
Algunas metodologías ágiles hacen hincapié en la clara separación de responsabilidades entre programadores y clientes. Durante la planificación, solo el cliente es responsable de las decisiones de negocio y la priorización, y solo los programadores son responsables de la estimación de tareas y la ejecución del desarrollo. Métodos ágiles Asimismo, se desaconseja encarecidamente a la dirección que imponga caprichosamente opciones tecnológicas al grupo de desarrollo, otorgando en su lugar a los desarrolladores la mayor libertad posible para elegir las mejores herramientas para el sistema y el proyecto.
Planificación preliminar del lanzamiento
El objetivo de la planificación inicial del lanzamiento es estimar aproximadamente qué funcionalidades se entregarán antes de la fecha límite (siempre que esta sea fija), o bien, elegir una fecha de entrega aproximada para un conjunto determinado de funcionalidades (si el alcance está definido). Esta información nos permite decidir si el proyecto generará suficiente retorno de la inversión como para, al menos, cubrir sus costes, y, por lo tanto, si debemos seguir adelante.
Las reuniones iniciales de planificación de lanzamiento rara vez duran más de un día, o dos medias jornadas si no se puede estar en una reunión todo el día. Primero, el cliente presenta las funcionalidades prioritarias que se deben entregar. Idealmente, los desarrolladores ya habrán elaborado estimaciones aproximadas del trabajo necesario para implementar cada una de esas funcionalidades.
Basándose en las estimaciones de los desarrolladores y las prioridades del cliente, el equipo elabora un plan de lanzamiento, asignando las funcionalidades, de forma aproximada, a las primeras iteraciones. Los desarrolladores pueden descubrir que las funcionalidades de baja prioridad presentan riesgos de diseño o arquitectura, y por lo tanto, pueden solicitar a los clientes que consideren asignarlas a iteraciones anteriores, con el fin de abordar dichos riesgos potenciales lo antes posible en el proyecto.
Resulta enormemente útil conocer la velocidad del equipo de desarrollo en una versión anterior. En ese caso, si el alcance es fijo, se divide la estimación total de todas las funcionalidades requeridas entre la velocidad del equipo para obtener el número aproximado de iteraciones necesarias para entregar la funcionalidad y, por lo tanto, la fecha límite. Si la fecha límite es fija (como suele ser habitual), se multiplica la velocidad por el número de iteraciones para tener una idea inicial de cuántas funcionalidades se pueden entregar. Si se desconoce la velocidad del equipo de desarrollo, este debe proporcionar una estimación, y el plan de lanzamiento debe ser menos preciso durante las primeras iteraciones, hasta que se pueda obtener una cifra de velocidad fiable.
Plan de lanzamiento preliminar
El plan de lanzamiento inicial rara vez satisface a todas las partes: o bien no se entrega la funcionalidad suficiente, o bien parece necesario demasiado tiempo para entregar la funcionalidad deseada. Pero en el mundo ágil, el equipo afronta estas duras realidades y desarrolla un plan de desarrollo de software en torno a ellas. Nadie cree en milagros que complazcan a todos. En lugar de practicar la negación colectiva, el equipo utiliza métricas reales y la negociación para tomar decisiones difíciles lo más cerca posible del inicio del proyecto.
Los líderes de pensamiento ágil coinciden en que, si bien es posible Para ajustar el alcance, el plazo, los recursos y la calidad de un proyecto, las únicas variables que responden bien a los ajustes son el plazo y el alcance. Numerosos estudios han demostrado que los equipos más grandes tienden a entregar sistemas de menor calidad con mayor lentitud, mientras que los equipos más pequeños tienden a entregar sistemas de mayor calidad con mayor rapidez. Si bien puede ser necesario añadir programadores a un equipo, es probable que esto lo ralentice, al menos temporalmente, en lugar de acelerarlo. Una vez que aceptamos estos hallazgos, asumimos que, en nuestra planificación de lanzamientos, debemos ajustar el alcance o el plazo para generar un plan de lanzamiento que sea viable para patrocinadores, clientes, desarrolladores, gerentes y demás partes interesadas. El hecho de que el equipo tome estas decisiones difíciles desde el principio reduce el riesgo general del proyecto. Además, aumenta las probabilidades de que el equipo entregue un conjunto de funcionalidades que justifique con creces la inversión de las partes interesadas antes de la fecha límite.
Planificación continua del lanzamiento
Se entiende que el plan de lanzamiento inicial es preliminar. Debe ser lo suficientemente detallado como para comenzar, prediciendo que el proyecto generará un retorno de la inversión suficiente para cubrirlo con creces. (Si el plan de lanzamiento inicial predice un retorno de la inversión demasiado bajo para justificar el proyecto, podemos cancelarlo antes de que se produzcan grandes pérdidas). En los proyectos ágiles, planificamos continuamente y ajustamos el rumbo sobre la marcha. Uno de los mecanismos principales para este ajuste es permitir que el plan de lanzamiento evolucione en respuesta a todo tipo de comentarios. Se necesitarán al menos un par de iteraciones para que el ritmo del equipo se estabilice. Las iteraciones a veces ofrecerán menos funcionalidad de la prevista, y otras veces más. Las características, las decisiones arquitectónicas, de diseño, de framework o de tecnología podrían resultar demasiado arriesgadas o simplemente inviables. La interfaz de usuario podría requerir revisiones. Podría haber bajas o altas de personal. Las prioridades de las características podrían cambiar. Todos estos factores nos ayudarán a revisar y refinar el plan de lanzamiento continuamente. Cuando se publique un nuevo plan de iteración, también deberá publicarse un plan de lanzamiento revisado que refleje la nueva realidad.
Inicio y cierre
Muchos equipos ágiles planean entregar solo una pequeña cantidad de funcionalidad en la primera iteración (a menudo llamada "iteración 0"), para así abordar explícitamente los problemas técnicos y logísticos iniciales, y quizás también para poner a prueba la arquitectura de principio a fin. Esto puede ser crucial para equipos con poca o ninguna experiencia en metodologías ágiles. Para un equipo sin una buena métrica de velocidad, esto podría significar que la velocidad solo se estabilice y sea fiable al final de la segunda o tercera iteración.
Algunos equipos programan hasta dos iteraciones al cierre del proyecto para la estabilización, la integración y las pruebas del sistema, la corrección de errores y la finalización de la documentación para el usuario. En un proyecto ágil ideal, esto no sería necesario, pero en la práctica depende de las prácticas ágiles específicas que siga el equipo, la estructura organizativa, la complejidad general del sistema, los entregables no relacionados con el código que se esperan del equipo, la complejidad del despliegue del sistema y otros factores similares.
Preguntas Frecuentes
¿Realmente necesito usar versiones y un plan de lanzamientos?
Algunos equipos pueden arreglárselas sin planificación ágil a nivel de lanzamiento. Por ejemplo, un proveedor de servicios de aplicaciones (ASP) puede simplemente implementar software en producción en cada iteración (es decir, cada pocas semanas), por lo que cada iteración se considera un lanzamiento y una planificación ágil simple por iteración puede ser suficiente. Si, por otro lado, la gerencia requiere cierto nivel de visibilidad del software gestión de la liberación Si se analiza el nivel de desarrollo (es decir, el progreso, el estado, los cambios con respecto al plan de desarrollo de software inicial, etc.), la planificación y la gestión a nivel de lanzamiento pueden resultar invaluables.
¿Qué tan grandes son los lanzamientos?
ReleaseSuelen tener una duración de entre dos y doce meses. Para lanzamientos más largos, puede ser conveniente dividirlos en varias sub-lanzamientos.
¿Cuántas iteraciones tiene una versión?
El número de iteraciones dentro de una versión suele estar determinado por el cronograma. Si una versión dura seis meses y las iteraciones son de dos semanas, entonces se deberían programar 13 iteraciones para dicha versión.
¿Quién participa en la planificación del lanzamiento?
Para equipos pequeños, puede ser conveniente que todo el equipo multidisciplinario participe, tanto para aportar ideas como para garantizar la rendición de cuentas. Para equipos y organizaciones más grandes, se puede seleccionar o elegir a un subconjunto del equipo para que lo represente.
¿Cuánto duran las reuniones de planificación de lanzamientos?
Release Las reuniones de planificación suelen durar entre cuatro y ocho horas.
¿Cuánto trabajo se realiza en la preparación de una reunión de planificación de lanzamiento?
Generalmente, se ha realizado bastante trabajo antes de una reunión de planificación de lanzamiento en términos de aprobación del proyecto, presupuesto, visión, identificación del equipo, etc. Con respecto a la funcionalidad, es probable que el cliente haya dedicado tiempo a trabajar con el equipo de desarrollo para identificar las características iniciales, así como posiblemente para desglosarlas y proporcionar estimaciones iniciales de alto nivel.
¿Cambia el plan de lanzamiento durante el lanzamiento?
A medida que se descubre más información, se implementan nuevas funcionalidades, se comprende mejor el sistema, evolucionan las necesidades del negocio y cambian las prioridades, la estructura general de la versión casi con seguridad cambiará. Si bien es algo previsto, la evolución de la gestión de versiones de software a lo largo del tiempo deberá comunicarse a todas las partes interesadas pertinentes.
