Les pratiques XP : un aperçu

XP n'est pas un menu où vous choisissez vos favoris. Les pratiques sont conçues pour se renforcer mutuellement. Retirez-en une, et les autres deviennent plus difficiles ou moins efficaces.

Par exemple :

• Le remaniement est sûr parce que vous avez des tests complets
• La conception simple est possible parce que vous pouvez remanier lorsque les exigences changent
• La propriété collective fonctionne parce que vous avez des normes de codage
• L'intégration continue est réalisable parce que vous avez de petites versions et des tests

Cette nature imbriquée explique pourquoi « faire du TDD mais pas de remaniement » ou « programmer en binôme sans tests » échoue souvent. Vous retirez un mur porteur.

Cela dit, il faut bien commencer quelque part. Nous discuterons de l'adoption progressive dans le module 5.

Ce sont les pratiques de base que la plupart des équipes XP adoptent :

Pratiques de planification :

• Récits utilisateur : les exigences comme points de départ de conversation
• Jeu de planification : l'entreprise choisit quoi, les développeurs choisissent comment
• Petites versions : livrer de la valeur fréquemment
• Planification d'itération : décomposer les récits en tâches pour chaque itération

Pratiques de développement :

• Développement piloté par les tests (TDD) : écrire le test en premier
• Programmation en binôme : deux développeurs, un clavier
• Remaniement : améliorer le code sans changer le comportement
• Conception simple : la chose la plus simple qui fonctionne
• Intégration continue : intégrer et tester plusieurs fois par jour

Pratiques d'équipe :

• Équipe complète : tous ceux nécessaires pour livrer, dans une même pièce
• Propriété collective du code : n'importe qui peut modifier n'importe quel code
• Normes de codage : conventions de code convenues
• Rythme soutenable : pas d'heures supplémentaires en règle générale

Nous couvrirons chacune de ces pratiques en profondeur dans les modules suivants.

Ces pratiques sont puissantes mais nécessitent plus de maturité ou des conditions spécifiques :

• Implication réelle du client : le client réel, pas seulement un représentant
• Analyse des causes profondes : corriger le système, pas seulement le symptôme
• Code partagé : tout le code est visible par tous les développeurs
• Code et tests : le code et les tests sont les seuls artefacts permanents
• Base de code unique : une branche, pas plusieurs
• Déploiement quotidien : déployer en production chaque jour
• Contrat à portée négociée : des contrats qui embrassent le changement
• Paiement à l'utilisation : rétroaction directe des vrais clients

Ce ne sont pas des « XP avancés ». Ce sont des pratiques qui fonctionnent bien dans le bon contexte mais qui pourraient être inappropriées ou impossibles dans d'autres.

Une façon de comprendre les pratiques XP est à travers leurs boucles de rétroaction :

Secondes : tests unitaires Minutes : programmation en binôme Heures : intégration continue Jour : mêlée quotidienne Semaine : planification d'itération, démo client Mois/trimestre : version, rétro

À chaque échelle, XP crée des opportunités d'apprendre et d'ajuster. C'est intentionnel. Plus vous apprenez vite, plus vous pouvez corriger le cap rapidement.

Si vous n'obtenez pas de rétroaction à chacune de ces échelles, quelque chose manque.

Cela peut sembler accablant. N'essayez pas d'adopter tout en même temps.

La plupart des équipes commencent par :

1. TDD ou au moins écrire des tests
2. Intégration continue
3. Itérations (ou sprints si vous utilisez Scrum)
4. Rétros

Celles-ci forment la fondation. Une fois qu'elles fonctionnent, ajoutez :

• Programmation en binôme (commencez avec seulement les problèmes difficiles)
• Remaniement (commencez avec le code le plus désordonné)
• Petites versions (commencez par livrer plus fréquemment)

Nous couvrirons les stratégies d'adoption dans le module 5. Pour l'instant, comprenez simplement le paysage.