eXtreme Programming

eXtreme Programming — qu’on appelle simplement XP — est le membre le plus exigeant de la famille agile. East Agile Tracker est conçu pour XP en premier lieu ; tout le reste en découle.

Cette page couvre ce qu’est XP, pourquoi cela fonctionne, et comment le pratiquer avec le tracker comme surface de planification.

Ce qu’est XP

XP a été créé par Kent Beck à la fin des années 1990. Le premier livre — Extreme Programming Explained: Embrace Change — est paru en 1999. Tout est parti, comme souvent, d’une équipe à bout de souffle qui essayait de livrer un système de paie chez Chrysler.

Le pari de XP, c’est que la bonne manière de gérer l’incertitude dans le logiciel, c’est de faire les choses qui marchent, et de les faire plus souvent. Tester ? Tester en permanence. Intégrer ? Intégrer toutes les heures. Parler ? Parler sans cesse. Planifier ? Planifier à chaque itération, et re-planifier à mesure que l’on apprend.

« XP est une méthodologie légère destinée aux équipes de petite à moyenne taille qui développent du logiciel face à des exigences floues ou en évolution rapide. » — Kent Beck

Les cinq valeurs

XP énonce cinq valeurs auxquelles tout le reste se rattache :

1. Communication — L’équipe se parle. Tous les jours. Du travail, de la conception, des obstacles. En face à face quand c’est possible. Les silos sont l’ennemi.
2. Simplicité — Faire la chose la plus simple qui puisse marcher. Vous pourrez ajouter de la complexité plus tard si vous en avez vraiment besoin. Vous n’en aurez probablement pas besoin.
3. Retour d’information (feedback) — Du code (les tests), de l’équipe (programmation en binôme, revues), de l’utilisateur (livraisons fréquentes). L’obtenir vite.
4. Courage — Dire la vérité sur l’avancement, les estimations et la conception. Jeter le code qui ne marche pas. Refactoriser ce qui vous freine.
5. Respect — Tout le monde dans l’équipe — et désormais, chaque agent dans l’équipe — apporte de la valeur. Traitez-vous en conséquence.

Les pratiques

XP est célèbre pour ses douze pratiques d’origine, organisées en quatre domaines :

Planifier

• Planning Game — L’équipe et le client planifient ensemble : ce qui vient ensuite, dans quel ordre, à quelle taille.
• Petites livraisons — Livrer souvent. À l’échelle de quelques jours, pas de quelques mois. Recueillir du feedback sur du concret.
• User Stories — Les exigences sont des conversations, capturées sous forme de courtes histoires du point de vue de l’utilisateur. « En tant qu’utilisateur, je veux X, pour que Y. »

Concevoir

• Conception simple — La conception la plus simple qui passe les tests et exprime tous les concepts nécessaires. Rien de plus.
• Refactorisation — Améliorer la conception d’un code qui marche déjà. Sans cesse.
• Métaphore du système — Une histoire partagée sur la façon dont le système fonctionne, utilisée pour rendre les décisions de conception cohérentes.

Coder

• Programmation en binôme — Deux développeurs, un seul clavier. L’un pilote, l’autre navigue. On échange souvent.
• Propriété collective du code — Quiconque peut améliorer n’importe quel code. Pas de fiefs.
• Intégration continue — Intégrer et tester le code plusieurs fois par jour. Détecter les régressions immédiatement.
• Conventions de codage — Un style décidé en commun, pour que le code se lise comme s’il avait été écrit par une seule personne.

Tester

• Test-Driven Development (TDD) — Écrire d’abord le test qui échoue, puis le code qui le fait passer.
• Tests d’acceptation — Le client définit, en code ou sous une forme exécutable, ce que « terminé » veut dire pour chaque story.

Pourquoi XP fonctionne

XP est inconfortable. La programmation en binôme vous oblige à penser à voix haute. Le TDD vous oblige à savoir à quoi ressemble le succès avant d’écrire le code. L’intégration continue tue vos branches longue durée préférées. Les petites livraisons vous empêchent de vous cacher derrière une feuille de route à six mois.

Cela fonctionne parce que toutes ces choses raccourcissent les boucles de feedback. Plus vite vous découvrez que vous aviez tort, moins la correction coûte cher. XP, c’est fondamentalement rendre la boucle de feedback aussi serrée que possible.

C’est aussi une affaire de courage et de respect. On ne peut faire du XP que dans une équipe où l’on se fait suffisamment confiance pour se tromper à voix haute.

Le modèle de story discipliné

East Agile Tracker encode une théorie précise de la planification. Considérez cette section comme le manuel d’utilisation expliquant pourquoi le modèle de données est ainsi fait — et comme le guide de terrain de ce qu’il faut faire (et ne pas faire) en pratique.

Pourquoi les quatre types de story comptent

Tout est une story, mais il y en a quatre sortes, et la distinction est tout l’intérêt :

• Les features portent des points et sont la seule chose qui « compte » pour la vélocité. C’est ce qui vous force à découper le travail en valeur observable par l’utilisateur.
• Les bugs ne sont pas pointés (zéro). Les défauts ne rapportent pas de crédit, ce qui rend le coût des reprises visible plutôt que récompensé.
• Les chores ne sont pas pointés non plus — un travail nécessaire sans valeur directe pour l’utilisateur (infra, refactorisations, mise en place). Les garder à zéro incite l’équipe à les regrouper dans des features partout où c’est possible, pour que le cadrage par la valeur reste honnête.
• Les releases sont des marqueurs à zéro point utilisés pour ancrer des jalons et permettre à l’outil de projeter une date.

L’effet comportemental est ce qui compte : quand les bugs et les chores ne marquent pas de points, une équipe pousse naturellement à exprimer le travail sous forme de fonctionnalités orientées utilisateur, et elle devient pleinement consciente du coût des défauts. C’est une discipline de planification encodée dans le modèle de données.

Le backlog unique et ordonné

Trois zones, une règle.

• L’Icebox est le réservoir d’idées non priorisées.
• Le Backlog est une liste strictement ordonnée, à priorité unique — pas d’ex æquo, pas de « P1/P1/P1 ».
• La zone Current contient la ou les itérations actives.

Le product owner est responsable de l’ordre de haut en bas, et l’invariant est que le haut du backlog est toujours le plus important et le mieux spécifié, la clarté décroissant légitimement à mesure que vous descendez. Une story proche du haut avec des critères d’acceptation flous est un bug de planification. L’Icebox a le droit d’être un cimetière ; le Backlog non.

La planification automatique pilotée par la vélocité

C’est la partie que la plupart des équipes réimplémentent mal ailleurs. La planification façon tracker calcule une vélocité moyenne glissante à partir des points récemment acceptés et tire automatiquement autant de points de stories dans l’itération suivante — vous ne vous « engagez » pas manuellement sur un sprint, ce sont les données empiriques qui le font pour vous. Deux conséquences qu’il vaut la peine de préserver :

• Vous estimez uniquement les features, avec des points relatifs (Fibonacci 1/2/3/5/8 ou notre échelle plus resserrée 0/1/2/3), pas des heures. L’estimation est une conversation de dimensionnement, pas une promesse.
• Vous ne trichez pas avec la vélocité. Gonfler les points pour « avoir l’air rapide », ou pointer les chores, casse la projection qui rend tout le système honnête. La vélocité est un instrument de mesure, et on ne trafique pas son propre instrument.

Le bénéfice est que la projection de date de livraison devient un calcul plutôt qu’une négociation, et la conversation avec les parties prenantes passe de « pouvez-vous vous engager sur X pour vendredi » à « à la vélocité actuelle, cette release atterrit autour de la date Y — voici l’arbitrage portée/date ».

Le cycle de vie de la story et la boucle d’acceptation

La machine à états est Start → Finish → Deliver → Accept / Reject. L’état critique est Deliver : un ingénieur marque une story comme livrée, mais elle n’est pas terminée tant que le product owner ne l’a pas explicitement acceptée au regard de ses critères d’acceptation — ou rejetée, ce qui la renvoie en arrière. Cela inscrit une boucle de retour client dans chaque story plutôt que de reporter l’acceptation à une démo de fin de sprint.

Les critères d’acceptation ont leur place sur la story avant qu’elle ne soit démarrée, idéalement sous forme Given/When/Then pour qu’ils se traduisent directement en tests d’acceptation. INVEST est le contrôle de bon sens pour savoir si une story est bien formée :

• Independent (indépendante) — peut être livrée sans les autres stories.
• Negotiable (négociable) — capte l’intention, pas une spec figée.
• Valuable (à valeur) — pour un utilisateur ou une partie prenante.
• Estimable — l’équipe sait la dimensionner.
• Small (petite) — tient confortablement dans une itération.
• Testable — possède des critères d’acceptation qui peuvent être exercés.

Cadence

Les cérémonies de planification sont légères et régulières :

• Une réunion de planification d’itération hebdomadaire pour pointer les nouvelles stories et verrouiller les critères d’acceptation en haut du backlog.
• Une courte mêlée quotidienne centrée sur le flux et les bloqueurs.
• Une rétrospective par itération pour ajuster le processus.

Les itérations durent en général une ou deux semaines — assez courtes pour qu’une mauvaise estimation soit peu coûteuse à découvrir.

Les pratiques d’ingénierie qui font fonctionner la planification

La planification façon tracker est la moitié visible de XP ; elle s’écroule sans la moitié ingénierie.

• Le test d’abord / TDD et une véritable suite de tests d’acceptation sont ce qui donne un sens à « livrée ».
• L’intégration continue et de petites livraisons fréquentes gardent le temps de cycle court, pour que la vélocité soit stable plutôt qu’en dents de scie.
• La programmation en binôme (ou une revue solide) maintient le travail en cours à un faible niveau — finir avant de commencer — ce qui est le plus grand levier sur le temps de cycle.
• Un product owner disponible est ce qui empêche la boucle accept/reject de s’arrêter.

Anti-patterns à surveiller

Les échecs récurrents :

• Traiter le Backlog comme un parking au lieu d’un véritable ordre de priorité.
• Estimer les bugs et les chores pour embellir la vélocité.
• Trimballer d’énormes stories qui ne peuvent pas se terminer dans une itération. Découpez jusqu’à ce que chacune soit livrable indépendamment.
• Laisser les stories s’accumuler dans Delivered parce que personne n’accepte.

Chacun de ces travers reconvertit en douce un système empirique en planification de vœux pieux. Le tracker ne peut pas vous empêcher de les commettre ; il peut seulement les rendre visibles. Regardez votre colonne Delivered à la fin de chaque itération — si elle grossit, c’est votre signal.

XP avec East Agile Tracker

Le tracker est la surface de planification que les équipes XP attendaient depuis l’époque de Pivotal Tracker. Chaque concept se traduit directement :

User Stories → Stories

Les user stories XP sont les stories d’East Agile Tracker. Écrivez-les avec le type Feature. Utilisez la description pour la conversation ; utilisez les commentaires pour les échanges qui suivent. Les critères d’acceptation ont leur place dans la description.

Planning Game → Le tableau

Le Planning Game en XP, c’est une conversation entre métier et équipe sur la priorité et la taille. Dans East Agile Tracker :

1. La personne produit écrit les stories dans le Backlog et les ordonne par priorité.
2. L’équipe estime les features en points (échelle Fibonacci ou East Agile).
3. Le système planifie automatiquement les itérations à partir de la vélocité.
4. L’équipe démarre les stories en haut de la colonne Current.

C’est tout. Le « jeu » se joue dans la conversation ; le tracker se contente de tenir le score.

Petites livraisons → Releases (le type de story)

XP dit de livrer souvent. Release est l’un des quatre types de stories d’East Agile Tracker. Créez une release pour chaque jalon d’expédition ; glissez-la dans l’itération où elle est livrée. Les releases sautent Started/Finished/Delivered et passent directement à Accepted au moment de la livraison.

Intégration continue → Machine à états des stories

La machine à états n’est pas l’IC à proprement parler — c’est l’affaire de votre système de build — mais le chemin Finished → Delivered → Accepted reflète la boucle d’acceptation client que XP décrit. Terminer le travail, le livrer au client, l’accepter une fois confirmé.

Vélocité → « Le temps qu’il faisait hier »

XP appelle cela yesterday’s weather : ce que vous avez fait à l’itération précédente est la meilleure prédiction de ce que vous ferez à la prochaine. East Agile Tracker calcule la vélocité automatiquement — moyenne des itérations récentes, stratégie configurable — et l’utilise pour planifier la capacité de l’itération suivante.

Tests d’acceptation → Relectures

Les relectures de stories dans le tracker correspondent à l’acceptation. Assignez un relecteur (le client, le product owner, ou même un agent qui en joue le rôle). Il ou elle approuve ou rejette. Un rejet renvoie la story à Started.

Programmation en binôme → Copropriété

Les équipes XP travaillent en binôme sur le code. Dans le tracker, cela se traduit par plusieurs propriétaires sur une story. Assignez les deux membres du binôme à la story ; les deux noms apparaissent sur la carte.

XP avec les agents — la nouvelle pratique

XP a été formulé avant que les agents IA puissent contribuer de manière significative au logiciel. Nous pensons que c’est la mise à jour la plus importante apportée à XP depuis vingt-cinq ans.

Dans notre pratique — et c’est pour cela que le tracker est conçu — un agent est un membre d’équipe XP nommé. Il a son propre rôle, son propre partenaire de binôme (humain ou agent), et sa propre piste d’audit. Il peut faire tout ce qu’un membre humain peut faire dans la surface de planification : estimer, posséder des stories, commenter, faire transitionner, accepter des relectures.

Les valeurs XP tiennent toujours. Communication : les agents communiquent en lisant le flux d’événements et en postant des commentaires. Simplicité : les agents sont contraints aux rôles que vous leur accordez. Feedback : chaque action d’agent figure dans le journal d’audit, immédiatement relisable. Courage : être honnête sur ce que les agents ont réussi et sur ce qu’ils ont raté. Respect : les coéquipiers-agents apportent de la valeur — reconnaissez-le.

Nous ne mettons pas les agents dans le tracker pour qu’ils codent. Nous offrons la surface de planification aux humains et aux agents qui travaillent ensemble. Vous apportez l’agent de codage — Claude Code, Codex, le vôtre — et vous le connectez au tracker via l’API. L’agent prend des stories, fait le travail, commente, fait transitionner. Vous relisez la trace et acceptez.

C’est cela, la planification agile inclusive. C’est XP, avec l’équipe qu’il a réellement.

Pour aller plus loin

• Extreme Programming Explained — Le livre fondateur de Kent Beck, 1999.
• Le Manifeste Agile — Là où la famille a commencé.
• Développement agile — Le tableau d’ensemble.
• Mode d’emploi — Guide pratique du tracker.
• Guide de l’API — Brancher votre agent de codage.