Conclusion

Nous mettons en œuvre ces pratiques XP depuis sept ans, principalement dans les domaines des télécoms et de la finance. Notre principale expérience a porté sur un projet télécom impliquant jusqu'à 25 développeurs, sur 4 ans - pour un total d'environ 1000 hommes-mois de développement. Les résultats de ce projet ont largement dépassé les objectifs initiaux :

• Nous avons tenu les délais.
• Le produit était apprécié de ses utilisateurs, et qualifié de "best in class" par certains clients.
• Le niveau de qualité du produit était reconnu comme très bon par l'ensemble de l'organisation, notamment grâce à la mise en place d'environ 20.000 tests automatiques. Lors de la dernière version du produit, nous avons mesuré que l'équipe "framework" de ce projet (8 personnes) était parvenu à un stade où chaque développeur introduisait moins d'un défaut par mois dans le logiciel - et quasiment tous ces défauts étaient interceptés par l'équipe de validation.
• Notre activité d'amélioration permanente de la conception nous a permis de positionner une partie de l'outil en tant que framework utilisé par d'autres équipes de la société.

Bien entendu, tout n'est pas complètement rose. Nous avons pu mettre en oeuvre l'ensemble des pratiques « internes » d'XP, celles qui concernent le travail de l'équipe, mais nous avons rencontré des difficultés pour progresser sur les parties liées au rôle du client et du testeur – et pour cause, ces rôles étaient pris en charge par d'autres équipes, ce qui a exigé de notre part un effort d'évangélisation de longue haleine.

Nous avons pu également noter la grande sensibilité de la méthode à l'entente des membres de l'équipe. Cela impose des contraintes sur le recrutement, et cela peut également nécessiter des remaniements de l'équipe en cas de dysfonctionnement.

D'une manière générale, nous avons constaté que la mise en œuvre d'XP apportait des résultats indéniables, mais au prix d'efforts eux aussi indéniables lors de la phase de transition. Une fois la transition effectuée, cependant, XP se présente comme un processus simple et naturel, qui offre une productivité très nettement accrue par rapport à ce que nous avions connu jusque là.

Cette difficulté de transition explique certainement pourquoi XP reste encore confidentiel en France. Nous avons eu ainsi des retours d'équipes ayant essayé « XP mais sans les tests unitaires », ou encore « XP mais sans le travail en binômes », avant de revenir à leur mode de fonctionnement initial quelques semaines plus tard.

Il faudra donc une impulsion particulière pour que XP se développe davantage dans notre pays. Nous pensons que cette impulsion viendra de deux directions complémentaires : d'abord des developpeurs eux-mêmes, qui auront compris en quoi XP constitue une façon plus naturelle et plus efficace de travailler, et ensuite des maîtrises d'oeuvre, maîtrises d'ouvrage et sociétés de service « visionnaires » qui auront réalisé que ce processus représente aujourd'hui un réel avantage compétitif dans un monde où l'adaptation au changement est un facteur primordial de succès.