Acabo de unirme y convertirme en el Scrum Master de un equipo en una empresa. Entré en los últimos tres días de uno de sus muchos sprints. En el último día del Sprint, lanzaron el incremento. Esto tomó alrededor de cinco o seis horas, encontrándose con problemas con la red, terceros, etc. para que fuera un proceso largo.
Mi pregunta es, ¿quién realiza el lanzamiento? ¿Cómo se estima esto normalmente? ¿Hay una tarea separada para ello? ¿Qué sucede si va tan lento que se superpone con el siguiente Sprint?
¡Gracias a todos!
¿Quién realiza el lanzamiento?
Normalmente, el ingeniero de lanzamiento. De lo contrario, dependería de las competencias necesarias para realizar la liberación. Descubrirá que el ingeniero de control de calidad podría hacerlo, o tal vez un desarrollador, un líder técnico...
¿Cómo se estima esto normalmente?
En mi opinión, no tienes que estimarlo. Debido a que esta es una tarea recurrente en cada sprint, con aproximadamente el mismo tipo de problemas a lo largo de los diferentes sprints, ya está incluida en tu velocidad de sprint.
¿Hay una tarea separada para ello?
Esta es una tarea separada para el hacedor, pero como es repetitiva, no es necesario incluirla en el trabajo pendiente del sprint.
¿Qué sucede si va tan lento que se superpone con el siguiente Sprint?
Lo mismo que llegará si una Historia de Usuario está mal estimada. Hablaría sobre los problemas en la retrospectiva y encontraría juntos las posibles soluciones para ellos para la próxima vez.
Por lo general, un equipo se organiza para determinar quién debe hacer el lanzamiento. En algunos equipos hay miembros del equipo que se especializan en lanzamientos. Otros equipos comparten la responsabilidad alrededor.
Por lo general, no esperaría que un equipo calcule por separado un lanzamiento. Esto se debe a que en Scrum la definición de hecho a menudo incluye el lanzamiento. Lo que significa que el tiempo necesario para el lanzamiento debe tenerse en cuenta en las estimaciones de las historias individuales.
Es bastante común tener una tarea que rastrea el lanzamiento. Sin embargo, esto depende mucho del esfuerzo requerido para hacer el lanzamiento. Algunos equipos tienen un mecanismo de lanzamiento muy ingenioso y, por lo tanto, no sienten la necesidad de realizar un seguimiento de los lanzamientos como tareas separadas.
Como correctamente señala, existe el riesgo de que el lanzamiento se retrase por algún motivo. Cuando esto sucede, puede ser muy disruptivo, tanto para la planificación del próximo sprint como para el negocio en general. Una vez más, si la definición de hecho para las historias incluye el lanzamiento, no hacerlo dentro del sprint debería afectar la velocidad del equipo.
He visto muchos enfoques para la estrategia de lanzamiento. Algunos equipos sueltan el último día del sprint. Otros equipos lanzan uno o dos días antes del final del sprint. Tampoco es raro que un equipo tenga un lanzamiento escalonado para que el trabajo de cada sprint se publique en el sprint siguiente.
Lo que esto destaca es la importancia de un mecanismo de liberación rápido y simple. La automatización de los lanzamientos puede ser muy beneficiosa para un equipo. Esto se debe a que reduce el tiempo que el equipo dedica a la liberación y reduce el riesgo de interrupción debido a problemas de liberación.
Vale la pena considerar hacer un caso de negocios para automatizar sus lanzamientos. Por ejemplo, supongamos que al automatizar sus lanzamientos puede ahorrar de 5 a 6 horas de esfuerzo por sprint. Más de 10 sprints que ahorrarían entre 50 y 60 horas de esfuerzo y también reducirían significativamente el riesgo de interrupciones. Si el equipo invirtiera 40 horas de esfuerzo en automatizar el proceso de lanzamiento, se amortizaría en 10 sprints o menos.