Trois questions sur XP

Goldratt nous invite à poser trois questions face à une technologie :

Quelle est sa force, qu'apporte-t-elle de nouveau ?
Pour une entreprise qui souhaite la mettre en place, quelle limitation de ses performances permet-elle de diminuer ?
Quelles sont les règles, tacites ou explicites, qui permettent à cette entreprise de vivre avec cette limitation ?

Je choisis comme sujet une méthode de développement agile, disons XP.

1) Quelle est sa force, qu'apporte-t'elle de nouveau ?

Elle maximise l'usage des boucles de feedback dans le processus de création de logiciel, en offrant la possibilité de livrer régulièrement et sans régression un système correspondant aux besoins actuels, et dont la connaissance est partagée par toute l'équipe.

2) Pour une entreprise qui souhaite la mettre en place, quelle limitation de ses performances permet-elle de diminuer ?

Elle diminue le niveau d'entropie d'une équipe appliquée à résoudre un problème complexe.

Cette entropie se manifeste sous trois aspects :

2.1) Perte d'information et/ou bruit : Dans son travail de résolution du problème, l'équipe oublie ou néglige des informations vitales concernant le problème, se désaligne (visions divergentes du problème) et perd en cohérence. Exemple: "Ce n'est pas un bug ! C'est une demande d'évolution par rapport à la spécification".

2.2) Ralentissement : Lorsque les données du problème changent, le temps de réadaptation de l'équipe (et de son produit) devient un facteur limitant particulièrement pénalisant. Exemple : "Ils ont d'abord dit que ce serait une application, maintenant ils veulent du web service. Il nous faudrait 6 mois. Ca va pas le faire."

2.3) Cristallisation : L'entropie se matérialise dans les artefacts du projet sous forme de "dette technique" : code sans tests, redondant, illisible, technologie inadaptée ou obsolète, design trop complexe, etc. L'incapacité de l'équipe à résorber cette dette technique ralentit le processus de résolution du problème, parfois jusqu'à l'arrêt complet. Exemple : "Il n'y a plus personne ici qui comprend ce que fait ce code."

3) Quelles sont les règles, tacites ou explicites, qui permettent à cette entreprise de vivre avec cette limitation ?

Ce sont habituellement des règles qui visent à diminuer l'entropie du système en le contraignant de manière à conserver ou rétablir l'information, quitte à le ralentir et à le refroidir encore plus. Voici les règles le plus souvent constatées dans mon expérience :

3.1) Fixer à l'avance et contractualiser le périmètre fonctionnel, l'effort à engager ainsi que les délais et tenter de se tenir à ces décisions coûte que coûte. Exemple : "Toute demande d'évolution émise après la validation du document de Spécifications Fonctionnelles Détaillées fera l'objet d'un avenant; sa mise en oeuvre devra faire l'objet d'une nouvelle estimation après réception du Système Principal ".

3.2) Produire une documentation exhaustive pour chaque artefact afin de limiter les pertes d'informations ou de tracer les décisions. Exemple : "La conception détaillée devra être entièrement documentée au format UML (diagramme de classe et de séquence) afin de faciliter la prise de connaissance du projet par l'équipe de maintenance."

3.3) Capturer le processus de décision du groupe dans une structure hiérarchique visant à limiter les risques d'erreurs. Exemple : "Le projet est en retard. A partir de maintenant, je serai présent au comité de suivi hebdo, et je veux un rapport de statut par jour. Je souhaite également que tous les congés fassent l'objet d'une demande écrite avec copie DUPANLON et ROBERT."

3.4) Spécialiser les tâches afin de faire reposer l'intégrité du produit sur l'intégrité de quelques individus plutôt que de l'équipe. Exemple : "On a Bert comme DBA à l'intégration, et en plus il s'entend assez bien avec Gus (qui est un crack du java) alors je pense qu'on ne devrait pas avoir trop de problèmes de modèles. C'est l'essentiel, le modèle !"

Conclusion

Que peut on tirer de ces réponses quand à l'adoption d'une méthode comme XP dans l'entreprise ? Personnellement, elles m'ont permis de mieux comprendre pourquoi la mise en place d'XP dans un contexte où ces règles existantes sont maintenues se traduit par un abandon de la méthode, jugée non rentable.

La conclusion que je tire de cette compréhension est que pour réussir avec XP, une entreprise doit non seulement identifier et expliciter les limitations qu'elle rencontre sur ses projets, mais également les règles qu'elle a mis en place au cours du temps afin d'y pallier, quitte pour cela à créer des conflits :

- Mais avec cette méthode il faudrait travailler tous dans le même bureau !
- Eh bien, pourquoi pas ?