IEEE Computer publicó un número sobre desarrollo ágil en 2003. De especial interés es un artículo sobre la historia del desarrollo iterativo, muy recomendable para cualquier persona interesada en los antecedentes de los métodos ágiles.
La mayoría de las metodologías de "desarrollo rápido de aplicaciones (RAD)" han aprovechado el desarrollo iterativo combinado con la entrega incremental. Craig Larman documenta la historia del desarrollo iterativo e incremental.
Larman, Craig y Basili, Victor R. Desarrollo iterativo e incremental: Breve historia. IEEE Computer 36:6:47-56, junio de 2003.
El desarrollo iterativo e incremental se remonta a mediados de los años 50 y destacados líderes de la ingeniería de software de cada década apoyaron y utilizaron las prácticas IID. Muchos grandes proyectos de la NASA, IBM y otros organismos las utilizaron. La norma del Departamento de Defensa sobre desarrollo en cascada estaba mal concebida, según su autor, que se basó principalmente en libros de texto y consultores. Un comité del Departamento de Defensa dirigido por Fred Books (el mítico Manmonth) tardó más de una década en solucionar el problema. Mientras tanto, se documentaron al menos $75B proyectos de software del Departamento de Defensa que fracasaron, y estos proyectos son sólo la punta de un iceberg muy grande de esfuerzos fallidos.
El primer documento publicado que Larman pudo encontrar sobre el desarrollo iterativo fue un informe de 1968 de Biran Randell y F.W. Zurcher en el Centro de Investigación T.J. Watson de IBM. Curiosamente, expone el modelo básico de desarrollo utilizado por el primer software Scrum de Easel Corporation en 1993.
"El enfoque básico reconoce la inutilidad de separar los procesos de diseño, evaluación y documentación en el diseño de sistemas de software. El proceso de diseño se estructura mediante un modelo en expansión sembrado por una definición formal del sistema, que proporciona un primer modelo funcional ejecutable. Se prueba y se amplía a través de una secuencia de modelos, que desarrollan una cantidad cada vez mayor de funciones y una cantidad cada vez mayor de detalles sobre cómo se va a ejecutar esa función. Al final, el modelo se convierte en el sistema".
Investigaciones recientes han proporcionado información más detallada sobre los efectos en la productividad de la entrega incremental. El análisis multivariante de MacCormack de los proyectos de software de Hewlett Packard mostró tres factores principales que reducían la tasa de defectos (prototipo temprano, revisiones de diseño y pruebas de integración o regresión en la comprobación del código) y dos factores principales que aumentaban la productividad (prototipo temprano y construcciones diarias). La entrega a los clientes de un prototipo que sólo está 40% funcionalmente completo aumenta la productividad en 36% y la adopción de la práctica de las compilaciones diarias aumenta la productividad en 93%.
MacCormack, A., y otros, Exploración de las compensaciones entre productividad y calidad en la selección de prácticas de desarrollo de software. IEEE Software, 2003(Sep/Oct): p. 78-85.
En su libro, Agile and Iterative Development, Larman ha documentado bien la historia de los muchos desastres introducidos por accidente cuando el Departamento de Defensa estandarizó un método no iterativo que no estaba probado en grandes proyectos. En esencia, fue una metedura de pata de un consultor que tenía poca experiencia con el desarrollo de software real.
El Departamento de Defensa hace tiempo que abandonó el método de la cascada, y el consultor se ha retractado, pero el enfoque de la cascada persiste como un mito urbano en muchas organizaciones de desarrollo de software. Craig Larman detalla y documenta esta tragedia histórica en el capítulo seis de su libro, en el que compara los dos principales métodos ágiles, SCRUM y XP, junto con RUP y Evo, un método iterativo primitivo.
<br>
Spanish 
English 
French