Ayer comentaba que Scrum era una metodología ágil , y destacaba su capacidad de responder ante requerimientos inestables y ofrecer entregas frecuentes e incrementales .

Pero, ¿Qué es Scrum? El término viene de una jugada de Rugby en la que los jugadores de los dos equipos de apiñan para sortearse el balón. Y, supongo, que la metáfora subyacente es que todo el equipo empuja para conseguir el mismo objetivo.

Una vez demostrada mi erudición sobre el mundo del rugby, contesto:

Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo. Reduce al máximo la burocracia, y se centra en producir software que funcione y en ofrecer resultados visibles cada pocas semanas, incluso ante requerimientos inestables. Sólo abarca prácticas de gestión sin entrar en las prácticas de desarrollo...

Quedará más claro si describimos el día a día de un proyecto con Scrum...

Al iniciar el proyecto se crea el "listado de funcionalidades" (o product backlog , según los puristas), que es un listado actualizado, incompleto y priorizado de los requerimientos del proyecto-producto.

El "cliente" (o product owner , según los dichosos puristas) es el encargado de mantener este "listado de funcionalidades" actualizado y priorizado.

La idea básica es que el desarrollo se hace de manera cíclica e incremental. En cada "ciclo de desarrollo" ( sprint , dicen), el "equipo de desarrollo" ( scrum team ) selecciona el subconjunto de funcionalidades ( sprint backlog ) que se incorporarán al producto, y durante el siguiente ciclo se centrarán únicamente en completar esas funcionalidades y entregárselas al cliente. Los equipos son pequeños (máximo 8 u 9 personas…) pero experimentados (¡No intentes utilizar metodologías ágiles con equipos juniors!). Los ciclos de desarrollo son cortos (entre 3 y 5 semanas, habitualmente), por lo que se tiene una buena visibilidad sobre el avance del proyecto.

El "jefe de proyecto" (o scrum master ) se encarga de ayudar al equipo en sus necesidades y evitar distracciones inútiles (coordinando reuniones, recabando información, ¡eliminando obstáculos!...). No ejerce exactamente de jefe (ya que es el propio equipo de desarrollo el que selecciona, estima y gestiona su tiempo, y se hace responsable del diseño, de la implantación, y del resultado). El equipo de desarrollo tiene una gran autonomía.

Tal como comentaba ayer, esta metodología se adapta muy bien a las características típicas de los proyectos Business Intelligence. Que son llevados a cabo por equipos relativamente pequeños. Que se pueden fraccionar los requerimientos y las entregas (incorporando áreas de información, mejorando rendimientos, "pintando pantallas", creando cubos…). Y que el cliente nunca sabe bien lo que quiere. Si asumes de entrada que habrá cambios, huirás de arquitecturas rígidas, y no darás nada por sentado , sabrás que te mueves en aguas pantanosas y eso te hará reflexionar, hecho fundamental para aumentar las probabilidades de éxito de cualquier proyecto...

Además, con Scrum, podrás ofrecer resultados tangibles de una manera continua, lo cual es deseable en todo tipo de proyectos, y también en los de BI … ¿Serán las metodologías ágiles una generalización de los tradicionales prototipos?

Os dejo un vídeo donde explican estos conceptos básicos de Scrum (...y con la terminología correcta). Entiendo que el vídeo está realizado en clave de humor, y que los equipos Scrum no han de ser tan frikis como pueda parecer.