Metodología ágil
Seguro que habrás oído el término alguna vez y, cuando lo has googleado, no te ha quedado demasiado claro el asunto.
Te lo cuento en las siguientes líneas. Ojo: esta es una explicación para dummies, es decir, para personas no introducidas en la materia, pero que quieren poder no perderse en una conversación sobre metodologías de desarrollo de proyectos. Si vas a formar parte de un proyecto desarrollado con metodología agile, te recomiendo que acudas a la bibliografía especializada.
Empecemos por el principio: los tipos de proyectos.
Los proyectos “clásicos” suelen ser predictivos: el alcance está perfectamente definido, así como los requisitos del producto objetivo. En base a los anteriores y en un marco rígido, se desarrollan todos los entregables del proyecto. Esta metodología “estructurada” suele llamarse waterfall o cascada: la finalización de cada estudio propicia el desarrollo del siguiente. El esquema operativo puede -y debe- reflejarse en una programación de camino crítico.
Sin embargo, ¿qué ocurriría si los requisitos del producto fueran cambiando a lo largo del propio proyecto? Esto ocurre frecuentemente en los proyectos de software y puede llegar a dejar sin valor el trabajo realizado previamente. La metodología ágil -originalmente agile en inglés- se desarrolla para afrontar este tipo de proyectos no predictivos. Nació en 2001 con el llamado Manifiesto Agile, cuyos autores fueron los CEO de las principales empresas de software.
La metodología ágil más conocida es la denominada scrum, que no es un acrónimo: ya en español significa “melé”, queriendo indicar que todos los miembros del equipo actúan como una unidad para hacer avanzar la pelota -el proyecto-.
El objetivo es tratar de conseguir resultados iterativos de forma ágil en períodos cortos, denominados sprint. Cada sprint comienza con una breve reunión de planificación, en la que se define el alcance –sprint backlog-, que normalmente son las funcionalidades que se desarrollarán durante el sprint, que forman parte de la denominada Product Backlog. A lo largo del sprint se desarrollan reuniones informales y cortas denominadas daily, en las que puede adaptarse el trabajo previsto, si fuera preciso. El sprint finaliza con una Review y una retrospectiva. En la primera interviene el cliente y los involucrados, informándoles del progreso conseguido y de cómo éste acerca el proyecto al objetivo, denominado Product Goal. En la retrospectiva el equipo busca cómo mejorar su eficiencia.
En la metodología ágil resulta fundamental la colaboración del cliente, de forma que se pueda reaccionar rápidamente a sus necesidades y nos podamos asegurar de que no nos desviamos de sus necesidades.
Los frecuentes ciclos de los sprint garantizan, por su lado, que el impacto de posibles errores o desviaciones será muy limitado.
Además, la metodología ágil requiere equipos pequeños (de no más de 10 miembros) y empoderados, con el fin de que puedan tomar las decisiones que les correspondan.
En definitiva, es una metodología orientada a gestionar cambios continuos, donde el alcance es variable, pero el plazo fijo, ya que se pretende entregar resultados con frecuencia regular. El objetivo es conseguir resultados rápidos e incrementales: pensemos en las infinitas versiones del software comercial y de la velocidad con la que quedan desfasadas.
¡Ah! Aunque ésta no sea una metodología que se use habitualmente en tu empresa, cada vez es más frecuente desarrollar proyectos piloto ágiles, especialmente aquellos que resultan novedosos o en los que la obtención de resultados prima sobre el alcance. De hecho, podríamos decir que, fruto de la metodología ágil, nació un spin off: los resultados ágiles. Pero eso es otra historia, de la que hablaremos otro día.