Tengo un argumento en curso: nuestro gerente de entrega intentó introducir un patrón de "lanzamiento después de 3 sprints" en nuestros equipos. Desafortunadamente, como muchas empresas, el trabajo real puede ser x número de sprints, a menudo más de 3.
Argumento, solo porque el alcance se fija por adelantado, ese es solo nuestro Departamento de Defensa. Liberamos a Live cuando completamos el alcance y hemos terminado. No hay nada que rompa los principios ágiles: solo reconocemos que aunque en teoría podríamos lanzar para vivir al final de un sprint dado, en realidad nunca lo haríamos hasta que hayamos terminado y luego tengamos un verdadero candidato de lanzamiento.
Él argumenta que ágil solo puede ser ágil si trabaja un sprint a la vez y tiene un candidato de lanzamiento cada sprint.
¿Qué versión es la correcta, o ambos tenemos razón o no?
En cualquier marco ágil, si desea realizar una estimación basada en un alcance fijo, las fechas de lanzamiento estimadas variarán. Si opta por una fecha de lanzamiento fija o una cadencia de lanzamiento de rutina, entonces es el alcance el que varía. Ambas son opciones legítimas, pero en este caso tu gestor de envíos tiene más razón que tú.
Su gerente de entrega tiene razón en su mayoría . Ya sea que esté siguiendo Scrum o algún otro marco que simplemente use el término "Sprint", una iteración ágil siempre debe dar como resultado un producto potencialmente liberable. Scrum, en particular, deja muy claro que cada incremento debe ser liberable :
Al final de un Sprint, el nuevo Incremento debe estar "Terminado", lo que significa que debe estar en condiciones de uso y cumplir con la definición de "Terminado" del Equipo Scrum... El incremento debe estar en condiciones de uso independientemente de si el Dueño del Producto decide liberarlo.
Si bien la mayoría de los marcos ágiles no definen una cadencia de lanzamiento fija, tampoco la prohíben. Dado que cada Sprint da como resultado un incremento potencialmente entregable, no hay razón para no apuntar a una cadencia de lanzamiento de tres meses para el proyecto si eso agrega valor comercial.
Es más tradicional ver una planificación de lanzamiento ágil estimando una fecha de lanzamiento en función de cuántas iteraciones probablemente se necesitarán para completar un conjunto determinado de funciones. Sin embargo, el flujo Lean, la cultura DevOps y un cambio de la industria hacia la entrega continua y la implementación continua han dado como resultado que algunos proyectos avancen hacia una cadencia de lanzamiento de rutina como la que desea su gerente de entrega.
Como ejemplo, Ubuntu tiene una cadencia de lanzamiento bienal para los lanzamientos de soporte a largo plazo y una cadencia de seis meses para los lanzamientos intermedios. Por el contrario, el ciclo de lanzamiento de Debian sigue un modelo más tradicional que no está intrínsecamente limitado en el tiempo.
Una cadencia confiable es generalmente algo bueno en un marco de gestión de proyectos. Sin embargo, una cadencia de entrega iterativa y una cadencia de lanzamiento de producto son en realidad dos cosas diferentes. Si los lanzamientos deben seguir una cadencia o no, es una decisión comercial específica del producto, y no hay una respuesta "única para todos" a esa pregunta.
Los lanzamientos son un aspecto muy importante de Agile. Hay muchas razones para su importancia, incluyendo:
Esta es la razón por la cual los marcos Agile como Scrum enfatizan la necesidad de tener un incremento potencialmente entregable al final de cada sprint.
Puede ser tentador decir que no desea lanzar el producto hasta que el trabajo de desarrollo terminado tenga muchas funciones y esté "completo" desde el punto de vista de la comercialización del producto. Sin embargo, esto pierde dos de los tres puntos mencionados anteriormente. Si espera hasta que el producto tenga muchas funciones antes de lanzarlo, retrasará el colapso de la incertidumbre del lanzamiento y dejará que sus desarrolladores adopten la mentalidad de retrasar el trabajo que solo es importante para un lanzamiento.
Vale la pena señalar que muchas organizaciones ágiles publicarán con frecuencia, pero no pondrán sus cambios a disposición de los usuarios de inmediato. Por ejemplo, algunos equipos usan alternancias de funciones . Esto ofrece lo mejor de ambos mundos, obtiene el valor de los lanzamientos frecuentes, pero también puede permitir que su personal comercial y de marketing controle cómo y cuándo las funciones estarán disponibles para los usuarios.
Todd A. Jacobs