Gestion de projet – Vers les méthodes agiles
140
Si le nombre total de points ainsi calculé correspond à la vélocité estimée de l’itération,
l’équipe peut s’engager collectivement auprès du client sur le résultat à atteindre et
l’achèvement des activités correspondantes.
À l’issue de cette réunion de planification, l’ensemble de l’équipe dispose d’un sprint ou
iteration backlog, c’est-à-dire un sous-ensemble du product backlog initial qui ne
comporte que les tâches des stories qui seront implémentées dans cette itération. Il
résulte de la formalisation des échanges de la réunion qui ont souvent lieu autour d’un
tableau blanc et de Post-it. Il est important de noter que dans le product backlog on liste
des fonctionnalités, alors que dans le sprint ou iteration backlog, on bascule vers les activités correspondant aux fonctionnalités implémentées.
Toutes les activités sont concernées : analyse, conception, développement, test, documentation… indispensables à l’implémentation complète d’une fonctionnalité, potentiellement livrable
(potentially shippable) à la fin de l’itération. Une fonctionnalité n’est considérée comme achevée (done) que lorsqu’elle a été validée par le client et documentée. On ne différencie pas ces
différentes disciplines, intégrées, par essence, dans une activité.
Quel est le principe du jeu de poker ou planning poker ?
C’est le principe du planning game dans XP, adapté pour Scrum par Mike Cohn a .
Lors d’une séance de « jeu de poker », toute l’équipe est réunie ; chaque participant se voit
confier un jeu de cartes, qui comportent chacune une valeur : par exemple, 0, 1, 2, 3, 5, 8, 13,
20, 40 et 100. Ces valeurs correspondent au nombre de story points ou de ideal days qui
seront affectés à une user story.
Une présentation de chaque user story est faite par le product owner à l’équipe, puis une
discussion s’ensuit sur les détails de cette story. Chacun estime ensuite la taille de la story et
présente une carte avec la valeur retenue correspondante. Les divergences d’estimation sont
alors débattues et analysées jusqu’à ce qu’un consensus soit trouvé.
L’avantage est que cette démarche d’estimation est, elle aussi, consensuelle, conviviale, rapide,
permettant à chacun de s’exprimer et de justifier son chiffre pour mieux s’engager ensuite.
NB : C’est encore la valeur relative qui est importante et non la valeur absolue.
Une équipe peut avoir recours à cette technique de « jeu » lors du lancement du projet (au
cours de deux ou trois réunions de deux ou trois heures, par exemple), puis au moment de la
planification d’une release ou d’une itération.
a. Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005.
La vélocité estimée par l’équipe, c’est-à-dire sa capacité à prendre en charge x points, est une
vélocité cible hypothétique lors d’une première expérience ; ensuite, elle est basée sur la vélocité réelle constatée sur l’itération précédente ou une moyenne calculée sur la vélocité des
itérations précédentes.
Il est à noter que ces activités ne sont pas nominatives.
GestProjInform Livre Page 140 Vendredi, 3. avril 2009 12:07 12
Précédent

- 157/290

Suivant