Ce livre a été conjointement écrit en 2001 par Kent Beck et Martin Fowler et préfacé par Tom DeMarco. Cela fait trois grosses signatures pour un seul et même ouvrage.LA GESTION DE PROJET
Les auteurs consacrent le livre à la planification et au pilotage d'un projet mené dans une démarche XP. Ils cherchent à montrer qu'en plus de pratiques techniques, la panoplie XP contient toutes les pratiques nécessaires et suffisantes pour planifier et piloter un projet.
XP + SCRUM OU XP?
On dit souvent que Scrum apporte aux pratiques techniques d'XP les pratiques de pilotage de projet et d'équipe. Ce livre tend à montrer que XP est déjà auto-suffisant pour la gestion de projet. La sur-couche Scrum ne fait que recouvrir avec son propre vocabulaire et ses rôles des pratiques pré-existantes dans XP. Ceci dit Scrum apporte plus de formalisme et de cérémonial, ce qui est une bonne chose à mon avis.
DE L'EAU DANS LE VIN
D'une manière générale, Martin et surtout Kent ont mis de l'eau dans leur vin. Dans ce livre, je trouve que l'aspect extrême d'XP est diminué. Déjà, en préface, les auteurs rappellent que XP n'est pas une destination mais un parcours. Une pratique conforme au livre d'XP doit servir à identifier ce qui dans la démarche doit être adapté au contexte du projet.
La durée de l'itération est devenue un sujet d'expérimentation. Le cycle hebdomadaire n'est plus une référence. L'essentiel est de rester en dessous du mois et de ne pas glisser!
De même, la pluridisciplinarité de chaque membre de l'équipe n'est plus encadrée par une rotation systématique des binômes sur toutes les parties de l'application. La spécialisation des développeurs est même encouragée à partir du moment qu'elle est liée à une motivation personnelle.
Aussi, les auteurs sont plus permissifs quand à l'existence de bugs dans le produit. La correction de bugs mineurs n'est pas nécessairement une priorité pour l'équipe.
Enfin, les auteurs sont moins impératifs sur la nécessité de développer les fonctionnalités de bout en bout. L'essentiel est désormais que tout ce qui est développé dans l'itération soit testé à la sortie de l'itération.
Personnellement je désapprouve le calcul d'une vélocité individuelle pour chaque développeur. Je suis peut-être un peu Bisounours, mais je ne vois pas comment cela peut rester compatible d'un esprit d'équipe efficace. Je préfère calculer la vélocité de l'équipe pour mesurer sa capacité de travail par itération et éventuellement diviser cette vélocité par le nombre de développeurs pour surveiller l'impact de l'intégration de nouveaux membres dans l'équipe.
Enfin, j'ai apprécié le désaccord entre Kent et Martin portant sur la priorité des fonctionnalités à développer. Kent accorde une plus grande priorité à celles qui apporte le plus de valeur au client alors que Martin accorde les plus hautes priorités à celles qui comportent le plus de risques. C'est le pilotage par retour sur investissement contre le pilotage par les risques.
EN CONCLUSION
Bref, si on connait déjà XP et Scrum, il ne me semble pas que la lecture de ce livre soit si importante. Par contre, si on croit que XP ne contient que des pratiques techniques, alors ce livre est une occasion de se détromper. Il se lit très vite gràce au style reconnaissable de Kent: une succession de petits chapitres de 2 ou 3 pages au plus.
Vous m'avez apporté beaucoup avec cette synthèse, car j'ai beau lire énormément sur le sujet, je n'avais pas lu cet ouvrage le titre m'ayant amené a penser que cela traitait uniquement de planification.
RépondreSupprimerCe qui me dérange un peu, car je considère XP comme la méthode ayant apporté le plus aux années 2000, c'est l'abandon en douceur des aspects extrêmes. Si l'on tire un trait sur le pair programming généralisé comme outil de communication et d’apprentissage et même sur les aspects qualité (TDD et le refactoring généralisés) que va t'il resté ? Le Programming?