Les douze principes

Livrer tôt et souvent de la valeur

Trois des douze principes du Manifeste parlent de livraison. Le premier en fait la plus haute priorité, le troisième en fixe le rythme et le septième en fait la mesure de l'avancement. Lus ensemble, ils demandent de juger un projet à ce qu'il a déjà remis d'utilisable, et non à ce qu'il promet pour plus tard.

Un projet « terminé à 90 % »

Un réseau de médiathèques commande une application qui permettra aux lecteurs de réserver des documents depuis leur téléphone. Le projet est prévu sur quatorze mois. Tous les deux mois, un comité de pilotage se réunit, et l'échange y est à peu près toujours le même.

« Où en sommes-nous ? » demande la directrice du réseau.

« Les spécifications sont validées, la base de données est en place et le développement est réalisé à 90 %, répond le chef de projet. Il reste l'intégration et les tests. »

Au treizième mois, les bibliothécaires essaient l'application pour la première fois. Elles découvrent en dix minutes qu'elle ne sait pas traiter le cas le plus courant de leur métier : le lecteur qui veut réserver un livre actuellement emprunté dans une autre médiathèque du réseau. Personne n'avait menti pendant les comités. Les documents étaient bien validés et le code était bien écrit, mais rien de ce qui avait été produit ne pouvait être essayé par les personnes qui allaient s'en servir. L'erreur est donc restée invisible pendant un an.

Imaginez maintenant le même projet mené autrement. Au bout de trois semaines, l'équipe met en service une première version très réduite : on peut chercher un titre dans le catalogue et réserver un exemplaire disponible dans une seule médiathèque. Deux bibliothécaires et une vingtaine de lecteurs volontaires l'utilisent. La question des documents déjà empruntés arrive dès la première semaine d'usage, et elle est traitée dans la version suivante, trois semaines plus tard. Les principes 1, 3 et 7 du Manifeste décrivent cette seconde façon de travailler.

Ce que disent les trois principes

Le premier principe ouvre la liste et donne la priorité :

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Manifeste agile, principe 1

Le troisième précise 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.

Manifeste agile, principe 3

Le septième dit comment on sait où l'on en est :

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

Manifeste agile, principe 7

Le texte anglais du premier principe parle d'une livraison « early and continuous », c'est-à-dire précoce et continue, que la traduction française officielle rend par « rapidement et régulièrement ». Le principe demande donc de commencer à livrer tôt, puis de continuer sans interruption, ce qui est autre chose qu'une consigne de vitesse. Il désigne aussi ce qui est livré : des « fonctionnalités à grande valeur ajoutée ». La valeur est ce qui est utile à la personne qui se sert du produit ou qui le finance. Livrer d'abord ce qui a le plus de valeur revient à commencer par ce qui compte le plus pour le client, même quand une autre partie serait plus commode à réaliser.

Le troisième principe donne un ordre de grandeur, « de quelques semaines à quelques mois », et une direction, la préférence pour les cycles les plus courts. En 2001, beaucoup de projets ne livraient qu'une seule fois, à la fin, après un an ou deux de travail. Les méthodes des signataires proposaient déjà des cycles bien plus courts : Extreme Programming (XP) avançait par périodes d'une à quelques semaines, et Scrum par périodes de trente jours. Depuis, des équipes mettent en service des modifications plusieurs fois par jour, grâce aux techniques de livraison continue, qui automatisent les vérifications et la mise en service, décrites par Jez Humble et David Farley en 2010. Le principe n'impose aucune durée et indique seulement dans quel sens chercher.

Le septième principe emploie le mot « principale » : le logiciel opérationnel passe avant les autres mesures d'avancement sans les supprimer. Un logiciel est opérationnel quand il fonctionne réellement entre les mains de ses utilisateurs, ou au moins dans des conditions proches de l'usage réel. La deuxième valeur du Manifeste disait déjà la même chose sous une autre forme (voir Des logiciels opérationnels).

Itération, incrément et découpage par tranches

Deux mots reviennent dans toutes les méthodes agiles pour décrire ce rythme. Une itération est une période courte et de durée fixe au terme de laquelle l'équipe a produit quelque chose d'utilisable. Un incrément est ce que chaque itération ajoute à ce qui fonctionnait déjà. Le produit grandit ainsi par ajouts successifs, et chacun de ces ajouts fonctionne.

Cette façon d'avancer suppose de découper le travail autrement. Un plan classique procède par couches techniques : on construit d'abord la base de données, puis les règles de gestion, puis les écrans. Aucune couche ne peut être essayée seule par un utilisateur, et il faut attendre la dernière pour voir quelque chose. Le découpage agile procède par tranches : chaque tranche est une petite fonction complète, qui traverse toutes les couches. Dans l'exemple des médiathèques, « chercher un titre et réserver un exemplaire disponible » touche le catalogue, le compte du lecteur et l'écran du téléphone. La tranche est mince, mais elle sert déjà à quelqu'un. Alistair Cockburn, l'un des signataires, appelle « squelette ambulant » (walking skeleton) la toute première de ces tranches : une réalisation minuscule qui exécute une petite fonction de bout en bout.

Ce que la livraison précoce change

Le premier effet est le retour d'information, souvent appelé feedback. Les personnes qui commandent un produit savent rarement dire à l'avance tout ce qu'elles en attendent. Elles réagissent beaucoup mieux à une chose qu'elles peuvent essayer qu'à un document qui la décrit. Les bibliothécaires de notre exemple n'auraient sans doute pas repéré l'oubli en relisant quatre-vingts pages de spécifications, alors qu'elles l'ont vu en dix minutes d'usage.

Le deuxième effet concerne le risque. Les difficultés d'un projet se cachent souvent dans l'assemblage des parties : deux modules qui ne se comprennent pas, un temps de réponse trop long ou un système voisin qui ne fournit pas les données prévues. En livrant une tranche complète dès les premières semaines, l'équipe rencontre ces difficultés quand il reste du temps et du budget pour y répondre.

Le troisième effet est économique. Une fonction mise en service au troisième mois d'un projet de quatorze mois rend service pendant les onze mois qui restent. Dans un projet à livraison unique, elle n'aurait rendu aucun service pendant cette période.

Le dernier effet est la liberté de s'arrêter. Si les fonctions sont livrées par ordre de valeur, les dernières de la liste sont celles qui comptent le moins. Le client peut décider, au vu de ce qui fonctionne déjà, que la suite ne vaut plus son coût. Si le budget est coupé au huitième mois, il reste un produit incomplet mais utilisable.

Hors du logiciel : le mémoire remis chapitre par chapitre

Le produit minimum viable, une notion voisine et plus tardive

On associe souvent ces principes au « produit minimum viable », ou MVP (minimum viable product). Le terme ne figure pas dans le Manifeste. Il a été proposé par Frank Robinson en 2001, puis popularisé par Steve Blank et surtout par Eric Ries dans The Lean Startup (2011). Chez Ries, le MVP est la version d'un nouveau produit qui permet d'apprendre le plus possible sur les clients avec le moins d'effort possible. C'est un instrument d'expérience : il sert à vérifier une hypothèse, par exemple que des clients sont prêts à payer pour le service envisagé.

La différence avec l'incrément est réelle. Un incrément est un morceau du produit, destiné à rester et à être complété. Un MVP est construit pour savoir si le produit mérite d'exister, et il peut être abandonné une fois la réponse obtenue. Dans l'usage courant, le mot désigne maintenant n'importe quelle première version réduite, ce qui fait perdre l'idée d'expérience. Le corpus Lean revient sur cette filiation dans Le Lean hors de l'usine.

Mesurer l'avancement par ce qui fonctionne

Les mesures habituelles d'un projet comptent de l'activité : le pourcentage de tâches réalisées, les heures consommées ou le nombre de documents validés. Elles ont un défaut connu, que la scène du comité de pilotage illustre. Un travail déclaré « terminé à 90 % » peut rester dans cet état très longtemps, parce que les 10 % restants contiennent tout ce qui n'a pas encore été confronté à la réalité.

Un petit calcul montre ce que change le septième principe. Deux équipes doivent réaliser dix fonctions de taille comparable. La première a avancé chacune des dix à 80 %. La seconde en a terminé huit et n'a pas commencé les deux dernières. Les deux équipes ont fourni la même quantité de travail, l'équivalent de huit fonctions. Un tableau de suivi classique les mettrait à égalité, à 80 % d'avancement. Pourtant, les utilisateurs de la première équipe ne peuvent rien faire, et ceux de la seconde disposent de huit fonctions. Selon le septième principe, la seconde équipe est en avance, et la première n'a encore rien montré.

Cette mesure suppose que l'équipe s'entende sur ce que « terminé » veut dire : testé, intégré au reste et utilisable. Scrum appelle cet accord la Definition of Done (voir La Definition of Done et la qualité dans le corpus Scrum).

Dans le même esprit, Nicole Forsgren, Jez Humble et Gene Kim proposent dans Accelerate (2018) de mesurer la performance d'une équipe par sa fréquence de mise en service et par le délai qui sépare l'écriture d'une modification de son arrivée chez les utilisateurs, complétés par deux mesures de stabilité. Leurs enquêtes concluent que les équipes qui livrent le plus souvent sont aussi les plus stables. Ces résultats reposent sur des questionnaires déclaratifs, et l'article Que valent les preuves ? en discute la portée.

Limites et pièges

Livrer souvent ne veut pas dire livrer n'importe quoi. Le troisième principe parle d'un logiciel « opérationnel », et une équipe qui met en service toutes les deux semaines un produit plein de défauts ne l'applique pas. Des livraisons fréquentes exigent des tests automatisés et une intégration soignée, faute de quoi chaque livraison devient un risque (voir Les pratiques d'ingénierie).

La valeur est par ailleurs difficile à mesurer. Faute de mieux, beaucoup d'organisations comptent les fonctions livrées, et retombent ainsi dans une mesure d'activité. Une fonction en service que personne n'utilise n'a apporté aucune valeur. Le premier principe parle de satisfaire le client, ce qui oblige à aller voir ce qu'il fait réellement de ce qu'on lui a livré.

Tous les contextes ne permettent pas non plus de mettre en service toutes les deux semaines. Un logiciel embarqué dans un appareil médical, un système soumis à une homologation ou un produit matériel ont des cycles de mise en service longs. Le principe garde un sens si l'on distingue la livraison de la mise sur le marché : l'équipe peut remettre régulièrement une version qui fonctionne à des utilisateurs pilotes ou sur un banc d'essai, même si le public ne la reçoit qu'une fois par an. À l'inverse, des utilisateurs dont l'outil change sans cesse peuvent s'en lasser, et le rythme de livraison doit rester supportable pour eux.

Le découpage en petites tranches peut enfin faire perdre la vue d'ensemble. Un produit construit fonction après fonction, sans attention à sa conception générale, devient difficile à faire évoluer. Les principes 9 et 10 répondent à ce risque (voir L'excellence technique et la simplicité). Le mot « rapidement » ne doit pas davantage être lu comme une invitation à presser l'équipe : le huitième principe demande au contraire un rythme que l'on peut tenir dans la durée.