En un artículo anterior, hablamos de proyectos, gestión, el Project Manager e introdujimos el concepto Agile. Es hora ya de poner los puntos sobre las íes, ya que la tendencia lleva tiempo siendo migrar a este enfoque tan molón en la gestión de proyectos.
Orígenes
Agile es un mundo cool, así que hay que conocer a los fundadores y a los máximos exponentes, si no se corre el riesgo de no estar en la onda, por ello merece la pena poner las cartas sobre la mesa y contar de dónde viene todo esto.
Se empieza a hablar de agilismo allá por el año 2001, cuando un grupo de 17 profesionales encabezados por Kent Beck y que habían estado buscando por su cuenta soluciones a los problemas clásicos de los proyectos de software, se reunieron durante un fin de semana de ski y firmaron el Manifiesto Ágil como punto de encuentro entre todas sus posturas.
Cuatro valores, doce principios y una frase lapidaria: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros”. Legiones de desarrolladores aclaman la iniciativa, y es que habla de cosas de cajón:
- Si estamos desarrollando software, es mejor entregar algo funcionando que pilas de documentación.
- Si estamos resolviendo un problema al cliente, es mejor escucharle y colaborar juntos para entender qué necesita a venderle un producto estándar.
- Es probable que a medida que avanza el proyecto las necesidades cambien, si somos rígidos el clima de colaboración se va a resentir: aceptemos los cambios.
- Los procesos ayudan, pero esto no son tuercas ni un Shakespeare producido por cientos de monos aporreando máquinas de escribir (Teorema del mono infinito). La comunicación fluida y sincera es importante, la gente es esencial.
No hemos dicho nada descabellado, el manifiesto no es la solución mágica a todos los problemas del software. Únicamente estamos centrándonos en cosas importantes, en lo práctico, en aquello que aporta valor. Y aquí está la clave, focalicemos nuestros esfuerzos y evitaremos pérdidas de tiempo y tener que repetir trabajo.
¿Cómo se aplica?
Claro, el manifiesto no dice cómo ponerlo en práctica. Cada uno de los 17 profesionales que lo firmaron tienen sus propias prácticas (CI, TDD, DSDM, XP, FDD, ¡cuántas siglas!) y estandarizar cualquiera de ellas hubiese sido motivo de desacuerdos.
Grosso modo podemos hablar de tres vertientes principales para aplicar Agile, dependiendo de nuestra adaptabilidad:
1. La programación extrema consiste en aplicar la simplicidad a nuestros proyectos, centrándonos en las pruebas y las buenas prácticas de programación, como los tests anticipados. Así, se programará precisamente aquello que resuelve la necesidad y será muy fácil validarlo y mantener la consistencia.
2. Probablemente el método más conocido. Define actividades, ceremonias, roles, etc para ayudar a un equipo a empezar a trabajar de manera ágil. Facilita que todo el mundo aprenda a trabajar de esta manera, siendo flexible para poder adaptarse a distintos equipos.
3. Este modelo encaja mejor en equipos de mantenimiento. Se basa en un ritmo de trabajo constante, poniendo la atención en que lo que se empieza se termina antes de ponerse con otra cosa.
Hablemos de Scrum…
Scrum es un framework que ayuda a los equipos a centrarse. Y esto es lo importante: centrarse, habituarse a las buenas prácticas dentro del proyecto. No es tan relevante que haya 5 reuniones, 3 artefactos y 3 roles distintos dentro del equipo. La teoría, las ceremonias, están descritas en todas partes así que no vamos a repetirlas. Vamos a hablar de valores, ya que sin ellos el castillo de naipes se derrumba.
- Foco. Es esencial que el equipo aprenda a centrarse en lo que importa, en un conjunto de tareas pequeño y controlable, sin querer abarcar demasiado.
- Compromiso. Implica mayor facilidad para adquirir compromisos realistas que permitan tener suficiente confianza en que se va a poder entregar. Confianza, no certidumbre, puede haber imprevistos. Este compromiso se basa también en una confianza con el cliente para aceptar estas eventualidades.
- Respeto. Es esencial tener un enfoque de respeto mutuo: el cliente no es nuestro enemigo, trabajamos juntos para conseguir un resultado que satisfaga a ambas partes. No es de recibo buscar culpables ni héroes.
- Coraje. Ese respeto permite que el equipo se sienta apoyado y no presionado, facilitando que se atreva con retos más ambiciosos y valiosos.
- Honestidad. Si tenemos un problema es importante comunicarlo cuanto antes para poder desbloquearlo y seguir adelante. Trabajamos juntos, es importante compartir abiertamente la información.
- Trabajo en equipo y mejora continua. El equipo debe ser una piña, una melé, y enfrentarse al proyecto para finalizarlo con éxito. Además, los requisitos, las tecnologías y los procesos cambian y siempre podremos mejorar la manera en la que trabajamos.
Para que Scrum funcione es esencial que estos valores formen una base firme en la que todo lo demás se asiente.