Gestion de projet – Vers les méthodes agiles
136
Il est en effet souhaitable d’avoir, au cours d’un projet, des itérations de même longueur,
afin de rythmer le projet et de faciliter ainsi la planification des réunions ou les validations pour toutes les parties prenantes. En outre, la vélocité, c’est-à-dire le nombre de
story points développés par l’équipe au cours d’une itération, ne peut être calculée et
réutilisée par l’équipe que sur des périodes comparables.
Planifier une release, cela revient par conséquent à ventiler des fonctionnalités dans
des itérations dont la taille a été déterminée. Au préalable, il est souvent nécessaire
de préciser ces fonctionnalités, voire de les découper pour les affecter efficacement et
logiquement aux itérations ; cette répartition est fonction de la vélocité. Au cours d’une
réunion de planification (release planning meeting), les fonctionnalités macroscopiques
prioritaires sont alors détaillées en unités plus fines, qui sont estimées en nombre de
points, selon leur complexité, et réparties sur les trois itérations de la release, en fonction de la vélocité de l’équipe.
On obtient ainsi le plan de la release (release plan), c’est-à-dire, pour cette première
release, le nombre d’itérations, leurs dates de début et de fin, ainsi que les fonctionnalités
que l’on envisage d’y développer, après calcul de la vélocité de l’équipe.
Dans la pratique, le plus simple est de faire courir une itération du lundi au vendredi de la
semaine suivante, par exemple. Certaines équipes font débuter l’itération le mardi, pour
pouvoir tenir les réunions de planification le lundi, lorsque tout le monde est bien reposé.
L’essentiel est de pouvoir répondre à la question « Quelle est l’itération en cours ? » d’un
simple coup d’œil sur le calendrier.
2) La réponse de l’expert David Gageot, directeur technique chez Tech4Quant.
Je laisse toujours une équipe décider de la durée de l’itération. Il est vrai que je les influence
juste un peu au début du projet en leur donnant les points forts des itérations courtes. Sachant
qu’ils sont à l’origine du choix, ils se sentiront plus à l’aise. En général, on arrive à une durée
de 2 ou 3 semaines.
J’ai tendance à figer cette durée pour tout le projet pour permettre à l’équipe de trouver un
rythme de croisière au plus vite. Cela permet même de caler des plannings figés dès le début
du projet (ex. démonstration un vendredi sur deux, le jour d’avant en cas de jour férié).
Le modèle le plus classique est de commencer une itération un lundi et de la terminer un
vendredi. Il m’est arrivé de changer ce schéma dans le cas d’équipes MOA (maîtrise
d’ouvrage) distante. Pour minimiser les déplacements, on terminait les itérations le lundi et on
commençait la suivante le mardi.
Parfois, l’équipe souhaite augmenter la durée des itérations pour avoir plus de temps pour finir.
Je leur montre alors qu’ils doivent peut-être au contraire réduire cette durée pour avoir moins
de tâches à effectuer et donc mieux les maîtriser.
Les fonctionnalités des autres releases, de priorité moyenne ou faible, ne sont pas traitées,
pour le moment.
GestProjInform Livre Page 136 Vendredi, 3. avril 2009 12:07 12
136
Il est en effet souhaitable d’avoir, au cours d’un projet, des itérations de même longueur,
afin de rythmer le projet et de faciliter ainsi la planification des réunions ou les validations pour toutes les parties prenantes. En outre, la vélocité, c’est-à-dire le nombre de
story points développés par l’équipe au cours d’une itération, ne peut être calculée et
réutilisée par l’équipe que sur des périodes comparables.
Planifier une release, cela revient par conséquent à ventiler des fonctionnalités dans
des itérations dont la taille a été déterminée. Au préalable, il est souvent nécessaire
de préciser ces fonctionnalités, voire de les découper pour les affecter efficacement et
logiquement aux itérations ; cette répartition est fonction de la vélocité. Au cours d’une
réunion de planification (release planning meeting), les fonctionnalités macroscopiques
prioritaires sont alors détaillées en unités plus fines, qui sont estimées en nombre de
points, selon leur complexité, et réparties sur les trois itérations de la release, en fonction de la vélocité de l’équipe.
On obtient ainsi le plan de la release (release plan), c’est-à-dire, pour cette première
release, le nombre d’itérations, leurs dates de début et de fin, ainsi que les fonctionnalités
que l’on envisage d’y développer, après calcul de la vélocité de l’équipe.
Dans la pratique, le plus simple est de faire courir une itération du lundi au vendredi de la
semaine suivante, par exemple. Certaines équipes font débuter l’itération le mardi, pour
pouvoir tenir les réunions de planification le lundi, lorsque tout le monde est bien reposé.
L’essentiel est de pouvoir répondre à la question « Quelle est l’itération en cours ? » d’un
simple coup d’œil sur le calendrier.
2) La réponse de l’expert David Gageot, directeur technique chez Tech4Quant.
Je laisse toujours une équipe décider de la durée de l’itération. Il est vrai que je les influence
juste un peu au début du projet en leur donnant les points forts des itérations courtes. Sachant
qu’ils sont à l’origine du choix, ils se sentiront plus à l’aise. En général, on arrive à une durée
de 2 ou 3 semaines.
J’ai tendance à figer cette durée pour tout le projet pour permettre à l’équipe de trouver un
rythme de croisière au plus vite. Cela permet même de caler des plannings figés dès le début
du projet (ex. démonstration un vendredi sur deux, le jour d’avant en cas de jour férié).
Le modèle le plus classique est de commencer une itération un lundi et de la terminer un
vendredi. Il m’est arrivé de changer ce schéma dans le cas d’équipes MOA (maîtrise
d’ouvrage) distante. Pour minimiser les déplacements, on terminait les itérations le lundi et on
commençait la suivante le mardi.
Parfois, l’équipe souhaite augmenter la durée des itérations pour avoir plus de temps pour finir.
Je leur montre alors qu’ils doivent peut-être au contraire réduire cette durée pour avoir moins
de tâches à effectuer et donc mieux les maîtriser.
Les fonctionnalités des autres releases, de priorité moyenne ou faible, ne sont pas traitées,
pour le moment.
GestProjInform Livre Page 136 Vendredi, 3. avril 2009 12:07 12