SCRUM es una metodología de gestión de proyectos que pretende aportar agilidad al proceso de desarrollo de los mismos. Detrás de un conjunto de reglas y roles más o menos simpáticos, se esconde una metodología que quiere incrementar la productividad, pero qué aporta realmente?
Empecemos por el principio. Para no aburrir, vamos con una 5-minute guide sobre SCRUM:
- Es una metodología de gestión de proyectos, que lleva a cabo un proceso de desarrollo incremental, mediante iteraciones que aportan progresivamente valor añadido.
- El objetivo de esta metodología es la obtención de flexibilidad y agilidad en el desarrollo de productos y, por tanto, de incremento de productividad (<nota>este tema será tratado en diversas entradas de este blog</nota>).
- Los participantes en esta metodología de gestión se subdividen en tres grupos:
- Scrum master o gestor del proyecto.
- El product owner, cliente(s) o interesado(s) en el proyecto (stakeholders).
- Team o equipo de desarrollo, coordinados por el scrum master.
- Cada iteración sobre el producto (llamada sprint) aporta un incremento del valor añadido y debe proporcionar un producto utilizable, que cubrirá un subconjunto de los requisitos solicitados por el product owner (denominados product backlog, y que obviamente, están sujetos a ampliaciones).
- Cada iteración debe abordar los requisitos por prioridad, según las necesidades del product owner (en primer lugar, lo que más valor le aporte).
- Cada iteración tiene una duración relativamente corta (de 15 a 30 días).
- Los requisitos de cada iteración (denominados sprint backlog) están congelados durante el sprint o iteración (no pueden cambiarse).
- El equipo de desarrollo está compuesto por profesionales multidisciplinares, auto-organizados, que se comunican verbalmente (requiere que todo el equipo tenga la misma localización geográfica).
- Se distinguen dos tipos de roles: los cerdo (scrum master, equipo, etc) y los gallina (product owner, stakeholders, etc). Los cerdos están comprometidos con el proyecto, los gallina están implicados ("En un plato de huevos con tocino el cerdo está comprometido, la gallina sólo está involucrada.").
- Antes de empezar un nuevo sprint, se realiza una reunion de planificación del sprint.
- Se realizan reuniones de seguimiento diarias, de corta duración (se debe ser puntual, se realizan de pie, etc). Cada cerdo debe indicar el progreso realizado desde la última reunión y si tiene algún problema para avanzar en sus tareas.
- Al finalizar, se realiza una reunión de validación del sprint y otra reunión de presentación del sprint al product owner y stakeholders (la archiconocida 'demo').
Respecto a la teoría expuesta, me parece acertado intentar congelar requisitos para una entrega. También veo muy correcto involucrar al cliente o interesados en el proceso de desarrollo del producto. Incluso me parece un importante activo que gran parte del equipo tenga capacidad para desempeñar diversas funciones o roles en un proyecto, pero, bajo mi punto de vista, SCRUM presenta diversas carencias:
- La burocracia debería ser reducida, y se deberían realizar iteraciones de 2 o 3 meses como mínimo, con seguimiento semanal o quincenal.
- Los cambios deberían ser gestionados de manera que los de impacto leve puedan ser absorbidos, pero los de impacto grande sean post-puestos a ampliaciones o mejoras futuras del producto o sistema.
- Los integrantes de los equipos deberían ser multidisciplinares, pero parcialmente, se debería dejar sitio a las nuevas incorporaciones. Los perfiles multidisciplinares no deberían solaparse, para evitar problemas. Un integrante no debería desempeñar más de 2 o 3 roles en un mismo proyecto.
- El control y la gestión del equipo de desarrollo debería delegarse, en su mayor parte, a herramientas colaborativas (control de versiones, blogs de proyecto, wikis, etc), de manera que se automatice la burocracia y se pueda obtener un snapshot de la situación del proyecto a golpe de click.
- Debería realizarse un análisis o diseño previo (sujeto a revisión frente a grandes cambios) que sirva de guía o estructura base sobre la que trabajar. Una lista de requisitos en lenguaje natural no me parece lo más adecuado para llevar a cabo un proyecto de construcción de un nuevo sistema (puede que sí para gestionar incidencias).
- El mejor incremento de productividad que puede realizarse en la gestión de proyectos software es disponer de un entorno con herramientas colaborativas telemáticas que desambigüen toda comunicación entre integrantes del equipo, y un conjunto de herramientas que faciliten el desarrollo de software, sobre una plataforma productiva y correctamente documentada.
Finalmente, me gustaría apuntar que los verdaderos comprometidos con los proyectos deberían ser los promotores del mismo (product owner, stakeholders...), el equipo de desarrollo no es más que un involucrado en el proceso. De todas formas, yo propondría llamar a los primeros promotores del proyecto y a los segundos ejecutores del mismo.
