Quand XP convient

XP a été conçu pour les projets où les exigences changent fréquemment. Si vous ne savez pas exactement quoi construire, XP vous aide à le découvrir.

Signes d'incertitude élevée :

• Les clients ne peuvent pas articuler leurs besoins avec précision
• Le marché évolue
• Vous construisez quelque chose de nouveau, pas une réplication de quelque chose de connu
• Les retours des utilisateurs changent régulièrement les priorités
• Les concurrents innovent, vous forçant à vous adapter

Dans ces environnements, les approches traditionnelles échouent. La conception détaillée en amont devient obsolète avant l'implémentation. Les grandes versions ratent la cible parce que les exigences ont changé.

XP embrasse le changement. Les petites versions obtiennent des retours rapidement. La conception simple évite le surinvestissement. Le jeu de planification s'ajuste continuellement. L'incertitude n'est pas un problème — elle est attendue.

Si vos exigences sont vraiment stables et bien comprises, XP fonctionne toujours, mais la proposition de valeur est différente. Vous gagnez en qualité et en santé d'équipe, mais les avantages d'adaptabilité sont moins prononcés.

XP brille lorsque le code vivra pendant des années. L'investissement dans les pratiques techniques porte ses fruits au fil du temps.

Pourquoi les systèmes à longue durée de vie bénéficient de XP :

• Tests : Détectent les régressions à mesure que le système évolue
• Refactorisation : Maintient la conception propre à mesure que les exigences changent
• Propriété collective : Diffuse les connaissances à mesure que les membres de l'équipe vont et viennent
• Conception simple : Évite l'accumulation de complexité
• CI : Maintient la discipline d'intégration à mesure que l'équipe grandit

Si vous construisez un prototype qui sera jeté, l'investissement de XP dans la qualité peut ne pas être rentable. Mais la plupart des « prototypes » deviennent des systèmes de production. La plupart du code « temporaire » vit pendant des années.

Le pari : Supposez que votre code vivra plus longtemps que vous ne le pensez. Investissez dans la qualité dès le départ. Si vous avez tort, vous avez perdu un peu de temps. Si vous avez raison (et c'est généralement le cas), vous avez économisé des années de souffrance.

XP nécessite une collaboration étroite. La programmation en binôme, les jeux de planification et la propriété collective ne fonctionnent que lorsque les gens travaillent bien ensemble.

Signes que votre équipe est prête :

• Les gens communiquent ouvertement, y compris sur les problèmes
• Il y a de la confiance entre les membres de l'équipe
• Les gens s'entraident sans qu'on le leur demande
• Les désaccords sont résolus de manière constructive
• L'équipe a une sécurité psychologique

Si votre équipe manque de ces qualités, les pratiques XP sembleront forcées et maladroites. Vous devrez peut-être construire la santé de l'équipe avant d'adopter XP — ou utiliser les pratiques XP pour construire progressivement la santé de l'équipe.

XP peut améliorer la collaboration, mais elle ne peut pas la forcer. Une équipe de personnes qui ne veulent pas partager le code n'embrassera pas soudainement la propriété collective. Une équipe qui a peur d'admettre ses erreurs ne bénéficiera pas de la transparence.

La culture doit soutenir les pratiques — ou au moins être prête à changer.

XP nécessite un client disponible — quelqu'un qui peut répondre aux questions, prendre des décisions de priorité et fournir des retours.

Sans disponibilité du client :

• Les développeurs devinent les exigences (souvent à tort)
• Les priorités ne sont pas claires (tout semble important)
• Les retours arrivent trop tard (les fonctionnalités sont mal construites)
• Le jeu de planification ne peut pas fonctionner

La disponibilité du client signifie :

• Réponses aux questions en heures, pas en jours
• Décisions de priorité prises quand demandées
• Retours réguliers sur le travail livré
• Engagement dans le processus de planification

Si vos clients ne sont pas disponibles, XP devient difficile. Vous pouvez utiliser un propriétaire de produit comme intermédiaire, mais quelqu'un doit jouer efficacement le rôle de client.

Le dysfonctionnement organisationnel empêche souvent la disponibilité du client. Le client est trop occupé, trop politique ou trop distant. Ce sont des problèmes organisationnels à résoudre, pas des problèmes XP.

Certaines pratiques XP supposent des contextes modernes de développement logiciel. Elles peuvent nécessiter une adaptation dans d'autres environnements.

TDD suppose :

• Vous pouvez écrire des tests automatisés (tous les environnements ne le supportent pas facilement)
• Les tests s'exécutent rapidement (les tests lents rendent TDD pénible)
• La culture de test existe (l'équipe croit aux tests)

CI suppose :

• Le code peut être intégré fréquemment
• La construction et les tests peuvent être automatisés
• Le développement basé sur le tronc est faisable

La programmation en binôme suppose :

• Le travail se fait sur un ordinateur
• Deux personnes peuvent voir le même écran
• Le travail bénéficie d'une collaboration en temps réel

Dans la plupart des développements logiciels, ces hypothèses sont valables. Mais les systèmes embarqués, le code dépendant du matériel ou les environnements hautement réglementés peuvent nécessiter une adaptation des pratiques.

Les principes restent. Les pratiques spécifiques peuvent changer.