¿Cuáles son los beneficios de tener sprints de longitud fija para Agile?

La idea detrás del sprint de duración fija es proporcionar un entendimiento entre el desarrollo y el cliente (o PO) cuando algo nuevo (y en funcionamiento) estará disponible, y definir la duración del ciclo de retroalimentación, que es igual a la duración de la pique.

En otras palabras, el cliente sabrá que obtendrá algo en 2 semanas, que funciona, y el equipo de desarrollo sabrá que recibirá comentarios sobre su trabajo y sabrá más sobre el próximo trabajo en dos semanas. Eso es previsibilidad .

Volvamos a la parte de la retroalimentación. La duración del sprint te ayuda a encontrar el equilibrio adecuado en el trabajo. Realmente no puede tomar más trabajo del que puede hacer en dos semanas, por lo que una duración acordada puede aliviar al equipo de desarrollo de una presión innecesaria .

Si su conjunto de características toma tres semanas, entonces debe encontrar la manera de dividirlo en tareas más pequeñas o historias de usuarios. La idea detrás de Scrum es acortar el tiempo de retroalimentación . Si dedica tres semanas a una historia de usuario, recibirá comentarios como mínimo en tres semanas. Si logra dividirlo en tres historias de usuarios de una semana de duración, los primeros comentarios llegarán en una semana, lo cual es extremadamente bueno.

¿Por qué no simplemente establecer sus objetivos para la iteración y terminarlos en el tiempo que toma en lugar de tener una iteración fija que se pierde por terminar demasiado pronto o demasiado tarde?

Realmente depende de la forma de trabajar que estés siguiendo. Digamos que está trabajando solo, y al próximo equipo o grupo que recibirá su código no le importa cuándo llegue, entonces puede cambiar a un modelo continuo como Lean (o Kanban). Si quieren recibir su trabajo cada dos semanas, entonces no tiene otra opción para entregar en un ciclo de dos semanas (a menos que pueda convencerlos de cambiar a un modelo continuo).

Antes de elegir un modelo, verifique todo el sistema (desde el cliente hasta el cliente) y elija un modelo que brinde los siguientes beneficios: calidad, velocidad, confiabilidad y previsibilidad .

Lo último: ceñirse al modelo . Si está haciendo (o tiene que seguir) un scrum, cambiar dinámicamente la duración del sprint está fuera de discusión, porque sin un sprint de tamaño fijo simplemente no funcionará, porque perderá la velocidad, la confiabilidad y la previsibilidad.

Cuando tomé una clase de scrum, el instructor mostró un gráfico similar a este.

Este es un gráfico de la cantidad de esfuerzo ejercido por los desarrolladores en un proyecto clásico en cascada frente a la cantidad de esfuerzo ejercido por los desarrolladores en un proyecto basado en scrum/sprint. La idea es que al crear muchos plazos pequeños, aumenta el esfuerzo ejercido en el proyecto para cada plazo de sprint en lugar de esperar hasta el final del proyecto cuando las personas comienzan a darse cuenta de que se acerca EL plazo y comienzan a trabajar horas locas durante semanas. de punta.

Sus estimaciones siempre van a estar por encima o por debajo de alguna cantidad. La programación es algo en lo que las personas pueden mejorar con el tiempo. Como cualquier otra cosa, algunas personas siempre serán mejores que otras. Pero haz tu mejor esfuerzo para llegar a buenas estimaciones.

Una de las razones por las que no desea ir a menos de 2 semanas es que los gastos generales del proceso (retrospectivas, demostraciones, aprobaciones, etc. si está haciendo esas cosas) comienzan a entrometerse. En un caso extremo, podría tener 52 sprints por año frente a 26.

Desea evitar pasar más de 2 semanas porque cuando comienza a programar cosas más grandes, aumenta la cantidad de errores de programación. Si ya está lidiando con algún error de programación, eso solo empeorará.

Completamente de acuerdo con Zsolt en esto. Aquí hay una buena cita de Scrum and XP from the Trenches [edición gratuita] de Henrik Kniberg que reitera la importancia de la previsibilidad en la duración del sprint:

Una vez que haya decidido qué largo le gusta más, manténgalo durante un período prolongado de tiempo. Después de unos meses de experimentación, descubrimos que 3 semanas era bueno. Así que hacemos sprints de 3 semanas, punto. A veces se sentirá un poco demasiado largo, a veces un poco demasiado corto. Pero al mantener la misma duración, esto se convierte en un latido corporativo en el que todos se acomodan cómodamente. No hay discusión sobre las fechas de lanzamiento y demás porque todos saben que cada 3 semanas hay un lanzamiento, punto.

El libro también tiene excelentes consejos sobre cómo evaluar cuántos puntos de la historia es probable que sea capaz de completar dentro de su sprint. Esto lo ayudará a evitar la situación en la que promete algo que no se puede entregar en su sprint. Al comprender su velocidad (que llevará tiempo porque necesita mirar datos anteriores), encontrará que su planificación de sprint se vuelve más precisa.

No necesitas ninguno si estás desarrollando solo. Los sprints de duración fija son para garantizar una retroalimentación rápida y continua entre los propietarios de productos y los desarrolladores, así como una comunicación continua entre los desarrolladores en forma de retrospectivas de sprints. También ayuda a garantizar que las historias de los usuarios (requisitos, elementos de la cartera de productos, lo que sea) se dividan en partes lo suficientemente pequeñas. La mayoría de los lugares en los que he sido testigo que no se mantuvieron firmes y rápidos en sus longitudes de sprint las aumentaron lentamente con el tiempo, hasta que básicamente volvieron a ser una cascada semi-ágil.

Consulte scrum.org para obtener más información.