La gestion de projets version XP

Lors d’un précédent apéro PHP sur Lille, Perrick Penet, l’animateur a organisé un jeu sur l’Extreme Programming. Cette méthode de travail qui prend de plus en plus d’ampleur concerne directement les développeurs d’applications informatiques. Toutefois, les fondements de cette méthode peuvent être, à mon avis, appliqués à d’autres secteurs.

Principe du XP Game

Un des principes de XP ( Extreme Programming ) consiste à mettre en place une relation beaucoup plus forte entre le client et le développeur. Cette implication du client passe notamment par une présence au sein de l’équipe de développeur.

Quand le projet est clairement connu par les deux parties ( le client et les développeurs ), le client décompose son projet en actions. Il donne ensuite à chacune de ces actions une valeur sous la forme d’une somme ou de points.

La valeur doit exprimée le degré d’importance dans le projet. Ainsi, une action qui détermine d’autres actions aura eu valeur plus élevée que les autres. Si une action ne sert qu’à répondre à une éventualité, elle sera considérée comme moins vitale et donc moins bien côtée.

Parallèlement, les deux équipes se mettent d’accord pour travailler sur des durées limitées ( itération ). Dans la moyenne, une itération dure deux semaines.
Le client présente les actions à mener et les développeurs doivent estimer le temps nécessaire sur une itération de deux semaines. S’ils considèrent que l’action peut-être réalisée en moins de deux semaines, le client peut proposer une autre action à mener. Dans le cas contraire, il doit soit découper son action en plusieurs étapes, soit choisir une autre action.

A partir de la valeur de l’action et de l’estimation de temps, le client peut ainsi définir son programme d’actions pour l’itération complète. Un tableau de suivi reprend les actions réalisées avec le temps estimé, le temps réalisé et la valeur de chaque action. Ce tableau de bord permet au client de voir quand la valeur totale des actions est trop faible par rapport au temps consacré, et quand les développeurs sur-estiment ou sous-estiment leur travail.

Retour sur l’expérience

Même si cette méthode est plus pensée pour des développeurs, elle peut répondre à bon nombre de besoins. Si on replace le projet dans ses trois phases : la finalité, l’objectif et le moyen, on se rend compte que la méthode XP apporte une solution à la gestion du troisième stade.

Un projet se décompose en trois temps. Le premier consiste à définir la finalité en une phrase. Exemple : une entreprise souhaite devenir un acteur incontournable dans son secteur.

Pour atteindre ce but, la direction va définir des objectifs mesurables et quantifiables dans le temps. Dans notre cas présent, cela pourrait se concrétiser de la manière suivante :
1°/ Gagner des parts de marchés sur les concurrents,
2°/ Concevoir de nouveaux produits,
3°/ Proposer la plus large information produits.
Au bout de six mois ou un an, on peut facilement mesurer combien de nouveaux produits ont été créés, quelles parts de marchés ont été prises aux concurrents et si la qualité et la quantité de l’information fournie est plus ou moins importante.

Pour réaliser ses objectifs, on définit un plan d’actions dans le temps. Ainsi, pour gagner des parts de marché, on va:
1°/ embaucher des commerciaux,
2°/ créer de nouveaux tarifs,
3°/ rencontrer tous les clients,
4°/ prescrire les produits aux clients indirects, etc …

C’est à ce stade que la méthode XP apporte une solution. La valeur du recrutement peut-être importante pour ensuite aller visiter les clients. Seulement, le recrutement n’est peut-être pas réalisable au cours d’une simple itération. Il faut alors dans ce cas, décomposer le recrutement en plusieurs actions et placer d’autres actions avant le recrutement.