Porqué nacieron las metodologías ágiles

Viendo todos los motivos anteriores  (ver mis post sobre el desarrollo en cascada) que justificaban (más o menos) la existencia en su momento de metodologías en cascada, y que éstos con el paso del tiempo, dejaban de tener sentido...fruto de aquella situación general de "indignación", nacieron las metodologías ágiles.

Esto que suena tan convincente, no deja de ser una verdad a medias. Realmente, no han cambiado tanto los proyectos de desarrollo de software. Y tampoco han cambiado en todos los escenarios. Sin embargo, las metodologías ágiles si han presentado una opción 100% radical, lo cual ha presentado sus propios problemas (ver mi artículo sobre los defectos de SCRUM).

Lo que sí han surgido son necesidades de cambio. Los proyectos a finales de los 90, tenían problemas: altas tasas de fallos, retrasos en las entregas, funcionalidades impredecibles...

Lo que hicieron los autores del manifiesto ágil fue tratar de vender sus ideas. Y como la mejor forma de vender sus ideas era siendo radicales...lo fueron. Se trató de dar un volantazo al mundo del desarrollo de software, y se establecieron las bases de lo que hoy son los desarrollos ágiles. Ojo, esto que suena tan irreverente, al final, resultó un buen argumento de venta. Las metodologías ágiles presentaban muy buenas ideas, y aunque envueltas en un manto de "giro radical" y "oposición a lo existente" (como toda buena revolución, esté o no justificada), ha traído un más que necesario aire fresco al mundo del desarrollo software.

Incorrecciones habituales al hablar de estas cosas:

Voy a comentar algunas incorrecciones (desde mi punto de vista), que observo al leer sobre estos temas.

• "El sistema en cascada para gestionar proyectos...". Waterfall, o Cascada, no habla de cómo gestionar proyectos. Gestionar proyectos no tiene nada que ver con cómo se estructura el ciclo de vida del software (SDLC). Cuando hablamos de estas metodologías, normalmente nos referimos al ciclo de vida (SDLC). No a la gestión, ni a otros procesos relativos a la construcción de software.
• Se suele intentar asociar de forma forzada a las metodologías ágiles con la ingeniería del software. Eso no quiere decir que las metodologías ágiles sean opuestas a la ingeniería, a pesar de que tradicionalmente los defensores de las metodologías ágiles se han mostrado contrarios a los paradigmas de la ingeniería del software, más cercana (insisto, tradicionalmente), al control y disciplina de los métodos predecibles.
• "En las metodologías ágiles se pueden realizar mantenimientos desde la primera entrega". La primera en la frente. O sea, que tengo un equipo de 5 personas realizando iteraciones. En la segunda iteración, quito a uno para que mantenga la primera iteración....en la tercera, quito a otro para ayudar al anterior a mantener las dos primeras...Para cuando lleve 5 iteraciones, ya no tengo avance: en lugar de añadir funcionalidades, tengo a los 5 del equipo, arreglando defectos, haciendo evolutivos...y sin añadir casi funcionalidad. O peor, conforme añado funcionalidad, tengo que corregir todo porque no se integra con todos los cambios que se hace sobre lo anterior. En fin.