sábado, 14 de enero de 2017

¿Cómo imprimen los sprints flujo en la construcción de un producto?

Ciclo de eventos del sprint
El evento principal de Scrum es el sprint, un evento iterativo contenedor de los demás: la reunión de planificación de sprint, la reunión diaria, la revisión de sprint y la retrospectiva.

El sprint es timeboxed, de duración fija de entre 1 y 4 semanas, duración que se establece al principio por el equipo o la organización. Su objetivo es marcar cadencia, un ritmo de avance en el que con cada final de sprint se produzca la entrega de un incremento terminado y potencialmente instalable en producción. Los equipos ágiles son como motores, cada uno con su propia velocidad, y los sprints son las pistonadas del mismo, pistonadas con entrega incremental de producto de forma sostenida.

Flujo de Scrum por Raúl Herranz
Uno de los beneficios de la cadencia es la reducción de la variabilidad, con los sprints relativamente cortos estamos provocando tamaños de historias de usuario pequeños limitados por el tamaño del sprint, de forma que con elementos pequeños imprimimos un flujo estable a la construcción del software.

El sprint también marca un ritmo fijo para comprobar el avance y visibilidad del producto a través de la planificación de sprint y la revisión de sprint. En la planificación de sprint ocurre el corte de la pila que hace el equipo, corte que apoyado por las medidas de velocidad de sprints anteriores, implica un límite del trabajo en curso (WIP) intrinseco, con el que se ajusta el trabajo a la capacidad, lo que significa ir a favor del flujo.

A la vez imprime ritmo a puntos de reflexión y mejora al modo de trabajo a través de las retrospectivas. En estas buscamos mejoras que irán a favor del flujo, tanto para resolver impedimentos como para acelerarlo.

Ocurren ocasiones en las que el equipo se atrasa o se adelanta, casos en los que dado el timeboxing no nos permite modificar la duración de sprint, se hace el ajsute en el alcance del sprint. Podemos incluir alguna historia a medio sprint o no construir historias de menor valor de negocio. Ambos ajustes son decisión del equipo que apoyándose en el Propietario del Producto deciden sobre las historias de usuario afectadas.

No hay comentarios:

Publicar un comentario