Les pratiques agiles et l'Extreme Programming

Beaucoup d'équipes échouent non pas faute de talent, mais sous le poids de leurs propres processus. Persuadées qu'elles livrent le mauvais produit, elles concluent qu'elles manquent de méthode, alors elles en rajoutent : davantage de documents, de revues, d'étapes, de jalons. Robert C. Martin nomme ce cercle vicieux l'inflation incontrôlée des processus (runaway process inflation) — un « monstre » qui décrivait assez bien l'état de bien des entreprises de logiciel autour de l'an 2000. Ce chapitre raconte la réaction à ce monstre : la naissance du mouvement agile, les valeurs et principes qu'il a posés, puis le panorama concret de l'Extreme Programming (XP), la plus célèbre des méthodes agiles, dont les pratiques irriguent tout le reste du livre.

L'Agile Alliance et son Manifeste

Début 2001, un groupe d'experts du secteur, lassés de voir tant d'équipes englués dans ce bourbier de processus toujours plus lourds, se réunit pour énoncer les valeurs et principes qui permettraient aux équipes de travailler vite et de répondre au changement. Ils se baptisent l'Agile Alliance. Le fruit de leur travail tient en quelques lignes : le Manifeste pour le développement agile de logiciels (Manifesto for Agile Software Development).

Le Manifeste ne dit pas que les pratiques traditionnelles sont sans valeur. Il établit un ordre de préférence : à gauche, ce qui compte le plus ; à droite, ce qui garde de la valeur mais passe au second plan.

Les individus et leurs interactions

Les gens sont l'ingrédient le plus important du succès. Un bon processus ne sauvera pas un projet si l'équipe ne compte pas de joueurs solides ; mais un mauvais processus peut rendre inefficaces les meilleurs d'entre eux. Or un joueur solide n'est pas forcément un programmeur d'exception : c'est souvent quelqu'un de moyen qui travaille bien avec les autres. Communiquer et interagir compte davantage que le talent brut. Une équipe de programmeurs moyens qui communiquent bien réussira plus probablement qu'un groupe de vedettes incapables de fonctionner ensemble.

Les outils — compilateurs, IDE, gestion de versions — sont vitaux, mais on les surestime souvent : une surabondance d'outils lourds et encombrants est aussi nuisible que leur absence. Le conseil de Martin est de commencer petit. N'achetez pas le système de gestion de versions le plus cher avant d'avoir essayé un gratuit ; utilisez tableaux blancs et papier millimétré avant d'investir dans le meilleur des ateliers de génie logiciel ; tentez les fichiers plats avant le mastodonte des bases de données. Surtout, construire l'équipe importe plus que construire l'environnement : trop d'équipes bâtissent l'environnement d'abord en espérant que l'équipe « prendra » toute seule. Faites l'inverse — formez l'équipe, puis laissez-la configurer son environnement selon ses besoins.

Un logiciel qui fonctionne

Un logiciel sans documentation est un désastre : le code n'est pas le médium idéal pour communiquer la raison d'être et la structure d'un système. Mais trop de documentation est pire que pas assez. Les énormes documents coûtent un temps fou à produire et plus encore à maintenir synchrones avec le code ; faute de l'être, ils deviennent de grands mensonges complexes et une source majeure de désorientation.

L'équipe devrait écrire un court document de justification et de structure — une ou deux douzaines de pages au plus, traitant uniquement de la logique de conception et des structures de plus haut niveau. Comment, alors, former les nouveaux ? En travaillant étroitement avec eux, en s'asseyant à leurs côtés. Les deux meilleurs vecteurs d'information restent le code (qui ne ment jamais sur ce qu'il fait) et l'équipe (qui détient dans sa tête la carte sans cesse mouvante du système). D'où une règle que Martin appelle sa première loi de la documentation.

La collaboration avec le client

On ne commande pas un logiciel comme une marchandise. Rédiger un cahier des charges puis le confier à quelqu'un qui reviendra, à date et prix fixes, avec le système attendu — cette approche a échoué encore et encore, parfois de façon spectaculaire. Les projets qui réussissent reposent sur un retour fréquent et régulier du client, qui travaille au contact étroit de l'équipe plutôt que de s'en remettre à un contrat.

Un contrat qui fige exigences, calendrier et coût est fondamentalement défaillant : ses termes deviennent caducs bien avant la fin du projet (parfois avant même sa signature). Les meilleurs contrats sont ceux qui régissent la manière dont l'équipe et le client travailleront ensemble. Martin cite un projet d'un demi-million de lignes négocié en 1994 : son équipe touchait un tarif mensuel modeste, et de gros paiements survenaient à la livraison de blocs de fonctionnalités — déclenchés non par une spécification détaillée, mais par le succès des tests d'acceptation du client. Le logiciel lui était livré presque tous les vendredis ; le lundi suivant, il revenait avec une liste de changements. Les exigences fluctuaient en permanence, des blocs entiers disparaissaient et d'autres surgissaient, et pourtant le projet a survécu et réussi — grâce à cette collaboration intense.

L'adaptation au changement

C'est souvent la capacité à répondre au changement qui décide du sort d'un projet. Le cours d'un projet ne se planifie pas très loin dans le futur : l'environnement métier évolue, les clients modifient leurs exigences dès qu'ils voient le système fonctionner, et même quand les exigences sont stables, nous estimons mal le temps de développement.

Le manager novice est tenté de scotcher au mur un beau diagramme de Gantt couvrant tout le projet, croyant ainsi le maîtriser. Ce qui se passe en réalité, c'est que la structure du diagramme se dégrade : à mesure que l'équipe et le client apprennent, des tâches deviennent inutiles, d'autres apparaissent. Le plan change de forme, pas seulement de dates. Une meilleure stratégie consiste à planifier en résolution décroissante : des plans détaillés pour les deux prochaines semaines, des plans grossiers pour les trois prochains mois, des plans très flous au-delà. On n'investit dans le détail que pour ce qui est imminent ; le reste demeure souple.

Les douze principes

Ces quatre valeurs ont inspiré douze principes qui distinguent un ensemble de pratiques agiles d'un processus lourd.

1. Notre plus haute priorité est de satisfaire le client par la livraison rapide et continue de logiciel utile. Une étude de la MIT Sloan Management Review a montré une forte corrélation entre qualité finale et livraison précoce d'un système partiellement fonctionnel — plus la première livraison est minimale, plus la qualité finale est élevée — ainsi qu'entre qualité et fréquence des livraisons.
2. Accueillez les changements d'exigences, même tard dans le développement. C'est une posture : les changements sont vus comme de bonnes choses, signe que l'équipe a appris ce qu'il faut pour satisfaire le marché.
3. Livrez du logiciel qui fonctionne fréquemment, de quelques semaines à quelques mois, avec une préférence pour les délais courts. Les lots de documents ou de plans ne comptent pas comme de vraies livraisons.
4. Les gens du métier et les développeurs doivent travailler ensemble quotidiennement. Un projet logiciel n'est pas une arme « tire et oublie » : il faut le guider en continu.
5. Bâtissez les projets autour d'individus motivés : donnez-leur l'environnement et le soutien dont ils ont besoin, et faites-leur confiance. Tout le reste — processus, environnement, management — est un effet de second ordre, ajustable s'il nuit aux gens.
6. La conversation en face à face est la méthode la plus efficace pour transmettre l'information. On crée des documents seulement quand un besoin immédiat et significatif le justifie ; par défaut, on parle.
7. Le logiciel qui fonctionne est la principale mesure de l'avancement. On ne mesure pas le progrès à la phase en cours ni au volume de documentation : on est avancé à 30 % quand 30 % des fonctionnalités nécessaires marchent.
8. Les processus agiles promeuvent un rythme soutenable. Un projet se court comme un marathon, pas comme un sprint de 50 mètres : pas question d'emprunter l'énergie de demain pour en faire un peu plus aujourd'hui.
9. Une attention continue à l'excellence technique et à la conception renforce l'agilité. La haute qualité est la clé de la vitesse : on ne fait pas de cochonneries en se promettant de nettoyer plus tard.
10. La simplicité — l'art de maximiser la quantité de travail non fait — est essentielle. On prend toujours le chemin le plus simple compatible avec l'objectif, sans chercher à se prémunir contre tous les problèmes de demain.
11. Les meilleures architectures et conceptions émergent d'équipes auto-organisées. Les responsabilités sont communiquées à l'équipe entière, qui décide de la meilleure manière de les remplir ; nul n'est seul propriétaire de l'architecture ou des tests.
12. À intervalles réguliers, l'équipe réfléchit à comment devenir plus efficace, puis ajuste son comportement en conséquence. L'environnement change sans cesse ; l'équipe doit changer avec lui pour rester agile.

Au moment où Martin écrit, plusieurs processus agiles coexistent — SCRUM, Crystal, le développement piloté par les fonctionnalités (Feature Driven Development), l'Adaptive Software Development — mais le plus marquant reste l'Extreme Programming.

Le tour d'horizon de l'Extreme Programming

Les valeurs et principes agiles fixent des buts et des attitudes, mais ne disent pas précisément quoi faire. C'est là qu'intervient l'XP : un ensemble de pratiques simples mais interdépendantes, qui se renforcent mutuellement pour former un tout supérieur à la somme de ses parties. Affaiblir l'une fragilise les autres. Voici ce tout.

Le client membre de l'équipe

On veut que le client et les développeurs travaillent au contact l'un de l'autre, conscients de leurs problèmes respectifs. Le client d'une équipe XP est la personne ou le groupe qui définit et priorise les fonctionnalités : analystes métier, représentants des utilisateurs, ou client payant. Quel qu'il soit, il est membre de l'équipe et disponible pour elle. L'idéal est qu'il travaille dans la même pièce que les développeurs ; à défaut, à moins de trente mètres. Plus la distance grandit, plus il est difficile d'en faire un vrai coéquipier. Si le vrai client ne peut être proche, trouvez quelqu'un de proche, capable et désireux de le représenter.

Les récits utilisateur

Pour planifier, il faut connaître les exigences — mais pas en détail. Il suffit d'en savoir assez pour estimer : savoir qu'il y a des détails, et de quels genres, sans en connaître les spécificités. Celles-ci changeront de toute façon avec le temps, surtout quand le client verra le système prendre vie. Capturer trop tôt le détail d'une exigence mène donc à du travail gâché et à une focalisation prématurée.

En XP, on saisit le sens des exigences en discutant avec le client, mais on ne capture pas ce détail. Le client écrit quelques mots sur une fiche cartonnée (index card) qui rappellera la conversation, et le développeur y inscrit une estimation au même moment, fondée sur le sens qu'il a tiré de l'échange.

Les cycles courts : itérations et releases

Un projet XP livre du logiciel qui fonctionne toutes les deux semaines. Chaque itération produit un système opérationnel qui répond à une partie des besoins, démontré aux parties prenantes en fin de cycle pour recueillir leur retour.

Le plan d'itération (iteration plan) couvre généralement deux semaines : c'est une livraison mineure, mise ou non en production. Les développeurs fixent un budget d'itération en mesurant ce qu'ils ont accompli lors de la précédente ; le client choisit alors autant de récits qu'il veut, tant que le total des estimations ne dépasse pas ce budget. Une fois l'itération lancée, le client s'engage à ne plus changer la définition ni la priorité de ses récits ; les développeurs sont libres de les découper en tâches et de les traiter dans l'ordre le plus sensé.

Le plan de release (release plan) cartographie les six itérations à venir environ. Une release représente d'ordinaire trois mois de travail : une livraison majeure, généralement mise en production. Là encore, le budget se déduit de la vélocité passée, et le client priorise les récits dans la limite du budget. Mais rien n'est gravé dans le marbre : le client peut à tout moment annuler un récit, en écrire un nouveau, ou en changer la priorité.

Les tests d'acceptation

Le détail des récits est capturé sous forme de tests d'acceptation (acceptance tests) spécifiés par le client, écrits juste avant — ou en même temps que — l'implémentation du récit. Rédigés dans un langage de script permettant de les exécuter automatiquement et de façon répétée, ils vérifient ensemble que le système se comporte comme le client l'a spécifié. Le client peut développer ce langage avec l'aide des développeurs ou d'un service qualité (QA).

La programmation en binôme

Tout le code de production est écrit par des paires de programmeurs travaillant ensemble au même poste. L'un tient le clavier et tape (le « pilote ») ; l'autre observe le code, traquant erreurs et améliorations. Les deux interagissent intensément, pleinement engagés. Les rôles changent fréquemment : le clavier passe de l'un à l'autre plusieurs fois par heure. Le code résultant est conçu et écrit par les deux ; aucun ne peut s'en attribuer plus de la moitié.

La composition des paires change au moins une fois par jour, si bien que chacun travaille dans deux paires différentes par jour. Sur la durée d'une itération, chaque membre devrait avoir travaillé avec tous les autres, et sur presque tout ce qui s'y joue. Cela diffuse la connaissance à travers l'équipe : les spécialistes restent, mais ils font équipe avec presque tout le monde, si bien que d'autres peuvent les remplacer au pied levé. Les études de Laurie Williams et de Nosek suggèrent que la programmation en binôme (pair programming) ne réduit pas l'efficacité de l'équipe tout en abaissant significativement le taux de défauts.

Le développement piloté par les tests

Tout le code de production est écrit pour faire passer un test unitaire qui échoue. On écrit d'abord un test qui échoue parce que la fonctionnalité testée n'existe pas, puis le code qui le fait passer. L'aller-retour entre test et code est très rapide — de l'ordre de la minute — et les deux évoluent ensemble, le test précédant le code d'une infime fraction.

// 1. On écrit d'abord le test, qui échoue (la fonction n'existe pas).
test("additionne deux nombres", () => {
  expect(additionner(2, 3)).toBe(5);
});

// 2. On écrit le minimum de code pour le faire passer.
function additionner(a: number, b: number): number {
  return a + b;
}
// 3. On relance les tests : au vert. On passe au cas suivant.

Il en résulte un corpus de tests très complet qui grandit avec le code. Les programmeurs peuvent vérifier à tout instant que le programme marche : après le moindre changement, ils relancent les tests pour s'assurer de n'avoir rien cassé, ce qui facilite grandement le remaniement. Plus subtil encore : du code écrit pour être testable est, par définition, testable — et il existe une forte incitation à découpler les modules les uns des autres pour les tester indépendamment. Le développement piloté par les tests (Test-Driven Development, TDD) pousse donc naturellement vers une conception faiblement couplée, et les principes de conception orientée objet y jouent un rôle décisif.

La propriété collective du code

Une paire a le droit d'extraire n'importe quel module et de l'améliorer. Aucun programmeur n'est individuellement responsable d'un module ou d'une technologie : tout le monde touche à l'interface graphique, à l'intergiciel, à la base de données. Personne n'a plus d'autorité qu'un autre sur quoi que ce soit. La propriété collective (collective ownership) ne nie pas les spécialités : si votre domaine est l'IHM, vous y travaillerez surtout, mais on vous demandera aussi de faire équipe sur l'intergiciel ou la base — et rien ne vous interdit d'apprendre une seconde spécialité au contact d'un expert.

L'intégration continue

Les programmeurs intègrent leur code plusieurs fois par jour. La règle est simple : le premier à intégrer gagne, tous les autres fusionnent. Les équipes XP utilisent un contrôle de version non bloquant : chacun peut extraire n'importe quel module à tout moment, quel que soit qui d'autre l'a extrait. En réintégrant, il doit être prêt à fusionner avec les changements de ceux qui l'ont précédé — d'où l'intérêt d'intégrer très souvent, pour éviter les longues sessions de fusion.

Une paire travaille une heure ou deux sur une tâche, crée tests et code de production, puis, à un point de rupture commode (souvent bien avant la fin de la tâche), décide de réintégrer. Elle s'assure d'abord que tous les tests passent, intègre son code, fait la fusion si nécessaire, reconstruit le système complet, et relance tous les tests, y compris les tests d'acceptation en cours. Si elle a cassé quelque chose qui marchait, elle le répare avant de finaliser. Ainsi, les équipes XP construisent le système plusieurs fois par jour, de bout en bout : si le produit final est un CD, elles le gravent ; si c'est un site web, elles le déploient sur un serveur de test.

Le rythme soutenable

Un projet est un marathon, pas un sprint. Une équipe qui bondit de la ligne de départ et fonce s'épuisera bien avant l'arrivée. Pour finir vite, il faut tenir un rythme soutenable (sustainable pace), conserver énergie et vigilance, avancer délibérément à allure régulière et modérée. La règle XP : pas d'heures supplémentaires, à une seule exception — la dernière semaine d'une release, si l'équipe est à portée de son objectif et peut sprinter vers la ligne d'arrivée.

L'espace de travail ouvert

L'équipe travaille ensemble dans une pièce ouverte, garnie de tables portant deux ou trois postes, chacun avec deux chaises pour la paire ; les murs sont couverts de graphiques d'avancement, de découpages de tâches, de diagrammes. Le bruit ambiant est un bourdonnement de conversations : chaque paire est à portée d'oreille des autres, perçoit quand l'une d'elles est en difficulté, connaît l'état des travaux voisins. On pourrait craindre un environnement distrayant et improductif ; en pratique, c'est l'inverse — une étude de l'université du Michigan suggère qu'un tel environnement de « salle de guerre » peut doubler la productivité.

Le jeu de la planification

L'essence du jeu de la planification (planning game) est la division des responsabilités entre métier et développement : les gens du métier (les clients) décident de l'importance d'une fonctionnalité, les développeurs décident de son coût. Au début de chaque release et de chaque itération, les développeurs donnent aux clients un budget fondé sur leur vélocité passée, et les clients choisissent des récits dont le total ne dépasse pas ce budget. Avec ces règles simples, des itérations courtes et des releases fréquentes, clients et développeurs prennent vite le rythme du projet : les clients perçoivent la vitesse de l'équipe et peuvent estimer durée et coût.

La conception simple

Une équipe XP rend ses conceptions aussi simples et expressives que possible, et restreint son attention aux seuls récits prévus pour l'itération courante. Elle ne se soucie pas des récits à venir : elle fait migrer la conception d'itération en itération pour qu'elle soit la meilleure conception possible pour les récits actuellement implémentés. Concrètement, l'équipe ne commence pas par l'infrastructure : ni la base de données, ni l'intergiciel en premier. Son premier acte est de faire fonctionner le premier lot de récits de la manière la plus simple possible, et elle n'ajoute l'infrastructure que lorsqu'un récit l'y contraint. Trois mantras guident le développeur.

La duplication n'est pas toujours du copier-coller : deux algorithmes peuvent être remarquablement similaires en différant par de subtils détails. On les unifie alors en une fonction ou via le patron patron de méthode (Template Method). La meilleure façon d'éliminer la redondance est de créer des abstractions : si deux choses se ressemblent, il existe une abstraction qui les unifie. Éliminer la redondance force donc l'équipe à créer des abstractions et à réduire encore le couplage.

// ❌ Avant : YAGNI violé — on prépare une infrastructure
// dont aucun récit actuel n'a besoin.
class DepotCommandes {
  constructor(
    private cache: CacheRedis, // « on en aura besoin un jour »
    private brokerMessages: KafkaBroker, // idem
    private base: ClusterBaseDistribuee, // idem
  ) {}
  enregistrer(commande: Commande): void { /* ... */ }
}

// ✅ Après : la chose la plus simple qui puisse marcher pour
// les récits du moment. On ajoutera le reste quand un récit
// l'exigera vraiment.
class DepotCommandes {
  private commandes: Commande[] = [];
  enregistrer(commande: Commande): void {
    this.commandes.push(commande);
  }
}

Le remaniement permanent

Le code a tendance à pourrir : fonctionnalité après fonctionnalité, correctif après correctif, sa structure se dégrade jusqu'au fouillis inextricable. Les équipes XP inversent cette dégradation par un remaniement (refactoring) fréquent. Remanier, c'est appliquer une série de minuscules transformations qui améliorent la structure du système sans changer son comportement. Chacune est triviale, à peine digne d'être faite ; mais ensemble, elles produisent des transformations majeures de la conception. Après chaque transformation, on relance les tests unitaires pour s'assurer de n'avoir rien cassé, puis on enchaîne. On remanie ainsi en continu — toutes les heures ou demi-heures — pas à la fin du projet, de la release ou de l'itération, pour garder le code aussi propre, simple et expressif que possible.

La métaphore

La métaphore (metaphor) est la moins comprise des pratiques XP, au point que ses propres promoteurs ont parfois songé à la retirer — et pourtant elle est l'une des plus importantes. Pensez à un puzzle. Comment savoir comment les pièces s'assemblent ? Par leur forme, certes ; mais il y a plus puissant : l'image. L'image est le vrai guide ; elle est si puissante que si deux pièces adjacentes de l'image n'ont pas des formes complémentaires, vous savez que le fabricant s'est trompé. Voilà la métaphore : la vue d'ensemble qui relie tout le système et rend évidentes la place et la forme de chaque module. Si un module est incohérent avec la métaphore, c'est le module qui a tort.

Souvent, la métaphore se résume à un système de noms qui fournit un vocabulaire aux éléments du système et définit leurs relations. Martin raconte un système qui transmettait du texte à un écran lent : on remplissait un tampon, on l'évacuait sur disque quand il était plein, on le rechargeait quand il se vidait. L'équipe en parlait en termes de camions-bennes ramassant des ordures — les tampons étaient les petits camions, l'écran la décharge, le programme le producteur de déchets. Sur un autre système d'analyse de trafic réseau, les blocs de données collectés s'appelaient des « tranches », le programme d'analyse « le grille-pain » qui les « faisait cuire », et les variables individuelles des « miettes ». Des noms qui s'emboîtent et aident à penser le système comme un tout.

Tableau des pratiques XP

Pratique	En une phrase
Client dans l'équipe	Le client définit et priorise les fonctionnalités, et reste disponible pour l'équipe.
Récits utilisateur	Jetons mnémoniques d'une conversation, estimés, servant à planifier.
Cycles courts	Itérations de deux semaines, releases d'environ trois mois, livrées au budget de vélocité.
Tests d'acceptation	Spécifiés par le client, automatisés, ils ne doivent plus jamais échouer une fois verts.
Programmation en binôme	Tout le code de production écrit à deux, paires recomposées chaque jour.
Développement piloté par les tests (TDD)	Écrire le test qui échoue, puis le code qui le fait passer ; conception découplée.
Propriété collective	N'importe quelle paire peut améliorer n'importe quel module.
Intégration continue	Intégrer plusieurs fois par jour ; le premier gagne, les autres fusionnent.
Rythme soutenable	Pas d'heures sup' ; le projet est un marathon, pas un sprint.
Espace ouvert	Une salle commune où chaque paire est à portée d'oreille des autres.
Jeu de la planification	Le métier décide de l'importance, le développement décide du coût.
Conception simple	La conception la plus simple pour les récits du moment ; YAGNI, Once and Only Once.
Remaniement	Petites transformations continues qui améliorent la structure sans changer le comportement.
Métaphore	La vue d'ensemble et le vocabulaire qui relient tout le système.

L'XP n'est pas la seule méthode agile, et ses pratiques ne sont pas des dogmes : beaucoup d'équipes l'adoptent telle quelle, d'autres l'adaptent en ajoutant ou modifiant des pratiques. Mais ce socle concret est le terrain sur lequel poussera tout le reste de ce livre : c'est en remaniant sans relâche, sous la protection des tests, vers la conception la plus simple, que les principes et les patrons de conception orientée objet vont émerger — non comme un catalogue à appliquer d'avance, mais comme les réponses naturelles aux pressions du changement.

À retenir

• Le mouvement agile est né en réaction à l'inflation incontrôlée des processus : alourdir la méthode aggrave le mal au lieu de le guérir.
• Les quatre valeurs du Manifeste privilégient les individus aux processus, le logiciel qui marche à la documentation, la collaboration client à la négociation contractuelle, et l'adaptation au changement au suivi d'un plan.
• Les douze principes déclinent ces valeurs : livraison précoce et fréquente, accueil du changement, rythme soutenable, simplicité, excellence technique, équipes auto-organisées.
• L'Extreme Programming traduit l'agilité en pratiques concrètes, simples mais interdépendantes : le tout vaut plus que la somme des parties.
• Le cœur technique de l'XP — TDD, remaniement permanent, conception simple, intégration continue — produit du code testable, découplé et toujours prêt à changer.
• Le cœur humain — client dans l'équipe, binôme, propriété collective, espace ouvert, jeu de la planification, rythme soutenable — fait circuler la connaissance et tient l'équipe sur la durée.
• La conception émerge : on ne planifie pas l'architecture à l'avance, on la fait évoluer itération après itération vers la meilleure forme pour les récits actuellement implémentés.