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 :

1. Écrire un test qui échoue (Red)
2. Écrire le code minimal pour passer le test (Green)
3. 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é) :

1. Passe tous les tests
2. Révèle l'intention
3. Pas de duplication
4. 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)

XP recommande d'adopter toutes les pratiques ensemble. En retirer une affaiblit l'ensemble du système.

• Kent Beck - "Extreme Programming Explained: Embrace Change" (1999, 2nd edition 2004)
• extremeprogramming.org - Site de référence un peu pourri