Note : 6 ; Quand planifier rime plus avec visibilité qu’avec « estimer ».

L’extrême programming se focalise sur des cycles de développement fortement itératifs, au sein desquels l’interaction avec le client et permanente et le formalisme réduit au minimum. Dans ce cadre, écrire un livre sur la planification d’un tel processus peut sembler une gageure. En fait, ce livre ne traite guère de métrique d’évaluation ou de consommation du développement, mais se focalise sur les aspects humains. Planifier en Extreme Programming, c’est avant tout s’assurer que l’on travaille sur les choses les plus importantes et pouvoir se coordonner avec les autres (le sujet du 1er chapitre). Pour faire cela, il faudra aussi estimer, mais différemment.

Cet ouvrage, co-écrit par deux grands noms de la communauté, n’est guère long : 130 pages ! A l’instar de nombreux volumes de l’XP series, il compte beaucoup de chapitres, il y en a 27. Les passer tous en revue serait fastidieux, je vais me contenter de relever quelques éléments qui m’ont marqué ou que j’ai aimé.

• Au chapitre 2, le « customer bill of rights » et le « programmer bill of rights », plutôt que des définitions de responsabilités.
• La manière dont XP aborde les 4 variables du développement logiciel : coût, qualité, délais et périmètre, au chapitre 7. La qualité se décline en interne et externe, les bugs étant souvent une question de définition de périmètre.
• Le « yesterday’s weather », une pratique simple généralisée aujourd’hui pour l’estimation agile… est couverte ici sur 2 pages !
• Les user stories, au chapitre 11, ont droit à 16 pages ! Si elles n’ont pas la même allure qu’aujourd’hui, les principes de base y sont clairement énoncés.
• Le chapitre 13 évoque la question de la business value et des risques pour prioriser les user stories. Un point de vue qui reste très qualitatif toutefois.
• Le chapitre 18 consacré au planning meeting ne compte que 7 pages. Néanmoins, c’est bel et bien le planning meeting Scrum tel qu’on le pratique aujourd’hui qui y st décrit.
• Le stand-up meeting est abordé au chapitre 20. Il fait une page.
• Le chapitre 25 sur le « business contract » est décevant. Il n’apporte pas de vraie réponse à cette épineuse question.

Le livre peut paraître décevant, car on n’y aborde pas la planification d’un projet XP avec des heuristiques bien définies et des pratiques prédictives. Il s’agit plutôt d’outils à aborder avec pertinence. Même sur ce point, on peut reprocher à l’ouvrage de rester superficiel, par exemple sur l’épineuse question des estimations ! On peut à ce titre comparer ce texte avec « Agile Estimating and Planning » de Mike Cohn, et la solidité du contenu de ce dernier fait mal à celui-ci… Malgré son format court, la table des matières contient des sujets qui ne sont pas précisément dans le scope du titre, mais plutôt un peu périphériques. J’attribue cela à l’approche un peu superficielle du sujet.

Il reste deux raisons principales de s’intéresser à ce livre, outre la renommée de ses deux auteurs. Tout d’abord il constitue une pièce d’histoire de l’agilité, en nous exposant avec limpidité la manière de mener un projet en XP au début des années 2000. Ensuite, pour qui ne souhaite pas affronter tout de suite la lecture un peu lourde de Mike Cohn, c’est une matière plus douce de s’immerger dans la planification agile.

Référence complète : Planning Extreme Programming – Kent Beck & Martin Fowler – Addison Wesley / XP series 2000 – ISBN: 0-201-71091-9