Manifiesto Ágil: los 4 valores, explicados y en español
El Manifiesto por el Desarrollo Ágil de Software es una declaración muy corta: una frase de introducción, cuatro valores y una frase de cierre. Cabe en una servilleta, y aun así es de los textos más citados (y peor leídos) de nuestra profesión.
Los 4 valores del Manifiesto Ágil
Este es el texto oficial en español, tal y como aparece en agilemanifesto.org:
| Valoramos más… | …que |
|---|---|
| Individuos e interacciones | procesos y herramientas |
| Software funcionando | documentación extensiva |
| Colaboración con el cliente | negociación contractual |
| Respuesta ante el cambio | seguir un plan |
Y la frase que da sentido a todo lo demás:
Aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Cómo se lee: es un desempate, no una prohibición
Piensa en una balanza con algo valioso en cada plato. Tener un plan es útil: nadie quiere trabajar sin saber hacia dónde va. Pero cuando el plan y lo que pide la realidad chocan, la balanza se inclina hacia responder al cambio. El plato del plan no se vacía: sigue pesando, solo que pesa menos.
Así funciona cada valor del manifiesto. Las dos cosas son buenas. La palabra clave es «sobre»: cuando las dos chocan y hay que elegir, gana la de la izquierda.
Individuos e interacciones sobre procesos y herramientas
Un proceso o una herramienta no arreglan un equipo que no habla entre sí. Si el procedimiento dice que hay que abrir una incidencia y la persona que sabe la respuesta está en la mesa de al lado, pregúntale.
Software funcionando sobre documentación extensiva
La mejor forma de saber si vas bien es enseñar algo que funcione. Un documento de cien páginas describe lo que se quiere hacer; un programa que funciona demuestra lo que ya está hecho. Documentar sigue siendo útil, pero no sustituye a entregar.
Colaboración con el cliente sobre negociación contractual
El contrato marca las reglas, pero el producto sale mejor si el cliente participa durante el desarrollo y no solo al principio y al final. Es la diferencia entre tratarle como un rival en una negociación o como parte del equipo.
Respuesta ante el cambio sobre seguir un plan
Los requisitos cambian: el mercado se mueve, el cliente aprende qué necesita al ver el producto, aparecen problemas que nadie previó. Un equipo ágil planifica, pero acepta que el plan se revisa.
Tres errores frecuentes al leerlo
Lo que no dice
- «En ágil no se documenta»
- «En ágil no hay plan»
- «Los procesos y las herramientas sobran»
Lo que sí dice
- Se documenta lo que aporta, sin que sustituya a entregar software
- Se planifica, y el plan cambia cuando la realidad lo pide
- Ayudan, pero no por encima de las personas
Los tres errores tienen el mismo origen: leer los valores como «esto sí, esto no», cuando la frase final dice expresamente que lo de la derecha también tiene valor.
De dónde salió
Según la historia que publica el propio sitio, escrita por Jim Highsmith, el 11, 12 y 13 de febrero de 2001 se reunieron 17 personas en la estación de esquí de Snowbird, en Utah. Venían de corrientes distintas, como Extreme Programming, Scrum, DSDM, Crystal o Feature-Driven Development, y todas buscaban una alternativa a los procesos pesados, guiados por la documentación. De ahí salió el manifiesto, firmado por todos los asistentes. Entre ellos estaba Kent Beck, el creador de Extreme Programming (XP).
Los cuatro valores se completan con doce principios, que bajan las ideas a algo más concreto: entregas frecuentes, ritmo sostenible, atención a la excelencia técnica, etc. Si quieres el panorama general, empieza por Agilismo.
El texto completo
Los autores permiten copiar y distribuir la declaración por cualquier medio, siempre que sea íntegra. Esta es la versión oficial en español:
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
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 planEsto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, los autores mencionados mediante esta nota se autoriza la copia y distribución de esta declaración a través de cualquier medio pero sólo de forma íntegra.
¿Siguen valiendo los valores cuando programas con IA?
Esto ya no es el manifiesto, sino una lectura propia desde el enfoque de IA Limpia. Los firmantes escribieron en 2001 y no hablaban de agentes de IA.
- Software funcionando no es lo mismo que código generado. Que un agente produzca cien líneas que compilan no demuestra nada; lo demuestran los tests que pasan y alguien que ha revisado el resultado.
- Individuos e interacciones sobre herramientas encaja de lleno: la IA es una herramienta más. La conversación con el equipo y con el cliente sobre qué hay que construir no se delega.
- Respuesta ante el cambio depende de que el código se pueda cambiar. Si la IA acelera la deuda técnica, cada cambio sale más caro y el equipo deja de poder responder.
Fuentes
Comprobado el 7 de noviembre de 2026 en el sitio oficial del manifiesto:
- Manifiesto por el Desarrollo Ágil de Software, versión oficial en español (traducción de Ángel Medinilla, Andrés Giné y Esther Gómez). El texto de los valores, la frase final, los firmantes y la nota de copia están copiados de esta página.
- Manifesto for Agile Software Development, versión original en inglés.
- History: The Agile Manifesto, de Jim Highsmith: fecha, lugar y corrientes representadas en la reunión.
Este artículo no incluye código ni comandos.