Adopter XP de manière progressive

N'essayez pas de tout adopter en même temps. Choisissez une pratique, maîtrisez-la bien, puis ajoutez-en une autre.

Pourquoi l'adoption progressive fonctionne :

• Moins accablant pour l'équipe
• Permet l'apprentissage et l'ajustement
• Démontre la valeur avant de demander plus de changements
• Développe les compétences progressivement
• Réduit la résistance

Le point de départ typique : le développement piloté par les tests (TDD).

Le TDD est souvent choisi en premier parce que :

• C'est la fondation pour un remaniement sécuritaire
• Il démontre rapidement sa valeur (moins de bogues)
• C'est une compétence que les individus peuvent pratiquer
• Il ne nécessite pas de changement organisationnel

Autres bons points de départ :

• L'intégration continue (si les tests existent déjà)
• La programmation en binôme (si la collaboration est le problème)
• Les petites versions (si la livraison est le problème)

Commencez là où se trouve la douleur. Si les bogues vous tuent, commencez par le TDD. Si les connaissances sont cloisonnées, commencez par le binômage. Si les versions sont effrayantes, commencez par l'IC.

Les pratiques XP se renforcent mutuellement. Après en avoir adopté une, ajoutez les pratiques qui la soutiennent.

Si vous avez commencé par le TDD :

• Ajoutez le remaniement (les tests permettent un remaniement sécuritaire)
• Ajoutez l'IC (exécutez les tests à chaque commit)
• Ajoutez la conception simple (le TDD favorise la simplicité)

Si vous avez commencé par la programmation en binôme :

• Ajoutez la propriété collective (le binômage diffuse les connaissances)
• Ajoutez les normes de codage (cohérence entre les binômes)
• Ajoutez le TDD (les binômes peuvent faire rouge-vert-remaniement ensemble)

Si vous avez commencé par l'IC :

• Ajoutez le TDD (de meilleurs tests = IC plus utile)
• Ajoutez les petites versions (si vous pouvez intégrer, vous pouvez livrer)
• Ajoutez le remaniement (l'IC détecte si le remaniement brise quelque chose)

Chaque pratique facilite la suivante. Cette nature imbriquée explique pourquoi XP fonctionne comme un tout.

Une séquence d'adoption courante :

Niveau 1 : Fondation

• Tests automatisés (une certaine couverture)
• Contrôle de version (tout le monde l'utilise)
• Intégration continue (compilation à chaque commit)

Niveau 2 : Qualité

• TDD (tests avant le code)
• Remaniement (amélioration continue)
• Conception simple (YAGNI, quatre règles)

Niveau 3 : Collaboration

• Programmation en binôme (au moins sur le travail complexe)
• Propriété collective (pas de silos de code)
• Normes de codage (cohérence)

Niveau 4 : Flux

• Petites versions (hebdomadaires ou plus souvent)
• Implication du client (disponible, engagé)
• Rythme soutenable (protégé)

Niveau 5 : Optimisation

• Déploiement continu
• Programmation en groupe (pour les problèmes complexes)
• Équipes interfonctionnelles

Toutes les équipes n'atteignent pas tous les niveaux. Arrêtez-vous lorsque vous avez résolu vos problèmes. Mais ne vous arrêtez pas trop tôt — les niveaux se construisent les uns sur les autres.

L'adoption de XP nécessite souvent de convaincre les autres — gestionnaires, coéquipiers, clients.

Pour les gestionnaires :

• Présentez-le comme un investissement en qualité et prévisibilité
• Montrez les données d'autres équipes (moins de bogues, livraison plus rapide)
• Commencez petit pour démontrer la valeur avant d'en demander plus
• Abordez explicitement l'objection « deux personnes sur un ordinateur »

Pour les développeurs :

• Partagez les avantages du développement des compétences
• Travaillez en binôme avec eux pour démontrer (n'expliquez pas seulement)
• Reconnaissez la courbe d'apprentissage
• Commencez avec ceux qui sont curieux

Pour les clients :

• Mettez l'accent sur la réactivité et la qualité
• Montrez des logiciels fonctionnels tôt et souvent
• Expliquez le jeu de planification comme leur donnant le contrôle

Ce qui fonctionne :

• Montrer, pas dire
• Petites expériences avec des résultats mesurables
• Aborder les peurs directement
• Construire une coalition de partisans

Ce qui ne fonctionne pas :

• Mandats sans explication
• Tout changer en même temps
• Ignorer la résistance
• S'attendre à des résultats instantanés

Suivez si XP fonctionne :

Métriques de qualité :

• Nombre de bogues (devrait diminuer)
• Incidents en production (devraient diminuer)
• Temps pour corriger les bogues (devrait diminuer)
• Couverture des tests (devrait augmenter)

Métriques de livraison :

• Délai de livraison (devrait diminuer)
• Fréquence des versions (devrait augmenter)
• Temps de cycle (devrait diminuer)
• Prévisibilité (devrait augmenter)

Métriques de santé d'équipe :

• Heures supplémentaires (devraient diminuer)
• Roulement de l'équipe (devrait diminuer)
• Satisfaction des développeurs (devrait augmenter)

Ne mesurez pas :

• Lignes de code (incite au gonflement)
• Vélocité comme productivité (se fait manipuler)
• Métriques individuelles (nuit au travail d'équipe)

Utilisez les métriques pour apprendre, pas pour juger. Si une métrique ne s'améliore pas, demandez pourquoi — ne punissez pas l'équipe.

La mesure ultime : Livrez-vous des logiciels de valeur de manière durable? Si oui, XP fonctionne. Si non, quelque chose nécessite un ajustement.