Fondements

Avant le Manifeste : de la cascade aux méthodes légères

Le Manifeste de 2001 n'a inventé ni les cycles courts ni le travail au contact des utilisateurs. Il a donné un nom à des pratiques que certaines équipes employaient depuis des décennies et que plusieurs auteurs avaient mises en forme dans les années 1990. Pour comprendre ce que les signataires ont hérité et ce qu'ils ont rejeté, il faut remonter à 1970.

Un projet en cascade

Prenons une mutuelle qui décide, au milieu des années 1990, de refaire son logiciel de remboursement. Le projet est prévu sur dix-huit mois. Les six premiers servent à rédiger un cahier des charges de quatre cents pages, que la direction signe. Viennent ensuite quatre mois de conception, six mois de programmation et deux mois de tests. Les gestionnaires qui traiteront les dossiers voient les écrans pour la première fois au seizième mois. Ils découvrent alors que la saisie d'un remboursement demande de passer par trois écrans successifs, alors qu'ils traitent chacun plusieurs dizaines de dossiers par jour. Le logiciel est conforme au cahier des charges, et il faut pourtant quatre mois supplémentaires pour le rendre utilisable.

Cette organisation porte un nom : le modèle en cascade (waterfall en anglais). Le travail y descend d'une phase à la suivante sans revenir en arrière, comme l'eau d'un bassin à l'autre. On recueille d'abord tous les besoins, on conçoit ensuite toute la solution, on la programme, puis on la teste. Chaque phase se termine par un document validé qui sert d'entrée à la suivante. Le défaut que montre l'exemple est connu depuis longtemps : les erreurs commises au début ne se révèlent qu'à la fin, au moment où elles coûtent le plus cher à corriger.

Royce, 1970 : un article lu à l'envers

On fait souvent remonter la cascade à un article de Winston W. Royce, « Managing the Development of Large Software Systems », présenté en 1970. Royce est ingénieur et s'appuie sur son expérience des logiciels de missions spatiales. Il dessine bien le schéma des phases successives, depuis l'expression des besoins jusqu'à l'exploitation. Il écrit pourtant aussitôt qu'il croit à ce concept, mais que sa mise en œuvre telle quelle est risquée et expose à l'échec. La raison qu'il donne est celle de notre mutuelle : les tests arrivent à la fin, et c'est seulement là que l'on découvre si la conception tient. Quand elle ne tient pas, il faut reprendre la conception, parfois même les exigences.

Le reste de l'article propose cinq compléments pour réduire ce risque. Royce demande une conception préliminaire avant l'analyse détaillée, une documentation abondante, une planification soignée des tests et l'implication du client à plusieurs étapes. Il recommande surtout, quand le programme est développé pour la première fois, de le faire deux fois : la version livrée au client devrait être la seconde, la première servant d'essai.

Le mot « cascade » ne figure pas dans son texte. Son premier emploi connu se trouverait dans un article de Bell et Thayer publié en 1976. La description d'un développement par phases est par ailleurs plus ancienne que Royce : Herbert Benington en avait présenté une en 1956 à propos du système de défense aérienne SAGE, et il a précisé bien plus tard que ce projet s'était appuyé sur un prototype.

Il faut se garder du contresens inverse. Royce ne recommandait pas la cascade pure, mais il n'était pas pour autant un précurseur des méthodes agiles. Ses remèdes consistent à concevoir davantage en amont et à documenter beaucoup. Il écrit lui-même qu'il faut une documentation bien plus abondante que celle que les programmeurs produiraient spontanément. Son schéma simplifié a été retenu, et ses réserves ont été oubliées.

Pourquoi la cascade s'est imposée

Le modèle séquentiel avait de bons arguments. Il ressemble à la manière dont on construit un pont ou un immeuble, où l'on ne coule pas les fondations avant d'avoir terminé les plans. Il convient aux contrats, parce qu'il permet de fixer d'avance un prix, un délai et un contenu. Il rassure aussi ceux qui pilotent, puisque chaque phase se termine par un document que l'on peut signer.

De grandes administrations l'ont inscrit dans leurs règles. En 1985, le département américain de la Défense publie la norme DOD-STD-2167, qui impose à ses fournisseurs un cycle de développement en phases successives. Craig Larman et Victor Basili, dans leur histoire du développement itératif publiée en 2003, expliquent que cette norme imposait un modèle en cascade strict, que sa version révisée de 1988, DOD-STD-2167A, a encore été lue comme le modèle même de la cascade, et que la norme MIL-STD-498, qui la remplace en décembre 1994, encourage au contraire un développement itératif et évolutif.

L'analogie avec le bâtiment a pourtant une limite. Un logiciel se modifie beaucoup plus facilement qu'un mur porteur, et ses utilisateurs savent rarement décrire à l'avance ce dont ils ont besoin. Ils le découvrent en se servant d'une première version. C'est le cas de la plupart des travaux de conception, bien au-delà de l'informatique.

Le développement itératif est plus ancien qu'on ne le croit

La démarche d'Inès a deux caractéristiques. Elle est itérative, parce qu'elle repasse plusieurs fois par le cycle complet qui consiste à analyser, réaliser et vérifier. Chaque passage s'appelle une itération. Elle est aussi incrémentale, parce que le résultat grandit par morceaux utilisables qui s'ajoutent les uns aux autres. Chaque morceau ajouté s'appelle un incrément.

Larman et Basili montrent que cette manière de faire est ancienne. Ils la rattachent aux cycles courts d'amélioration que Walter Shewhart proposait dans les années 1930 pour la qualité industrielle et que W. Edwards Deming a ensuite diffusés (le corpus Lean les présente dans l'article Le PDCA et le rapport A3). Ils en trouvent des applications dans l'aéronautique des années 1950, puis dans le programme spatial Mercury de la NASA, au tournant des années 1960, dont le logiciel avançait par itérations très courtes. Ils citent aussi le logiciel de vol de la navette spatiale, construit de 1977 à 1980 en dix-sept itérations réparties sur trente et un mois, soit environ huit semaines chacune, parce que les exigences du programme changeaient en cours de route.

Plusieurs auteurs ont défendu cette approche avant les années 1990. Tom Gilb plaide dès les années 1970 pour une livraison « évolutive », par petits pas dont on mesure le résultat. Frederick Brooks, dans son article « No Silver Bullet » de 1986, conseille de faire grandir les logiciels progressivement plutôt que de les construire d'un bloc. Barry Boehm publie la même année son modèle en spirale, repris en 1988 dans la revue Computer. Le projet y parcourt plusieurs boucles. Chacune commence par l'examen des objectifs et des risques, passe souvent par un prototype et se termine par la préparation de la boucle suivante. L'idée centrale de Boehm est que les risques du projet doivent décider de la démarche : on traite d'abord ce qui est le plus incertain.

Les années 1990 : les méthodes légères

Dans les années 1990, plusieurs praticiens transforment ces idées en méthodes complètes, pensées pour de petites équipes. Elles ont été appelées « légères » par contraste avec les processus très documentés qui dominaient alors les grands projets.

Il faut y ajouter un livre qui ne propose pas de méthode, The Pragmatic Programmer d'Andrew Hunt et Dave Thomas (1999), consacré aux habitudes de travail du développeur. Extreme Programming est né sur un projet réel, le système de paie de Chrysler, dont Kent Beck prend la direction en 1996 (voir Extreme Programming). FDD a été mis au point pour un grand projet bancaire à Singapour. Ces méthodes viennent donc du terrain, et leurs auteurs étaient presque tous consultants ou chefs de projet.

Ce que ces méthodes avaient en commun

Malgré leurs différences, ces approches partagent plusieurs choix. Elles découpent le travail en cycles courts, de quelques semaines. Elles cherchent à montrer tôt un logiciel qui fonctionne, même incomplet. Elles gardent les utilisateurs près de l'équipe pendant tout le projet. Elles acceptent enfin que les besoins changent en cours de route, et elles s'organisent pour que ce changement coûte peu.

Elles diffèrent sur le reste. Extreme Programming prescrit des pratiques techniques précises, alors que Scrum organise le travail de l'équipe sans rien dire de la programmation. Crystal demande d'adapter la méthode à chaque projet, quand DSDM fournit un cadre plus complet. Au printemps 2000, lors d'une réunion organisée par Kent Beck dans l'Oregon, plusieurs de ces auteurs constatent cette parenté. Moins d'un an plus tard, ils se retrouvent à Snowbird et rédigent le Manifeste, qui énonce ce fonds commun sans choisir entre les méthodes. L'article Snowbird, février 2001 raconte cette rencontre.

Limites et pièges de cette histoire

Le premier piège est la caricature. Dans beaucoup de présentations, la cascade sert de repoussoir, et tout ce qui précède 2001 passe pour absurde. Or il est difficile de trouver un auteur qui ait défendu la cascade pure, et les démarches séquentielles gardent leur pertinence quand les besoins sont stables et que les modifications tardives sont très coûteuses. Le modèle en spirale de Boehm repose sur cette idée que la bonne démarche dépend des risques du projet.

Le deuxième piège est le mythe inverse, selon lequel l'agilité aurait inventé l'itération. Le Manifeste ne le prétend pas : ses auteurs y écrivent seulement qu'ils découvrent comment mieux développer des logiciels « par la pratique ».

Le troisième piège concerne les chiffres. Pour justifier l'abandon de la cascade, on cite souvent des statistiques alarmantes sur les échecs des projets informatiques des années 1990, en particulier celles des rapports CHAOS du Standish Group. Leur méthode a été sérieusement critiquée, et il faut les manier avec prudence. L'article Que valent les preuves ? fait le point sur cette question.

Enfin, cette histoire est le plus souvent racontée par ceux qui y ont pris part ou qui défendent le développement itératif. L'article de Larman et Basili, très bien documenté, est aussi un plaidoyer. Il faut le lire en sachant que les projets séquentiels qui ont réussi ont laissé moins de récits.