Barrapunto

Las metodologías ágiles (en plural) no dejan de ser más que una reflexión sobre lo que funciona y no funciona de un desarrollo, visto más como el proceso de una creación que de una ingeniería. Si fallan cuando se llevan a la práctica es por la incapacidad de muchos directores de proyecto de asumir estas reflexiones, cayendo nuevamente en las mismas trampas de siempre.

Por ejemplo, la programación extrema habla de los beneficios de la conciliación de vida laboral y familiar, o de que el trabajador tenga tiempo propio para investigar por su cuenta y así mejorar su creatividad. Estos aspectos son completamente inconcebibles en las metodologías clásicas que todo lo miden en unidades de hombre/hora.

Así que si siguen la metodología en cascada y fallan es porque la cascada es intrínsecamente mala y no funciona, pero si siguen metodologías ágiles y fallan es porque ellos son unos incapaces. ¿Es eso?.

¿Las metodologías clásicas o *las métricas* que se intentan utilizar para medir los costes y la calidad?. Porque las métricas no son intrínsecas a ningún modelo de desarrollo, puedes perfectamente usar unidades hombre/hora o líneas de código/hora para calcular costes de desarrollo con metodologías ágiles.

Y yo creo que muchos confundís el mensaje original, que curiosamente tú mismo das ("La idea detrás de esta metodología es descubrir los posibles errores en las fases tempranas, cuando son menos dañinos") con toda la burocracia que se le ha echado luego encima por motivos relacionados sólo tangencialmente con el desarrollo de software (estimación de tiempos, costes y cálculo del rendimiento del trabajo de cada persona, automatización de la documentación, estandarización de procesos, coordinación de equipos, etc).