Coma Informatique

Pour la suite de notre feuilleton traitant de la mise en place d’eXtreme Programming, nous allons traiter du planning game.

Un changement dans la gestion des plannings

Avant la mise en place de XP, nous avions des réunions roadmap (plan de développement en français) stratégiques tous les trimestre et tactiques toutes les semaines.

La réunion tactique a été remplacée par les standup meetings matinaux.

La réunion trimestrielle a été remplacée par le planning game. Mais sa fréquence n’était plus fixe, mais fonction des besoins.

Quand ?

Nous avons d’abord fait un planning game initial, ou macroscopique, afin de définir les fonctions à développer d’une manière générales et faire un chiffrage approximatif.

Par la suite à chaque grande étape nous faisions un planning game pour définir le contenu de la prochaine release en détail.

Nous pouvions aussi décider lors d’un standup meeting de programmer un nouveau planning game si le besoin s’en faisait sentir, par exemple si suite à l’arrivée de beaucoup de demandes non prévues le planning devait être remis en cause.

Chiffrage

Le planning game se déroulait dans une salle fermée pour éviter toute distraction.

Dans un premier temps l’ensemble des scénarios utilisateur (ou fonctions), noté sur des fiches bristol, était chiffré collectivement par les développeurs, en fonction du coût de scénarios équivalents déjà réalisés. Au début nous étions forcement peu efficace sur les chiffrages, mais une fois que l’on avait à disposition une banque de fiches de scénario, les chiffrages étaient plus faciles, en procédant par analogie : « Ce scénario ressemble à tel autre qui nous a coûté tant, donc nous utiliseront le coût du réalisé pour le futur scénario ».

Planification

Une fois tous les scénarios chiffrés, le client classé les scénarios par priorité client ou marché. Parallèlement les développeurs classaient les scénarios par risque (facile, moyen, risqué). Le risque est différent du coût, en ce sens qu’il indique la difficulté technique, ce qui n’a rien à voir avec la durée. L’idée est de ne pas mettre trop de scénario risqué dans une même release pour d’une certaine manière repartir le risque entre les itérations.

Ensuite on calcule le coût réalisable par itération (en fonction des dates de release visé, et des effectifs disponible), et on repartie les scénario sur les releases à venir. On peut même planifier l’ensemble des fonctions voulues.

Et on itère

Evidement à partir de la première itération les plannings prévus n’ont jamais été respectés. Les raisons sont multiples et assumées : changement de priorité, ajout de nouveau scénario, problèmes techniques.

Chaque planning game permettait d’affiner le contenu le la prochaine release, tout en gardant une vision des futures releases. Le fait de ne plus avoir deux planifications (stratégique et tactique) réalisés séparément a permit d’avoir une vision plus correcte de ce qui sera disponible à une date donnée.

Bilan

Globalement on a obtenu une planification plus réaliste.

Par contre la durée du projet a largement dépassé le planning initial prévu, surtout parce que le niveau des fonctionnalités livrées a largement dépassé ce qui été prévu au départ.

A suivre

Cet article a été publié par Alexis KARTMANN le Mercredi 1 juin 2005 à 12:14 et est classé dans Tags:extreme programming, programmation
.
Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0.
Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.