Utilizar las metodologías ágiles en proyectos que no sean de software
Objetivos de aprendizaje
Después de completar este módulo, podrá:
- Describir los valores y principios de las metodologías ágiles.
- Explicar cómo aplicar los valores y principios de las metodologías ágiles a proyectos que no sean de software.
Encontrar la receta adecuada para el éxito de los proyectos
Crédito de la imagen: Sergey Nivens/Adobe Stock
Cuando prepara una cena, es probable que aprecie el valor de una buena receta. Los ingredientes, las instrucciones, las directrices y los consejos. Sin embargo, un mismo plato puede tener varias recetas. Una búsqueda en Internet de recetas de lasaña puede arrojar cientos o incluso miles de resultados con variaciones distintas.
¿A qué se debe? A diferencias de experiencia, preferencias y circunstancias. Si ya tiene una amplia experiencia como cocinero o cocinera, es posible que prefiera la receta que utiliza desde hace años. O puede que prefiera algo que requiera menos esfuerzo o que sea más rápido de realizar. Tal vez alguno de los invitados sea intolerante a los lácteos. La experiencia, las preferencias y las circunstancias suelen condicionar la preparación.
La Universidad Walden afirma que las metodologías y los enfoques de gestión de proyectos son, en muchos sentidos, como las recetas de los platos. Incluye los pasos, las directrices y los consejos necesarios para garantizar el éxito del proyecto. Aunque los gestores de proyectos experimentados pueden elegir un enfoque en función de su experiencia o sus preferencias, también es importante tener en cuenta las características y circunstancias del proyecto. Esto es especialmente cierto en el caso de la gestión ágil de proyectos.
El recetario ágil: el Manifiesto por el desarrollo ágil de software
Un grupo de 17 desarrolladores de software experimentados elaboraron en 2001 el Manifiesto por el desarrollo ágil de software como solución a los problemas que planteaban los métodos tradicionales de desarrollo de software (en especial, la elevada tasa de fracaso de los proyectos de desarrollo de software). Definieron cuatro valores y 12 principios rectores que sirven de base para las prácticas ágiles.
Valores ágiles
De forma parecida a lo que sucede con V2MOM de Salesforce, estos valores son una orientación sobre cómo se desarrollan los planes ágiles y las cosas que deben ser prioritarias para cualquiera que siga la metodología.
- Individuos e interacciones sobre procesos y herramientas
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
- Software funcionando sobre documentación extensiva
Principios ágiles
- Nuestra mayor prioridad es satisfacer al cliente mediante 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 por periodo 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 sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de 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 luego ajustar y perfeccionar su comportamiento en consecuencia.
Aunque originalmente se diseñó para mejorar el desarrollo de software, el diseño ágil se adapta a numerosos entornos. Cada vez más, las empresas adoptan la metodología ágil para mejorar la productividad y el rendimiento en toda la organización.
Veamos un ejemplo de un proyecto con resultados diferentes utilizando la gestión de proyectos tradicional frente a la ágil.
¡Sorpresa!
Su organización prepara una jornada de puertas abiertas para presentar su nuevo edificio de oficinas. Los empleados están muy ilusionados por ver el nuevo espacio del que hace años que oyen hablar. Por lo que han oído, las zonas de trabajo son modernas y tienen un diseño flexible que puede modificarse fácilmente para favorecer una mayor colaboración entre los equipos. Los directivos de la empresa se mostraron especialmente orgullosos del diseño de la "fila de directivos", un concepto de espacios abiertos que garantiza una mayor comunicación entre directivos y empleados.
Como gestor del proyecto de diseño y desarrollo de la fila de directivos, estaba deseando ver sus reacciones. Esperaba que todos le dieran la enhorabuena y le felicitaran por su innovador diseño. Sin embargo, no estaba preparado para lo que pasó: el grupo de directivos se quedó mirándole en silencio, con una decepción evidente.
¿Qué ha ocurrido? Usted y el equipo del proyecto colaboraron estrechamente con un arquitecto y un constructor para planificar el proyecto. Ellos tenían un plan de proyecto exhaustivo que se siguió paso a paso. Todas las tareas se completaron, y el proyecto se acabó a tiempo y sin salirse del presupuesto. Eso significa que el proyecto fue un éxito, ¿no? Pues no.
Veamos la situación en el contexto de la gestión tradicional de proyectos.
La gestión tradicional de proyectos se basa en gran medida en una extensa documentación. Se parte de la base de que todos los requisitos del proyecto se conocen y se fijan antes de que empiece el trabajo. El cliente o el usuario final participan en la fase de planificación para definir los requisitos Pueden recibir informes sobre el estado y el rendimiento del proyecto, pero no ven el resultado final hasta el final. ¡Sorpresa!
En cuanto a satisfacción del cliente, este proyecto no ha cumplido las expectativas.
A de ágil
Con la metodología ágil, sin embargo, los bucles de retroalimentación integrados permiten una estrecha colaboración con el cliente, así como la oportunidad de incorporar cambios de manera rápida y sencilla sin que ello repercuta en los plazos ni en los costes.
¿En qué se diferenciaría el resultado del proyecto del espacio de trabajo si se hubiera utilizado un enfoque ágil? Veamos el ejemplo.
Ciclo 1
En la primera iteración participan el equipo del proyecto, los directivos que ocuparán el nuevo espacio, el arquitecto que lo diseñará y el constructor. El resultado esperado de esta iteración es un dibujo prototipo del nuevo espacio que cumpla los requisitos del cliente.
Los gestores aportan sus requisitos. El arquitecto captura los requisitos en un software de diseño y muestra al equipo el dibujo de un prototipo del diseño. El constructor proporciona información sobre el cumplimiento de las normativas de construcción que no pueden omitirse. El arquitecto modifica el diseño para ajustarlo a las normativas de construcción. Al final de la sesión, todos coinciden en que se ha obtenido el resultado esperado.
Ciclo 2
El mismo grupo se reúne para la segunda iteración. El resultado esperado de esta sesión es un modelo 3D del espacio de trabajo proporcionado por el constructor. El arquitecto aporta el dibujo más actual del espacio. El constructor entrega una maqueta preliminar. Al revisar el modelo, los gestores detectan un problema de inmediato.
Los espacios abiertos para directivos no permiten privacidad. Los directivos deben poder hablar con los empleados en privado, y encontrar una sala de conferencias para estas conversaciones resulta complicado. El arquitecto y el constructor proponen un diseño modificado. La maqueta 3D se actualiza y todos aceptan el nuevo diseño.
Ciclo 3
Para la tercera iteración, el constructor aporta un equipo para que realice una construcción parcial del nuevo espacio. Mientras los obreros se instalan, el constructor revisa la maqueta 3D con el equipo del proyecto e incorpora algunos pequeños cambios solicitados por los directivos. El equipo de construcción recibe el visto bueno.
Ahora, el equipo del proyecto tiene la oportunidad de ver el espacio y hacer las últimas aportaciones antes de que empiece la construcción final. Los directivos están satisfechos con el resultado, ya que se han tenido en cuenta sus aportaciones y se han atendido sus necesidades.
Al cambiar la "receta", ha reducido la probabilidad de que se produzcan sorpresas el día de la inauguración. ¡Ufff!
Su proyecto está servido
No existe una receta única que sirva para todo el mundo, ya que la experiencia, las preferencias y las circunstancias varían. Por estas mismas razones, ningún enfoque de gestión de proyectos funciona para todos. Para los proyectos que puedan beneficiarse de un enfoque iterativo que acepte el cambio y se centre en aportar valor al cliente, la metodología ágil representa una opción deseable. A pesar de su historia como enfoque para el desarrollo de software, muchas organizaciones están descubriendo que sus ventajas son demasiado sabrosas como para ignorarlas.
Hasta ahora, la Universidad Walden nos ha explicado el ciclo de vida de un proyecto y las distintas metodologías que se pueden aplicar. En la unidad siguiente, lo unirá todo aprendiendo a garantizar que su proyecto aporte valor a su organización.