Les 12 pratiques de l'Extreme Programming

Ces pratiques visent à obtenir un retour d'information très rapidement (de quelques secondes à quelques jours) plutôt que d'attendre des semaines ou des mois.

Deux développeurs travaillent ensemble sur le même ordinateur. L'un écrit le code (le “driver”), l'autre observe et réfléchit à la stratégie (le “navigator”). Les rôles s'échangent régulièrement.

Bénéfices :

Meilleure qualité du code
Partage des connaissances
Réduction des erreurs

Le Pair Programming contribue aussi fortement à la compréhension partagée du système.

Processus de planification collaboratif entre l'équipe technique et le client. Se divise en deux parties :

Release Planning : planification à long terme
Iteration Planning : planification détaillée pour l'itération en cours

Principes :

Le client définit les priorités
Les développeurs estiment la complexité
Décisions basées sur la valeur métier

Les tests unitaires sont écrits avant le code de production.

Cycle TDD :

Écrire un test qui échoue (Red)
Écrire le code minimal pour passer le test (Green)
Améliorer le code (Refactor)

Un représentant du client est présent à temps plein avec l'équipe de développement.

Rôle du client :

Répondre aux questions immédiatement
Écrire les user stories
Définir les tests d'acceptation
Prioriser les fonctionnalités

Le code est intégré et testé plusieurs fois par jour dans le dépôt principal.

Règles :

Intégrer au minimum une fois par jour
Tous les tests doivent passer à 100%
Si les tests échouent, corriger immédiatement

Amélioration continue de la structure du code sans modifier son comportement.

Objectifs :

Éliminer la duplication
Améliorer la lisibilité
Simplifier la conception
Faciliter les évolutions futures

Principe : Le refactoring est une activité continue, pas une phase distincte.

Livrer fréquemment des versions fonctionnelles du logiciel en production.

Avantages :

Feedback rapide du client
Réduction des risques
Valeur délivrée rapidement
Apprentissage continu

Fréquence typique : De quelques semaines à quelques mois maximum

Le code doit être aussi simple que possible, tout en remplissant les besoins actuels.

Critères d'une conception simple (par ordre de priorité) :

Passe tous les tests
Révèle l'intention
Pas de duplication
Minimum d'éléments (classes, méthodes, etc.)

Ne pas anticiper les besoins futurs (YAGNI - You Aren't Gonna Need It)

Une histoire simple et partagée qui décrit comment fonctionne le système.

Objectif :

Vocabulaire commun entre tous les acteurs
Guide pour l'architecture
Facilite la communication

Exemple : “Le système fonctionne comme une chaîne de montage” ou “C'est comme un bureau de poste”

Tout le monde est responsable de tout le code. N'importe quel développeur peut modifier n'importe quelle partie du système.

Conditions nécessaires :

Standards de codage respectés
Tests unitaires exhaustifs
Intégration continue

Bénéfices :

Pas de goulot d'étranglement
Meilleure connaissance du système
Flexibilité des affectations

L'équipe suit des conventions de codage communes et cohérentes.

Éléments couverts :

Formatage du code
Conventions de nommage
Structures de fichiers
Commentaires

Objectif : Le code doit sembler écrit par une seule personne.

L'équipe travaille à un rythme qui peut être maintenu indéfiniment, typiquement 40 heures par semaine.

Règle : Pas plus d'une semaine d'heures supplémentaires consécutive.

Raisons :

La fatigue génère des erreurs
La créativité diminue
Le turnover augmente
La productivité à long terme baisse

Cette pratique était initialement appelée “40-hour week” mais a été renommée pour être plus universelle.

Les pratiques XP se soutiennent mutuellement :

TDD rend possible la propriété collective (confiance dans le code)
Programmation en binôme facilite le refactoring (deux cerveaux pour améliorer)
Intégration continue s'appuie sur les tests (validation automatique)
Client sur site nourrit le jeu de planification (feedback immédiat)
Rythme soutenable améliore la conception simple (esprit clair)