Menú

Manifiesto ágil: comprensión de los valores y principios ágiles

  • Principal
  • Otro
  • Manifiesto ágil: comprensión de los valores y principios ágiles

agile manifesto understanding agile values

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Introducción al Manifiesto Ágil:

Nuestro tutorial anterior sobre Metodología ágil nos explicó todo sobre los modelos y metodologías ágiles en detalle.

Pero hasta ahora no nos hemos preocupado por qué había una necesidad de agilidad en primer lugar y qué tan ágil superó las deficiencias de las metodologías de desarrollo de software existentes como el modelo en cascada.

En este tutorial, profundizaremos en los detalles del ágil y el manifiesto ágil. Veremos qué dice el manifiesto y cuáles son los valores y principios consagrados en él.

manifiesto ágil

Lo que vas a aprender:

Introducción

Como vimos en nuestro tutorial anterior , las metodologías de desarrollo anteriores llevaban demasiado tiempo y, cuando el software estaba listo para su implementación, los requisitos comerciales habrían cambiado, por lo que no satisfacían las necesidades actuales.

La velocidad de cambio que faltaba en ese momento estaba causando muchos problemas. Cuando los líderes de diferentes metodologías de desarrollo se reunieron para decidir el camino a seguir, pudieron acordar un método mejor y también pudieron finalizar la redacción del manifiesto.

Esto fue capturado como 4 valores y 12 principios para ayudar a los practicantes a comprenderlo, referirlo y ponerlo en práctica. Y en ese momento, ninguno de ellos podría haber imaginado el impacto que esto tendría en el futuro de la gestión de proyectos.

Manifiesto ágil

El manifiesto ha sido redactado con mucho cuidado para capturar la esencia de lo ágil en palabras mínimas y se lee a continuación:

“Estamos descubriendo mejores formas de desarrollar un software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado al siguiente valor:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software de trabajo sobre documentación completa.
  • Colaboración con el cliente sobre negociación de contratos.
  • Responde al cambio sobre el siguiente plan.

Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda '.

Como podemos ver, estas son declaraciones bastante concisas y simples y dejan muy claro lo que los fundadores querían promover. Por lo general, los planes de proyectos tradicionales son rígidos y enfatizan los procedimientos y los plazos, pero el manifiesto ágil propaga exactamente lo contrario.

Prefiere:

  • Gente
  • Producto
  • Comunicación y
  • Sensibilidad

Exploraremos este nuevo paradigma que los fundadores querían promover en detalle obteniendo una comprensión más profunda de los valores y principios ágiles.

Los 4 valores ágiles

Los cuatro valores junto con los 12 principios guían la entrega ágil de software. Discutiremos cada uno de los valores en detalle ahora.

Valores ágiles

# 1) Individuos e interacciones sobre procesos y herramientas

Se prefieren los individuos y las interacciones a los procesos y herramientas porque hace que el proceso sea más receptivo. Si las personas están alineadas y una vez que se entienden, el equipo puede resolver cualquier problema con las herramientas o los procesos.

Pero si los equipos insisten en ceñirse ciegamente a los procesos, podría causar malentendidos entre las personas y crear obstáculos inesperados, lo que provocaría retrasos en los proyectos.

Por eso, siempre es preferible tener interacciones y comunicación entre los miembros del equipo en lugar de depender ciegamente de los procesos para guiar el camino a seguir. Una de las formas de lograrlo es contar con un propietario de producto involucrado que trabaje y pueda tomar decisiones en colaboración con el equipo de desarrollo.

Permitir que las personas contribuyan por su cuenta también les permite mostrar libremente lo que pueden aportar. Cuando estas interacciones de equipo están dirigidas a resolver un problema común, los resultados pueden ser bastante poderosos.

# 2) Software de trabajo sobre documentación completa

La gestión de proyectos tradicional implicaba una documentación completa que implicaba un retraso de meses. Esto solía tener un impacto negativo en la ejecución del proyecto y los retrasos resultantes eran inevitables.

El tipo de documentación creada para estos proyectos fue muy detallada y se crearon tantos documentos que muchos de ellos ni siquiera fueron mencionados durante el progreso del proyecto. Este era un mal innecesario con el que solían convivir los equipos del proyecto.

Pero esto también exacerbó los problemas en la entrega. La atención se centró en la documentación hasta tal punto porque los equipos querían terminar con un producto terminado que fuera 100% según las especificaciones. Es por eso que la atención se centró en capturar todas las especificaciones en detalle.

Pero aún así, el producto final solía ser bastante diferente de las expectativas o habría perdido relevancia. Es por eso que ágil dice que un software que funcione es una opción mucho mejor para medir las expectativas del cliente que un montón de documentación.

Esto no implica que la documentación no sea necesaria. Simplemente significa que un producto funcional es cualquier día un mejor indicador de alineación con las necesidades y expectativas del cliente que un documento creado hace meses. También implica que los equipos sean receptivos y estén listos para adaptarse al cambio cuando sea necesario, mientras muestran el software en funcionamiento al cliente cuando finaliza el sprint.

No probar el producto durante los sprints conlleva muchos costos y esfuerzos en el siguiente sprint. Una vez que se implementa la funcionalidad, el costo de estos cambios aumenta aún más en un grado significativo.

extraer direcciones de correo electrónico del sitio web gratis

3. Colaboración del cliente sobre la negociación del contrato

Negociar significa que los detalles aún se están capturando y no se han finalizado. Todavía hay margen para la renegociación. Pero una vez que finaliza la negociación, no puede haber discusión al respecto. Lo que dice ágil es que en lugar de negociación, apueste por la colaboración.

La colaboración implica que todavía hay espacio para la discusión y la comunicación está en curso.

No es algo de una sola vez. Lo que esto hace es que ofrece una ventaja doble: mientras que ayuda al equipo a corregir el rumbo si es necesario en una etapa anterior, ayuda al cliente a refinar también su visión y redefinir sus requisitos si es necesario durante el transcurso del proceso. proyecto.

El otro aspecto es que si bien los modelos de desarrollo de software tradicionales involucran al cliente antes de que comience el desarrollo durante la fase de documentación y negociación, no están tan involucrados durante el desarrollo del proyecto.

Una vez que se han congelado los requisitos, solo pueden ver el producto, una vez que el producto está listo. Agile también rompe esta barrera al permitir la participación del cliente durante todo el ciclo de vida.

Esto ayuda a que los equipos ágiles se alineen mejor con las necesidades del cliente. Una de las formas de lograr esto es a través de un propietario de producto dedicado e involucrado que pueda ayudar al equipo en tiempo real para aclarar y alinear el trabajo con las prioridades del cliente.

4. Responder al cambio siguiendo un plan

El proceso de pensamiento estándar es que los cambios son un asunto costoso y debemos evitar los cambios a toda costa. Ese es el enfoque innecesario en la documentación y los planes elaborados para cumplir con los plazos y las especificaciones del producto.

Pero como la experiencia también nos enseña, los cambios son en su mayoría inevitables y, en lugar de huir de ellos, debemos tratar de aceptarlos y planificarlos.

Agile nos permite hacer esta transición. Lo que ágil piensa es que el cambio no es un gasto, es una retroalimentación bienvenida que ayuda a mejorar el proyecto. No se debe evitar, sino que agrega valor.

Con los sprints cortos propuestos por ágil, los equipos pueden obtener una retroalimentación rápida y cambiar las prioridades en poco tiempo. Se pueden agregar nuevas características de una iteración a otra.

¿Por qué hacemos esto? Porque la mayoría de las funciones desarrolladas con el enfoque de cascada nunca se utilizan. Esto se debe a que el modelo de cascada sigue el plan, mientras que esa es la fase en la que menos sabemos.

Agile también planifica, pero también sigue el enfoque justo a tiempo en el que la planificación se realiza lo suficiente cuando es necesario. Y los planes siempre están abiertos a cambios a medida que avanzan los sprints.

Los 12 principios ágiles

Hay 12 principios ágiles que se agregaron después de la creación del manifiesto para ayudar y guiar a los equipos en la transición a ágil y verificar si las prácticas que están siguiendo están en línea con la cultura ágil.

A continuación se muestra el texto de los 12 principios originales, publicados en 2001 por Agile Alliance:

#1) Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de un software valioso.

#2) Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.

#3) Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

#4) Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

#5) Construya proyectos alrededor de personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo.

#6) El método más eficiente y eficaz de transmitir información al equipo de desarrollo y dentro de él es una conversación cara a cara.

comando grep en un script de shell de Unix

#7) El software que funciona es la principal medida de progreso.

#8) Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante de forma indefinida.

#9) La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

#10) Simplicidad: el arte de maximizar la cantidad de trabajo no realizado es muy esencial.

#11) Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.

#12) A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego sintoniza y ajusta su comportamiento en consecuencia.

Estos principios ágiles proporcionan una guía práctica para los equipos de desarrollo.

Otra forma de organizar los 12 principios es considerarlos en los siguientes cuatro grupos distintos:

  • La satisfacción del cliente
  • Calidad
  • Trabajo en equipo
  • Gestión de proyectos

#1) Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de un software valioso: Obviamente, los clientes estarán encantados de ver que se entrega un software en funcionamiento en cada sprint en lugar de tener que pasar por un período de espera ambiguo al final del cual solo ellos podrán ver el producto.

Aquí, el cliente puede definirse como el patrocinador del proyecto o la persona que paga por el desarrollo. El usuario final del producto también es un cliente, pero podemos diferenciar entre los dos, ya que el usuario final se denomina usuario.

#2) Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente: Los cambios se pueden incorporar sin demasiados retrasos en los plazos generales.

Dado que los equipos ágiles creen en la calidad por encima de todas las cosas, preferirían incorporar cambios y cumplir con los requisitos del cliente que evitar cambios y entregar un producto que no satisface las necesidades comerciales.

#3) Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta. De esto se encargan los equipos que trabajan en sprints. Dado que los sprints son iteraciones encuadradas en el tiempo y entregan un software que funciona al final de cada sprint, los clientes regularmente tienen una idea del progreso.

#4) Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto. Se toman mejores decisiones cuando ambos trabajan juntos en colaboración y hay un ciclo de retroalimentación constante entre los dos para corregir el rumbo y agilidad en el cambio. La comunicación entre las partes interesadas es siempre la clave en ágil.

#5) Construya proyectos alrededor de personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo. Hay que apoyar, confiar y motivar a los equipos. Un equipo motivado tiene más probabilidades de tener éxito y entregará un producto superior que los equipos descontentos que no están dispuestos a dar lo mejor de sí mismos.

Una de las formas de hacer esto es empoderar al equipo de desarrollo para que se autoorganice y tome sus propias decisiones.

#6) El método más eficiente y eficaz de transmitir información al equipo de desarrollo y dentro de él es una conversación cara a cara: La comunicación es mejor y más impactante si los equipos están en el mismo lugar y pueden reunirse cara a cara para debatir. Ayuda a generar confianza y aporta comprensión entre las distintas partes interesadas.

#7) El software que funciona es la principal medida de progreso: Un software en funcionamiento supera a todos los demás KPI y es el mejor indicador del trabajo realizado.

#8) Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante de forma indefinida: Se enfatiza la consistencia de la entrega. El equipo debe poder mantener su ritmo durante la duración del proyecto y no agotarse después de los primeros sprints.

#9) La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. El equipo debe tener todas las habilidades y un buen diseño de producto para manejar los cambios y producir un producto de alta calidad al tiempo que puede incorporar cambios.

#10) Sencillez - El arte de maximizar la cantidad de trabajo no realizado es esencial y es suficiente para cumplir con la definición de realizado.

#11) Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados - Los equipos autoorganizados se empoderan y se apropian de su trabajo. Esto conduce a una comunicación abierta y al intercambio regular de ideas entre los miembros del equipo.

#12) A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego sintoniza y ajusta su comportamiento en consecuencia: La superación personal conduce a resultados más rápidos y menos retrabajos.

Conclusión

La centralidad en el cliente y el enfoque en la comunicación han llevado el éxito a lo ágil que es visible hoy.

Es una técnica probada con implicaciones no solo en la entrega de software, sino también en otras industrias y hoy se ha convertido en una industria en sí misma.

¡Nuestro próximo tutorial de esta serie explicará más sobre el equipo Scrum junto con sus roles!

PREV Tutorial | SIGUIENTE Tutorial

Lectura recomendada

^