Métodos Ágiles – Un poco de historia

A finales de los años 80 y principios de los 90 surgió un movimiento reaccionario contra los métodos de desarrollo de software establecidos. Esta revolución no carecía de motivos ya que los fracasos de los métodos tradicionales de desarrollo lineal y en cascada eran cada vez mas evidentes.

La propuesta de modelos de desarrollo iterativos, incrementales y adaptativos era totalmente contraria a la ortodoxia metodológica que imperaba. Los impulsores del cambio negaban la posibilidad de que los modelos predictivos fueran capaces de dar la flexibilidad necesaria al proceso de desarrollo.

Los métodos ágiles tienen en común estar basados en una filosofía de desarrollo incremental (ciclos cortos de entregas de software), en equipo (usuarios y desarrolladores trabajan juntos), adaptativo (capaz de incorporar cambios) y simple (sencillo de aprender). En el lado opuesto se encuentran los modelos en cascada y lineales que se basan en ir cerrando etapas en el desarrollo las cuales no pueden volverse a abrir (no adaptativos ni incrementales), en los que el usuario no habla con los desarrolladores si no es a través de un documento (no cooperativo) y fundamentado en una burocracia difícil de comprender (véanse normativas ISO9000 o CMM).

Como todo cambio tuvo y sigue teniendo sus detractores que basan sus críticas en la falta de método y en una supuesta «tiranía» de los técnicos que deja al margen toda una estructura de gestores y pseudo-técnicos (jefes de proyecto, analistas y coordinadores de todo tipo).

A mediados de los 90 las metodologías ágiles se vieron reforzadas por la deslegitimación que supuso el no respaldo del British Standard Institute al ISO9000 al asegurar que su seguimiento no garantizaba ni la calidad ni el éxito de los proyectos.

Tras el ISO9000 cayó el CMM del SEI. Pese a no ser este un modelo en sí mismo estaba muy ligado a los métodos lineales en cascada. Se le acusaba de ser un método de «papel» (solo generaba documentación) y está no era válida para asegurar el éxito de un proyecto. La lista de proyectos fallidos basados en CMM era cada vez mas amplia y terminó por desacreditar el método.

Menos dañado terminó el PMI (Project Management Institute) y su Book Of Knowledge (PMBOK) ya que han sabido adaptarse mas rápidamente pero siguen sin cuadrar totalmente con los nuevos métodos.

Expertos como Edward Yourdon, Barry Boehm,… retiraron de forma progresiva el apoyo a las metodologías tradicionales. El apoyo temprano al cambio de Martin Fowler o Ivar Jacobson terminó de dar la vitalidad suficiente al nuevo método.

Solo las grandes consultoras mantenían las metodologías tradicionales frente al cambio imparable que se estaba produciendo en los métodos de desarrollo. Las grandes empresas, de la mano de estas influyentes consultoras, siguieron manteniendolo también.

Actualmente los métodos ágiles se siguen abriendo paso de forma imparable y las grandes empresas, en estos momentos de crisis, ven con mas claridad los beneficios del cambio.

Pero sigue existiendo un profundo dilema que aún no está resuelto: CMM o ISO9000 no son compatibles con los métodos ágiles y el intento de combinación o convivencia resulta pernicioso ya que obtienes lo peor de ambos mundos. Hay muchas experiencias e intentos de coexistencia pero ya se sabe, «los experimentos con gaseosa». Cómo en muchas otras facetas de la vida se debe elegir un camino ya que por el medio solo vas a encontrar piedras.

Mi experiencia personal me dice que los métodos tradicionales lineales y en cascada no funcionan. Normativas como CMMI o ISO9000 ayudan en algunos casos pero crean una rigidez y burocracia al sistema innecesaria. Los sistemas predictivos basados en la experiencia fallan sistemáticamente y normalmente no se cumplen las planificaciones de esfuerzo, duración y, por tanto, de los costes de los proyectos.

Los métodos ágiles son una alternativa a valorar, pero la apuesta es arriesgada para empresas con una larga historia en desarrollo tradicional y, aunque ven los beneficios del cambio de método, tienden a la ambigüedad: quiero desarrollar rápido pero sin perder mi control económico predictivo y por tanto todos mis niveles de gestión que le rodean. Es comprensible pero ineficaz ya que los descuadres en costes seguirán existiendo (los métodos ágiles no son predictivos) y tenderán a no valorar correctamente el cambio.

Recomiendo la lectura del documento de Carlos Reynoso sobre este tema «Métodos Heterodoxos en Desarrollo de Software» en dónde podréis encontrar información mas detallada sobre las metodologías ágiles y su posicionamiento en la historia.