Primera parte: Scrum

Los orígenes

Todo empezó en 2001, con la creación del Manifiesto ágil, cuando, en Estados Unidos, diecisiete especialistas en desarrollo de software se reunieron para poner fin a la "gestión de los años 30”, en la que el sistema de jerarquías y procesos excesivamente engorrosos estaba resultando ineficaz en la gestión de proyectos informáticos. De hecho, mucho antes de este Manifiesto, ya existían métodos ágiles, como Scrum y Extreme Programming (XP), que datan de los años 90. XP fue creado por Kent Beck y fueron Ken Schwaber y Jeff Sutherland quienes crearon Scrum en 1993 y lo presentaron oficialmente en una conferencia dos años después. Cuando Kent Beck creó XP en 1996, se inspiró en los métodos ágiles de los 90 y amplió un poco más los límites. Por ejemplo, todo lo que tenía que hacerse "a menudo” tenía que hacerse continuamente con XP: ahora las pruebas se realizaban continuamente, es decir, de forma sistemática, la integración se hacía continuamente, la verificación del código también se hacía continuamente, el despliegue se hacía continuamente y hoy hablamos de despliegue continuo. Mucho antes, en los años 50, las fábricas Toyota ya utilizaban el método ágil Lean. El gran mérito del Manifiesto...

Scrum

Scrum es un marco de trabajo ágil que permite producir proyectos con mayor frecuencia, produciendo algo presentable y funcional en cada sprint.

El cliente final participa en una fase muy temprana del proyecto, ya que puede evaluar al final de cada sprint lo que se ha conseguido.

Como veremos, Scrum se basa en conceptos muy sencillos. El proyecto se desarrolla en iteraciones llamadas sprints. Un sprint es simplemente un periodo de 1, 2, 3 o 4 semanas. Una vez elegida la duración del sprint, todos los sprints tendrán la misma duración, que no cambiará a lo largo del proyecto. Esto se conoce como iteración, porque los sprints se suceden continuamente a lo largo del tiempo. Cada sprint producirá una parte de la solución final del proyecto. De este modo, el producto a desarrollar se produce de forma incremental, sprint a sprint. El objetivo no es completarlo todo en una sola entrega y esperar meses o años para ver el resultado final, sino dividir el desarrollo en periodos cortos llamados sprints. Solo después de x sprints se finalizará el proyecto.

Planificamos lo que hay que hacer durante un sprint en la fase de Planificación del Sprint. Durante la misma, se plantea la cuestión de qué características deben desarrollarse durante el sprint en cuestión. Estas funcionalidades se clasifican en una especie de cesta llamada Product Backlog. El Product Backlog es un contenedor lleno de las características del producto que se va a desarrollar, aunque no las contiene todas; no es un Roadmap (Hoja de ruta) global que proporciona una visión a largo plazo de todo el trabajo que hay que hacer. El Product Backlog solo enumera las funcionalidades que deben desarrollarse en los dos o tres sprints siguientes. Para una visión más amplia, los gestores se basan obviamente en un Roadmap global, pero los equipos Scrum trabajan con el Backlog.

A medida que avanza el proyecto, es decir, a medida que avanza cada sprint, los líderes de cada equipo Scrum seleccionarán las nuevas características que deben desarrollarse a partir del Roadmap global y las introducirán en su propio Product Backlog.

Una vez iniciado el sprint, cada día del sprint celebramos una ceremonia de Daily Scrum para supervisar el progreso del trabajo a diario. Al final del sprint, el último día, hacemos una demostración...