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.
Most of the "Rapid Application Development (RAD)" methodologies have taken advantage of iterative development combined with incremental delivery. Craig Larman documents the history of iterative and incremental development.
Larman, Craig y Basili, Victor R. Desarrollo iterativo e incremental: Breve historia. IEEE Computer 36:6:47-56, junio de 2003.
Iterative and incremental development dates back to the mid-1950's and prominent software-engineering though leaders from each decade supported and used IID practices. Many large projects at NASA, IBM, and elsewhere used them. The DOD standard on waterfall development was misconceived according to its author who relied mainly on textbooks and consultants. It took over a decade for a DOD committee led by Fred Books (Mythical Manmonth) to remedy the problem. Meanwhile there were at least $75B of failed DOD software projects documented and these projects are only the tip of a very large iceberg of failed efforts.
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