Tutoriales online de Programación: Juegos, Engines y C/C++: Metodologías ágiles: SCRUM

Hola a todos,

Una cosa que pasa bastante durante el desarrollo de un proyecto de software (ya sea grande o pequeño) es que cambien los requerimientos antes de acabarse el proyecto: un cambio en el mercado, una acción inesperada de la competencia o sencillamente haber encontrado un enfoque mejor al problema original.

En las metodologías "tradicionales" esto es devastador. Se pueden perder meses de trabajo de planificación, el código empeora drásticamente a nivel de calidad y normalmente los equipos acaban pagando las consecuencias debido a que tienen que hacer un sobreesfuerzo realizando trabajo en horas no "normales" o incluso en fines de semana.

SCRUM es una metodología ágil de las más usadas actualmente (y desde hace años). Fue desarrollado por Ken Schwaber y Jeff Sutherland y presentado en público en 1995 y se basa en entregar partes del producto acabado en ciclos cortos de tiempo, así que si hay un cambio en los requirimientos en el peor de los casos se pierden unos pocos días o semanas y no meses o años de trabajo.

En SCRUM se definen 3 roles principales:
- Product Owner ( P.O ): Es el que se encarga de encapsular toda la información que le llegue al equipo. Es decir, es el que hablará con los accionistas,el cliente, dirección o quien sea que defina que se quiere para ese producto y se lo transmitirá al equipo. De la misma manera es el que definirá que se quiere, para cuando se quiere y que quiere decir que algo está acabado. Calculará costes, retornos de inversión y decidirá si el proyecto es viable o no. Todo lo que el equipo haga lo tendrá que validar el PO antes de ser entregado al cliente. Vendría a ser la figura de jefe de equipo en otras metodologías antiguas.(pero solo a nivel de producto, el equipo no es de su "propiedad")

- Scrum Master (S.M) : También se le llama facilitador, es el que se encarga que el equipo pueda producir a su máximo nivel. Organizará todas las reuniones , detectará impedimentos (y luchará por solucionarlos) e intentará que el equipo vaya mejorando poco a poco. Vendría a ser el jefe del equipo en cuanto a que una de sus funciones principales es la de proteger el equipo de interferencias externas, pero no tiene decisión sobre el producto como tal (eso es potestad del PO). Para poder conseguir esto necesita hacer cumplir las normas de SCRUM.

- Miembro de equipo : Toda aquella persona que junto con otras, produce un bien o servicio. Puede ser programador, artista, músico, tester, etc...Debe comunicarle al SM cualquier impedimento en su trabajo y al PO cualquier duda que tenga sobre el producto. Los que forman parte de un equipo no tienen "jefe" como tal sino que son células auto-organizadas, SM y PO tienen unas funciones muy delimitadas que en ningún punto pueden interferir en la gestión interna del equipo.

SCRUM divide el trabajo temporalmente en forma de sprints. Un sprint es una cantidad de tiempo que siempre ha de ser la misma (aunque en cada equipo se puede escoger una u otra) que suele variar entre las 2 semanas y el mes.

El PO tiene que dar al equipo los requirimientos y tiene que priorizarlos en función de que es lo que quiere que sea lo primero en ser entregado. A partir de ahí el equipo debe "pesar" cada una de las tareas y asignarle cierta cantidad de puntos en función de cuan complicada cree el equipo que es. Cuando el equipo ya tiene experiencia trabajando juntos, el SM puede extraer, más o menos, cual es la velocidad media del equipo, es decir, cuantos puntos pueden asumir por sprint, y por lo tanto se le puede decir al PO (con un margen de error bastante bajo) que se le va a entregar al finalizar el sprint.

Al acabar el sprint el equipo ha de poder entregar trabajo al cual se ha comprometido acabado, es decir, que funcione y que cumpla con todos los requisitos que el PO ha especificado. En el supuesto que el equipo vea que no llegará a la entrega deberá avisar cuanto antes mejor al PO.

Con este proceso iterativo (un proyecto se puede hacer en 1 sprint o en 30 por decir algo) se va consiguiendo por un lado tener cosas "definitivas" que se puedan enseñar al cliente para que nos de feedback sobre si vamos bien encaminados o no y por otro lado una gran flexibilidad en cuanto a cambios de requirimientos.

Para realizar todo este proceso SCRUM define un mínimo de cuatro tipos de reuniones imprescindibles a realizar en los equipos:

- Daily Scrum: Es una reunión que se hace de pie, de un máximo de 10-15 minutos, normalmente al inicio de la mañana en la que todos los miembros del equipo deben responder a tres preguntas muy sencillas:
¿Qué has hecho desde ayer?
¿Qué es lo que harás hasta la reunión de mañana?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
Esta reunión le sirve al SM para detectar impedimientos o interferencias en el equipo e intentar solucionarlos cuanto antes. Además permite a los miembros del equipo sincronizarse y entender lo que está haciendo el resto del equipo.

- Planificación de Sprint: Es una reunión que se hace al incio de cada sprint en el que se decidirá que trabajo se realizará durante ese sprint en base a las tareas que ha pedido el PO (priorizadas), su peso (dado por el equipo), y la velocidad del equipo (analizado por el SM)

- Revisión de sprint ( demo ): Es una reunión en la que se revisa el trabajo completado y no completado y se enseñan el trabajo completado al PO para que de su aceptación.

- Retrospectiva: Es una reunión que se hace al finalizar todo el sprint en la que todo el mundo tiene libertad para comentar que le ha parecido ese sprint y en que se puede mejorar. Es la base para que el SM pueda intentar realizar mejora continua dentro del equipo.

Finalmente se definen unas herramientas para realizar todo este proceso que llamaremos backlogs (la traducción sería algo así como "mochila donde almaceno papeles con información"). Estos backlogs normalmente están hechos con papeles adhesivos de notas y pizarras, pero cada uno se lo puede montar como quiera. La idea es que hay dos backlogs principales:
- Backlog de producto: Todo aquello que el PO ha pedido para poder dar por acabado el producto.
- Sprint Backlog: Todo aquello que el equipo se ha comprometido a realizar durante ese sprint.

Aparte de estos backlogs existe otra herramienta llamada gráfico de burndown que muestra de forma bastante sencilla si el equipo está yendo a la velocidad adecuada o no.