Ágil y Scrum

Las metodologías ágiles nacen como reacción a los procesos pesados de los años noventa, en los que se dedicaba más esfuerzo a documentar y contratar que a construir. Su apuesta es entregar software funcionando pronto y a menudo, y aceptar que los requisitos van a cambiar en vez de intentar congelarlos.

El Manifiesto Ágil declara cuatro preferencias y doce principios. Las preferencias no niegan el lado derecho de cada pareja: dicen que, cuando hay que elegir, pesa más el izquierdo.

• Satisfacer al cliente con entregas continuas y tempranas de software que funcione.
• Aceptar los requisitos cambiantes, incluso avanzado el proyecto, porque son una ventaja competitiva para el cliente.
• Entregar con frecuencia, en periodos cortos que se cuentan en semanas y no en meses.
• Que el negocio y el equipo de desarrollo trabajen juntos a diario durante todo el proyecto.
• Construir los proyectos con individuos motivados, dándoles el entorno y el apoyo que necesitan y confiando en ellos.
• Conversar cara a cara como forma más eficaz de transmitir información dentro del equipo.
• Medir el progreso por el software que funciona, no por el porcentaje de documento redactado.
• Mantener un ritmo sostenible que el equipo pueda aguantar de forma indefinida.
• Cuidar la excelencia técnica y el buen diseño, porque son lo que permite seguir siendo ágil.
• Buscar la simplicidad, entendida como el arte de maximizar el trabajo que no se hace.
• Confiar en equipos autoorganizados para que salgan de ahí las mejores arquitecturas y diseños.
• Reflexionar a intervalos regulares sobre cómo ser más eficaces y ajustar el comportamiento en consecuencia.

Son doce principios y cuatro valores. El número más preguntado es el doce, y el principio que más cae es el primero: satisfacer al cliente con entregas continuas y tempranas.

Bajo el paraguas ágil conviven varios métodos concretos: Scrum, que es el más extendido; Kanban, que gestiona el flujo de trabajo; XP o Extreme Programming, centrado en las prácticas de programación; y FDD (Feature Driven Development), que organiza el trabajo por funcionalidades pequeñas y visibles para el cliente, cada una entregable en un plazo corto.

Scrum es un marco de trabajo iterativo e incremental. El proyecto se corta en ciclos de duración fija llamados sprints, y al final de cada uno tiene que haber un incremento del producto terminado y utilizable. Es incremental porque cada sprint suma funcionalidad, e iterativo porque lo ya entregado se puede revisar y mejorar en sprints posteriores.

Se apoya en la inteligencia colectiva del equipo, que se organiza a sí mismo en vez de recibir tareas asignadas por un jefe, y en el pensamiento Lean, que consiste en eliminar todo lo que no aporte valor al producto. Es un marco deliberadamente ligero: define pocos roles, pocos artefactos y pocas reuniones, y todo lo demás lo decide el equipo.

El Product Owner decide QUÉ se hace y en qué orden; el equipo decide CÓMO se hace; el Scrum Master no decide ninguna de las dos cosas, se asegura de que el marco funcione.

Esos tres son los roles principales o comprometidos, los que están dentro del equipo. Aparte quedan los roles secundarios, que a veces se llaman implicados o stakeholders: usuarios, clientes, gestores y cualquier interesado externo o interno que se ve afectado por el producto. No participan en el día a día, pero sí acuden a la revisión del sprint a ver el resultado y dar su opinión.

Los artefactos son los productos con los que el equipo trabaja y que hacen visible el estado del proyecto para cualquiera que mire. Son tres, y cada uno lleva asociado un compromiso que le da sentido.

• Product Goal: el objetivo a largo plazo del producto, el compromiso asociado al Product Backlog.
• Sprint Goal: el objetivo único del sprint, el compromiso asociado al Sprint Backlog.
• Definition of Done: la definición de terminado, la lista de condiciones que algo debe cumplir para considerarse acabado. Es el compromiso asociado al incremento y es la que evita que «terminado» signifique una cosa distinta para cada persona.

La Definition of Done es común a todo el equipo y no se negocia sprint a sprint. Sin ella, un incremento «terminado» podría estar sin probar o sin documentar, y la deuda se acumularía en silencio.

El sprint es el contenedor de todo lo demás: un periodo de tiempo fijo, normalmente de una a cuatro semanas, durante el cual el equipo trabaja para completar el Sprint Backlog. Su duración no cambia a mitad de camino, y en cuanto termina uno empieza el siguiente sin huecos. Dentro del sprint ocurren cuatro reuniones más.

La diferencia que más se pregunta: la Review mira el PRODUCTO y en ella participan los interesados; la Retrospective mira el PROCESO del equipo y es interna. Van seguidas y por ese orden.

El Daily Scrum no es una reunión de reporte a un jefe: es del equipo y para el equipo, dura como mucho un cuarto de hora y suele hacerse de pie para que nadie se acomode. Si aparece un problema que necesita discusión larga, se anota y se trata aparte con los implicados.

El burn down chart es la gráfica con la que se sigue el avance. En el eje horizontal va el tiempo y en el vertical el trabajo que queda pendiente, medido en puntos de historia o en horas. La línea baja según se va terminando trabajo, y por eso «burn down», quemar hacia abajo.

Su valor está en la comparación con la línea ideal, la recta que llegaría a cero justo el último día. Si la línea real va por encima, el equipo se ha comprometido a más de lo que puede o han aparecido imprevistos; si va por debajo, sobra capacidad. Lo interesante es que ese aviso llega a mitad del sprint, cuando todavía se puede reaccionar, y no el último día.

El burn down mide lo que FALTA, así que su tendencia es descendente. Su hermano, el burn up, mide lo que se lleva hecho y sube. Confundir el sentido de la gráfica es el fallo típico.