A de Agile

Agile no es una metodología, ni un proceso, ni un framework. Creo que hasta es incorrecto decir que es una mentalidad o mindset. Quizá podríamos decir que Agile es una forma de reflexionar sobre el desarrollo de software. O, si lo prefieres, se trata de una filosofía para abordarlo.

Históricamente, podemos pensar que Agile nace con el Manifiesto Agile. Sin embargo, el Manifiesto fue más un punto de encuentro para diversos grupos y profesionales que ya habían desarrollado sus propias metodologías y frameworks, como extreme programming, scrum, crystal clear, o lean software development. Incluso DevOps podría considerarse una forma de Agile. Muchos de estos frameworks están inspirados u obtienen ideas de las metodologías Lean Manufacturing o el Toyota Production System, aplicadas a desarrollo de software.

¿Por qué Agile? Pues porque los equipos de desarrollo de software entendieron que las metodologías clásicas de la ingeniería no funcionaban bien cuando se aplicaban al software.

Por lo general, la ingeniería física require un diseño meticuloso y una planificación cuidadosa antes de lanzarse a implementar. No puedes empezar a construir un puente sin saber donde vas a poner los pilares, qué hay al otro lado, cómo se va a usar, qué peso va a tener que soportar, qué fuerzas pueden influir sobre él, como corrientes de agua o vientos, y un largo etcétera.

Dicho de un modo sencillo: la ingeniería física crea productos que han de acertar a la primera. Sin embargo, al requerir mucho tiempo de desarrollo y ejecución, es muy posible que cuando por fin han sido desplegados puedan haber ocurrido cambios en el entorno a los que ya no es posible adaptarse. Por eso, es necesario considerar muy cuidadosamente todas las variables en juego, partiendo de los requisitos del proyecto, pero también anticipando circunstancias futuras.

El software no tiene los mismos condicionantes. En comparación con cualquier ingeniería física, que trabaja con materiales sujetos a las leyes de la naturaleza, el software es mucho más libre. Puedes usar el software a medida que se construye, una vez que hay suficientes elementos desplegados. Incluso aunque esté incompleto puede proporcionar un valor. Además, es relativamente fácil de cambiar, lo que permite reaccionar cuando vemos que el negocio va transcurriendo de maneras que no habíamos previsto o, simplemente, cuando comprobamos que nos hemos equivocado en algo.

Para ello son fundamentales los ciclos de feedback, es decir, la información que obtenemos de diversas fuentes acerca del comportamiento del software. Cuanto más cortos, mejor. Y por cortos entendemos minutos mejor que horas, horas mejor que días, días mejor que semanas y así sucesivamente. Para lograrlo necesitamos incorporar, por un lado, a la cliente o usuaria en el equipo de desarrollo de forma que podamos tener conversaciones con ella cada vez que sea necesario. Por otro lado, incorporamos prácticas que nos faciliten el feedback, como pair-programming, test driven development, etc. Pero también implica entregar el software en pequeños lotes de funcionalidad, de tal modo que revertir lo desplegado o introducir cambios sea lo menos costoso posible.

Esta forma de abordar los proyectos de software puede parecer idílica, pero es perfectamente factible.

Hay que tener en cuenta es que no es algo que se pueda conseguir de la noche a la mañana. Requiere un proceso de aprendizaje. Implica hacerse consciente de como trabajas y reflexionar sobre cómo mejorar esa forma de trabajar. Por tanto, presupone una cierta capacidad de autocrítica, individual y grupal.

Es decir: un equipo no se vuelve Agile porque le adjudiquemos esa etiqueta, o por introducir una serie de prácticas descontextualizadamente. Ni siquiera por seguir un framework concreto. En vez de eso, un equipo aprende a trabajar de forma Agile a medida que desarrolla un proyecto.

No existe una receta para ser Agile salvo aplicar, quizá, los principios del Manifiesto. Por otro lado, disponemos de frameworks que buscan articular una forma de trabajar ágilmente. Pero estas metodologías no definen la agilidad.

En fin, si el manifesto te parece demasiado largo, quédate con esta definición de Allen Holub sobre Agile:

• Trabajad en lotes pequeños
• Hablad entre vosotras
• Mejorad la vida de la gente

Todo lo demás es basura y distracciones.