¿Va a usar Agile en su próximo proyecto Software?

¿Ha tenido usted alguna vez la experiencia de un proyecto software que haya fracasado? Si ha estado trabajando en este sector algún tiempo, es casi seguro que le ha pasado alguna vez. ¿Recuerda la sensación cuando se iba dando cuenta de que no iba a ser posible cumplir el plazo, o que el producto sería inaceptable?

Usted intentó alertar a la dirección, pero ellos no querían escucharle. Más bien al contrario, declaraban abiertamente lo bien que iba el proyecto. A usted le parecía un tanto “surrealista” lo convencidos que estaban de que todo iba bien, cuando era obvio que todo iba mal. Los que sabían que su proyecto iba en caída libre, tampoco querían hacer nada al respecto. En vez de intentar salvar el proyecto, se concentraban en salvarse a ellos mismos: El proyecto no iba tan mal (por lo menos en su área no había problemas).

¿Recuerda el estilo de gestión que se utilizaba en este proyecto? Seguro que la comunicación no era buena, y había poca realimentación por parte de los miembros del equipo sobre requisitos, funcionalidad, tamaño, etc. Si algún miembro del equipo trataba de decir algo sobre la situación real del proyecto, se le tachaba de “negativo” o “poco colaborador”.

Aquel proyecto fracasó, básicamente, porque los miembros del equipo sabían la verdad y la dirección se negaba a admitirla. No había espíritu colaborativo ni verdadera comunicación. Fue una mala experiencia y no quiere que se repita ahora que está a punto de comenzar otro nuevo proyecto software, ¿verdad?

¿Por qué fracasan los proyectos software?

Muchos proyectos software fracasan porque se hacen de la forma tradicional, que siguen un “ciclo de vida en cascada”: Se planifica en profundidad al principio y se evitan los cambios en fase de ejecución. Se llama “en cascada” porque las fases del proyecto transcurren como los saltos de agua de una cascada: cuando una fase acaba, se baja al siguiente nivel, sin posibilidad de vuelta atrás.

Este método de trabajo inflexible, orientado a cumplir exhaustivamente la planificación, hace que cuando estos grandes proyectos terminan, muchas veces el cliente no obtenga lo que quería. Una vez se supera la fase de planificación, ya no hay buena comunicación con el cliente. Como tampoco se analizan las lecciones aprendidas, los mismos errores se repiten una y otra vez en los proyectos siguientes.

Los problemas de la gestión de proyectos tradicional

Los proyectos software que se gestionan de forma predictiva, siguiendo estrictamente una planificación inicial, generalmente no entregan valor al cliente hasta que se produce la entrega final. No se hacen buenas pruebas hasta las últimas fases del proyecto, los grandes problemas permanecen encubiertos, y cuando se descubren ya es demasiado tarde para repararlos. Tampoco se produce ninguna validación por parte del cliente hasta el final del ciclo de vida, cuando, cuando sus requisitos pueden haber cambiado drásticamente.

En este tipo de proyectos, si el Director del Proyecto es sustituido (o se va de la empresa), el proyecto está en peligro porque suele depender demasiado de la dirección de una sola persona.

Usando métodos ágiles para gestionar proyectos software

Cada vez más empresas están cambiando a métodos ágiles porque el tipo tradicional de gestión no está funcionando.

Los métodos ágiles han evolucionado durante años a partir de los procesos de fabricación como “just-in-time” (JIT). JIT trataba de reducir los desperdicios y la sobreproducción determinando qué partes necesitaban los clientes en cada momento, mejor que producir masivamente demasiados productos que se quedaban en el almacén. JIT surgió como resultado de las nuevas capacidades de computación, que permitían gestionar inventarios y predecir cuántas unidades serían requeridas, dónde y cuándo. Antes de JIT, había que mantener grandes almacenes porque nadie sabía calcular qué cantidades serían requeridas, y quedarse sin producto era peor que tener productos sobrantes. Desde que tenemos JIT, los suministros llegan justo a tiempo para usarse.

Este concepto ha sido extendido y adaptado hasta convertirse en una herramienta útil para gestionar proyectos de software.

Los métodos ágiles se parecen a JIT porque los componentes de software son entregados tan pronto como están listos: no se “almacenan” con el objeto de entregar todo a la vez.

La idea básica de los métodos ágiles

La forma ágil de trabajar consiste en lo siguiente: En vez de pasar mucho tiempo planificando un proyecto al principio y luego ejecutando el plan sin revisión ni comunicación frecuente con el cliente, se planifica una pequeña funcionalidad que se puede entregar rápidamente.

A diferencia de lo que ocurría con los métodos predictivos, con los métodos ágiles (o adaptativos) se puede empezar el proyecto sin un plan completo. Dicho plan irá surgiendo poco a poco, según se avanza. En los métodos predictivos, donde se tiene un plan completo desde el principio, los cambios se toleran peor porque también hay que modificar la planificación.

En los métodos ágiles, se comienza planificando una pequeña parte inicial, se asigna un equipo con las habilidades necesarias y comienzan a trabajar. No se pierde tiempo esperando a que alguien termine algo en otra parte de la organización. Se desarrolla el elemento de software y se va probando según se avanza. Al final de una corta iteración, hay algo que poder enseñarle al cliente, ya sea un prototipo o una demo. El cliente percibe un valor en esa entrega y transmite buena realimentación sobre la funcionalidad y la usabilidad. Después comienza una siguiente iteración incremental.

Según se avanza iteración a iteración, se va reduciendo la sobrecarga del proyecto que no aporta valor, como por ejemplo: la planificación con demasiados supuestos, la funcionalidad interesante pero no realmente necesaria, etc.