Agile Software Development - Conclusiones Pro's y Contra's

Las metodologías de desarrollo ágil surgieron como remedio a los problemas vividos con métodos tradicionales. Focalizándose en reducir los riesgos de crear un mal producto por no trabajar bien los requerimientos con el cliente, no mostrar rápidamente resultados para obtener su feedback, estar predispuesto y preparado al cambio basado en ese feedback.

A partir de ahí, métricas de calidad como la integración continua, orientación del código al test,  etc. que bien pueden tener cabida en un modelo tradicional. 

Inherentemente las metodologías ágiles mejoran el control del proyecto, para gestores y clientes. Pero también enfatizan la visibilidad del grado de avance para el equipo, algo igualmente beneficioso.

Así mismo, promueve un elevado de comunicación mediante organización de equipos unidos, reuniones diarias, y posteriores a cada hito de interés (sprint, entrega, etc) haciendo transparente la situación del proyecto y facilitando una correcta toma de decisiones. Anticipar el feedback del cliente reduce el coste y el impacto, incluso diría yo el desgaste, que supone identificarlo a posteriori.

Según una encuesta de VersionOne 2008 la percepción de beneficio se centra en puntos como:

• Mejora de la visibilidad del proyecto
• Mejora la moral del equipo
• Mejora de la productividad
• Simplificación del proceso de desarrollo
• Mejora de la calidad, la mantenibilidad del código
• Mejora la alineación entre producción y negocio
• Acelera el time-to-market
• Reducción del riesgo
• Mejora la capacidad de gestión en cambios
• Mejora las buenas prácticas de Ingeniería

¿Hay puntos negativos o críticas?

Veamos una enumeración de puntos:

• La auto-organización de los equipos, es efectiva a nivel de proyecto ... lo que puede dificultar la optimización a nivel de organización, si la forman más de un equipo. 
• Así mismo en proyectos de elevada exigencia de rendimiento, donde el diseño inicial de arquitectura es crítico en relación al rendimiento posterior, no encontramos un reflejo claro formalmente de como integrar esta fase en un modelo iterativo orientado a dar visibilidad desde el minuto 0
• Personalmente, en los proyectos con un presupuesto inicialmente pactado, gestionar las expectativas del cliente en relación al número de iteraciones disponibles, y no perder de vista el alcance global de la solución vs. la recogida de feedback para mejoras de la solución, resulta ciertamente inquietante
• Otro punto a tener en consideración, mencionado en anteriores artículos, es la gestión de la responsabilidad, teóricamente compartida por todo el equipo, pero en realidad los equipos cada vez son más multi-disciplinares (analista web, dba, usability master, front-end dev, back-end dev, etc) por lo que difícilmente vamos a conseguir configurar un equipo que pueda realmente asumir la responsabilidad común del resultado

Volviendo a los resultados de la encuenta VersionOne del 2..8, se identificaron los siguientes puntos o causas de error en proyectos:

• La cultura o filosofía a nivel de compañía entra en conflicto con los valores ágiles
• Falta de experiencia con los métodos ágiles
• Presión externa, incluso obligación (si es una imposición del cliente) a seguir métodos y prácticas tradicionales
• Dificultad por parte del equipo para seguir las nuevas prácticas. La gestión del cambio interna
• Falta de formación, de soporte a la gestión

Pese a todo, ser una metodología integrada específicamente a cada organización, con puntos de mejora inherentes en la metodología, hacen que muchas de las deficiencias identificadas hayan sido resueltas en el día a día, por los mismos equipos.

Aunque parece más que recomendable, planificar correctamente una correcta gestión del cambio, comunicar que se quiere hacer, analizar la organización, y implicar a todo el equipo en el cambio.

Saludos,