Le management de projet traditionnel ou en cascade (waterfall en anglais), est un héritage de l’industrie et de la construction de bâtiments, et ses phases principales ont été modélisées la première fois en 1956 par Herbert D. Benington lors d’un Symposium sur les méthodes de programmation avancées. Ce modèle repose sur les hypothèses suivantes :
- on ne peut pas construire une maison tant qu’on n’a pas identifié les besoins de la famille, fait dessiner des plans par un architecte… Pour garantir la robustesse de l’édifice, il convient donc d’enchainer de manière séquentielle plusieurs phases de développement :
- les conséquences d’une modification en amont du cycle (le haut de la chute d’eau) ont un impact majeur sur les coûts en aval (le bas) : si, une fois que vous avez monté la toiture de votre maison, vous décidez de modifier le besoin associé aux fondations alors que ce n’était pas prévu, cela va vous coûter très cher ! Reprenons l’image de la cascade : si vous vous êtes lancé dans le projet (certes un peu audacieux), de descendre les chutes du Niagara en bouée canard, et qu’au milieu du chemin, vous vous dites que finalement, vous auriez dû partir à gauche plutôt qu’à droite, vous aller devoir déployer beaucoup d’énergie pour remonter tout en haut !
La robustesse du modèle s’accompagne donc d’une certaine rigidité par rapport à toute demande de changement. Et le problème se pose lorsque le client peine à exprimer l’intégralité de ses besoins au démarrage du projet… ce qui s’avère, malheureusement, très fréquent !
Dix-sept hommes en colère
En février 2001, aux Etats-Unis, dix-sept experts en développement logiciel, venant d’horizons différents, se réunissent pour changer la donne. Leur objectif : extraire de leurs concepts respectifs des critères pour définir une approche différente de la cascade pour développer des logiciels.
Parmi eux : Ward Cunningham, l’inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l’extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l’ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler et Dave Thomas ainsi qu’Arie van Bennekum pour DSDM (Dynamic System Development Method), la version anglaise du RAD (développement rapide d’applications).
L’histoire ne dit pas s’ils sont en colère (peut-être même qu’ils ont passé un moment très agréable !), mais en tout cas, ils sont extrêmement productifs, car ils rédigent le Manifeste agile, constitué de quatre valeurs et de 12 principes fondateurs, et considéré comme la définition canonique du développement agile et de ses principes sous-jacents.
Première différence fondamentale : contraindre le projet par le périmètre, ou le contraindre par les moyens et les délais
Dans son Framework AGILE PM ®, DSDM représente les différences entre les 2 approches de la manière suivante : une approche traditionnelle qui contraint le projet par un périmètre à livrer (et asservit donc coûts et délais à ce dernier), et une approche agile qui le contraint par les coûts et les délais (et leur asservit donc le périmètre).
Reprenons l’exemple de la maison :
- dans une approche traditionnelle, l’architecte va dessiner les plans de la maison, puis on va cadrer les délais et moyens nécessaires pour réaliser le projet.
- dans une approche agile, on va décider de livrer en 3 mois et pour 100k€ une solution d’habitation qui réponde la mieux possible aux besoins de la famille… quitte à ne pas livrer tout ce qui avait été prévu par l’architecte !
Ce changement de paradigme va induire des modes de fonctionnement très différents entre les 2 approches.
2 manières d’aborder le projet
Nota : pour en savoir plus sur le bus factor
L’impact sur la réussite des projets
Le Standish Group a publié en 2015 la nouvelle version du Rapport CHAOS, qui présente une photographie de l’état de l’art du développement logiciel. Le rapport, qui analyse 50 000 projets à travers le monde (de petites modifications à la mise en oeuvre de refontes globales), intègre notamment une comparaison des performances des projets en fonction de l’approche utilisée :
Les chiffres interpellent, et posent les questions suivantes :
- Les approches agiles peuvent-elles s’appliquer à d’autres domaines qu’au développement logiciel ?
- faut-il passer au plus vite d’une approche traditionnelle à une approche agile, et si oui, de quelle manière gérer la transition ?
Rendez-vous dans le prochain billet !