Quand XP rencontre des difficultés

De nombreux projets logiciels ont des contrats qui fixent la portée, la date et le prix. L'approche itérative d'XP entre en conflit avec cela.

La position XP : Vous ne pouvez pas fixer les trois (portée, date, ressources). Quelque chose doit être flexible. XP préfère une portée flexible avec une qualité fixe.

La réalité contractuelle : Les clients veulent savoir exactement ce qu'ils obtiendront, quand et pour combien. Les contrats traditionnels promettent cela.

Tensions :

• XP dit « nous découvrirons la meilleure solution ensemble ». Les contrats disent « construisez exactement ceci ».
• XP dit « le changement est bienvenu ». Les contrats disent « les changements coûtent plus cher ».
• XP dit « livrez tôt et itérez ». Les contrats disent « livrez tout à la fin ».

Options :

• Négocier de meilleurs contrats : Temps et matériaux, basés sur les résultats, ou accords à portée flexible
• Utiliser XP en interne : Même avec un contrat fixe, les pratiques internes peuvent être XP
• Gérer les attentes : Communiquer que la livraison anticipée d'une portée partielle est possible

XP dans des environnements contractuels n'est pas impossible, mais cela nécessite l'éducation du client et la négociation du contrat.

XP a été conçu pour des équipes colocalisées. Cela peut fonctionner à distance, mais seulement avec de bons outils et une bonne culture de communication.

Défis :

• La programmation en binôme est plus difficile (latence, fuseaux horaires)
• La disponibilité du client est plus difficile (pas de possibilité d'aller demander)
• La propriété collective est plus difficile (moins de diffusion organique des connaissances)
• La confiance est plus difficile (moins de temps en face à face, moins de rapport)

Si votre équipe distribuée a :

• Une culture fortement asynchrone (des jours entre les réponses)
• Des écarts de fuseaux horaires qui empêchent le chevauchement
• Une réticence à utiliser la vidéo ou la communication synchrone
• Aucune confiance établie entre les membres de l'équipe

...les pratiques XP auront du mal.

Pour que cela fonctionne, il faut :

• Des heures de travail qui se chevauchent (au moins quelques heures par jour)
• De solides normes de communication écrite
• Une construction délibérée de relations
• Des outils qui permettent la collaboration en temps réel

Certaines équipes distribuées font très bien XP. D'autres ne peuvent pas le faire fonctionner. La différence est généralement la culture de communication, pas la géographie.

Les industries comme la santé, la finance et l'aviation ont des exigences réglementaires qui peuvent entrer en conflit avec les pratiques XP.

Tensions :

• Déploiement continu vs comités de contrôle des changements
• Propriété collective vs exigences d'approbation individuelle
• Documentation simple vs preuves de conformité
• Refactorisation vs exigences de revalidation

Cependant : XP n'est pas impossible dans les environnements réglementés. De nombreuses équipes réglementées utilisent XP avec succès.

Adaptations :

• Les tests deviennent des preuves de conformité (chaque comportement est validé)
• Le contrôle des changements s'applique aux versions, pas aux commits
• La documentation est automatisée à partir du code et des tests
• Validation basée sur les risques (tout le code ne nécessite pas la même rigueur)

L'idée clé : Les pratiques de qualité d'XP dépassent souvent les minimums réglementaires. Des tests complets, la révision de code (binôme) et la traçabilité sont des choses que les régulateurs veulent.

Ce à quoi XP résiste, c'est le gaspillage : documentation pour elle-même, longs cycles d'approbation, cérémonie qui n'améliore pas la qualité.

Les pratiques d'ingénierie d'XP ne sont pas négociables. Si l'équipe refuse de les adopter, XP ne fonctionne pas.

Résistance courante :

• « Le TDD est trop lent » (idée fausse sur la productivité)
• « Nous n'avons pas le temps de travailler en binôme » (fausse économie)
• « La refactorisation est du perfectionnisme » (confusion sur la maintenance)
• « L'IC est une surcharge » (incapacité à voir la valeur)

Si la résistance vient des développeurs :

• Cela peut être un manque d'expérience (ils ne savent pas comment)
• Cela peut être un traumatisme passé (mauvaise mise en œuvre qu'ils ont vue)
• Cela peut être une menace identitaire (défis à leur expertise)
• Commencez petit, démontrez la valeur, développez les compétences progressivement

Si la résistance vient de la direction :

• « Le binôme signifie la moitié de la productivité » (éduquer sur les avantages de qualité)
• « Le TDD est du temps perdu » (montrer la réduction des bogues, le débogage plus rapide)
• « Nous ne pouvons pas nous permettre l'investissement » (montrer les économies à long terme)

XP nécessite l'adhésion. Vous pouvez introduire les pratiques progressivement, mais si l'équipe ou l'organisation refuse de s'engager dans l'excellence technique, XP ne prendra pas racine.

Certains domaines rendent le TDD beaucoup plus difficile :

Applications à forte composante UI : Tester l'apparence visuelle et l'interaction peut être délicat. (Bien que les outils modernes comme React Testing Library aient amélioré cela.)

Modèles d'apprentissage automatique : Tester des résultats probabilistes ne correspond pas au modèle assert-equals.

Systèmes dépendants du matériel : Le comportement des dispositifs physiques est difficile à simuler.

Systèmes hautement concurrents : Le comportement dépendant du timing est difficile à tester de manière déterministe.

Pour ces domaines :

• Le TDD peut s'appliquer à des parties du système (logique métier) mais pas à d'autres (UI, entraînement ML)
• Différentes stratégies de test peuvent être nécessaires (tests basés sur les propriétés, régression visuelle, simulation matérielle)
• Le principe (rétroaction rapide sur l'exactitude) demeure même si la pratique s'adapte

N'utilisez pas cela comme excuse pour sauter complètement les tests. Chaque système a des parties testables. Poussez le TDD aussi loin qu'il peut aller ; adaptez-vous là où vous le devez.