Por qué trabajamos con metodología ágil

De dónde viene la agilidad

En 2001, diecisiete desarrolladores de software se reunieron en Snowbird, Utah, para hablar de algo que todos habían observado por separado: los métodos tradicionales de gestión de proyectos no funcionaban bien para hacer software. De aquel encuentro salió el Manifiesto Ágil (Manifesto for Agile Software Development), un texto breve que ha acabado definiendo cómo trabaja buena parte de la industria.

El manifiesto no es una metodología ni un conjunto de normas. Son cuatro valores y doce principios. Los valores dicen que, aunque los elementos de la derecha tienen valor, valoramos más los de la izquierda:

• Individuos e interacciones por encima de procesos y herramientas.
• Software que funciona por encima de documentación exhaustiva.
• Colaboración con el cliente por encima de negociación contractual.
• Respuesta al cambio por encima de seguir un plan.

Es importante leerlo bien: no dice que la documentación, los planes o los contratos no sirvan. Dice que cuando hay conflicto entre las dos cosas, la izquierda debe ganar.

El problema que resuelve

Para entender por qué esto es una buena idea, hay que entender el modelo al que sustituía. El desarrollo en cascada (waterfall) organiza un proyecto en fases secuenciales: primero se especifica todo, después se diseña todo, después se programa todo y, al final, se prueba y se entrega. Sobre el papel es ordenado. En la práctica tiene un defecto estructural: todo el feedback llega al final, cuando ya se ha gastado la mayor parte del tiempo y del presupuesto.

Y el feedback al final es caro por una razón muy simple: el software es un producto que nadie sabe especificar del todo por adelantado. El cliente descubre qué necesita realmente cuando ve el producto funcionando. Los desarrolladores descubren las dificultades técnicas cuando trabajan en ellas. El mercado cambia mientras el proyecto avanza. En un proyecto de dieciocho meses en cascada, todos estos descubrimientos se hacen cuando ya es tarde para reaccionar sin rehacer trabajo.

Ciclos cortos, riesgo pequeño

La respuesta ágil a este problema es trabajar en iteraciones cortas, normalmente de una a cuatro semanas, y que cada una acabe con software que funciona en manos del cliente. Uno de los doce principios lo dice literalmente: la medida principal de progreso es el software funcionando, no los documentos aprobados ni las fases completadas.

Este cambio tiene consecuencias en cadena:

• El riesgo se fragmenta. Si una iteración va por mal camino, se pierden dos semanas, no dieciocho meses. Los errores de concepto se detectan cuando todavía son baratos de corregir.
• El cliente valida sobre realidad, no sobre promesas. Ver una funcionalidad en marcha genera un feedback mucho más útil que revisar un documento de especificaciones de cien páginas.
• Las prioridades pueden cambiar. Como el plan se revisa en cada iteración, incorporar un cambio de prioridades es el funcionamiento normal del sistema, no una crisis. El manifiesto lo convierte en un principio explícito: los cambios de requisitos son bienvenidos, incluso tarde en el desarrollo.
• Se entrega valor desde el principio. El cliente no espera al final para tener algo útil: las funcionalidades más importantes se hacen primero y se pueden poner en producción antes de que el proyecto termine.

Personas que hablan entre ellas

El segundo pilar es menos técnico y más humano. El manifiesto pone a los individuos y las interacciones en primer lugar porque la mayoría de problemas en un proyecto de software no son de herramientas: son de comunicación. Requisitos mal entendidos, supuestos no verificados, decisiones tomadas sin quien tenía la información.

De ahí vienen prácticas como la conversación directa y frecuente entre negocio y equipo técnico (otro principio pide que trabajen juntos a diario), los equipos pequeños y autoorganizados, y la retrospectiva: pararse a intervalos regulares a pensar cómo trabajar mejor y ajustarlo. Esta última es quizás la idea más potente del manifiesto, porque convierte la manera de trabajar en algo que también se itera y se mejora, igual que el producto.

Qué no es la agilidad

Conviene deshacer dos malentendidos habituales. El primero es que ágil no significa improvisar. Se planifica constantemente; lo que no se hace es fingir que un plan detallado a un año vista sobrevivirá al contacto con la realidad. El segundo es que ágil no es sinónimo de ningún marco concreto. Scrum, Kanban o Extreme Programming son implementaciones de los valores del manifiesto, cada una con sus herramientas. Se puede seguir Scrum al pie de la letra y no ser nada ágil, si las ceremonias se hacen vacías de contenido.

En resumen

La metodología ágil funciona porque acepta una verdad incómoda del desarrollo de software: la incertidumbre no se puede eliminar, solo gestionar. En lugar de intentar predecirlo todo al principio, construye un sistema que aprende rápido, con iteraciones cortas, feedback constante y el software funcionando como única medida fiable, y que puede cambiar de dirección cuando aprende algo nuevo. Casi veinticinco años después, los cuatro valores del manifiesto siguen siendo la mejor descripción breve de cómo se hace buen software: no siguiendo un proceso perfecto, sino colaborando, entregando a menudo y adaptándose.