SW Saber

Últimamente las metodologías denominadas ágiles están en boca de todos. Algunas personas piensan que este tipo de metodologías son la panacea a todos sus problemas, y no se explican cómo han podido vivir sin ellas todo este tiempo; otras sin embargo las ven como “hijas del maligno”, y no quieren oir ni hablar de nada que tenga que ver con todas ellas.

Ante todo, aquí no entraremos en cuestiones filosóficas y temas políticos, sino que abordaremos el asunto con objetividad y sin fanatismos.

¿Qué es Scrum?

Scrum es una de las denominadas metodologías ágiles, y por lo tanto es una metodología que aboga por el desarrollo que tiene en cuenta la situación cambiante de los requisitos del cliente, así como minimizar la necesidad de documentación, para comenzar cuanto antes a hacer trabajo “efectivo”.

Historia

Scrum, es un término proveniente del Rugby, que viene a significar “melé”, donde todo el equipo colabora hombro con hombro para lograr llevar el balón a lo largo del campo.

Los primeros en hablar de Scrum (aunque el término en sí no estaba acuñado), fueron los japoneses Hirotaka Takeuchi e Ikujiro Nonaka en el 1986. Los primeros pasos de la metodología fueron aplicados a proyectos teconológicos de desarrollo de productos electrónicos, y no fue hasta principios de los 90 cuando Ken Schwaber que empezó a aplicarlo al desarrollo de Software.

Metáfora

Los roles o partícipes en Scum vienen ilustrados por el siguiente chiste:

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice, “Hey, ¿por qué no abrimos un restaurante?” El cerdo mira a la gallina y le dice, “Buena idea, ¿cómo se llamaría el restaurante?” La gallina piensa un poco y contesta, “¿Por qué no lo llamamos “Huevos con jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tu solamente estarías involucrada”.

La historia deja de manifiesto que siempre hay dos tipos de personas, los cerdos, que son los que hacen el trabajo, y las gallinas que son las que piden.

Características

Scrum organiza el desarrollo de manera evolutiva en los denominados Sprints, que no son más que periódos de tiempo entre 15 y 30 días (definidos al principio de proyecto y luego inamovibles), en los cuales se prioriza el desarrollo en base a las necesidades del cliente.

De un vistazo rápido, el proceo Scrum se desarrolla de la siguiente manera:

Para conseguir esto se definen una serie de roles, reuniones y documentos:

1) En Scrum hay 4 roles principales: Product Owner, decide que es lo importante para el proyecto; Scrum Master, dirige el proceso; Scrum Team, son los que llevan a cabo el trabajo; Clientes, son los clientes internos o externos del producto.

2) Se definen 3 reuniones típicas: inicio de sprint, se planea que se va a hacer en el próximo sprint, diaria, donde se dice lo que se ha hecho y los puntos de bloqueo, restrospectiva, después de cada sprint.

3) Hay 3 documentos a usar: Product Backlog, es una lista de requisitos del cliente; Sprint Backlog, lo que se va a hacer en un Sprint; Burn Down, gráfica con lo que queda por hacer del Sprint actual.

El flujo de trabajo de Scrum puede verse detallado en la siguiente ficha:

A continuación se detallará más en profuncidad cada uno de los términos brevemente expuestos.

Roles

Como se comentó anteriormente hay 4 roles:

Product Owner (Cerdo)

Es la persona encargada de mantener el Product Backlog, o dicho de otro modo el contacto con los clientes, que reflejará en dicho documento los requisitos de una manera priorizada. Esta persona tiene la perspectiva de que va a ser el producto, hacia donde se dirige, y por tanto la priorización de los requisitos.

Scrum Master (Cerdo)

Un Scrum Master cumple 3 cometidos básicos:

1) Elimina los obstáculos que hace que el Scrum Team no avance.

2) Cuida de que la metodología Scrum se cumpla.

3) No es un líder del equipo, el Scrum Team se autoorganiza.

Scrum Team (Cerdo)

Es el equipo que desarrolla el producto, normalmente formado por un grupo de entre 5 ó 9 personas, donde no se diferencian por puestos, aunque si deberían complementarse en competencias (análisis, diseño, programación, …).

Clientes (Gallina)

Los clientes son los que guiarán las prioridades de ejecución de tareas del Product Backlog, mediante la intermediación del Product Owner.

Reuniones

Hay 3 tipos de reuniones:

Inicio de Sprint

En esta reunión se planifica que tareas del Product Backlog se van a hacer en el próximo sprint. Para ello el Product Owner indica las tareas más prioritarias al equipo, y este le indica cuales va a hacer en el siguiente sprint.

Una vez fijadas las tareas (requisitos) del sprint, estas no se tocan, es decir, se congelan las tareas abordadas desde el sprint.

Reunión diaria

Llama Daily Standup, esta reunión se celebra diárimente, y tiene las siguientes características:

1) Reunión diaria, en el mismo sitio y a la misma hora.

2) Dura 15 minutos.

3) Se hace de pié (así se fomenta que sólo dure 15 minutos).

4) Se exige puntualidad (nuevamente sino no duraría 15 minutos), hay grupos Scrum que penalizan a las personas que no cumplen con esto.

5) Todas las personas están invitadas, pero sólo los 3 roles de “cerdo” comentados anteriormente (Product Owner, Scrum Leader, Scrum Team) pueden hablar.

Cada miembro del Scrum Team debe responder a estas preguntas:

1) ¿Qué has hecho desde ayer?

2) ¿Qué planeas hacer mañana?

3) ¿Qué problemas te han surgido que te hayan impedido hacer tus tareas?

Reunión Retrospectiva

Reunión posterior a cada Sprint, con las siguientes características:

1) Se hace después de cada Sprint.

2) Dura 4 horas.

3) Se analiza que tal ha ido el Sprint, con el objetivo de mejorar el proceso para futuros Sprints.

Documentos

Los 3 tipos de documentos Scrum son:

Product Backlog

Características del Product Backlog:

1) Es relativo a todo el proyecto.

2) Mantiene una lista de requisitos o funcionalidades (wish-list) priorizada, en base a las necesidades del cliente.

3) Cualquiera puede añadir tareas nuevas, pero sólo el Product Owner puede priorizarlas.

4) Las estimaciones de las tareas son poco detalladas, normalmente en días.

Sprint Backlog

Características del Sprint Backlog:

1) Describe en detalle lo que se va a hacer durante un Sprint.

2) Las tareas provenientes del Product Backlog se descomponen en tareas del Sprint, de modo que se estimen en horas, con un tiempo máximo de 16 horas (si las tareas son mayores, debe volver a descomponerse).

3) No hay asignación de las tareas por parte del Product Owner o el Scrum Leader, sino que el el propio Scrum Team el que escoge que tarea va a hacer cada uno (auto organizado).

Burn Down

El Burn Down es una gráfica que muestra las tareas pendientes de terminar durante un Sprint.

Herramientas

La metodología Scrum no necesita de herramientas tecnológicas para llevarse a cabo, sino que más bien se apoya en utensilios de oficina como:

1) Lista de tareas del Product Backlog, que puede estar escrita en una libreta, o en una Hoja de Cálculo.

2) Lista de tareas del Sprint Backlog, igualemente puede ser artesanal o electrónica.

3) Pizarra (Sprint) con Poss-its (tareas), donde las tareas (poss-its) son colocadas por el Scrum Leader (bajo el sistema priorizado del Product Backlog realizado por el Product Owner), y son los miembros del Scrum Team los que escogen cuales hacer.

Conclusiones

Scrum es una metodología ágil, que se aplica a cualquier tipo de proyecto, no sólo a proyectos de Desarrollo Software, dado que la metodología sólo habla de cómo despachar tareas, centrándose en la importancia de sacar trabajo adelante en cada uno de los Sprint, y en la importancia de avanzar en la línea de lo que el cliente quiere, adaptándose contínuamente al cambio.

Bajo mi punto de vista, es una metodología útil cuando los proyectos de desarrollo no sean grandes, dado que con Scrum no se tiene una gran perspectiva global del proyecto más allá de tener una lista de tareas pendientes (Product Backlog).

Fusión con lo tradicional

Sin embargo, y teniendo en cuenta la estructura de Scrum, las desventajas podrían ser superadas si se aplica conjuntamente con una metodología más tradicional, y se usa Scrum para despachar las tareas que vayan surgiendo de otra metodología más orientada a lo “tradicional” (aquellas que descomponen el desarrollo en fases como: Requisitos, Diseño, Implementación y Pruebas).

Aclarando un poco esto último (bajo petición de Juan), la idea de fusionar Scrum con metodologías tradicionales, es hacer que:

1) Las metodologías tradicionales generarán tareas, de distinta naturaleza: documentación, diseño, implementación, pruebas, …

2) Dichas tareas sirven como tareas de entrada a Scrum (en el Product Backlog).

3) Las tareas son despachadas mediante la aplicación de Scrum.

Tampoco es que se esté inventando nada nuevo, sólo usamos a Scrum como una herramienta ágil, que nos permite ir realizando tareas de manera incremental (sprint).

Enlaces y documentación

A continuación enumero algunos enlaces que pueden resultar de utilidad:

1) Scrum en la Wikipedia

2) Flexibilidad con Scrum (PDF)

3) Explicando Scrum a mi abuela

4) Plantilla para Sprints (Excel)

Tags: Backlog, Scrum, Sprint

This entry was posted on Lunes, Septiembre 8th, 2008 at 7:30 am and is filed under Metodologías, Ágiles. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.