Pese a que han pasado diecisiete años desde que fue creado, el manifiesto ágil sigue más vivo que nunca. Esto se debe a que cada día más y más empresas están interesadas en aplicar principios, técnicas, herramientas y framework agiles en el desarrollo de sus productos y proyectos.
El inicio de todo
Allá en el 2001, diecisiete capos de la industria del software encabezados por Jeff Sutherland, Ken Schwaber, 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, Kent Beck y Dave Thomas, decidieron poner todos sus años de experiencia, su conocimiento, sus errores, sus éxitos y crearon lo que llamaron “El manifiesto ágil”.
Jeff Sutherland inventó Scrum en 1993 y no fue hasta la OOPSLA* de 1995 que fue cuando lo presentaron al mundo, luego de trabajar 2 años con Ken Schwaber.
Valores del Manifiesto Ágil
El manifiesto ágil establece un conjunto común de valores y principios que deben (deberían) estar presentes en todas las metodologías ágiles de forma individual.
Los detalles del manifiesto se basan en cuatro valores que pueden parecer básicos pero que son la base para generar equipos con alta productividad y con ello productos de gran calidad en tiempos muy cortos.
Cada uno de los valores funciona. A continuación, veremos un detalle de cada valor:
1. Individuos e interacciones sobre procesos y herramientas
El manifiesto ágil proponer poner foco en las personas y sus interacciones, es decir, centrarnos en quienes hacen posible crear el producto.
Mantener una comunicación eficaz entre individuos que forman un equipo puede lograr que el equipo sea 50% más productivo que el promedio en el sector donde se desarrollan.
Este valor, se contempla dentro del marco de trabajo está todas las metodologías ágiles permitiendo obtener equipos con un alto rendimiento.
Para lograr enfocarnos en las personas y mejorar la comunicación, las metodologías ágiles, le dedican un tiempo a comunicarse, a inspeccionar y luego a mejorar, esto durante todo el ciclo de vida del producto.
Para lograr que un equipo trabaje como equipo (pienso en mí como pienso en el resto) se necesita que cada miembro sea reconocido y respetado como persona, trabajando en un ambiente donde la confianza, la transparencia y el compromiso con valores internos y fundamentales que se trabaja día a día.
2. Software que funciona sobre la documentación completa
El segundo punto del manifiesto ágil nos habla del software como un entregable funcionando. Sabemos de la importancia y el beneficio que trae contar con un sprint (una parte mínima que genere valor) que generar valor al negocio.
La pregunta sería ¿cómo debe entregarse esa parte de software? Será acaso ¿un software listo para pruebas de usuario final? O estamos hablando de ¿software listo para implementar a producción?
Lo que recomienda el manifiesto ágil es que cada equipo de trabajo genere software que genere valor al negocio, en un tiempo determinado (generalmente corto) y en intervalos definidos.
3. Colaboración del cliente sobre la negociación del contrato
Cómo hablamos en el post “El Dueño del Producto y la clave del éxito del proyecto”, el manifiesto ágil nos recuerda la importancia de trabajar codo a codo con los involucrados en el negocio.
Dado esto, SCRUM y XP reconocen y mencionan dentro de su marco de trabajo el rol del negocio, llamado “Dueño de Producto” o “Cliente”. Este rol funciona de “proxy”, filtra requerimientos, los analiza, valida, define, prioriza los que generan valor a la empresa y se los lleva al equipo de desarrollo a decirles “Esto quiero”.
Con el involucramiento de una persona de negocio a los proyectos de desarrollo de software, el éxito de los proyectos se ha duplicado en los últimos 20 años.
4. Responder al cambio sobre seguir un plan
Todos hemos escuchado, pensado y creído alguna vez: “El cliente nunca sabe lo que quiere”, por lo menos no hasta antes de verlo funcionando.
En los 90’s y 2000’s e incluso hasta hoy, muchos participamos de proyectos en donde el cliente veía el software funcionando después de muchos meses, cuando estaba “todo” terminado (desarrollo de software secuencial o cascada). Y en ese preciso momento empezaban los “inconvenientes”. El cliente sentía que lo que se había creado no era lo que él había pedido o por lo menos, no era como él lo había imaginado.
«Entonces, algo era claro: dejar que el cliente no ven el software que funciona hasta el final de proyecto, era muy contraproducente (demora en tiempos, desgaste del equipo, sobre costos, insatisfacción y sensación de fracaso).
Sobre ese problema, el manifiesto ágil y con ello las metodologías ágiles buscan el involucramiento del cliente durante todo el proyecto de modo que cuando antes, ante cualquier cambio del entorno (mercado) o durante las dudas del equipo de desarrollo, este pueda darle el feedback a tiempo y con ello el valor al negocio no se ve afectado o por lo menos, no en gran cantidad.
Un gerente de proyectos tradicional se centra en seguir el plan con los mínimos cambios posibles, mientras que un líder ágil se centra en adaptarse con éxito a los cambios que son inevitables.
Cumpliendo la regla 80/20, el 80% del valor del negocio se encuentra solo en un 20% de los requerimientos, con esto, en los proyectos ágiles bien realizados logran cumplir con ese 80%, realizándose en menos tiempo e incluso permitiendo cambios durante su desarrollo, mientras que los proyectos tradicionales generalmente no logran terminar a tiempo y si a esto se le suma cambios, se puede aumentar hasta un 50% de tiempo más en la finalización.
Importante: los procesos, la documentación, los contratos el plan pueden ser «necesarios»
Si leemos el manifiesto ágil. En la parte final, luego de la emoción y las lágrimas al leer los valores, vemos una frase que dice: “Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”
Esa frase final es las que muchos profesionales omiten leer o se les olvida rápidamente. Lo que los autores nos dicen, es que ambos puntos son importantes, sino que se establece prioridades y sobre todo formas.
Algunas preguntas que resultan salir del manifiesto ágil son:
- ¿Hago documentación o no? la respuesta siempre será: ¿servirá para el futuro? Es decir, ¿me ahorra tiempo en un futuro? Si la respuesta es sí, entonces hazlo con lo mínimo indispensable.
- ¿Hago planificación o no? Las metodologías ágiles tienen un tiempo de planificación, una planificación sencilla, rápida y potente. No necesita ser extensiva y tediosa para tomar acción.
- ¿Qué hago con los procesos? Los procesos serán necesarios siempre y serán explicados a las personas. El equipo necesita conocer el proceso, pero el proceso no puede estar por sobre las personas.
- Sí todo cambia, ¿cómo manejo mis contratos? Hasta que no exista un trabajo en equipo, es difícil determinar exactamente cómo se va a cobrar (referido al cobro por horas). Una alternativa es los contratos mensuales por el equipo que se encuentra desarrollando el sprint (pago del sueldo de cada miembro del equipo) y así hasta terminar. Lo fundamental es que podremos saber cuál es la productividad del equipo (cuánto puede avanzar en un mes) con el tiempo (trabajando juntos), siempre que el cliente esté involucrado.
Uses la metodología ágil o marco de trabajo que uses, el manifiesto ágil de ello y sus valores nos invitan a enfocarnos en lo realmente prioritario sin dejar de lado lo que consideres necesario en el camino.
Si tienes preguntas cómo: ¿Qué es agilidad y por qué todos están hablando de eso? ¿Por qué yo (jefe/líder/analista/ejecutivo…) debo saber de agilidad? ¿Quienes hacen agilidad?… y sobre todo, si buscas respuestas a estas y otras preguntas, te esperamos en Agile Fundamentals, dale clic aquí y entérate de todos los detalles.
¡Nos vemos dentro!
Saludos.
Johana Chuquino
Johana Chuquino
OOPSLA* Object-Oriented Programming, Systems, Languages & Applications
