Leçon 7 : Programmation extrême (XP) et Développement piloté par les tests (TDD)

La Programmation extrême (XP – eXtreme Programming) est l'une des méthodes agiles les plus connues et les plus complètes, créée par Kent Beck en 1996 — avant même que le terme « Agile » ne soit inventé. Dans cette leçon, on découvre les quatre valeurs de base de XP (simplicité, communication, feedba

En bref : XP dit « prends les bonnes choses qu'on fait déjà et amplifie-les » — communication, simplicité, feedback et courage. Et TDD dit : on écrit d'abord un test qui échoue, puis on écrit juste assez de code pour qu'il passe — et ensuite on s'arrête.

Programmation extrême (XP): Méthode de développement agile créée par Kent Beck en 1996, parmi les plus complètes et les plus connues ; fondée sur quatre valeurs (simplicité, communication, feedback, courage) et 12 pratiques d'ingénierie, selon l'idée « prends ce qui marche et amplifie-le ».
Développement piloté par les tests (TDD): Méthode où l'on écrit d'abord un test unitaire qui doit s'exécuter et échouer, puis on écrit du code jusqu'à ce que le test passe, et on s'arrête dès qu'il passe — sans ajouter de fonctionnalité ; aucun test qui réussissait auparavant ne doit échouer.
Jeu de planification (Planning Game): Pratique de planification en XP qui sépare les décisions d'affaires des décisions de développement : le métier présente et priorise les User Stories, les développeurs estiment l'effort, et les itérations sont courtes (1 à 2 semaines) et ne dépassent jamais le temps alloué.
User Story: Description courte sur une carte (nom + description) d'une fonctionnalité qui apporte de la valeur au client, écrite par le client et estimée par les développeurs ; remplace les gros documents d'exigences, avec un objectif similaire à celui d'un Use Case.
Programmation en binôme (Pair Programming): Tout le code est écrit en binôme à un seul poste : l'un écrit, l'autre réfléchit à si ça va marcher, à de meilleures façons de faire et à des scénarios de test ; ils échangent les rôles environ toutes les deux heures, et les binômes tournent — cela soutient la propriété collective du code et une revue informelle.
Restructuration (Refactoring): Amélioration de la structure du code existant sans changer son comportement, afin de garder une conception simple ; une activité continue et non ponctuelle, où les tests garantissent que le comportement n'a pas été cassé.
Intégration continue (CI): Construction et test de tout le système plusieurs fois par jour (intégration au moins une fois par jour), avec des tests automatisés ; les tests unitaires doivent réussir à 100 % avant et après l'intégration.
Rythme durable (Sustainable Pace, semaine de 40 heures): « Programmer est un marathon, pas un sprint » : l'équipe travaille jusqu'à 40 heures par semaine ; les gens fatigués ne sont pas productifs ; en cas de crise, une semaine d'heures supplémentaires est tolérée, mais des semaines consécutives sont le signe que quelque chose ne va pas.