Méthodes et pratiques

Extreme Programming

En 1996, Kent Beck reprend chez Chrysler un projet de paie qui n'a encore produit aucun bulletin. Il y applique sans demi-mesure quelques pratiques que les bons programmeurs connaissaient déjà, et il en tire une méthode au nom provocateur : Extreme Programming, ou XP. Cet article présente ses valeurs et ses pratiques, raconte le projet qui l'a fait connaître et fait le point sur ce que l'on sait de son efficacité.

Un projet de paie chez Chrysler

Au début des années 1990, le constructeur automobile Chrysler décide de remplacer ses différentes applications de paie par un système unique. Le projet s'appelle Chrysler Comprehensive Compensation System, abrégé en C3. Lancé en 1993, il doit à terme payer les quelque 87 000 salariés de l'entreprise. Le développement se fait dans le langage Smalltalk, mais en 1996 le système n'a toujours pas imprimé un seul bulletin de paie.

Chrysler fait alors appel à Kent Beck, un consultant réputé dans le milieu Smalltalk. Beck fait repartir le projet sur de nouvelles bases et demande à Ron Jeffries d'accompagner l'équipe au quotidien, dans un rôle que l'on appellera bientôt « coach ». L'équipe travaille dans une même salle, écrit ses tests avant le code, programme à deux par poste et assemble son travail plusieurs fois par jour. En 1997, le système entre en service et paie environ dix mille personnes.

La suite est moins heureuse. C3 n'a jamais été étendu au reste des salariés. Les nouveaux développements cessent en 1999 et le projet est arrêté en février 2000, après le rapprochement de Chrysler avec Daimler-Benz. Ce projet au bilan mitigé reste le lieu de naissance d'une méthode : Beck y a mis au point l'ensemble de pratiques qu'il publie en 1999 sous le titre Extreme Programming Explained: Embrace Change.

Pourquoi « extrême » ?

Le mot évoque les sports à risque, mais Beck lui donne dans son livre un sens précis. Il part de pratiques dont personne ne conteste l'utilité et il se demande ce qui arriverait si on les poussait au maximum, comme on tourne un bouton de volume jusqu'au bout. Si relire le code d'un collègue est utile, on le relira en permanence, en programmant à deux. Si tester est utile, tout le monde testera tout le temps, les programmeurs comme les clients. Si les itérations courtes sont bonnes, on les rendra vraiment courtes. Une itération est un cycle de travail de durée fixe, au terme duquel l'équipe a produit quelque chose qui marche.

L'idée est donc moins téméraire que le nom ne le laisse croire : XP est une méthode très disciplinée. Beck la destine à des équipes de taille petite ou moyenne, confrontées à des besoins flous ou qui changent vite.

Quatre valeurs, puis cinq

La première édition du livre repose sur quatre valeurs. La seconde, que Beck publie en 2004 avec Cynthia Andres, en ajoute une cinquième.

• La communication. Beck observe que les difficultés d'un projet remontent presque toujours à une chose importante que quelqu'un n'a pas dite à quelqu'un d'autre. Plusieurs pratiques d'XP obligent donc à se parler.
• La simplicité. Beck fait un pari : il vaut mieux faire simple aujourd'hui, quitte à payer un peu plus demain pour modifier, que faire compliqué aujourd'hui pour un besoin qui ne viendra peut-être jamais.
• Le feedback, ou retour d'information. Un test dit en quelques secondes si le code fonctionne, et une livraison dit en quelques semaines si le logiciel rend service.
• Le courage. Il en faut pour annoncer qu'un délai est intenable ou pour jeter un code mal parti. Beck prévient que le courage sans les trois autres valeurs est dangereux.
• Le respect, ajouté en 2004. Si les membres de l'équipe ne se soucient ni les uns des autres ni de leur travail, écrit Beck, la méthode ne peut pas fonctionner.

Les douze pratiques de 1999

Le livre de 1999 décrit douze pratiques, qui rendent ces valeurs concrètes.

Prises une à une, plusieurs de ces pratiques paraissent imprudentes : une conception réduite au strict nécessaire risque de devoir être refaite, et laisser chacun modifier n'importe quel code ressemble à une invitation au désordre. L'argument central de Beck est que chaque pratique compense les faiblesses des autres. La conception simple est tenable parce que le refactoring permet de la faire évoluer. Le refactoring est sûr parce que les tests signalent aussitôt une régression, c'est-à-dire un comportement qui marchait et qui ne marche plus.

Écrire le test d'abord

Dans XP, le programmeur commence par écrire un test automatisé, c'est-à-dire un petit programme qui vérifie un cas précis. Il écrit ensuite le code qui fait réussir ce test, puis il nettoie ce code. Beck a consacré à cette discipline un livre entier en 2002, et l'on parle depuis de développement piloté par les tests, ou TDD. Les tests accumulés forment un filet de sécurité que l'on rejoue à chaque modification.

Programmer à deux

Dans un binôme, l'un tient le clavier pendant que l'autre relit et pense à la suite. Les rôles s'échangent souvent, et les binômes se recomposent d'un jour à l'autre. Beck y voit une relecture permanente et un moyen de faire circuler la connaissance du système. La pratique a un coût évident, puisque deux personnes font ce qu'une seule semblait pouvoir faire, et la section sur les limites y revient.

Intégrer et livrer souvent

L'intégration continue consiste à réunir le travail de chacun dans le code commun plusieurs fois par jour, et à vérifier à chaque fois que tous les tests réussissent. Les petites livraisons prolongent cette logique jusqu'à l'utilisateur : le logiciel est mis en service très tôt, dans une version modeste, puis il grandit par ajouts fréquents.

Un client dans la salle

XP demande qu'une personne qui utilisera réellement le logiciel soit présente dans l'équipe. Elle fixe les priorités et répond aux questions au moment où elles se posent. Beck répond d'avance à l'objection du coût : si le projet ne mérite pas qu'on lui consacre un utilisateur, on peut se demander s'il mérite d'être mené.

Ce qui se transpose hors du logiciel

XP a été pensée pour des programmeurs, mais l'esprit de quelques-unes de ses pratiques s'applique à d'autres travaux.

La comparaison a ses limites. Il n'existe pas ici de tests automatisés que l'on rejoue en quelques secondes, alors que ce filet est ce qui rend le changement peu coûteux dans un logiciel.

D'XP au Manifeste, et après

XP est la méthode la mieux représentée à Snowbird en février 2001 : Kent Beck, Ron Jeffries, Ward Cunningham et Martin Fowler signent le Manifeste. Plusieurs des douze principes portent sa marque. La « semaine de 40 heures » se retrouve ainsi, sous une forme plus générale, dans le huitième principe :

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Manifeste agile, principe 8 (texte intégral)

La seconde édition du livre, en 2004, réécrit largement la méthode. Les pratiques sont réparties entre pratiques « primaires » et pratiques « corollaires », et plusieurs changent de nom. La semaine de 40 heures devient un travail mené « avec énergie », sans chiffre imposé. Le client sur site s'élargit à l'idée d'une équipe complète, qui réunit toutes les compétences nécessaires au projet.

Aujourd'hui, peu d'équipes disent « faire de l'XP ». Ses pratiques se sont pourtant diffusées partout : les user stories, les tests d'abord, l'intégration continue et le refactoring font partie du bagage courant des développeurs, souvent en complément de Scrum, qui ne dit rien de la technique.

Limites et pièges

Un projet fondateur au bilan discuté. C3 a payé dix mille personnes et non les 87 000 prévues, puis il a été arrêté. Les critiques d'XP y voient la preuve que la méthode ne tient pas ses promesses. Ses défenseurs répondent que le système a bel et bien été mis en service, alors que la première tentative n'avait rien livré. Un projet unique ne prouve de toute façon pas grand-chose.

Un ensemble fragile. Dans Extreme Programming Refactored (2003), Matt Stephens et Doug Rosenberg retournent l'argument de Beck. Si chaque pratique compense les faiblesses des autres, il suffit d'en abandonner une pour que l'ensemble se défasse, et peu d'organisations parviennent à les tenir toutes. Le piège courant est l'adoption partielle : une équipe retient la conception minimale, oublie les tests et le refactoring, et obtient un code que plus personne n'ose toucher.

Un client introuvable. Rares sont les organisations qui détachent un utilisateur à plein temps. Quand elles le font, cette personne porte seule la voix de tous les utilisateurs, ce qui est une charge lourde.

Des preuves partielles. La programmation en binôme a fait l'objet de nombreuses expériences. Une méta-analyse de Jo Hannay et de ses collègues, publiée en 2009 et portant sur dix-huit études, trouve un petit effet positif sur la qualité, un travail terminé plus vite et un effort total plus élevé. Les auteurs ajoutent que les résultats varient beaucoup d'une étude à l'autre et que des signes de biais de publication apparaissent. Le binôme n'est donc pas avantageux partout. Les résultats sur les tests d'abord sont eux aussi mitigés : ils sont détaillés dans l'article sur les pratiques d'ingénierie et replacés dans l'ensemble des preuves dans l'article critique du corpus.

Un domaine de validité étroit. XP suppose une petite équipe réunie dans un même lieu. Elle compte sur le code et sur les tests pour tenir lieu de documentation, ce qui convient mal aux équipes dispersées et aux systèmes soumis à des obligations réglementaires.