Metodología ágil no es lo mismo que desarrollo ágil

Hoy en día pareciera que si no decimos que trabajamos con metodologías ágiles, ni vale la pena desarrollar software. Scrum por acá, Kanban por allá, dailys, sprints… la fiebre de la metodología ágil está por todos lados. Y ojo, está bien. Veo muchos proyectos en los que piden como requerimiento manejar este tipo de metodologías y no me tomen en mal, también estoy convencidos de que trabajar en ciclos cortos, con entregas frecuentes que nos permitan validar si vamos por buen camino o si necesitamos ajustar, es una de las mejores formas de cuidar el tiempo (y el presupuesto) de un proyecto. La metodología tradicional, tan centrada en la documentación completa de todo el sistema para empezar a trabajar y hacer esperar a los usuarios por meses para mostrar una pantalla de login, crea mucho gasto y esfuerzo inicial, para cuando llegue el momento en el que el usuario viene con todas las ganas de ver el producto, se encuentre con errores de conceptos que pueden deberse a varios temas, como una mala explicación del usuario, mal entendimiento del problema por el técnico, y muchas otras posibilidades.

Las metodologías ágiles, nos da visibilidad, nos da control, y hasta nos da confianza. Pero hay algo de lo que no se habla tanto: ¿qué pasa con el desarrollo ágil?.

Hablemos del desarrollo en serio. Del código. De cómo logramos que esa promesa de agilidad no se quede solo en la pizarra de tareas o en la herramienta del project manager. Llevar adelante un proyecto con una metodología ágil no significa que el software sea fácil de mantener, de extender o de corregir. Y eso, lo sabemos bien, es lo que realmente determina si un sistema va a sobrevivir o si va a terminar dejando desarrolladores boca abajo en la piscina del código. La sostenibilidad del sistema también depende de cómo escribimos, organizamos y pensamos el código.

De la gestión a la arquitectura

Muchas veces la agilidad se queda solo en el ámbito de la gestión. Dividimos tareas en sprints, hacemos plannings, demos, etc… pero cuando llega un pequeño cambio, como modificar un label, se siente como si se nos viniera el mundo abajo. Y ni hablar si hay que cambiar una relación many-to-many por dos many-to-one para una clase asociativa con campos extras. Ahí es donde todo colapsa, pero no debería ser así. Y si pasa, es porque no estamos pensando la arquitectura desde un enfoque ágil.

Y no, no se trata solo de elegir entre microservicios o monolitos. Se trata de diseñar software que esté preparado para cambiar. Que sea predecible, entendible y testeable. Porque la verdadera agilidad se nota cuando hay que corregir una mala decisión, adaptar un módulo, agregar una funcionalidad urgente o simplemente entender qué hace ese código que nadie quiere tocar.

Cuando hablamos de arquitectura, no hablamos solo de en qué carpeta guardamos cada clase. Hablamos de pensar en cómo el sistema puede crecer, cambiar y adaptarse sin convertirse en una trampa mortal para quienes lo mantienen. Queremos que el software evolucione con nosotros, no contra nosotros. Y para eso hace falta algo más que metodología: hace falta criterio técnico, experiencia y por sobre todo visión a futuro.

¿Qué significa desarrollar de forma ágil?

Me ha pasado muchas veces, llevando adelante proyectos, que al comunicar un cambio a los desarrolladores noto enseguida una expresión de desesperación. No es broma. Cambiar un flujo, agregar un paso, hasta algo tan inocente como una modificación en el formulario, genera una tensión que no debería estar ahí. Lo primero que pienso cuando eso ocurre es que algo no está funcionando como debería. Que no estamos compartiendo la expectativa en la visión del usuario. Que el equipo está viendo el cambio como un problema, y no como parte del ciclo natural de crecimiento del producto.

En otros casos, me encontré con solicitudes que terminan devueltas como si se tratara de una reescritura completa del sistema. Un pequeño ajuste viene con una estimación de 50 horas y un documento de análisis que da miedo. Pero cuando uno se toma el tiempo de analizar el problema en serio, encuentra una solución de 2 líneas de código. Lógicamente exagero —aunque no tanto como quisiera—, porque sé que los proyectos tienen muchas capas, pero también sé que estas situaciones no deberían ser tan comunes si desarrollamos con un enfoque ágil, pensando en cambios, en mantenimiento, en el día después.

Desarrollar ágilmente es tener la libertad de experimentar, ajustar, corregir sin que eso signifique reescribir medio sistema. Es apoyarnos en una arquitectura limpia, con buen desacoplamiento, con piezas reutilizables y convenciones claras. Es escribir código como quien prepara el terreno para lo que viene, no como quien clava todo con cemento. Esto está muy ligado al artículo sobre refactorización del que ya hablamos.

Un desarrollo ágil no se logra solo con buenas intenciones de gestionar el proyecto. Necesitamos herramientas, prácticas y componentes que nos ayuden a mantener ese ritmo constante. Desde tener un entorno local fácil de levantar hasta contar con pruebas automatizadas; desde documentar decisiones clave hasta definir convenciones para nombres y estructuras de carpetas. Todo eso suma a la agilidad.

Pensemos por ejemplo en los smoke tests, de los que ya hablamos en otro artículo. Si son tan importantes para la salud del software pero nunca tenemos el tiempo de hacerlos, ¿por qué no los hacemos fáciles de implementar? Tener una clase base que nos permita testear cualquier ruta nueva en segundos es una forma concreta de aplicar desarrollo ágil. Eso también es arquitectura y escribir código que permita crecer sin miedo también es una decisión de diseño.

Otro ejemplo: ¿cuántas veces postergamos una refactorización por miedo a romper algo? ¿Cuántas veces agregamos “parches” sabiendo que algún día habrá que arreglarlo bien? Ese miedo es síntoma de que no estamos trabajando con una base sólida. En el desarrollo ágil, no se requiere que el sistema sea solo confiable sino también modificable. No solo que esté terminado.

El código importa, y mucho

A veces nos quedamos encantados con los post-its, los tableros kanban, las ceremonias de los 5 minutos diarios, pero el sistema que construimos es el que queda cuando el proyecto termina. Y ahí es donde el desarrollo ágil tiene que decir presente. Porque el mantenimiento no es una etapa del proyecto: es el día a día de cualquier sistema vivo.

Como arquitectos, como desarrolladores, como equipo técnico, tenemos la responsabilidad de pensar en la sostenibilidad del software. Que se pueda entender, probar, modificar y plasmar en un milestone la expectativa del usuario de que su cambio aparecerá en la mañana siguiente. Que pueda crecer sin dejar muertos por el camino. Eso no lo define la metodología de gestión, lo define el código. Y lo define también la actitud con la que lo escribimos.

Necesitamos escribir código con empatía. Pensando en la persona que va a venir después, que puede ser otra… o podemos ser nosotros mismos dentro de seis meses. Necesitamos dejar huellas claras, caminos transitables, estructuras que tengan sentido. No solo para sobrevivir, sino para disfrutar de los cambios pensando en el objetivo que se logrará con el nuevo release.

Para cerrar

La próxima vez que hablemos de agilidad, no nos quedemos solo en las reuniones. Pensemos también en el código que estamos vamos a escribir. Porque es ahí, en ese barro, donde realmente se juega el futuro del software que construimos juntos. Si queremos sistemas sanos, duraderos, capaces de acompañar los cambios que pide el negocio, empecemos a pensar en desarrollar con agilidad.

Una agilidad real. De la buena. De la que se siente cuando el cambio no duele y el software sigue avanzando sin frenos.