Descripción de Scrum

Nacimiento de Scrum

En 1986 se empieza a esbozar Scrum. Los japonenses Hirotaka Takeuchi e Ikujiro Nonaka imaginan en esta época una manera de aumentar la velocidad de desarrollo de una aplicación, conservando al mismo tiempo una fuerte noción de flexibilidad. Para esto, imaginaron un equipo de competencias múltiples, que pudiera abordar el conjunto de tareas necesarias para la realización del producto, superponiendo los procesos. Su enfoque se basa en el concepto enunciado por el rugby de quince jugadores: un equipo unido que tiene como objetivo común hacer avanzar el balón hacia el campo contrario.

En 1991, DeGrace y Stahl retoman este concepto dándole un nombre: Scrum, este nuevo término hacía referencia a la melé, reforzando la idea de equipo que persigue un objetivo común.

El año 1995 se puede considerar como el año oficial de nacimiento de Scrum. En este año Ken Schwaber describe los fundamentos del método antes de publicarlos, junto con Mike Beedle en 2001, en su libro "Agile Software Development With Scrum".

Hubo que esperar al año 2011 para que Jeff Sutherland y Ken Schwaber, publicaran la primera versión de la "Scrum Guide", que es la referencia del método (su última versión, en el momento de escribir este libro, está fechada en noviembre del año 2017).

Pasados algunos años...

Scrum en pocas palabras

En 2017, los principios escritos del método Scrum ya tienen veinte años. Por lo tanto, no se trata de un "método nuevo" o de un efecto que esté de moda. En consecuencia, los principios que se presentan en este capítulo y de manera general, en el resto del libro, han sido ampliamente verificados.

Scrum se define como un marco de trabajo (framework) para el desarrollo, entrega y mantenimiento de productos complejos, que es al mismo tiempo ligero (es muy cierto: la "Scrum Guide" solo contiene 22 páginas en su versión española), sencillo de entender (sin ninguna duda podemos preguntarnos más sobre este punto) y difícil de dominar (la experiencia lo muestra muy a menudo).

Podemos posicionar fácilmente los conceptos principales que se explican en este capítulo en un esquema de conjunto muy resumido:

1. Los valores Scrum

En la versión de la "Scrum Guide" del año 2016, apareció la noción de "valores". Esto nos parece una excelente idea, porque, como hemos indicado en la introducción de este libro (y ya no se volverá a repetir), el primer factor esencial del éxito en la implantación de Scrum o de cualquier otro método ágil, es la postura adoptada por los miembros de la organización ágil.

Estos valores son cinco:

compromiso,
coraje,
enfoque,
apertura,
respeto.

El hecho de que el equipo los encarne y los sitúe en el centro de su modo de funcionamiento, es de alguna manera un requisito previo y el medio privilegiado para que los pilares Scrum, es decir transparencia, inspección y adaptación (de los que hablaremos más adelante), se conviertan en una realidad con todo su esplendor.

Por lo tanto, vale la pena pasar un poco de tiempo detallando lo que esperamos de estos conceptos, a los que no estamos forzosamente acostumbrados, a destacar en el marco de los métodos tradicionales de gestión de proyectos.

Compromiso

Veremos que en Scrum, se pedirá al equipo un comprimiso colectivo alrededor de un objectivo: por lo tanto, esperamos que cada uno de los miembros del equipo se comprometa personalmente, sea cual sea su función o posición. Esto es crucial para la motivación y el rendimiento del equipo.

Coraje

Para asegurar que se alcanzan los objetivos, algunas veces...

Ciclo de vida de Scrum

Como "vale más una imagen que mil palabras", hemos preferido presentar la siguiente figura que agrupa de manera visual los diferentes elementos del método, para ilustrar su ciclo de vida:

El ciclo de vida es el siguiente:

1. El Product Owner redacta las User Stories y las sitúa en el Product Backlog.

2. A continuación, el Product Owner prioriza estas User Stories y ordena el Product Backlog en consecuencia.

3. El equipo Scrum se junta en la reunión de planificación del Sprint, con el objetivo de establecer la lista de las User Stories que se tratarán durante el Sprint. Esto forma el Sprint Backlog y a continuación se descomponen en tareas por el equipo de desarrollo.

4. Entonces el Sprint puede comenzar con una iteración de 2, 3 o 4 semanas.

5. El equipo se reúne diariamente para realizar la Melé diaria.

6. Como consecuencia del Sprint, obtenemos un producto potencialmente entregable que forma parte de una demostración durante la revisión del Sprint.

7. El ciclo termina con la retrospectiva del Sprint.

Y a continuación, solo hay que repetir todo de nuevo.

Coste, plazo y perímetro

Ahora vamos a abordar un aspecto importante del método Scrum, que es la manera de gestionar las nociones de coste, plazo y perímetro.

En una gestión de proyecto clásica, solo se fija el perímetro. Los costes y los plazos son variables. En efecto, si una empresa desea desarrollar una aplicación para gestionar la relación con el cliente, el perímetro del proyecto está fijo pero los desconocidos son el tiempo de realización y los costes. Estos aspectos desconocidos influyen en el coste global del proyecto, porque no hay nada que indique que los costes y los plazos se respetarán (recuerde el efecto túnel).

En Scrum, ocurre lo totalmente opuesto. Los costes y los plazos se respetarán pero el perímetro puede variar. Aquí se trata de una noción algunas veces difícil de hacer entender por parte de la gestión (así como el cliente) y normalmente origina la siguiente reflexión:

"¿Puede que no llegue a tener todas las funcionalidades esperadas? ¿Cómo es posible? ¡La aplicación no será usable!"

A estas preguntas es importante responder que las funcionalidades con un importante valor de negocio se desarrollarán en primer lugar, y algunas, aquellas con menor valor, se podrían descartar. Por lo tanto, el Product Owner se debe asegurar de que el Backlog de Producto...

Conclusión

Hemos llegado al final de este capítulo, que le ha presentado el método Scrum en su conjunto. Hemos visto que se materializa por medio de eventos y herramientas y se basa en tres pilares que son transparencia, inspección y adaptación.

Como ya se ha dicho, son los individuos los que alcanzan el éxito de un proyecto y la noción de equipo es un aspecto esencial de la metodología: por tanto, vamos a profundizar en este punto en el próximo capítulo.