Pilotage

Le rôle de « client XP »

Le pilotage du projet est assuré par un membre spécifique de l'équipe projet : le « client ». Le client détermine les fonctionnalités du logiciel, gère les priorités, définit les spécifications précises du produit – en somme, ce rôle correspond à ce que nous nommons en France la maîtrise d'ouvrage du projet. Dans un projet XP, ce représentant de la maîtrise d'ouvrage rejoint le projet à plein temps.

Le choix de cette personne dépend très fortement du type de projet. Dans les contextes les plus simples, il pourra s'agir d'une personne qui est à la fois donneur d'ordre et utilisateur final. Dans d'autres contextes, le client pourra être le représentant d'un groupe plus large réunissant un comité de direction, des architectes, etc.

La phase initiale d'exploration

Le projet démarre par une phase d'exploration volontairement très courte (typiquement un mois maximum), qui a pour triple objectif de définir le contenu fonctionnel de l'application, établir un premier plan de développement pour le projet, et produire la toute première version du logiciel.

Au cours de cette phase, le client explore et définit le contenu fonctionnel qu'il souhaite voir implémenté dans le produit. Il établit ainsi une liste de fonctionnalités, qui prennent en XP la forme de « scénarios client ».

Un scénario client décrit en quelques mots un besoin particulier du client. Par exemple, pour un logiciel de gestion de carnet d'adresses le client pourrait écrire les scénarios suivants :

• "Je rentre un nom ou prénom, et le logiciel affiche la liste de toutes les personnes qui possèdent ce nom ou ce prénom"
• "Je peux exporter mon carnet d'adresses au format HTML."

Les scénarios sont rédigés dans le langage du client, et décrivent des fonctionnalités dont l'implémentation paraît assez rapide – un scénario doit en effet pouvoir être complètement implémenté en une itération. Si un scénario paraît trop vague ou trop complexe, il est décomposé en scénarios plus simples. A l'inverse, des scénarios trop courts peuvent être regroupés en un seul pour obtenir la granularité souhaitée.

Au cours de la phase d'exploration, le client et l'équipe se forgent ainsi une idée assez précise du périmètre fonctionnel souhaité de l'outil. Ils établissent alors le premier plan de développement du projet.

Planification du projet

La planification est réalisée au cours d'une réunion dédiée, qui réunit l'équipe et le client et se déroule comme suit :

1. Le client présente les différents scénarios à l'équipe, qui tente de se faire une idée de la charge de travail de chacun d'entre eux.
2. L'équipe donne pour chaque scénario une estimation de son coût d'implémentation, en « points » abstraits : tel scénario coûte 3 points, tel autre 1 point, etc.
3. L'équipe donne au client une estimation de sa « vélocité », c'est-à-dire du nombre de points de scénarios qu'elle s'estime capable de traiter en une itération – par exemple 10 points.
   Au tout début du projet cette vélocité est seulement estimée, mais après les premières itérations elle est réajustée en adoptant la règle suivante : la vélocité estimée pour une itération donnée correspond exactement au nombre de points effectivement traités à l'itération précédente.

Remarque
La vélocité ne représente en aucun cas le niveau de "performance" de l'équipe, dans la mesure où elle dépend en grande partie de la façon dont les développeurs font leurs estimations. Cependant, ses variations peuvent indiquer des problèmes passagers : si la vélocité baisse brutalement, c'est peut-être que l'équipe a été ralentie pour une raison ou une autre, et il ne faut pas ignorer cette information.

Le client établit lui-même le plan de développement en affectant les différents scénarios aux itérations à venir, de sorte qu'à chaque itération la somme du nombre de points des scénarios choisis soit égale à la vélocité annoncée.

Côté outillage, on donne la priorité à l'aspect participatif de la démarche en notant les scénarios sur des fiches cartonnées que l'on colle sur un grand tableau ou un mur :

Cette pratique peut surprendre dans des contextes où les documents ont souvent une forme électronique, mais les séances de planification jouent avant tout sur l'aspect humain du projet, la communication directe entre l'équipe et le client permettant d'aligner les deux parties sur l'objectif à atteindre.

Le plan de développement ainsi constitué est disposé à proximité de l'endroit où travaille l'équipe, de manière à ce que celle-ci ait une vision toujours à jour de ses engagements.

Première mise en production

Comme nous l'avons évoqué plus haut, la phase d'exploration se termine par la première livraison du logiciel.

Cette première mise en production intervient aussi tôt que possible dans le projet : il faut trouver le contenu fonctionnel minimal qui commence à avoir un sens pour les utilisateurs, quitte à faire preuve d'imagination en amenant par exemple le nouveau logiciel en complément d'un système existant dans le cadre d'une fonctionnalité bien précise.

Livraisons suivantes

Les mises en production s'enchaînent ensuite à un rythme régulier, toujours fixé par le client. L'objectif est d'obtenir un feedback très rapide sur le développement – en pratique toutes les une à six itérations selon la complexité de déploiement du produit.

Le plan de développement est continuellement mis à jour si nécessaire pour tenir compte des événements suivants :

• L'équipe de développement progresse à une vitesse différente de celle prévue (dans le bon ou le mauvais sens)
• Le client décide de changer le contenu des itérations restantes. Il peut ainsi permuter des scénarios en fonction de nouvelles priorités, ou encore remplacer certains scénarios du plan par de nouveaux.

Suivi du projet

Le suivi « haut niveau » du projet peut par exemple s'appuyer sur des graphes inspirés de celui représenté ci-dessous, dans lequel on note le nombre de points de scénarios restant à implémenter.

Tous les scénarios imaginés par le client ne sont pas nécessairement représentés dans ce graphe. Seuls y figurent ceux qui ont été retenus pour la prochaine grande échéance – typiquement la prochaine version majeure du produit, ou encore la fin du projet pour un développement de type forfait.

Cette courbe permet par projection d'estimer si les objectifs du projet seront tenus, et elle permet aussi d'identifier certains « patterns » dans le fonctionnement de l'équipe - par exemple une tendance à la sur- ou sous-estimation des tâches (1).

Tests de recette automatiques

Pour chaque scénario planifié, un ensemble de tests de recette est écrit. Ces tests ont pour but de vérifier de manière automatique (c'est-à-dire sans intervention ou interprétation humaine) chacune des fonctionnalités demandées par le client. Le client définit ces tests et participe éventuellement à leur implémentation, assisté pour cela d'un certain nombre de testeurs.

Ces tests peuvent prendre plusieurs formes. Il peut s'agir de jeux de données, sous forme par exemple de feuilles de tableur ou de fichiers XML, qui définissent une transformation effectuée par le logiciel : « pour telle entrée, le logiciel doit produire tel résultat ». Il peut s'agir également de scripts pour les cas plus complexes, ces scripts décrivant par exemple des séquences d'interactions de l'utilisateur avec l'interface graphique du produit.

Ces tests représentent dans un projet XP les spécifications détaillées de l'outil – des spécifications formelles, toujours en phase avec le développement. Dans un contexte « pur XP », ce sont les seules spécifications : il n'y a pas de document de spécifications à proprement parler. En pratique, cependant, des documents peuvent être exigés par l'organisation qui encadre le projet. Des documents synthétiques sont alors réalisés par le client.

Les tests de recette sont lancés fréquemment, et tous les participants du projet (client, direction, développeurs) sont informés en permanence de leurs résultats (2).

_____

(1) Le livre « Agile Software Development with Scrum » de Ken Schwaber et Mike Beedle comporte une très intéressante présentation de ce type d'analyse.
(2) Des outils d'intégration continue tels que « Cruise Control » ou « Damage Control » peuvent être utilisés à cette fin.