Principes agiles : le Manifeste, ses valeurs et ce qu'elles changent

En février 2001, dix-sept praticiens qui expérimentaient chacun de leur côté des méthodes de développement légères se sont réunis et se sont mis d'accord sur une seule page de texte. Cette page — le Manifeste pour le développement agile de logiciels — contient quatre énoncés de valeurs et douze principes associés, et rien d'autre. Elle ne nomme aucun rôle, aucune réunion, aucun artefact et aucune certification. Tout ce que l'on appelle aujourd'hui agile, des tableaux Scrum aux événements de planification trimestriels en passant par toute l'industrie du passage à l'échelle, a été construit par-dessus cette page après coup, et une bonne partie la contredit.

C'est à cause de cet écart que ce guide commence par le texte lui-même. Si vous comprenez ce que les valeurs affirment réellement et contre quel problème les auteurs réagissaient, vous pouvez évaluer n'importe quelle pratique qu'on vous présente — y compris celles que votre organisation utilise déjà — sur ses mérites plutôt que sur le fait qu'elle porte l'étiquette agile. Cet article reste au niveau des valeurs et des principes ; le guide sur le framework Scrum couvre la mise en œuvre concrète la plus répandue, et celui sur les fondamentaux de la gestion de projet couvre la tradition prédictive avec laquelle le manifeste débattait.

Pourquoi le manifeste a été écrit

Le modèle dominant des années 1990 venait de disciplines d'ingénierie où la forme du produit était connue avant le début de la construction. On recueillait les exigences, on rédigeait une spécification, on concevait le système, on le construisait, on le testait et on le livrait — chaque phase étant terminée et validée avant que la suivante ne commence. On appelle généralement cette approche waterfall (en cascade), d'après un article de 1970 qui présentait le diagramme séquentiel comme un modèle défectueux servant de repoussoir, avant de proposer d'itérer ; l'industrie a adopté le diagramme et ignoré la mise en garde.

Des phases séquentielles fonctionnent quand trois conditions sont réunies : les exigences sont réellement connaissables à l'avance, elles ne changent pas pendant la construction, et le coût de la découverte d'une erreur à la fin reste supportable. Le logiciel n'en remplit presque jamais une seule. Les utilisateurs ne savent pas décrire ce qu'ils veulent tant qu'ils n'ont rien vu ; les marchés évoluent pendant un chantier de dix-huit mois ; et les défauts qui comptent le plus — un workflow mal compris, un écran inutilisable, un plafond de performance dans l'architecture — ne deviennent visibles que lorsque quelqu'un essaie de se servir du produit. Un projet qui découvre son malentendu central pendant la recette a déjà dépensé son budget.

Les méthodes légères de la fin des années 1990 étaient des réactions indépendantes à ce schéma. Elles différaient dans le détail mais partageaient un pari : si l'on ne peut pas connaître la réponse d'avance, il faut raccourcir la boucle entre faire et apprendre jusqu'à ce que le coût de l'erreur devienne faible.

Les quatre valeurs

Chaque valeur est formulée comme une comparaison, et toutes se terminent par la même précision : même si les éléments de droite ont de la valeur, les auteurs accordent davantage de valeur à ceux de gauche. Cette formulation compte. Aucune des quatre n'ordonne d'abandonner l'élément de droite.

Les individus et leurs interactions plutôt que les processus et les outils. Un processus défini rend des gens compétents un peu plus réguliers ; il ne rend pas bonne une équipe faible. Quand quelque chose tourne mal, la première question dans la plupart des organisations est de savoir quelle étape du processus a été sautée. La question du manifeste est de savoir quelle conversation n'a pas eu lieu. En pratique, cela signifie réunir physiquement, ou relier correctement, les personnes qui doivent se parler, garder des équipes petites et stables, et traiter un outil comme quelque chose qui enregistre une décision plutôt que comme quelque chose qui la prend.

Un logiciel opérationnel plutôt qu'une documentation exhaustive. La seule mesure honnête de l'avancement est un système qui tourne et fait quelque chose qu'un utilisateur reconnaît. Une spécification complète à quatre-vingt-dix pour cent ne vous dit rien sur la part du produit qui existe. C'est la valeur la plus souvent détournée, et la FAQ ci-dessous traite de ce détournement ; la discipline qu'elle exige, c'est que chaque document ait un lecteur identifié et une raison d'exister.

La collaboration avec le client plutôt que la négociation contractuelle. Les contrats au forfait, à périmètre et prix fixes, créent une relation conflictuelle dans laquelle chaque découverte devient une demande de changement et un bras de fer. L'alternative consiste à fixer le budget et le calendrier et à laisser le périmètre varier, avec un client présent en continu pour décider de ce qui remplit l'enveloppe. Cela suppose un client prêt à s'impliquer chaque semaine plutôt qu'aux jalons, ce qui est souvent la partie la plus difficile à obtenir dans une adoption de l'agilité.

L'adaptation au changement plutôt que le suivi d'un plan. Un plan est une prévision faite au moment de l'ignorance maximale. Traiter tout écart comme un échec crée une forte pression pour cacher les mauvaises nouvelles. Traiter le plan comme quelque chose à réviser à mesure que de nouveaux éléments arrivent rend les mauvaises nouvelles peu coûteuses à annoncer, et c'est le seul moyen qu'elles arrivent assez tôt pour qu'on puisse agir.

Les douze principes en pratique

Les principes sont plus concrets que les valeurs, et c'est là que se trouve l'essentiel du contenu pratique. Plutôt que de les énumérer comme des slogans, voici ce que chacun demande concrètement à une équipe de faire différemment.

Trois d'entre eux méritent qu'on s'y arrête, car ils sont régulièrement ignorés. Le neuvième principe lie l'agilité à la qualité de l'ingénierie : une base de code sans tests ne peut pas absorber des exigences qui changent, si bien qu'une équipe qui adopte les itérations sans adopter le test-driven development, l'intégration continue et le refactoring ralentira à chaque itération jusqu'à s'arrêter. Le huitième principe exclut le cycle sprint-puis-effondrement que beaucoup d'équipes prennent pour de la haute performance. Et le douzième est le moteur : sans rétrospective qui change quelque chose, les onze autres restent des règles figées au lieu d'un système qui s'améliore.

Le contrôle empirique des processus

Sous tout cela se trouve une idée empruntée à l'ingénierie des procédés. Un processus défini est un processus que l'on peut spécifier entièrement à l'avance puis exécuter : avec les mêmes entrées, il produit les mêmes sorties, donc le planifier une fois est rationnel. Un processus empirique est un processus où trop de variables sont inconnues, si bien qu'on le pilote plutôt par inspection et adaptation fréquentes — en faire un peu, regarder le résultat, ajuster.

L'empirisme a besoin de trois choses pour fonctionner : la transparence, pour que chacun voie le même état honnête du travail ; l'inspection, à une fréquence assez courte pour qu'une fausse route coûte peu ; et l'adaptation, c'est-à-dire l'autorité et la volonté de changer de cap en fonction de ce qui a été constaté. Retirez-en une et la boucle se rompt. Une équipe qui inspecte chaque semaine mais n'a aucune autorité pour changer quoi que ce soit tient une réunion de suivi, elle ne pilote pas un processus empirique.

Itératif et incrémental sont les deux techniques qui rendent l'inspection possible, et ce ne sont pas des synonymes. Incrémental signifie construire le produit par tranches qui ajoutent chacune une fonction utilisable — un parcours de connexion, puis une recherche, puis un paiement. Itératif signifie revenir sur l'existant et l'améliorer au fil de l'apprentissage. Une vraie livraison a besoin des deux : découper assez fin pour livrer, puis s'attendre à revenir retravailler les premières tranches dès que les utilisateurs s'en servent. Une équipe qui travaille uniquement de façon incrémentale accumule un produit plein de premiers jets.

Les contresens courants

• « Agile veut dire pas de documentation. » L'énoncé de valeur compare la documentation au logiciel opérationnel ; il ne la supprime pas. Les produits réglementés, les API publiques et les systèmes qui survivent à leur équipe ont tous besoin de documents écrits durables.
• « Agile veut dire pas d'estimations ni de dates. » Les décisions métier exigent des prévisions. L'agilité change la façon dont les prévisions sont produites et la fréquence à laquelle elles sont révisées — voir estimation et planification — pas le fait qu'elles existent.
• « Agile veut dire pas d'architecture. » Une conception émergente n'est pas une absence de conception. Cela signifie reporter les décisions jusqu'au dernier moment responsable et garder sous revue délibérée celles qui sont coûteuses à défaire.
• « Nous faisons des sprints de deux semaines, donc nous sommes agiles. » La durée d'itération est la chose la plus facile à copier et la moins significative. Une équipe qui planifie deux semaines de tâches assignées, rend compte de son avancement chaque jour et livre deux fois par an a changé son calendrier, et rien d'autre.
• « Auto-organisation veut dire pas de management. » Les équipes décident de la manière de faire le travail. Quelqu'un fixe toujours le cap, finance l'effort, recrute et règle les problèmes hors de portée de l'équipe.

Là où l'agilité ne convient pas

Être honnête sur les limites, c'est ce qui distingue un praticien d'un évangéliste.

Les approches adaptatives supposent qu'on peut se permettre de changer d'avis tardivement. Là où ce n'est pas le cas — génie civil, série de production de matériel, lancement de satellite, migration avec une bascule unique et irréversible —, une analyse initiale poussée est le choix rationnel, et les modèles hybrides qui planifient de façon prédictive les parties immuables tout en menant le logiciel de façon adaptative à l'intérieur fonctionnent mieux que de prétendre que tout est flexible.

Elles supposent aussi un client prêt à s'impliquer. Quand l'acheteur signe un contrat à périmètre fixe puis disparaît pendant six mois, ou quand une règle de marché public exige la spécification complète avant le choix d'un fournisseur, la valeur de collaboration n'a nulle part où s'exercer. Et elles supposent une équipe assez petite pour se parler. La coordination entre de nombreuses équipes demande une structure supplémentaire, ce que les frameworks de passage à l'échelle tentent d'apporter, et c'est bien pourquoi ils sont controversés.

Enfin, l'agilité au niveau de l'équipe ne peut pas réparer une chaîne de livraison qui met trois mois à faire arriver un changement en production. C'est précisément la contrainte que les pratiques DevOps ont pour rôle de lever, et sans elles une équipe peut être parfaitement agile jusqu'au moment où son travail attend dans une file.

Points clés à retenir

• Le manifeste tient en une page de quatre valeurs et douze principes ; chaque framework, rôle et cérémonie que l'on associe à l'agilité a été ajouté ensuite et reste optionnel.
• Chaque valeur est une comparaison qui reconnaît explicitement que l'élément de droite garde sa valeur — aucune n'abolit la documentation, les contrats ou les plans.
• Le contrôle empirique des processus — transparence, inspection, adaptation sur un cycle court — est le mécanisme ; la livraison itérative et incrémentale est ce qui crée quelque chose à inspecter.
• L'excellence technique n'est pas une garniture facultative : sans tests, automatisation et refactoring, la capacité à accueillir le changement disparaît en quelques mois.
• L'approche convient au travail intellectuel aux exigences incertaines et aux décisions réversibles, et convient mal là où un changement tardif est réellement catastrophique ou lorsque le client ne peut pas participer.
• Copier le calendrier — sprints, stand-ups, un tableau — sans changer qui décide, à quelle fréquence on livre et avec quelle honnêteté on rend compte est l'échec d'adoption le plus courant.