Su navegador no soporta JavaScript. Scrum: Where Did Rapid Application Development Come From? - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS


IEEE Computer published an issue on agile development in 2003. Of particular interest is an article on the history of iterative development, highly recommended for anyone interested in the background Agile methods.

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".

Recent research has provided more detailed information on the productivity effects of incremental delivery. MacCormack’s multivariate analysis of Hewlett Packard software projects showed three primary factors that lowered defect rate (early prototype, design reviews, and integration or regression testing at code checkin) and two primary factors that increased productivity (early prototype and daily builds). Releasing a prototype to customers that is only 40% functionally complete increases productivity by 36% and adopting the practice of daily builds increases productivity by 93%.

MacCormack, A., et al., Exploring Tradeoffs Between Productivity and Quality in the Selection of Software Development Practices. IEEE Software, 2003(Sep/Oct): p. 78-85.

In his book, Agile and Iterative Development, Larman has well documented the history of the many disasters introduced by accident when the Department of Defense standardized on a non-iterative method that was unproven on large projects. It was essentially, a blunder by a consultant who had little experience with real software development.

The DOD has long since abandoned the waterfall method, and the consultant has recanted, but the waterfall approach persists as an urban myth in many software development organizations. Craig Larman details and documents this historical tragedy in Chapter Six of his book which compares the two leading agile methods, SCRUM and XP, along with RUP and Evo, an early iterative method.

<br>

es_ARSpanish
Acciones