Soy consciente de que la duración de un Scrum Sprint puede variar según el caso. Esto plantea las siguientes preguntas:
Enfoque típico
Scrum según el libro asume que usted lanza al final de la iteración, luego hace una demostración del producto a un cliente. "Lanzamiento" y "demostración", por supuesto, pueden significar cosas diferentes según el producto que cree, por ejemplo, una aplicación administrativa para una gran corporación frente a una aplicación dirigida directamente a los usuarios finales.
La mayoría de los equipos de Scrum intentan lanzar al final de la caja de tiempo, ya que les da más libertad en términos de cómo se realiza el trabajo dentro de la iteración, por ejemplo, pueden comenzar todo al comienzo de un sprint y terminar las historias solo cuando se acerca el final del sprint.
Lanzamientos frecuentes
Sin embargo, si desea publicar con más frecuencia, lo que personalmente recomendaría, siéntase libre de hacerlo, sin importar cuál sea la práctica típica o lo que digan los libros. Scrum, como cualquier otro método, no es una religión y no debe ser tratado como dogmático.
Es posible que desee introducir lanzamientos (más) frecuentes ya que:
Por cierto, existen métodos que desacoplan los ciclos de planificación, publicación y retrospectiva. En este caso estamos hablando de la cadencia. La cadencia de planificación no tiene que ser la misma que la cadencia de lanzamiento o la cadencia retro. Es solo Scrum lo que los hizo así. Lea más sobre cadencia versus iteración aquí .
En general, el cambio a lanzamientos frecuentes afecta al equipo, ya que las herramientas que usa generalmente tienen que evolucionar. Puede pasar un par de horas para lanzar un producto si lo hace cada dos semanas. Si lo haces todos los días, no puedes. Lo bueno es que puede hacer que esta transición sea evolutiva, acortando el ciclo de liberación paso a paso, por ejemplo, de quincenal a semanal, buscando puntos débiles y abordándolos.
Scrum originalmente no tenía nada relacionado con los lanzamientos, pero afortunadamente se ha cambiado y hay algo llamado Planificación de lanzamientos . Durante esta reunión, el equipo Scrum y el propietario del producto se sientan juntos y ven cuándo se puede lanzar el producto. Es una reunión de planificación de alto nivel.
En realidad, los lanzamientos los establecen los proyectos y las partes interesadas. El Equipo Scrum y el Dueño del Producto deben usar esta reunión para brindar retroalimentación periódica a las partes interesadas sobre el lanzamiento. Esta retroalimentación debe contener información sobre los riesgos, alcance (contenido) y posibles impedimentos.
La frecuencia de esta reunión depende de la duración de los Sprints y la duración del proyecto original. No logré encontrar ningún dato sobre la frecuencia, pero diría que tengo al menos 3 reuniones durante un proyecto, distribuidas equitativamente en la duración del proyecto.
Este fue el caso cuando el lanzamiento se envió al equipo. Si el equipo puede decidir sobre los lanzamientos, me referiré a la idea original de Scrum de que el resultado de un Sprint debe ser algo entregable , por lo tanto, el lanzamiento ocurre después de cada reunión de revisión de Sprint .
Los lanzamientos frecuentes en un contexto grande tienen una sobrecarga enorme, pero los comentarios recibidos de los clientes/usuarios/partes interesadas son muy valiosos. Es por eso que los equipos deben hacer Agile: recibir comentarios frecuentes sobre su trabajo para verificar que están en el camino correcto, y sin lanzamientos frecuentes es casi imposible.
Creo que tan pronto como esté listo un paquete liberable, puede ser lanzado. Es por eso que escribí sobre por qué los sprints deben tener un límite de tiempo y las correcciones y los lanzamientos pueden ocurrir siempre que esté listo un paquete liberable. Puede desacoplar el proceso de sprint del proceso de lanzamiento:
Gracias por el CI avanzado y el proceso de entrega continua, podemos lanzar incluso varias veces al día... El proceso de lanzamiento en la mayoría de los lugares puede ser casi independiente al completar el sprint.
— Extraído de ¿Por qué los sprints en caja de tiempo? ¿Qué sucede con los lanzamientos?
La frecuencia de los lanzamientos en un Sprint no está definida por definición y esto podría variar según la necesidad del Proyecto según la definición del alcance de un lanzamiento por parte del Propietario del producto. Aunque la mayoría de los equipos prefieren hacer el lanzamiento al final de la iteración.
Otro aspecto importante de un lanzamiento es la Velocidad del equipo. Este término no se menciona en ninguna de las respuestas. La velocidad es el promedio del número total de puntos de historia Puntos de historia completados por el equipo Scrum. El mismo se calcula en base a los siguientes puntos:
El rol de Product Owner incluye, mantener un Backlog bien priorizado y definido . Estas Historias del Backlog de alta prioridad también deben tener Puntos de Historia. En función de algunos de los puntos de la historia que el propietario del producto desea completar e incluir en un lanzamiento y la velocidad del equipo, se puede calcular la cantidad de Sprints necesarios para realizar un lanzamiento.
Número de Sprint necesarios para un lanzamiento = Número total de puntos de historia a completar / Velocidad del equipo
Esto sería útil para obtener una fecha de lanzamiento. Por lo tanto, un propietario del producto tiene la opción de cambiar la fecha de lanzamiento o el alcance del lanzamiento en función de la velocidad del equipo. Esto podría resultar en un lanzamiento después de 5 Sprints de más de 5 lanzamientos en el Sprint.
Scrum se trata de boxear el tiempo. La entrega continua se trata de lanzamientos continuos y (hasta cierto punto) integración e implementación continuas automatizadas. No son completamente ortogonales, pero tampoco son sinónimos.
Si está practicando Scrum "real", entonces un lanzamiento debe coincidir con un incremento entregable al final de una caja de tiempo. Sin embargo, he visto ejemplos del mundo real en los que el "envío" era una historia dentro de un Sprint, donde la historia de envío se rastrea como trabajo y tiene historias de usuarios que continúan más allá de la historia de envío en Sprint Backlog. Si eso se ajusta a su flujo de trabajo, entonces ciertamente es algo a considerar.
Alternativamente, cualquier Sprint puede ser cancelado por el propietario del producto, por lo que incluso dentro del marco tradicional de Scrum, existe una metodología para el envío anticipado. La idea es que el Product Owner pueda terminar el Sprint en cualquier momento y devolver el equipo a Sprint Planning. Esto genera una sobrecarga de proceso, pero puede muy bien estar justificado en algunos casos.
Una terminación anticipada de Sprint no es automáticamente algo negativo; es simplemente una herramienta de administración que intercambia parte del tiempo del ciclo y la sobrecarga del proceso para responder a los cambiantes requisitos comerciales. Si el Sprint Goal para un Sprint dado es "enviar el producto", entonces la terminación anticipada del Sprint después de un envío exitoso del producto es la esencia misma de Agile, ya que el proyecto no avanza e incurre en costos que no son necesarios para la organización una vez alcanzados sus objetivos.
La liberación ocurre en dos niveles: para la parte interesada interna; al cliente externo. En lo que respecta al equipo de scrum, se realiza una vez que se codifica, se diseña, se prueba, se implementa en Pre-Prod o Prod, se corrigen los errores y se recibe la aceptación del usuario. Esto se llama característica mínimamente comercializable. El cliente puede elegir su propio tiempo para implementar en el servidor en vivo.
MCW
hoss