Aunque Scrum es una metodología con mas de 10 años de vida, es la de mayor aceptación entre los seguidores de las metodologías ágiles, aún parece algo desconocida en la industria informática (especialmente en las compañías mas "maduras"), y es por eso que quiero compartir un breve resumen de lo que hasta hoy conozco del tema.
Múltiples metodologías de desarrollo de software se han planteado a lo largo del tiempo, desde el modelo clásico o en cascada, en donde una tarea no puede comenzar hasta que su predecesora esté completamente finalizada, metodologías basadas en prototipos, modelos en espiral, hasta metodologías ágiles, basadas en desarrollo incremental e iterativo donde el software se va definiendo y construyendo siguiendo un proceso cíclico de entregas progresivas muy frecuentes, facilitando la adaptación al cambio de requerimientos.
Una de las metodologías ágiles que mejor se adoptan a los nuevos modelos de operación es Scrum, originado en 1995 por Jeff Sutherland y Ken Schwaber mediante un artículo presentado en la OOPSLA’95 describiendo el proceso en general, con posteriores refinamientos hasta su concepción formal.
Esta metodología proviene de la teoría de sistemas adaptativos complejos y nace influenciada por las buenas prácticas de optimización de esfuerzo de la industria Japonesa (seguidas especialmente por compañías automotrices como Toyota y Honda) y las estrategias de administración del conocimiento desarrolladas por Hirotaka Takeuchi e Ikujiro Nonaka.
Se le ha dado el nombre “Scrum” por analogía con el deporte del rugby, en donde un equipo auto gestionado avanza hacia la meta como una sola unidad.
Scrum estructura el desarrollo en ciclos de trabajo llamados sprints, de entre 1 y 4 semanas de duración fija. No es posible extender un Sprint si el objetivo no se ha completado.
Al comienzo de cada sprint, durante la reunión de planificación del sprint (sprint planning meeting) el equipo selecciona un número determinado de la lista completa de requerimientos previamente priorizada. Este subconjunto de requerimientos deberá estar terminado al finalizar el sprint y durante éste, la lista no podrá ser modificada.
Diariamente el equipo se reúne por un muy breve período de tiempo, nunca más de 15 minutos, para reportar avances del día, planes para el siguiente día y problemas importantes que requieran atención especial (siempre por fuera de ésta reunión diaria).
Uno de los resultados más relevantes de la reunión diaria es la actualización del reporte de tareas/esfuerzo restante, como medida de avance del proyecto en general y mecanismo de motivación dentro del equipo:
Una vez el sprint ha finalizado, se convoca otra reunión con el cliente para verificar la cantidad de producto ejecutable que se ha incrementado durante el ciclo. Deberá basarse en demostraciones sobre el producto, más que en reportes.
Las tareas del sprint se consideran completas sólo si las pruebas han sido ejecutadas.
Aquellas tareas del sprint (spring backlog) que no fueron completadas, retornan a la lista original de requerimientos (product backlog) como candidatas para el siguiente Sprint.
El proceso completo puede visualizarse gráficamente de la siguiente manera:
Para terminar, quiero compartir este video con una excelente explicación de todo el proceso:
