Principios ágiles: el Manifiesto, sus valores y lo que cambian

En febrero de 2001, diecisiete profesionales que llevaban tiempo experimentando cada uno por su cuenta con métodos de desarrollo ligeros se reunieron y acordaron una única página de texto. Esa página —el Manifiesto por el Desarrollo Ágil de Software— tiene cuatro declaraciones de valores y doce principios que las acompañan, y nada más. No nombra roles, ni reuniones, ni artefactos, ni certificaciones. Todo lo que hoy se llama ágil, desde los tableros de Scrum hasta los eventos de planificación trimestral y toda la industria del escalado, se construyó después encima de esa página, y buena parte lo contradice.

Precisamente por esa distancia, esta guía empieza por el propio texto. Si entiendes qué afirman realmente los valores y contra qué problema reaccionaban sus autores, puedes evaluar cualquier práctica que te pongan delante —incluidas las que tu organización ya usa— por sus méritos y no por si lleva la etiqueta de ágil. Este artículo se queda en el nivel de los valores y los principios; la guía del framework Scrum cubre la implementación concreta más extendida, y la de fundamentos de la gestión de proyectos cubre la tradición predictiva con la que discutía el manifiesto.

Por qué se escribió el manifiesto

El modelo dominante en los años noventa venía de disciplinas de ingeniería en las que la forma del producto se conocía antes de empezar a construir. Se recogían los requisitos, se escribía una especificación, se diseñaba el sistema, se construía, se probaba y se entregaba, y cada fase se completaba y se aprobaba antes de empezar la siguiente. Al enfoque se le suele llamar waterfall o cascada, por un artículo de 1970 que presentaba el diagrama secuencial como un ejemplo defectuoso para luego proponer iterar; la industria adoptó el diagrama e ignoró la advertencia.

Las fases secuenciales funcionan cuando se cumplen tres condiciones: los requisitos se pueden conocer de verdad por adelantado, no cambian mientras construyes y el coste de descubrir un error al final es asumible. El software rara vez cumple alguna de ellas. Los usuarios no saben describir lo que quieren hasta que ven algo; los mercados se mueven durante un desarrollo de dieciocho meses; y los defectos que más importan —un flujo de trabajo mal entendido, una pantalla inservible, un techo de rendimiento en la arquitectura— solo se hacen visibles cuando alguien intenta usar el producto. Un proyecto que descubre su malentendido central durante las pruebas de aceptación ya se ha gastado el presupuesto.

Los métodos ligeros de finales de los noventa fueron reacciones independientes a ese patrón. Diferían en los detalles, pero compartían una apuesta: si no puedes conocer la respuesta de antemano, acorta el ciclo entre hacer y aprender hasta que equivocarse cueste poco.

Los cuatro valores

Cada valor está escrito como una comparación, y todos terminan con la misma aclaración: aunque los elementos de la derecha tienen valor, los autores valoran más los de la izquierda. Esa formulación importa. Ninguno de los cuatro es una orden de abandonar el elemento de la derecha.

Individuos e interacciones sobre procesos y herramientas. Un proceso definido hace que la gente buena sea algo más consistente; no convierte a un equipo flojo en uno bueno. Cuando algo sale mal, la primera pregunta en la mayoría de las organizaciones es qué paso del proceso se saltó. La pregunta del manifiesto es qué conversación no tuvo lugar. En la práctica, esto significa juntar físicamente, o conectar bien, a las personas que necesitan hablar, mantener equipos pequeños y estables, y tratar una herramienta como algo que registra una decisión y no como algo que la toma.

Software funcionando sobre documentación extensiva. La única medida honesta del progreso es un sistema en marcha que hace algo que un usuario reconoce. Una especificación completa al noventa por ciento no te dice nada sobre cuánto producto existe. Es el valor del que más se abusa, y las preguntas frecuentes de más abajo tratan ese abuso; la disciplina que exige es que cada documento tenga un lector identificado y una razón para existir.

Colaboración con el cliente sobre negociación contractual. Los contratos de alcance y precio cerrados crean una relación de confrontación en la que cada descubrimiento se convierte en una solicitud de cambio y en una pelea. La alternativa es fijar el presupuesto y el calendario y dejar que el alcance varíe, con el cliente presente de forma continua para decidir qué cabe dentro. Eso requiere un cliente dispuesto a implicarse cada semana y no solo en los hitos, que suele ser lo más difícil de conseguir en una adopción ágil.

Respuesta ante el cambio sobre seguir un plan. Un plan es una previsión hecha en el momento de máxima ignorancia. Tratar cualquier desviación como un fracaso genera una fuerte presión para ocultar las malas noticias. Tratar el plan como algo que se revisa a medida que llegan datos hace que dar malas noticias salga barato, que es la única forma de que lleguen a tiempo para actuar.

Los doce principios en la práctica

Los principios son más concretos que los valores, y en ellos está la mayor parte del contenido práctico. En lugar de enumerarlos como eslóganes, esto es lo que cada uno le pide a un equipo que haga de forma distinta.

Tres de ellos merecen una pausa porque se pasan por alto sistemáticamente. El principio nueve vincula la agilidad a la calidad de ingeniería: un código sin tests no puede absorber requisitos cambiantes, así que un equipo que adopta iteraciones sin adoptar test-driven development, integración continua y refactoring irá más lento en cada iteración hasta detenerse. El principio ocho descarta el ciclo de sprint y colapso que muchos equipos confunden con alto rendimiento. Y el principio doce es el motor: sin una retrospectiva que cambie algo, los otros once son reglas estáticas y no un sistema que mejora.

Control empírico de procesos

Debajo de todo esto hay una idea tomada de la ingeniería de procesos. Un proceso definido es uno que puedes especificar por completo de antemano y luego ejecutar: con las mismas entradas produce las mismas salidas, así que planificarlo una vez es racional. Un proceso empírico es uno en el que hay demasiadas variables desconocidas, por lo que se controla mediante inspección y adaptación frecuentes: haces un poco, miras el resultado y ajustas.

El empirismo necesita tres cosas para funcionar: transparencia, para que todos vean el mismo estado real del trabajo; inspección, con una frecuencia lo bastante corta como para que un giro equivocado salga barato; y adaptación, es decir, la autoridad y la disposición para cambiar de rumbo según lo observado. Quita cualquiera de las tres y el ciclo se rompe. Un equipo que inspecciona cada semana pero no tiene autoridad para cambiar nada está celebrando una reunión de seguimiento, no dirigiendo un proceso empírico.

Iterativo e incremental son las dos técnicas que hacen posible la inspección, y no son sinónimos. Incremental significa construir el producto en porciones que añaden cada una funcionalidad utilizable: un flujo de inicio de sesión, luego una búsqueda, luego un proceso de pago. Iterativo significa volver sobre lo que ya existe y mejorarlo a medida que aprendes. Una entrega real necesita ambas cosas: cortar lo bastante fino como para publicar y contar con que habrá que rehacer las primeras porciones en cuanto los usuarios las toquen. Un equipo que solo trabaja de forma incremental acumula un producto lleno de primeros borradores.

Malas interpretaciones habituales

• «Ágil significa sin documentación». La declaración de valor compara la documentación con el software funcionando; no la elimina. Los productos regulados, las API públicas y los sistemas que sobreviven a su equipo necesitan material escrito duradero.
• «Ágil significa sin estimaciones ni fechas». Las decisiones de negocio necesitan previsiones. Lo ágil cambia cómo se hacen las previsiones y con qué frecuencia se revisan —consulta estimación y planificación—, no si existen.
• «Ágil significa sin arquitectura». Diseño emergente no es ausencia de diseño. Significa aplazar las decisiones hasta el último momento responsable y mantener bajo revisión deliberada las que son caras de revertir.
• «Hacemos sprints de dos semanas, así que somos ágiles». La duración de la iteración es lo más fácil de copiar y lo que menos significa. Un equipo que planifica dos semanas de tareas asignadas, informa del estado a diario y publica dos veces al año ha cambiado su calendario y nada más.
• «Autoorganización significa sin gestión». Los equipos deciden cómo hacer el trabajo. Alguien sigue marcando la dirección, financiando el esfuerzo, contratando y resolviendo los problemas que están fuera del alcance del equipo.

Dónde no encaja lo ágil

Ser honesto con los límites es lo que separa a un profesional de un evangelista.

Los enfoques adaptativos dan por hecho que cambiar de opinión tarde es asumible. Donde no lo es —obra civil, una tirada de producción de hardware, el lanzamiento de un satélite, una migración con un único corte irreversible—, un análisis previo exhaustivo es la opción racional, y los modelos híbridos que planifican de forma predictiva las partes inamovibles mientras desarrollan el software de forma adaptativa dentro de ellas funcionan mejor que fingir que todo es flexible.

También dan por hecho un cliente que se implique. Cuando el comprador firma un contrato de alcance cerrado y luego desaparece durante seis meses, o cuando una norma de contratación pública exige la especificación completa antes de elegir proveedor, el valor de la colaboración se queda sin espacio. Y dan por hecho un equipo lo bastante pequeño como para hablar entre sí. Coordinar muchos equipos requiere estructura adicional, que es lo que intentan aportar los frameworks de escalado y la razón por la que son tan polémicos.

Por último, lo ágil a nivel de equipo no puede arreglar un pipeline de entrega que tarda tres meses en llevar un cambio a producción. Esa es justo la restricción que las prácticas DevOps existen para eliminar, y sin ellas un equipo puede ser perfectamente ágil hasta el punto en que su trabajo se queda esperando en una cola.

Ideas clave

• El manifiesto es una página con cuatro valores y doce principios; cada framework, rol y ceremonia que se asocia con lo ágil se añadió después y es opcional.
• Cada valor es una comparación que reconoce explícitamente que el elemento de la derecha sigue valiendo algo; ninguno elimina la documentación, los contratos ni los planes.
• El control empírico de procesos —transparencia, inspección y adaptación en un ciclo corto— es el mecanismo; la entrega iterativa e incremental es la forma de tener algo que inspeccionar.
• La excelencia técnica no es un adorno opcional: sin tests, automatización y refactoring, la capacidad de aceptar el cambio desaparece en pocos meses.
• El enfoque encaja con el trabajo del conocimiento con requisitos inciertos y decisiones reversibles, y encaja mal donde un cambio tardío es de verdad catastrófico o el cliente no puede participar.
• Copiar el calendario —sprints, dailies, un tablero— sin cambiar quién decide, con qué frecuencia se publica y con qué honestidad se informa es la adopción fallida más común.