La siguiente metodología ágil en nuestra lista es SCRUM. Al igual que Extreme Programming es una de las más conocidas y probablemente hayáis oído hablar de ella con anterioridad pero, vamos a darle un breve repaso. Además de ser otra de las más conocidas, yo diría por lo que he visto en los diferentes proyecto y empresas por las que he pasado, que es una de las más adoptadas. Quizás no en su totalidad, pero si al menos una parte de la metodología. Ni que decir tiene que cada uno coge lo que mejor se adapte a su entorno de trabajo, al tipo de proyecto en el que está implicado y a la gente con que trabaja. Pero bueno, sin entretenernos más, vamos a entrar en materia.
Scrum como ya hemos comentado es una metodología ágil utilizada para gestionar proyectos complejos de “software” utilizando prácticas iterativas o incrementales. ¿Por qué he puesto las comillas alrededor de la palabra software? Porque aunque actualmente este es el campo en el que más se utilizan este tipo de metodologías, no es excluyente con ningún otro campo, uno puede usar Scrum en cualquier tipo de proyecto, ya hemos dicho que no hace falta seguir a rajatabla toda la metodología, uno puede seleccionar aquellas partes que más le interesan y le benefician. Pero bueno, que me vuelvo a ir por las ramas, volvamos con lo que estábamos.
A partir de este momento, quedémonos con estas tres palabras: rol, iteración e implicación.
En Scrum tenemos varios roles bien definidos y con funciones concretas y conocidas. Pero no penséis en una estructura piramidal tipo “Jefe de proyecto, analista, analista-programador, programador”, pensad en algo más fluido. No os preocupéis, vamos a tratar de explicarlo.
En primer lugar tenemos un Scrum Master que será la persona que se ocupa de que el equipo pueda trabajar sin distracciones o problemas, y en caso de haberlos (siempre los hay) los intentará solucionar para que estos afecten lo menos posible al equipo de trabajo. Además, este se asegurará de que se sigan de forma correcta los procesos asociados a Scrum.
En segundo lugar tenemos al Product Owner que será la voz del cliente en el equipo, este será el encargado de resolver todas las dudas del equipo sobre el negocio, preparar las historias de usuario, priorizar estas según necesidades del cliente y estar disponible el mayor tiempo posible para solucionar cualquier duda y dar feedback sobre el proyecto.
Finalmente, tenemos al equipo de desarrollo que son los encargados del desarrollo del producto. Muchos estaréis pensando que esto no es un rol, y tenéis razón teóricamente, pero desde el punto de vista práctico, en un equipo de desarrollo Scrum todos los miembros deben estar preparados para hacer cualquier tarea, análisis, diseño, desarrollo, pruebas, documentación, etc… Además, cualquiera de ellos debe conocer el código y poder modificar cualquier parte.
Volviendo a las tres palabras que teníamos que recordar, una vez abordados os roles, vamos a pasar a las iteraciones. Como ya hemos dicho, Scrum es una metodología iterativa, pero ¿qué significa esto? Pues significa que el avance del proceso se va haciendo en sucesivas fases compuestas de las mismas tareas. En Scrum se planifican iteraciones, a partir de aquí sprints de entre 2 y 4 semanas, obviamente los podemos adaptar a nuestras necesidades, pero este tiempo es el recomendado. Para cada sprint, se definen las tareas a realizar basándose en las prioridades indicadas por el Product Owner, y a partir de este momento, no se pueden modificar, lo que significa que todos aquellos requisitos incluidos en el sprint ya no se pueden cambiar y quedan congelados.
Finalmente la última de las palabras a recordar era la implicación. Scrum persigue la creación de equipos autogestionados y fomenta la comunicación verbal entre los miembros del proyecto. Recordemos que el Product Owner forma parte del proyecto, por lo que se está fomentando la constante comunicación con el cliente también. Está promoción de la integración y comunicación se materializa en la definición de varios tipos de reuniones. La primera de ellas es el daily scrum (scrum diario). Esta reunión se lleva a cado diariamente, y debería tener una duración de unos quince minutos. En ella cada miembro del equipo informa de lo que ha hecho el día anterior, lo que va a hacer ese día y si hay algo que le bloquea o impide el desarrollo de su tarea. De esta forma, dichos bloqueos pueden ser solucionados con la mayor brevedad posible por el resto de miembros del equipo.
Otro tipo de reunión es la de planificación del la iteración, en ella se define sobre que se va a trabajar durante la iteración y se estiman las diferentes tareas a llevar a cabo. El sistema es muy curioso, en ella participan todos lo miembros del equipo, cada uno de ellos posee unas tarjetitas con cifras para duraciones (1, 2, 3, 4,…) y dos especiales, una con un café y otra con una interrogación. Para cada tarea los miembros del equipo sacan una carta de forma simultanea y se trata de alcanzar una consenso entre todos ellos, normalmente los valores extremos explican el porque de su elección. Las dos cartas diferentes sirven para pedir una pausa o descanso, el caso del café; representar que la tarea no está bien definida o que hay que profundizar más en ella, en el caso de la interrogación.
En resumen, los puntos a tener en cuenta scrum son:
– Iteraciones: hacen que el cliente vaya viendo el avance del proyecto y se puedan ir corrigiendo y/o adaptando cosas conforme pasan las iteraciones. También nos permiten estimar a largo plazo (intentar nunca más de 6 meses) ya que tras 4 o 5 iteraciones tendremos una media de el trabajo realizado por iteración.
– El cliente se convierte en parte del equipo: A través del Product Owner, al cual lo ideal sería tener a disposición ocho horas al día.
– Rápida visibilidad de los problemas: Se consigue a través de las reuniones diarias.
– Conocimiento del proyecto por parte de los desarrolladores: lo cual mitiga posibles reemplazos en el equipo, ya que una sustitución solo implicará bajar el ritmo de una iteración y no una perdida de conocimiento difícilmente salvable.
– Una excelente monitorización del proyecto.
Bueno, hasta aquí la metodología de hoy. Aunque ha quedado un poco largo espero que no se os haya hecho muy pesado. Nos vemos.
Binary Coders 