{"id":10853,"date":"2026-03-05T22:41:03","date_gmt":"2026-03-05T14:41:03","guid":{"rendered":"https:\/\/www.archimetric.com\/es\/agile-manifesto-4-values-12-principles-explained\/"},"modified":"2026-03-05T22:41:03","modified_gmt":"2026-03-05T14:41:03","slug":"agile-manifesto-4-values-12-principles-explained","status":"publish","type":"post","link":"https:\/\/www.archimetric.com\/es\/agile-manifesto-4-values-12-principles-explained\/","title":{"rendered":"Manifiesto \u00c1gil: 4 Valores Principales & 12 Principios Explicados"},"content":{"rendered":"

La imagen de abajo proviene del sitio web del Manifiesto \u00c1gil<\/a> y muestra las cuatro declaraciones de valores \u00c1giles.<\/p>\n

\"Agile<\/p>\n

Como puede ver en la introducci\u00f3n a los valores, los autores afirman que estaban descubriendo mejores formas de desarrollar software y ayudar a otros. Todos los valores son importantes, pero aquellos del lado izquierdo tienen prioridad sobre los del lado derecho.<\/p>\n

Personas e interacciones sobre procesos y herramientas<\/b><\/p>\n

Como se mencion\u00f3 anteriormente, cuando se lanz\u00f3 el Manifiesto \u00c1gil, desafi\u00f3 a las metodolog\u00edas pesadas. El Modelo de Madurez de Capacidades (CMM) y ITIL eran tendencias populares hacia enfoques orientados a procesos en ese momento.<\/p>\n

Por lo tanto, fue sorprendente que estos l\u00edderes de pensamiento decidieran comenzar con las personas. Cre\u00edan que encontrar a las personas adecuadas (personas<\/strong>) dentro de un equipo y ayudarlas a colaborar de manera efectiva (interacciones<\/strong>) es mucho m\u00e1s importante que seguir cualquier proceso espec\u00edfico y\/o utilizar herramientas particulares. Por eso pusieron el \u00e9nfasis en el lado izquierdo: personas e interacciones.<\/p>\n

Software funcional sobre documentaci\u00f3n exhaustiva<\/strong><\/p>\n

En el desarrollo tradicional o en cascada de software, los equipos invert\u00edan mucho tiempo en recopilar requisitos y desarrollar dise\u00f1os y especificaciones, solo construyendo algo tangible al final del ciclo de vida. Los autores del manifiesto cre\u00edan que tener una soluci\u00f3n funcional es m\u00e1s valiosa que tener una gran cantidad de documentos que describen c\u00f3mo funciona la soluci\u00f3n.<\/p>\n

Colaboraci\u00f3n con el cliente sobre negociaci\u00f3n de contratos<\/strong><\/p>\n

El tercer valor es la colaboraci\u00f3n con el cliente sobre la negociaci\u00f3n de contratos\u2014donde la negociaci\u00f3n de contratos significa discutir sobre lo que est\u00e1 incluido en el alcance. Por ejemplo, podr\u00edas escuchar frases como \u00abEso no estaba en su documento de requisitos\u00bb. Estos l\u00edderes de pensamiento cre\u00edan que colaborar con nuestros clientes para entregar la soluci\u00f3n que realmente necesitan es mucho m\u00e1s importante.<\/p>\n

Responder al cambio sobre seguir un plan<\/strong><\/p>\n

El cuarto y \u00faltimo valor \u00c1gil es responder al cambio sobre seguir un plan. Los autores coinciden en que la planificaci\u00f3n es importante\u2014de hecho, los equipos \u00c1giles hacen mucha planificaci\u00f3n. Pero estos l\u00edderes de pensamiento cre\u00edan que la capacidad de responder a los cambios inevitables es m\u00e1s crucial que adherirse a un plan elaborado al inicio de un proyecto, cuando la informaci\u00f3n a\u00fan es limitada.<\/p>\n

Todos estos valores en el manifiesto son importantes, pero aquellos del lado izquierdo tienen mayor prioridad que los del lado derecho.<\/p>\n

12 Principios \u00c1giles<\/a><\/h2>\n

Adem\u00e1s de estos 4 valores \u00c1giles, los autores del Manifiesto \u00c1gil acordaron un conjunto de 12 Principios \u00c1giles<\/a>, que forman la base de las formas de trabajo \u00c1giles. Aunque menos conocidos que los 4 valores \u00c1giles, encuentro que los 12 principios \u00c1giles son m\u00e1s pr\u00e1cticos y ofrecen una gu\u00eda m\u00e1s clara para las pr\u00e1cticas \u00c1giles.<\/p>\n

\"12<\/p>\n

Para mayor comodidad, he numerado los 12 principios, aunque no est\u00e1n numerados en el sitio web oficial<\/a>.<\/p>\n

    \n
  1. El primer principio es el mayor prioridad<\/strong>es satisfacer al cliente mediante la entrega temprana y continua de software valioso. La frase \u00absoftware valioso\u00bb confunde a algunos. Recuerde que en 2001, cuando estos l\u00edderes de pensamiento introdujeron los valores y principios \u00c1giles, se centraban \u00fanicamente en el desarrollo de software. Desde entonces, el \u00c1gil se ha adoptado en casi todas las industrias\u2014arquitectura, fabricaci\u00f3n de autom\u00f3viles e incluso producci\u00f3n de cazas de combate. Si le resulta m\u00e1s claro, sustituya \u00absoluci\u00f3n valiosa\u00bb por \u00absoftware valioso\u00bb.<\/li>\n
  2. El segundo principio es dar la bienvenida a los cambios en los requisitos<\/strong>, incluso muy avanzado en el desarrollo. Mientras que la mayor\u00eda de las personas hoy se enfocan en controlar el cambio o gestionar el \u201ccrecimiento de alcance\u201d, la realidad es que el cambio es inevitable. Los procesos \u00e1giles posponen las decisiones, acortan los ciclos de desarrollo y apoyan el an\u00e1lisis oportuno de las solicitudes. Esto permite a los equipos \u00e1giles adaptarse r\u00e1pidamente y con bajo costo. Esto proporciona una ventaja competitiva y es uno de los pilares fundamentales del trabajo \u00e1gil.<\/li>\n
  3. El tercer principio esentregar con frecuencia software funcional<\/strong>, de unas pocas semanas a unos pocos meses, preferiblemente con plazos m\u00e1s cortos. Una de las principales ventajas de la entrega frecuente es obtener retroalimentaci\u00f3n para asegurarse de que se est\u00e1 en el camino correcto y realmente construyendo lo que el cliente necesita.<\/li>\n
  4. El cuarto principio \u00e1gil trata sobrela colaboraci\u00f3n diaria entre personas del negocio y desarrolladores<\/strong> a lo largo del proyecto. Hoy en d\u00eda, los interesados del negocio a menudo crean documentos de requisitos y los \u201clanzan por encima del muro\u201d a los desarrolladores. Meses o incluso a\u00f1os despu\u00e9s, los desarrolladores entregan la soluci\u00f3n al solicitante para la prueba final\u2014solo para descubrir que la soluci\u00f3n fue malinterpretada, construida incorrectamente o ya no es necesaria. El enfoque de este principio est\u00e1 en la colaboraci\u00f3n entre quienes construyen la soluci\u00f3n y quienes la utilizan, para evitar estos resultados.<\/li>\n
  5. El quinto principio \u00e1gil esconstruir proyectos alrededor de personas motivadas<\/strong>, proporcion\u00e1ndoles el entorno y el apoyo que necesitan, y confiando en que cumplir\u00e1n con su trabajo. B\u00e1sicamente, se trata de un enfoque de tres partes: empoderar a las personas, otorgarles autonom\u00eda y confiar en ellas.<\/li>\n
  6. El sexto principio \u00e1gil promueveel desarrollo sostenible<\/strong>. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante indefinidamente. Cuando comenc\u00e9 a trabajar en proyectos tecnol\u00f3gicos, sol\u00edan durar 6 meses, 12 meses o m\u00e1s. Era com\u00fan lograr poco en los primeros meses. No sorprende que esto condujera a periodos de estr\u00e9s extremo al final, donde deb\u00edan completarse cargas de trabajo enormes. Se esperaba que los miembros del equipo trabajaran en las noches o fines de semana para cumplir con fechas y alcances fijos. Esto se conoce como un proyecto de \u201cmarcha hacia la muerte\u201d. \u00c1gil no dice que nunca trabajar\u00e1s en noches o fines de semana, pero s\u00ed enfatiza trabajar a un ritmo sostenible para todos.<\/li>\n
  7. El principio siete es queel software funcional<\/strong> es la medida principal del progreso. Tradicionalmente, se ha usado el porcentaje de completitud para rastrear el progreso del proyecto. El porcentaje de completitud es altamente poco confiable porque es dif\u00edcil de evaluar, especialmente cuando alcanza el 80% o el 90%. Un 90% de completitud a menudo significa que solo queda un 10% de esfuerzo o tiempo. Los equipos \u00e1giles evitan el porcentaje de completitud al dividir el trabajo en funciones o funcionalidades, dividirlas en peque\u00f1os fragmentos y rastrear si estos fragmentos se han completado. Este enfoque evita m\u00e9tricas enga\u00f1osas de progreso.<\/li>\n
  8. El octavo principio es que la forma m\u00e1s efectiva y eficiente de transmitir informaci\u00f3n al equipo de desarrollo y dentro del equipo es a trav\u00e9s dela conversaci\u00f3n cara a cara<\/strong>. Hoy en d\u00eda, la herramienta de comunicaci\u00f3n m\u00e1s popular podr\u00eda ser el correo electr\u00f3nico. Es eficiente para el remitente\u2014despu\u00e9s de todo, pueden enviar mensajes a cientos o miles de personas a la vez. Pero no es una comunicaci\u00f3n real. La investigaci\u00f3n muestra que leer la escritura de otra persona deja un margen significativo para malentendidos. Los defensores del \u00e1gil han aprendido que la verdadera comprensi\u00f3n compartida requiere reunir a las personas. Si la conversaci\u00f3n cara a cara no es posible, utilice el canal de comunicaci\u00f3n de mayor ancho de banda disponible\u2014esto podr\u00eda ser videollamadas o llamadas telef\u00f3nicas. Esto es mucho mejor que publicar documentos en SharePoint. La conclusi\u00f3n aqu\u00ed es utilizar el canal de comunicaci\u00f3n de mayor ancho de banda disponible. Un efecto secundario de preferir la interacci\u00f3n cara a cara es que tiene sentido colocar a los miembros del equipo del mismo equipo \u00e1gil juntos. Hoy en d\u00eda, muchas organizaciones pasan por alto este punto aparentemente obvio.<\/li>\n
  9. El principio nueve es el enfoque continuo enla excelencia t\u00e9cnica y el buen dise\u00f1o<\/strong> para mejorar la agilidad. El enfoque est\u00e1 en evitar atajos o deuda t\u00e9cnica. No hagas algo que haga las cosas m\u00e1s r\u00e1pidas a corto plazo pero que cueste m\u00e1s a largo plazo. Si sigues acumulando deuda t\u00e9cnica, perder\u00e1s agilidad. Esto es com\u00fan en proyectos en cascada con plazos fijos. Para cumplir con las fechas prometidas, se toman atajos. Los ciclos de pruebas pueden reducirse o eliminarse para ahorrar tiempo, lo que conduce a m\u00e1s problemas en producci\u00f3n despu\u00e9s del lanzamiento. Esto resulta en tareas de emergencia y c\u00f3digo dif\u00edcil de mantener.<\/li>\n
  10. El principio 10 trata sobre mantener las cosas simples y eliminar el trabajo innecesario.La simplicidad\u2014el arte de maximizar la cantidad de trabajo que no se hace\u2014es esencial.<\/strong>Es decir, debemos examinar nuestros procesos y eliminar cualquier cosa que no aporte valor al cliente, maximizando as\u00ed la cantidad de trabajo no realizado, sin dejar de entregar lo necesario.<\/li>\n
  11. El principio 10 tambi\u00e9n trata sobre los equipos autogestionados. Las mejores arquitecturas, requisitos y dise\u00f1os provienen deequipos autogestionados<\/strong>. Deber\u00edamos permitir que quienes est\u00e1n m\u00e1s cerca del trabajo decidan c\u00f3mo hacerlo mejor\u2014esta es la esencia de este principio.<\/li>\n
  12. El principio final, el n\u00famero 12, trata sobre las retrospectivas. Los equipos reflexionan regularmente sobre c\u00f3mo volverse m\u00e1s efectivos y luegoajustar y adaptarse<\/strong>su comportamiento en consecuencia.<\/li>\n<\/ol>\n

    Los valores y principios \u00e1giles pueden no parecer radicales hoy en d\u00eda, pero cuando se anunciaron en 2001, fueron bastante revolucionarios. Por eso el t\u00e9rmino \u00abManifiesto\u00bb. Ellos definieron una forma de trabajar completamente diferente a la forma en que las organizaciones hab\u00edan operado en el siglo anterior. Antes de eso, el desarrollo de software se asemejaba en gran medida a las pr\u00e1cticas laborales de la era industrial. Comprender este contexto hist\u00f3rico es crucial, como se discute a continuaci\u00f3n.<\/p>\n

    \u00a0<\/p>\n

    <\/p>\n