Manifiesto Ágil: 4 Valores Principales & 12 Principios Explicados

La imagen de abajo proviene del sitio web del Manifiesto Ágil y muestra las cuatro declaraciones de valores Ágiles.

Agile Manifesto and the 4 Agile Values answer what agility is

Como puede ver en la introducción 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.

Personas e interacciones sobre procesos y herramientas

Como se mencionó anteriormente, cuando se lanzó el Manifiesto Ágil, desafió a las metodologías pesadas. El Modelo de Madurez de Capacidades (CMM) y ITIL eran tendencias populares hacia enfoques orientados a procesos en ese momento.

Por lo tanto, fue sorprendente que estos líderes de pensamiento decidieran comenzar con las personas. Creían que encontrar a las personas adecuadas (personas) dentro de un equipo y ayudarlas a colaborar de manera efectiva (interacciones) es mucho más importante que seguir cualquier proceso específico y/o utilizar herramientas particulares. Por eso pusieron el énfasis en el lado izquierdo: personas e interacciones.

Software funcional sobre documentación exhaustiva

En el desarrollo tradicional o en cascada de software, los equipos invertían mucho tiempo en recopilar requisitos y desarrollar diseños y especificaciones, solo construyendo algo tangible al final del ciclo de vida. Los autores del manifiesto creían que tener una solución funcional es más valiosa que tener una gran cantidad de documentos que describen cómo funciona la solución.

Colaboración con el cliente sobre negociación de contratos

El tercer valor es la colaboración con el cliente sobre la negociación de contratos—donde la negociación de contratos significa discutir sobre lo que está incluido en el alcance. Por ejemplo, podrías escuchar frases como «Eso no estaba en su documento de requisitos». Estos líderes de pensamiento creían que colaborar con nuestros clientes para entregar la solución que realmente necesitan es mucho más importante.

Responder al cambio sobre seguir un plan

El cuarto y último valor Ágil es responder al cambio sobre seguir un plan. Los autores coinciden en que la planificación es importante—de hecho, los equipos Ágiles hacen mucha planificación. Pero estos líderes de pensamiento creían que la capacidad de responder a los cambios inevitables es más crucial que adherirse a un plan elaborado al inicio de un proyecto, cuando la información aún es limitada.

Todos estos valores en el manifiesto son importantes, pero aquellos del lado izquierdo tienen mayor prioridad que los del lado derecho.

12 Principios Ágiles

Además de estos 4 valores Ágiles, los autores del Manifiesto Ágil acordaron un conjunto de 12 Principios Ágiles, que forman la base de las formas de trabajo Ágiles. Aunque menos conocidos que los 4 valores Ágiles, encuentro que los 12 principios Ágiles son más prácticos y ofrecen una guía más clara para las prácticas Ágiles.

12 Agile Principles behind the Agile Manifesto

Para mayor comodidad, he numerado los 12 principios, aunque no están numerados en el sitio web oficial.

  1. El primer principio es el mayor prioridades satisfacer al cliente mediante la entrega temprana y continua de software valioso. La frase «software valioso» confunde a algunos. Recuerde que en 2001, cuando estos líderes de pensamiento introdujeron los valores y principios Ágiles, se centraban únicamente en el desarrollo de software. Desde entonces, el Ágil se ha adoptado en casi todas las industrias—arquitectura, fabricación de automóviles e incluso producción de cazas de combate. Si le resulta más claro, sustituya «solución valiosa» por «software valioso».
  2. El segundo principio es dar la bienvenida a los cambios en los requisitos, incluso muy avanzado en el desarrollo. Mientras que la mayoría de las personas hoy se enfocan en controlar el cambio o gestionar el “crecimiento de alcance”, la realidad es que el cambio es inevitable. Los procesos ágiles posponen las decisiones, acortan los ciclos de desarrollo y apoyan el análisis oportuno de las solicitudes. Esto permite a los equipos ágiles adaptarse rápidamente y con bajo costo. Esto proporciona una ventaja competitiva y es uno de los pilares fundamentales del trabajo ágil.
  3. El tercer principio esentregar con frecuencia software funcional, de unas pocas semanas a unos pocos meses, preferiblemente con plazos más cortos. Una de las principales ventajas de la entrega frecuente es obtener retroalimentación para asegurarse de que se está en el camino correcto y realmente construyendo lo que el cliente necesita.
  4. El cuarto principio ágil trata sobrela colaboración diaria entre personas del negocio y desarrolladores a lo largo del proyecto. Hoy en día, los interesados del negocio a menudo crean documentos de requisitos y los “lanzan por encima del muro” a los desarrolladores. Meses o incluso años después, los desarrolladores entregan la solución al solicitante para la prueba final—solo para descubrir que la solución fue malinterpretada, construida incorrectamente o ya no es necesaria. El enfoque de este principio está en la colaboración entre quienes construyen la solución y quienes la utilizan, para evitar estos resultados.
  5. El quinto principio ágil esconstruir proyectos alrededor de personas motivadas, proporcionándoles el entorno y el apoyo que necesitan, y confiando en que cumplirán con su trabajo. Básicamente, se trata de un enfoque de tres partes: empoderar a las personas, otorgarles autonomía y confiar en ellas.
  6. El sexto principio ágil promueveel desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante indefinidamente. Cuando comencé a trabajar en proyectos tecnológicos, solían durar 6 meses, 12 meses o más. Era común lograr poco en los primeros meses. No sorprende que esto condujera a periodos de estrés extremo al final, donde debían 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 “marcha hacia la muerte”. Ágil no dice que nunca trabajarás en noches o fines de semana, pero sí enfatiza trabajar a un ritmo sostenible para todos.
  7. El principio siete es queel software funcional 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ícil 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 ágiles evitan el porcentaje de completitud al dividir el trabajo en funciones o funcionalidades, dividirlas en pequeños fragmentos y rastrear si estos fragmentos se han completado. Este enfoque evita métricas engañosas de progreso.
  8. El octavo principio es que la forma más efectiva y eficiente de transmitir información al equipo de desarrollo y dentro del equipo es a través dela conversación cara a cara. Hoy en día, la herramienta de comunicación más popular podría ser el correo electrónico. Es eficiente para el remitente—después de todo, pueden enviar mensajes a cientos o miles de personas a la vez. Pero no es una comunicación real. La investigación muestra que leer la escritura de otra persona deja un margen significativo para malentendidos. Los defensores del ágil han aprendido que la verdadera comprensión compartida requiere reunir a las personas. Si la conversación cara a cara no es posible, utilice el canal de comunicación de mayor ancho de banda disponible—esto podría ser videollamadas o llamadas telefónicas. Esto es mucho mejor que publicar documentos en SharePoint. La conclusión aquí es utilizar el canal de comunicación de mayor ancho de banda disponible. Un efecto secundario de preferir la interacción cara a cara es que tiene sentido colocar a los miembros del equipo del mismo equipo ágil juntos. Hoy en día, muchas organizaciones pasan por alto este punto aparentemente obvio.
  9. El principio nueve es el enfoque continuo enla excelencia técnica y el buen diseño para mejorar la agilidad. El enfoque está en evitar atajos o deuda técnica. No hagas algo que haga las cosas más rápidas a corto plazo pero que cueste más a largo plazo. Si sigues acumulando deuda técnica, perderás agilidad. Esto es común 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ás problemas en producción después del lanzamiento. Esto resulta en tareas de emergencia y código difícil de mantener.
  10. El principio 10 trata sobre mantener las cosas simples y eliminar el trabajo innecesario.La simplicidad—el arte de maximizar la cantidad de trabajo que no se hace—es esencial.Es decir, debemos examinar nuestros procesos y eliminar cualquier cosa que no aporte valor al cliente, maximizando así la cantidad de trabajo no realizado, sin dejar de entregar lo necesario.
  11. El principio 10 también trata sobre los equipos autogestionados. Las mejores arquitecturas, requisitos y diseños provienen deequipos autogestionados. Deberíamos permitir que quienes están más cerca del trabajo decidan cómo hacerlo mejor—esta es la esencia de este principio.
  12. El principio final, el número 12, trata sobre las retrospectivas. Los equipos reflexionan regularmente sobre cómo volverse más efectivos y luegoajustar y adaptarsesu comportamiento en consecuencia.

Los valores y principios ágiles pueden no parecer radicales hoy en día, pero cuando se anunciaron en 2001, fueron bastante revolucionarios. Por eso el término «Manifiesto». Ellos definieron una forma de trabajar completamente diferente a la forma en que las organizaciones habían operado en el siglo anterior. Antes de eso, el desarrollo de software se asemejaba en gran medida a las prácticas laborales de la era industrial. Comprender este contexto histórico es crucial, como se discute a continuación.

 

 

Dejar una contestacion