Les quatre valeurs

Des logiciels opérationnels

La deuxième valeur du Manifeste préfère un logiciel qui fonctionne à une documentation exhaustive. Elle propose surtout une manière de mesurer l'avancement : compter ce que les utilisateurs peuvent réellement faire, et non les documents produits. Elle ne demande pas de cesser d'écrire, et cet article précise quelle documentation mérite d'être gardée.

Un projet avancé à 65 % qui ne fait rien

Le comité de pilotage d'un projet se réunit au huitième mois. Le tableau d'avancement comporte quatre lignes : les spécifications sont terminées à 100 %, la conception à 100 %, la programmation à 60 % et les tests à 0 %. Le chef de projet fait la moyenne des quatre et annonce un avancement de 65 %. Une directrice demande à voir le logiciel. On lui explique qu'il n'y a encore rien à montrer, parce que les modules ne sont pas assemblés. Après huit mois de travail, aucun utilisateur ne peut accomplir la moindre tâche avec ce qui a été produit, et personne ne sait si les 35 % restants prendront quatre mois ou douze.

Dans le bâtiment voisin, une autre équipe travaille sur un projet comparable. Elle avait prévu vingt fonctions. Neuf sont livrées et utilisées chaque jour par le service comptable, ce qui représente 45 % du total. Ce chiffre est plus faible que le premier, mais il mesure quelque chose de vérifiable : neuf fonctions existent, ont été essayées par leurs utilisateurs et ont déjà été corrigées d'après leurs remarques.

La deuxième valeur du Manifeste prend parti pour la seconde façon de compter.

Des logiciels opérationnels plus qu’une documentation exhaustive

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

Un logiciel opérationnel (working software dans le texte anglais) est un logiciel qui tourne réellement, qui a été testé et avec lequel un utilisateur peut accomplir une tâche complète. Une maquette, un écran sans traitement derrière lui ou un programme « presque fini » n'entrent pas dans cette définition.

Le logiciel qui marche comme mesure

Deux des douze principes précisent la valeur. Le septième en fait un instrument de mesure :

Un logiciel opérationnel est la principale mesure d’avancement.

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

Le troisième fixe le rythme :

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

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

Ces deux phrases répondent à un problème ancien des projets informatiques. Tant qu'un logiciel n'est pas assemblé et essayé, son avancement repose sur des déclarations. Chacun estime de bonne foi que sa partie est « presque terminée », et les difficultés apparaissent au moment d'assembler l'ensemble. Une boutade attribuée à Tom Cargill, des laboratoires Bell, résume l'expérience : les premiers 90 % du code occupent 90 % du temps prévu, et les 10 % restants occupent les autres 90 %.

La réponse agile consiste à découper le travail en itérations, c'est-à-dire en périodes courtes au terme desquelles l'équipe a produit quelque chose qui fonctionne. Chaque itération ajoute un incrément, un morceau utilisable qui s'ajoute aux précédents. L'avancement se lit alors dans ce qui marche. Une fonction est terminée ou elle ne l'est pas, et l'équipe ne compte pas les fonctions à moitié faites.

Cette manière de faire a un second avantage. Un utilisateur réagit beaucoup mieux à un écran qu'il peut manipuler qu'à la description de cet écran dans un document. Les malentendus sur le besoin se révèlent donc à chaque livraison, quand ils sont encore faciles à corriger. L'article Livrer tôt et souvent de la valeur développe ce point.

Ce que l'on reprochait à la documentation exhaustive

Dans les grands projets des années 1980 et 1990, chaque phase se terminait par un document volumineux : cahier des charges, spécifications détaillées et dossier de conception. Jim Highsmith décrit ces démarches, dans l'historique du Manifeste, comme des processus lourds pilotés par la documentation.

Ces documents posaient plusieurs problèmes. Ils coûtaient cher à écrire et retardaient d'autant le premier essai réel. Ils décrivaient un besoin supposé, que personne n'avait encore pu vérifier. Ils cessaient d'être exacts dès que le programme évoluait, parce que peu d'équipes prenaient le temps de les mettre à jour. Or un document inexact peut faire plus de dégâts qu'un document absent, car le lecteur s'y fie.

Highsmith précise pourtant la position des signataires : ils acceptent la documentation, mais pas des centaines de pages jamais mises à jour et rarement consultées. La critique vise l'adjectif « exhaustive ». Le texte ne dit pas qu'il faut cesser de documenter.

Quelle documentation garder

La question utile porte sur le lecteur. Un document mérite d'être écrit quand on sait qui le lira, à quel moment et pour quoi faire. Alistair Cockburn, l'un des signataires, propose une image dans Agile Software Development (2001). Il compare un projet à un jeu coopératif dont le premier but est de livrer un logiciel qui fonctionne, et dont le second but est de préparer la partie suivante. La documentation sert ce second but. Elle s'adresse à ceux qui reprendront le logiciel, et elle doit être suffisante pour eux sans chercher à tout dire.

La dernière ligne mérite une explication. Un test automatisé est un petit programme qui vérifie qu'une fonction donne le résultat attendu. Une collection de tests constitue une description précise du comportement du logiciel, avec un avantage sur un document ordinaire : elle ne peut pas devenir fausse en silence, puisqu'un test qui ne correspond plus au programme échoue.

Hors du logiciel : un résultat utilisable plutôt qu'un dossier

La valeur se transpose à tout projet où l'on peut rédiger longtemps avant d'essayer. L'équivalent du logiciel opérationnel est alors un résultat que ses destinataires peuvent utiliser, même s'il est modeste.

L'exemple montre aussi ce que la valeur ne dit pas. Les professeurs ont bien écrit un document, parce que le conseil d'administration en a besoin pour décider. Ils l'ont écrit après l'essai, et il est plus court et plus juste que celui qu'ils auraient rédigé avant.

Limites et pièges

Le premier piège est de confondre « opérationnel » et « utile ». Un logiciel peut fonctionner parfaitement et ne servir à personne. Le premier principe du Manifeste parle de livrer des « fonctionnalités à grande valeur ajoutée », et compter les fonctions livrées ne dit rien de leur valeur. Une équipe jugée sur le nombre de fonctions produites finit par en produire beaucoup, y compris d'inutiles, selon un mécanisme que décrit l'article La loi de Goodhart du corpus Modèles mentaux.

Le deuxième piège est la formule « le code est la documentation », employée pour ne rien écrire. Elle oublie le nouvel arrivant qui doit comprendre le système, et la collègue qui part avec ce qu'elle était la seule à savoir. La phrase finale du Manifeste reconnaît la valeur de la documentation, et une équipe qui n'en produit aucune ne peut pas s'en réclamer.

Le troisième piège est de montrer un logiciel qui marche en apparence. Une démonstration réussie peut reposer sur un programme fragile, écrit à la hâte. On parle de dette technique, selon une métaphore proposée par Ward Cunningham en 1992, pour désigner ces raccourcis qui font gagner du temps aujourd'hui et qui renchérissent chaque modification future. C'est pourquoi les équipes agiles conviennent d'une définition précise de ce que « terminé » veut dire, tests compris (voir L'excellence technique et la simplicité et, dans le corpus Scrum, La Definition of Done et la qualité).

La valeur a aussi des limites d'application. Certains produits ne se découpent pas en petits morceaux utilisables : la moitié d'un pont ne permet pas de traverser, et un logiciel embarqué dans un appareil médical ne peut être mis en service qu'avec son dossier de certification. Dans ces domaines, la documentation exigée fait partie de ce qui rend le produit opérationnel.

Quant aux preuves, les livraisons petites et fréquentes figurent parmi les pratiques agiles les mieux étayées par les études disponibles, avec les réserves que détaille l'article Que valent les preuves ?. La question de la quantité de documentation à produire reste en revanche une affaire de jugement.