IEEE Computer a publié un numéro sur le développement agile en 2003. Un article sur l'histoire du développement itératif est particulièrement intéressant. Il est vivement recommandé à toute personne intéressée par l'historique des méthodes agiles.
La plupart des méthodologies de "développement rapide d'applications (RAD)" ont tiré parti du développement itératif combiné à une livraison incrémentale. Craig Larman retrace l'histoire du développement itératif et incrémental.
Larman, Craig et Basili, Victor R. Développement itératif et incrémental : Une brève histoire. IEEE Computer 36:6:47-56, juin 2003.
Le développement itératif et incrémentiel remonte au milieu des années 1950 et d'éminents leaders du génie logiciel de chaque décennie ont soutenu et utilisé les pratiques IID. De nombreux grands projets de la NASA, d'IBM et d'ailleurs les ont utilisées. La norme du ministère de la défense sur le développement en cascade a été mal conçue selon son auteur, qui s'est principalement appuyé sur des manuels et des consultants. Il a fallu plus de dix ans à un comité du ministère de la défense dirigé par Fred Books (Mythical Manmonth) pour remédier au problème. Entre-temps, au moins $75B de projets logiciels du ministère de la défense ont échoué, et ces projets ne sont que la partie émergée d'un très grand iceberg d'efforts infructueux.
Le premier document publié que Larman a pu trouver sur le développement itératif est un rapport de 1968 de Biran Randell et F.W. Zurcher du centre de recherche IBM T.J. Watson. Il est intéressant de noter qu'il présente le modèle de développement de base utilisé par le premier logiciel Scrum d'Easel Corporation en 1993.
"L'approche de base reconnaît la futilité de séparer les processus de conception, d'évaluation et de documentation dans la conception de systèmes logiciels. Le processus de conception est structuré par un modèle en expansion, initié par une définition formelle du système, qui fournit un premier modèle fonctionnel exécutable. Ce modèle est testé et développé à travers une séquence de modèles qui développent de plus en plus de fonctions et de détails sur la manière dont ces fonctions doivent être exécutées. En fin de compte, le modèle devient le système".
Des recherches récentes ont fourni des informations plus détaillées sur les effets de la livraison progressive sur la productivité. L'analyse multivariée de MacCormack sur les projets logiciels de Hewlett Packard a montré que trois facteurs principaux réduisaient le taux de défauts (prototype précoce, revues de conception et tests d'intégration ou de régression lors de la vérification du code) et que deux facteurs principaux augmentaient la productivité (prototype précoce et constructions quotidiennes). La mise à disposition des clients d'un prototype dont la fonctionnalité n'est complète qu'à 40% augmente la productivité de 36% et l'adoption de la pratique des constructions quotidiennes augmente la productivité de 93%.
MacCormack, A., et al, Exploration des compromis entre productivité et qualité dans la sélection des pratiques de développement de logiciels. IEEE Software, 2003(Sep/Oct) : p. 78-85.
Dans son livre Agile and Iterative Development, Larman a bien documenté l'histoire des nombreux désastres introduits par accident lorsque le ministère de la défense a standardisé une méthode non itérative qui n'avait pas fait ses preuves sur des projets de grande envergure. Il s'agissait essentiellement d'une bévue commise par un consultant qui n'avait que peu d'expérience en matière de développement de logiciels.
Le ministère de la Défense a depuis longtemps abandonné la méthode en cascade, et le consultant s'est rétracté, mais l'approche en cascade persiste comme un mythe urbain dans de nombreuses organisations de développement de logiciels. Craig Larman détaille et documente cette tragédie historique dans le chapitre six de son livre, qui compare les deux principales méthodes agiles, SCRUM et XP, ainsi que RUP et Evo, une première méthode itérative.
<br>
French 
English 
Spanish