En Scaled Agile Framework de Dean Leffingwell existe el concepto de una iteración de endurecimiento EG después de tres sprints de dos semanas de duración, tenemos un sprint de endurecimiento de una semana.
En este breve sprint podemos pagar parte de la deuda técnica acumulada en los sprints anteriores, garantizar que se lleven a cabo pruebas de integración más rigurosas y que se revise la calidad de los procedimientos de instalación y desmontaje. El tiempo también se puede tener en cuenta para cualquier requisito de entrenamiento que se haya descubierto durante los tres sprints anteriores.
Es cierto que si tenemos un DOD maduro en la entrega de un elemento de trabajo de sprint, debería haber un nivel de calidad decente, pero apegarse al principio de que entregamos solo lo que se requiere para satisfacer los criterios de cada historia eventualmente conducirá a una duplicación conocida en la base del código. Los buenos desarrolladores, naturalmente, querrán mejorar su base de código, por lo que tener un sprint de fortalecimiento garantizará que puedan concentrarse en mover WIP en los sprints principales, pero abordar periódicamente refactorizaciones más amplias.
Hace poco asistí a una conferencia en la que Rachel Davies de Unruly Software explicó que sus desarrolladores de XP tienen todos los viernes como Golden Time , donde tienen la libertad de refactorizar la base de código y aprender nuevas tecnologías. Eso funciona en un día en 5 en lugar de un día en siete al tener sprints de 3*2 semanas más un sprint de endurecimiento.
Creo que este es un buen enfoque para pagar la deuda técnica de manera administrada. La deuda técnica será más costosa de pagar cuanto más tiempo continúe el proyecto, de la misma manera que una historia se vuelve más costosa de cambiar una vez que la hayamos entregado.
Sé que la idea de un sprint de endurecimiento es anatema para los puristas ágiles, pero creo que funciona bien en nuestro enfoque pragmático de scrumban.
Creo que el problema es similar al de la validez de tener un Sprint Zero que altera algunas plumas.
Entonces, la pregunta es:
¿Es una buena idea un Hardening Sprint ? Si no, ¿por qué y cómo se abordarían las preocupaciones descritas anteriormente?
En mi trabajo anterior, realizamos un sprint de fortalecimiento de una semana antes de implementar el contenido de 2 o 3 sprints de dos semanas en un sitio web de producción. En ese momento estábamos haciendo pruebas de regresión manual. No se realizaron suficientes pruebas de regresión dentro del sprint para asegurarse de que se pueda enviar. Entonces, durante el sprint de endurecimiento, todo lo que hicimos fue una prueba de regresión. Si se encuentran errores, los corregiremos y los verificaremos.
Finalmente, contratamos a un miembro del equipo con habilidades de automatización de pruebas y construimos un conjunto de pruebas de regresión. También usamos algunas de estas pruebas para ejecutar pruebas de carga y estrés. Luego eliminamos el sprint de endurecimiento.
Si está refactorizando el código durante el sprint de endurecimiento, diría que es una señal de alerta o, para usar su propio término, ¡una "brebaje de brujas"! Está creando más posibilidades de problemas de regresión.
Por lo tanto, es posible que necesite un sprint de endurecimiento cuando esté sobre ruedas de entrenamiento. Una vez que sus prácticas de ingeniería mejoren para asegurar un incremento entregable en cada sprint, puede dejarlo.
Que sea una buena o mala idea depende de cómo gestione los riesgos relacionados con ella.
Por lo que he experimentado, los riesgos son:
Otra cosa a tener en cuenta es que alguien tiene que administrar los elementos pendientes relacionados con la refactorización. Más elementos en la cartera de pedidos significa más tiempo dedicado a debatir si este refactor es más importante que el otro.
Un sprint de endurecimiento es una herramienta. Si utiliza la herramienta correctamente, es una buena idea. Si usa la herramienta sin conocer el problema que está tratando de resolver, puede que sea una buena idea o no.
Esa es una respuesta vaga, así que en la práctica:
Si tiene un equipo que no está listo para construir continuamente calidad en su producto (es decir, han acumulado una tonelada de deuda tecnológica o el negocio no permite suficiente holgura para priorizar la deuda tecnológica, el aprendizaje y la CI en las iteraciones regulares), entonces un sprint de endurecimiento es una buena herramienta para abordar el problema tangible de que la calidad del producto está sufriendo o que el equipo de entrega no tiene suficiente tiempo para aprender y mejorar.
Yo diría que es ideal apuntar a equipos que brinden alta calidad y tengan tiempo para CI en cada iteración (si está en un mundo Scrum) o continuamente (si está en un mundo Kanban). Diría que los sprints de endurecimiento son una solución intermedia para llegar a un modelo de desarrollo sostenible. También son excelentes para aclarar los problemas de calidad, ya que tener un sprint de endurecimiento durante algunas semanas puede ser una píldora costosa para la gerencia y el equipo cuando tienen 1-4 semanas sin valor comercial entregado.
La desventaja del sprint de endurecimiento es que las actividades del sprint de endurecimiento suelen ser más eficientes y/o efectivas para abordarlas justo cuando ocurre el problema. Hay un costo de aumento asociado con el endurecimiento de las iteraciones que es menor si la calidad/CI se integran en cada iteración o elemento de trabajo.
nathan cooper
Daniel