Les quatre valeurs

L'adaptation au changement

La quatrième valeur du Manifeste préfère l'adaptation au changement au suivi d'un plan. Elle est souvent résumée par « pas de plan », alors que les équipes agiles planifient beaucoup, à plusieurs échéances et de façon répétée. Cet article explique cette planification continue, puis présente avec prudence deux idées souvent citées à son appui : le cône d'incertitude et le coût du changement selon Kent Beck.

Un plan juste en septembre, dépassé en novembre

Mme Garnier enseigne les mathématiques en cinquième. En septembre, elle a établi sa progression pour l'année : trois semaines de fractions en novembre, puis la proportionnalité. Fin novembre, l'évaluation montre que quatorze élèves sur vingt-six, soit plus de la moitié, ne savent pas reconnaître deux fractions égales. Suivre le plan voudrait dire commencer la proportionnalité lundi, alors que ce chapitre s'appuie sur les fractions. Mme Garnier décide de consacrer une semaine de plus aux fractions et de ramener le chapitre de statistiques, prévu en juin, de trois semaines à deux.

Elle n'a pas abandonné sa progression. Elle l'a refaite, en tenant compte de ce qu'elle a appris sur sa classe et qu'elle ne pouvait pas savoir en septembre. Son plan de novembre est meilleur que celui de la rentrée parce qu'il repose sur plus d'informations. La quatrième valeur du Manifeste exprime ce choix.

L’adaptation au changement plus que le suivi d’un plan

Manifeste pour le développement Agile de logiciels (2001), texte intégral

Ce que dit la valeur

Un plan est rédigé au début d'un projet, c'est-à-dire au moment où l'on en sait le moins. Il contient des hypothèses sur le besoin, sur la difficulté du travail et sur ce qui se passera autour du projet. L'original anglais oppose le fait de répondre au changement (« responding to change ») au fait de suivre un plan (« following a plan »). La critique vise le plan devenu un but, que l'on continue d'exécuter alors que ses hypothèses se sont révélées fausses.

Dans un projet de logiciel, les sources de changement sont nombreuses. Le client comprend mieux ce qu'il veut en voyant les premières versions. La réglementation ou la concurrence évoluent. L'équipe découvre qu'une partie du travail est plus difficile que prévu. Les signataires du Manifeste en tirent une conclusion nette dans le deuxième principe :

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

Principes sous-jacents au Manifeste (2001), principe 2

L'article Accueillir le changement commente ce principe en détail. Martin Fowler rapporte que le mot « agile » a été retenu à Snowbird parce qu'il exprimait cette capacité d'adaptation. Kent Beck avait donné pour sous-titre à son livre sur Extreme Programming, en 1999, la formule « Embrace Change », que l'on peut traduire par « accueillir le changement ».

Planifier reste nécessaire

La phrase finale du Manifeste reconnaît la valeur du plan. Jim Highsmith écrit dans l'historique publié sur le site que les signataires planifient, tout en reconnaissant les limites de la planification dans un environnement instable. L'idée est ancienne. Dans un discours de 1957, le président américain Eisenhower rapportait une formule entendue dans l'armée, selon laquelle les plans ne valent rien mais la planification est tout. Le travail de préparation oblige à étudier la situation, et c'est cette connaissance qui permet de réagir quand les événements ne se passent pas comme prévu.

Les méthodes agiles remplacent le grand plan initial par une planification répétée. Kent Beck et Martin Fowler la décrivent dans Planning Extreme Programming (2000), et Mike Cohn dans Agile Estimating and Planning (2005). Elle se fait à plusieurs échéances, avec une précision qui augmente à mesure que l'échéance se rapproche.

Une itération est une période courte et de durée fixe au terme de laquelle l'équipe livre quelque chose qui fonctionne. Les demandes en attente sont rangées par ordre de priorité dans une liste appelée backlog. À la fin de chaque itération, l'équipe compare ce qu'elle a terminé à ce qu'elle avait prévu et corrige le plan de la version.

Le cône d'incertitude, à manier avec prudence

Pour justifier cette planification progressive, on cite souvent le « cône d'incertitude ». Dans le logiciel, l'idée remonte à Barry Boehm, qui écrivait en 1981 dans Software Engineering Economics qu'une estimation faite au tout début d'un projet peut se tromper d'un facteur quatre dans un sens ou dans l'autre, et que cette marge se resserre au fil des étapes. Steve McConnell a popularisé l'image du cône à la fin des années 1990. Appliquée à la lettre, elle signifie qu'un projet estimé à 6 mois au premier jour pourrait durer en réalité entre un mois et demi et 24 mois.

Ces chiffres ne doivent pas être pris pour une loi. Laurent Bossavit, qui a retracé leur origine dans The Leprechauns of Software Engineering, souligne qu'ils reposaient au départ sur le jugement de Boehm plus que sur des mesures. Todd Little a publié en 2006 dans IEEE Software les données de projets réels d'un éditeur de logiciels : l'incertitude relative sur la date de fin y restait à peu près la même à tous les stades. Le cône ne se referme donc pas tout seul avec le temps.

On peut retenir de cette image deux idées raisonnables. Les estimations faites au début sont très incertaines, et il est imprudent de s'engager fermement sur elles. L'incertitude ne diminue que si l'on apprend quelque chose, par exemple en livrant une partie du produit, ou si l'on prend des décisions qui ferment des options.

Le coût du changement selon Kent Beck

L'argument classique en faveur du plan détaillé repose sur une courbe. D'après des travaux menés notamment par Barry Boehm dans les années 1970 et 1980, une erreur coûte de plus en plus cher à corriger à mesure que le projet avance : peu de chose pendant l'analyse, beaucoup plus pendant les tests, et davantage encore après la mise en service. Si cette courbe monte très vite, il est rationnel de tout décider le plus tôt possible.

Dans Extreme Programming Explained, Kent Beck part de l'hypothèse inverse. Il soutient que certaines pratiques peuvent aplatir la courbe, de sorte qu'un changement tardif coûte à peine plus qu'un changement précoce. Ces pratiques sont les tests automatisés, qui signalent aussitôt ce qu'une modification a cassé, une conception simple, le refactoring, qui consiste à améliorer la structure du programme sans changer ce qu'il fait, et l'intégration continue, qui assemble et vérifie plusieurs fois par jour le travail de toute l'équipe. Si le changement coûte peu, il devient raisonnable de retarder les décisions jusqu'au moment où l'on dispose des meilleures informations.

Beck présente cette courbe aplatie comme le pari technique de sa méthode, sans prétendre l'avoir mesurée. Les données qui fondent la courbe classique sont elles-mêmes discutées, et Bossavit leur consacre un chapitre critique. Ce que l'on peut retenir est que le coût d'un changement tardif dépend en grande partie de la manière dont on a travaillé jusque-là. Les articles L'excellence technique et la simplicité et Les pratiques d'ingénierie décrivent ces pratiques et l'état des preuves qui les concernent.

Limites et pièges

S'adapter ne veut pas dire céder à toute demande. Dans les méthodes agiles, un changement est accueilli dans le backlog, où il est comparé aux autres demandes, et le contenu d'une itération en cours reste en principe stable. Scrum protège explicitement ce temps de travail, comme l'explique l'article Protéger le Sprint des interruptions du corpus Scrum : une équipe dont les priorités changent chaque jour a peu de chances de terminer ce qu'elle commence.

L'adaptation suppose aussi une direction. Mme Garnier modifie sa progression parce qu'elle garde un objectif stable : que ses élèves maîtrisent le programme en juin. Sans objectif de ce genre, les ajustements successifs deviennent une dérive, et l'invocation de l'agilité sert à masquer l'absence de réflexion.

Certains changements restent coûteux quelle que soit la méthode. On ne déplace pas facilement un mur porteur, on ne change pas sans peine la structure d'une base de données déjà remplie, et un matériel commandé ne se renvoie pas. Plus une décision est difficile à défaire, plus elle mérite d'être étudiée avant d'être prise (voir, dans le corpus Modèles mentaux, Les décisions réversibles). Certaines dates ne bougent pas non plus : une rentrée scolaire ou une échéance légale s'imposent au projet, et l'adaptation porte alors sur le contenu.

Le changement permanent use aussi les personnes. Des priorités sans cesse bouleversées par la direction fatiguent les équipes et contredisent le principe du rythme soutenable (voir Le rythme soutenable).

Il faut enfin redire que les deux modèles présentés ici, le cône et la courbe du coût du changement, reposent sur peu de données. Ils aident à raisonner, et l'article Que valent les preuves ? examine ce qui est réellement étayé.