Les douze principes

Accueillir le changement

Le deuxième principe du Manifeste demande d'accueillir positivement les changements de besoins, même tard dans le projet. La phrase contredit l'expérience de tous ceux qui ont vu un projet dérailler à cause d'une demande de dernière minute. Elle ne tient que si l'équipe s'est organisée pour que changer coûte peu, et cet article examine cette condition.

Une demande au septième mois

Une petite entreprise livre des paniers de légumes par abonnement. Elle fait développer un site où ses clients gèrent leur compte. Le cahier des charges prévoit que le client peut modifier le contenu de son panier chaque semaine. Au septième mois, alors que le site est déjà utilisé par une centaine d'abonnés, la gérante appelle la responsable du projet.

« Nos clients ne modifient presque jamais leur panier, dit-elle. En revanche, ils nous écrivent tous pour suspendre l'abonnement pendant leurs vacances. Nous traitons ces courriels à la main et nous en oublions. Il nous faut un bouton de suspension. »

Dans un projet mené au forfait sur un cahier des charges figé, cette demande ouvre une négociation. Le prestataire rappelle que la suspension ne figurait pas au contrat, chiffre un avenant et annonce un report de la date de fin. La gérante a le sentiment d'être punie pour avoir compris son propre métier. Le prestataire, lui, a le sentiment qu'on lui demande de refaire gratuitement un travail déjà validé. Les deux ont raison selon les règles qu'ils se sont données.

Dans une équipe organisée selon le deuxième principe, la réponse est différente : « C'est une bonne nouvelle, vous savez maintenant ce que vos clients veulent. Les options de modification du panier, que nous devions enrichir ce mois-ci, peuvent attendre. Nous mettons la suspension en tête de liste et vous l'aurez dans deux semaines. » La demande tardive est traitée comme une information de valeur, et son coût se limite à un échange de priorités.

Ce que dit le 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.

Manifeste agile, principe 2

Le principe porte sur les « changements de besoins », c'est-à-dire sur ce que le client attend du produit. Il ne dit rien des autres changements qu'un projet peut subir, comme le départ d'un membre de l'équipe ou une réduction de budget.

Les mots « même tard » sont le cœur de la phrase. Tout le monde accepte un changement au début d'un projet, quand rien n'est construit. Le principe va plus loin et vise le moment où le changement dérange le plus. Le texte anglais dit « even late in development », tard dans le développement.

La seconde phrase donne la raison. Un changement de besoin y est présenté comme une occasion à exploiter au profit du client, plutôt que comme un aléa à supporter. Si un concurrent sort une nouvelle offre, si la réglementation évolue ou si les premiers utilisateurs se comportent autrement que prévu, le client qui peut réorienter son produit en quelques semaines a un avantage sur celui qui doit attendre la fin d'un plan établi un an plus tôt. Ce principe prolonge la quatrième valeur du Manifeste, présentée dans L'adaptation au changement.

Pourquoi les besoins changent

Les gestionnaires de projet ont longtemps traité le changement de besoin comme un défaut de préparation : si le client change d'avis, c'est que le recueil initial a été mal fait. Les signataires du Manifeste partent d'un constat inverse. Les besoins changent pour de bonnes raisons, et la plupart sont impossibles à éliminer par une meilleure préparation.

La première raison est que le client apprend en voyant. La gérante de notre exemple ne pouvait pas savoir, avant que le site existe, que ses abonnés demanderaient surtout à suspendre leurs livraisons. Cette connaissance est née de l'usage. Les anglophones résument ce phénomène par une formule : « je le saurai quand je le verrai ». La seconde raison est que le monde bouge pendant le projet. Plus un projet est long, plus il est probable qu'une loi, un concurrent ou une technologie viennent modifier ce qui avait été demandé au départ.

Un changement de besoin tardif porte donc une information que personne n'avait au début. Le refuser revient à livrer un produit conforme à ce que l'on croyait savoir un an plus tôt.

La question du coût

La difficulté est économique. En 1981, dans Software Engineering Economics, Barry Boehm a rassemblé des données de grands projets montrant que la correction d'une erreur de besoin coûte de plus en plus cher à mesure qu'elle est découverte tard : beaucoup plus pendant les tests que pendant la conception, et jusqu'à cent fois plus après la mise en service qu'au moment de la rédaction des besoins. Cette courbe a longtemps justifié l'effort mis sur les spécifications initiales. Si changer tard coûte cent fois plus cher, il faut tout décider tôt.

Boehm lui-même a nuancé ce chiffre. Dans un article de 2001 écrit avec Victor Basili, il écrit que ce rapport de cent pour un se vérifie « souvent », et qu'il est plutôt de l'ordre de cinq pour un sur les petits systèmes non critiques.

Kent Beck, dans Extreme Programming Explained (1999), a fait un pari différent. Il admet la courbe pour les projets tels qu'ils étaient menés, mais il soutient qu'elle dépend de la manière de travailler, et qu'un ensemble de pratiques peut l'aplatir au point que le coût d'un changement augmente peu avec le temps. Si ce pari est tenu, le raisonnement s'inverse : il devient raisonnable de décider tard, quand on en sait plus. L'article L'adaptation au changement présente cette courbe plus en détail.

Ce qui rend le changement bon marché

Le deuxième principe ne tient donc que grâce à d'autres pratiques. Celles que l'on cite le plus souvent sont rassemblées dans le tableau suivant.

Quelques-uns de ces termes demandent une définition. Le backlog est la liste ordonnée de tout ce qui reste à faire sur le produit, la plus haute priorité en tête. Le refactoring consiste à améliorer la structure interne du code sans changer ce qu'il fait. L'intégration continue est l'habitude de réunir très souvent le travail de tous les développeurs dans une version commune, contrôlée automatiquement. Ces pratiques sont détaillées dans L'excellence technique et la simplicité et dans Les pratiques d'ingénierie.

La dernière ligne du tableau vient du Lean appliqué au logiciel. Mary et Tom Poppendieck, dans Lean Software Development (2003), recommandent de décider le plus tard possible : on garde les options ouvertes tant que l'information manque, et l'on tranche au dernier moment où il est encore possible de le faire sans dommage.

Le backlog joue un rôle particulier. Dans la scène du début, la suspension d'abonnement a remplacé un travail prévu qui n'avait pas encore commencé. Rien n'a été jeté. Tant qu'un besoin n'est qu'une ligne dans une liste, le changer ne coûte que le temps d'une conversation. Le coût apparaît quand le changement touche ce qui est déjà construit, et les autres pratiques du tableau servent à limiter ce coût.

Hors du logiciel : la cuisine en carton

Accueillir ne veut pas dire tout accepter sur-le-champ

Le principe demande d'accueillir « positivement » le changement. Il ne demande pas de l'exécuter dans l'heure, ni de le faire gratuitement. Les méthodes agiles encadrent cet accueil de deux façons.

La première protège le travail en cours. Dans Scrum, pendant un sprint (une itération d'un mois au plus), on n'introduit pas de changement qui mettrait en danger l'objectif que l'équipe s'est fixé. La demande nouvelle entre dans le backlog et peut être traitée dès le sprint suivant. Le client attend au plus quelques semaines, et l'équipe termine ce qu'elle a commencé.

La seconde rend le coût visible. Dans XP, le client qui veut ajouter une demande à l'itération en retire une autre de taille équivalente. La réponse à une demande devient alors : « Oui, et voici ce que cela déplace. » C'est au client de décider si le changement vaut ce qu'il repousse.

Limites et pièges

Certains changements restent chers quelles que soient les pratiques. Changer le modèle des données quand des années d'historique y sont rangées, remplacer une technologie de base ou modifier un système qui a reçu une homologation réglementaire coûte beaucoup, même dans une équipe exemplaire. Dès qu'un produit comporte du matériel, changer tard redevient très coûteux : on ne modifie pas un moule d'injection comme une ligne de code. Les décisions difficiles à défaire méritent toujours d'être prises avec soin (voir Décisions réversibles et irréversibles dans le corpus Modèles mentaux).

Le changement peut aussi être le symptôme d'une absence de direction. Un client qui modifie ses priorités toutes les semaines sans rien avoir appris de nouveau hésite, et cette hésitation ne lui donne aucun avantage. L'équipe avance alors en zigzag et ne termine rien. Le principe suppose qu'il existe un cap, que les changements viennent corriger.

Il arrive également que le principe serve d'excuse. « Nous sommes agiles » peut vouloir dire que personne n'a pris la peine de réfléchir avant de commencer, ou qu'un prestataire refuse de s'engager sur quoi que ce soit. Le Manifeste reconnaît la valeur du plan, et un changement n'a de sens que par rapport à une intention de départ.

Reste la question de savoir qui paie. Un contrat au forfait sur un périmètre figé rend le changement conflictuel par construction, comme dans la première version de notre scène. Le deuxième principe demande donc une autre forme de relation avec le client, décrite dans La collaboration avec les clients. Il a aussi un coût humain : voir son travail du mois dernier mis de côté est décourageant, et une équipe l'accepte mieux quand on lui explique ce qui a été appris.

Enfin, l'aplatissement de la courbe du coût du changement est une conviction de praticiens, appuyée sur leur expérience, plus qu'un résultat mesuré. L'article Que valent les preuves ? fait le point sur ce qui est étayé.