Abonnez-vous au blog

Afin de vous abonner et pour des raisons de sécurité, votre navigateur doit accepter les cookies et le JavaScript.

Approche traditionnelle ou agilité : quelles différences ?

Par le 20 juin 2016

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 :

Waterfall

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

Approche traditionnelle ou agilité : quelles différences ?

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

Approche traditionnelle ou agilité : quelles différences ?

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

Waterfall vs agile

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 :

Mesurer le % de réussite des projets

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 !

Autre dossier sur le même thème

Laisser un commentaire

Avatar

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Avatar

Adil Mostakim Il y a 8 années

Merci François pour l’article, c’est bien de valeur de profiter de l’innovation que la méthode agile a apportée, par contre nous constatons qu’il y a bel et bien des organisations assez complexes et bureaucratiques qui ne sont pas en mesure de franchir le cap, et par le fait même sont obligé de convenir à une méthode hybride entre agile et traditionnel !

Répondre
    François Debois

    François Debois Il y a 8 années

    @Adil : oui, la cohabitation des approches est un défi pour des organisations qui n’ont pas encore opéré leur mue ! Ce sera l’objet du billet de lundi prochain 🙂

Avatar

Laurent METAIS Il y a 8 années

Bonne comparaison des 2 méthodes.
Mais quid des projets qui ne sont pas uniquement logiciels mais qui intègrent des développements mécaniques et électroniques par exemple qui ne sont pas directement transposables en modèle agile ?

Répondre
    François Debois

    François Debois Il y a 8 années

    @Laurent: oui, c’est une question très pertinente, car les expériences de Scrum manufacturing se limitent aujourd’hui plus à du prototypage rapide qu’à des projets de développement lourds. Ce sera l’objet du billet de la semaine prochaine.

Abonnez-vous au blog

Afin de vous abonner et pour des raisons de sécurité, votre navigateur doit accepter les cookies et le JavaScript.