Hace ya unos cuantos años (muchos) escuché por primera vez el término metodología agile. Por aquel entonces sonaba raro y esperanzador al mismo tiempo, parecía la solución a nuestros males: alguien había encontrado la bala de plata para el desarrollo de software. Cuando el término comenzó a difundirse, podías hablar con gente de la profesión con puntos de vista radicalmente distintos. Los había que ni lo habían oído ni tenían demasiado interés. Los había (como yo) que habían indagado algo sobre el concepto agile, pero que estábamos en un filo entre el escepticismo y la esperanza de un nuevo enfoque que solucionara nuestros problemas. Los había (los menos) que de manera más o menos acertada lo tomaron como práctica en el día a día de sus equipos. Y, por supuesto, también los hubo a que les gustó tanto la idea que se dedicaron a difundir la palabra del agile evangelizando a los tristes mortales.
Para poder desarrollar este post voy a contar brevemente qué son las metodologías ágiles. Para ello, qué mejor manera de hacerlo que escribir lo que en su día fueron algo así como los diez mandamientos del agile, escritos por los grandes de la época y bautizados como Manifiesto Ágil:
- Individuos e interacciones sobre procesos y herramientas.
- Software funcionando sobre documentación extensiva.
- Colaboración con el cliente sobre negociación contractual.
- Respuesta ante el cambio sobre seguir un plan.
Uno de los autores de este manifiesto fue Martin Fowler, quien en su blog utiliza dos contrastes del desarrollo ágil frente al tradicional y que, bajo mi punto de vista, son imprescindibles para comprender realmente qué es una metodología ágil:
- Agile Development is adaptive rather than predictive
- Agile Development is people-oriented rather than process-oriented
Resumiendo, podríamos decir que el “movimiento” agile pretendía buscar una nueva manera de desarrollar aplicaciones. Esta nueva forma tomaba como base la experiencia de expertos que habían aprendido y constatado que desarrollar software siguiendo un plan estricto, procedimental y basado en la generación de toneladas de documentación, no funcionaba. El fallo principal radicaba en tomar el software como algo que se podía definir y planificar desde el inicio del proyecto y seguir un plan sin apenas variaciones. Todos sabemos que esto no es cierto. Por tanto, los métodos ágiles tomaron como premisa que el cliente no iba a saber al 100% lo que quería hasta que empezara a verlo. Ante esto, planteó soluciones basadas en esa misma premisa dejando los procesos, las herramientas y la documentación en un segundo plano y poniendo en el centro del proyecto al cliente, asumiendo el cambio desde el principio y teniendo como objetivo único construir software que funcionara como el cliente quería.
Pero, ¿qué NO es agile?
Una vez puesto en contexto qué es agile, estamos en disposición de explicar qué NO ES AGILE. Aquí una lista de prácticas que todavía se observan en algunos equipos de desarrollo autodenominados ágiles:
- No es agile seguir claramente una metodología clásica en cascada y utilizar palabras como historia de usuario y sprint en el día a día del equipo, cuando realmente no estás haciendo un uso real ni adecuado. Estás encasquetando conceptos que claramente se pegan entre ellos y, por supuesto, estás alimentando el fuego de la confusión, fuego que con toda seguridad quemará la productividad de tus programadores.
- No es agile tomar requisitos del product owner una vez (si se complica, podemos llegar a dos o tres veces) y no volver a verle la cara hasta que estás en fase de “validación”. Recuerda, people-oriented. Para ser realmente agile, el product owner debe de dejar de verse como el malo de la película y empezar a ser uno más del equipo de desarrollo.
- No es agile Aferrarse al alcance firmado como a un clavo ardiendo. No tiene NINGÚN sentido decir que vas a seguir una metodología ágil en un proyecto para el que te han contratado y después ir a cuchillo con los cambios de alcance. Cuando antes asimiles que el cliente no sabrá lo que quiere hasta que lo vea y que el cambio es una constante, mucho mejor para ti.
- No es agile enseñar al cliente la aplicación cuando está casi terminada y en un entorno de demo.
- No es agile separar las pruebas del proceso de desarrollo. Estar meses desarrollando para entregar un producto “listo” para pruebas.
- No es agile realizar el 100% de las pruebas de manera manual.
- No es agile dedicar semanas de pruebas manuales totalmente ajenas al equipo de desarrollo.
- No es agile no enseñar una funcionalidad X al cliente porque todavía está en el horno.
- No es agile que los programadores pasen horas sentados delante de sus portátiles sin hablar con sus compañeros (incluyo ahí también al cliente, que es uno más del equipo).
- No es agile tener una pared o pizarra (física o lógica) llena de post-it desfasados, con descripciones del tipo “hacer análisis”, “listados” o lindezas de ese estilo.
- No es agile trabajar sin un entorno mínimo de integración y despliegue continuo, donde el cliente pueda ver el avance del desarrollo.
- No es agile ser estricto y vivir en una eterna pelea con el cliente/usuario de la aplicación que estamos desarrollando.
- No es agile dedicar cientos de horas de análisis sin comenzar el desarrollo e involucrar a los programadores desde el primer momento.
- No es agile generar toneladas de documentación que nadie lee, ni actualiza y que realmente no son necesarias para construir la aplicación.
¿Ser o no ser agile?
En definitiva, ser agile o no serlo, bajo mi punto de vista, tiene mucho más que ver con la filosofía y la cultura que comparte nuestro equipo, las sensaciones que inspiramos en nuestros clientes desde el momento en que firmamos un contrato de desarrollo, el plantearnos dudas a nosotros mismos, no dar por bueno lo que por sistema hacemos, dejar de hacer ese documento que nadie va a leer, dejar de entrar en una reunión con el cliente con el hacha de guerra pensando en luchar a capa y espada para no moverme del alcance pactado o desarrollar lo acordado frente a lo que realmente necesita el cliente. Concentremos nuestro esfuerzo en aquello que realmente aporta valor a nuestro cliente, en construir el software que realmente necesita y dediquemos la energía mínima al resto de actividades que no le aportan ningún tipo de valor.
Te invito a que leas el artículo Implementación de un método agile en la empresa: caso práctico Belike en el que trato de forma más minuciosa cómo ponemos en práctica en nuestra empresas el método agile.
Deja una respuesta