Agile Journey: Los malentendidos más comunes

En mi trabajo diario con empresas de desarrollo de software oigo a empresarios decir con orgullo que "somos ágiles". Esto me deja pensando: "¿Es la agilidad en sí misma un logro?". Para mí, la respuesta es no. La agilidad es muchas cosas, pero no un logro en sí. 

Cuando hablo con diferentes personas sobre la mejor forma de dirigir un proyecto piensan que ser ágil es "tener un objetivo semanal" o "desarrollar lo más rápido posible". Es entonces cuando les pregunto, 

El manifiesto ágil, redactado en 2001, indica que: 

• Las personas y las interacciones priman sobre los procesos y las herramientas, 

• El software operativo tiene prioridad sobre la documentación exhaustiva, 

• La colaboración con el cliente es más valiosa que las negociaciones contractuales, 

• Responder al cambio es más valioso que seguir el plan. 

Esta forma de pensar, definida en los 12 principios sugeridos en el manifiesto ágil, es lo que realmente genera un cambio en una organización que busca mejorar su forma de trabajar. Estos principios son: 

1. Nuestra máxima prioridad es la satisfacción del cliente mediante la entrega temprana y continua de software valioso. 
2. Aceptamos que los requisitos cambien, incluso en fases avanzadas del desarrollo. Los procesos ágiles aprovechan el cambio para ofrecer una ventaja competitiva al cliente. 
3. Entregamos software funcional con frecuencia, entre dos semanas y dos meses, con preferencia por el plazo más breve posible. 
4. Los gerentes comerciales y los desarrolladores colaboraron a diario durante todo el proyecto. 
5. Los proyectos se desarrollan en torno a personas motivadas. Deles el entorno y el apoyo que necesitan, y confíe en que hagan el trabajo. 
6. Una conversación cara a cara es el método más eficiente y eficaz de comunicar información al equipo de desarrollo y entre ellos. 
7. El software de trabajo es la medida principal del progreso. 
8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores, los desarrolladores y los usuarios deben ser capaces de mantener un ritmo constante de manera indefinida. 
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 
10. La simplicidad es fundamental o el arte de maximizar la cantidad de trabajo no realizado. 
11. Las mejores arquitecturas, los requisitos y los diseños surgen de equipos autoorganizados. 
12. A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego ajusta y perfecciona su comportamiento en consecuencia. 

Por el contrario, encuentro empresas que se consideran ágiles y en las que se dan situaciones como las siguientes: 

• Los gerentes ven cualquier cambio en los requisitos del software como algo terrible y que nunca debería ocurrir. 
  ➔ ¿Qué ocurrió con el principio 2? 

• Los empresarios evitan al máximo el contacto entre las personas que realizan las actividades y los clientes finales, salvo cuando es necesario. 
  ➔ ¿Dónde se encuentra el principio 4? 

• Gerentes que desean medir el progreso con el número de horas trabajadas o los porcentajes de finalización del PBI por parte de los desarrolladores. 
  ➔ ¿Y dónde se encuentra el principio 7? 

• Las organizaciones exigen a sus empleados que trasnochen de manera constante, lo que a menudo les agota. 
  ➔ ¿Dónde se encuentra los principios 5 y 8? 

Por último, quiero señalar que la forma ágil de trabajar no es necesariamente beneficiosa para todos los proyectos. 

Algunos criterios para decidir si merece la pena trabajar de esta manera son: 

1. ¿Mi equipo de desarrollo es "maduro"? 
   1. Si la respuesta es afirmativa, podría beneficiarse de la auto-organización. 
   2. Si la respuesta es negativa, intentar aplicar estas técnicas podría perjudicar a la organización. 
      
      
2. ¿El proyecto que quiero desarrollar posee requisitos precisos de principio a fin y no van a cambiar de manera significativa? 
   1. Si la respuesta es afirmativa, ¿tiene sentido planificar en pequeños bloques en lugar de planificar todo el proyecto a la vez? 
   2. Si la respuesta es negativa, sería muy beneficioso poder planificar en pequeños bloques de trabajo y recibir información sobre cada entrega. 
      
      
3. ¿Tiene el proyecto algún elemento técnico con el que no tengamos experiencia previa? 
   1. Si la respuesta es afirmativa, el enfoque ágil probablemente gestionará mejor esta incertidumbre. 
   2. Si la respuesta es negativa, el proyecto podría planificarse por completo (si los requisitos son precisos) desde el principio. 
      
      
4. ¿Podrían los beneficiarios del proyecto obtener beneficios o rentabilizar la inversión con entregas parciales del sistema? 
   1. Si la respuesta es afirmativa, merece la pena entregar pequeños bloques de trabajo de forma constante, al maximizar el valor a corto plazo para los clientes. 
   2. Si la respuesta es negativa, trabajar en pequeños bloques de trabajo puede provocar más carga de trabajo y ralentizar la entrega final del proyecto, en comparación con ejecutar el desarrollo en un único bloque de trabajo. 

Espero que esto sirva como una pequeña introducción a lo que es agilidad. Háganos saber si hay algo en lo que podamos ayudarle.