El manifiesto ágil (también Manifiesto por el desarrollo ágil de software, ) es una declaración creada en 2001 en Estados Unidos que define cuatro valores principales y doce principios para mejorar el desarrollo de software, dando prioridad a las personas, la adaptabilidad y la entrega de valor real frente a los procesos rígidos.
Historia El 12 de febrero de 2001 diecisiete críticos de los modelos de mejora del desarrollo de software basados en procesos, convocados por Kent Beck, quien había publicado un par de años antes Extreme Programming Explained, libro en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en Snowbird,UtahQ3487194. (2025, November 9). Wikidata. Retrieved 06:41, April 11, 2026 from https://www.wikidata.org/w/index.php?title=Q3487194&oldid=2427494099. para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término Métodos Ágiles para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales (CMMI, SPICE) a las que consideraban excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.
Los integrantes de la reunión resumieron los principios sobre los que se basan los métodos alternativos en cuatro postulados, lo que ha quedado denominado como Manifiesto ágil.
Hasta mediados de la década de 2000, el panorama del desarrollo de software se caracterizó por una fuerte polarización entre dos enfoques principales: los modelos de procesos predictivos o plan-driven (tradicionalmente representados por el modelo en cascada o Waterfall) y los modelos ágiles o ligeros. Esta confrontación generó posturas a menudo radicales. Muchos defensores de uno y otro bando dedicaron más esfuerzos a criticar y descalificar el enfoque contrario que a analizar en profundidad sus respectivos métodos, fortalezas y posibles áreas de mejora. En lugar de buscar una comprensión objetiva que permitiera enriquecer ambas escuelas de pensamiento, el debate frecuentemente derivó en una oposición binaria y dogmática: los partidarios de los métodos tradicionales acusaban a los enfoques ágiles de carecer de disciplina, rigor y previsibilidad; mientras que los defensores de lo ágil criticaban los modelos predictivos por su rigidez, su incapacidad para adaptarse al cambio y su tendencia a generar proyectos largos, costosos y desconectados de las necesidades reales del cliente. Este clima de confrontación fue especialmente visible en los años previos y posteriores a la publicación del Manifiesto Ágil en 2001, aunque sus raíces se remontan a las críticas que surgieron durante la década de 1990 contra los métodos “pesados” dominantes. Solo con el paso del tiempo, y a medida que se acumuló evidencia empírica y experiencia práctica, el debate comenzó a evolucionar hacia una perspectiva más madura, que reconoce las ventajas y limitaciones contextuales de cada enfoque y explora posibles combinaciones o usos híbridos según el tipo de proyecto, el sector y el nivel de incertidumbre involucrado.
En el Manifiesto Ágil, firmado por 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 y Dave Thomas,Firmantes del Manifiesto Ágil se expone que:
Valores Los valores del manifiesto son:
Valorar más a los individuos y sus interacciones que a los procesos y las herramientas
Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la reingeniería de procesos ha dado a estos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan. Además, se centra en los individuos, los roles son intercambiables.
Los procesos deben ser una ayuda y respaldo para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.
Con cambios tan rápidos que se dan en todos los ámbitos, es innegable que los procesos y herramientas en una organización competitiva deban cambiar ágilmente. Para ello, es vital primeramente que las personas propongan iniciativas de cambio o se adapten rápidamente al mismo.
Valorar más el software que funciona que la documentación exhaustiva
Poder ver anticipadamente cómo se comportan las funcionalidades esperadas sobre prototipos o sobre las partes ya elaboradas del sistema final ofrece una retroalimentación muy estimulante y enriquecedora que genera ideas imposibles de concebir en un primer momento; difícilmente se podrá conseguir un documento que contenga requisitos detallados antes de comenzar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son apoyo del software, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.
Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, estos documentos se acaban empleando de forma defensiva como barricadas ante departamentos o personas.
Valorar más la colaboración con el cliente que la negociación contractual
Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.
Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.
Valorar más la respuesta ante el cambio que seguir un plan
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta ante el cambio que la de seguimiento y aseguramiento de planes preestablecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Principios Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los principios que de ellos se derivan:
Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al período de tiempo más corto posible. Los responsables del negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. El software funcionando es la medida principal de progreso. Los procesos ágiles promueven el desarrollo sostenido. Los promotores, desarrolladores y usuarios debemos mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento en consecuencia.
Referencias
Enlaces externos Manifiesto por el Desarrollo Ágil de Software Recopilación de artículos sobre metodologías ágiles Más información sobre el liderazgo organizacional con management 3.0 en Youssef Oufaska
Categoría:Ingeniería de software Categoría:Gestión de proyectos Categoría:Manifiestos Categoría:Manifiestos informáticos
en:Agile Manifesto he:מנשר לפיתוח תוכנה זריז nl:Agile Manifesto pt:Manifesto ágil