Gestion de projet – Vers les méthodes agiles
144
Un burndown chart (figure 4-14) peut être établi pour l’itération en cours mais également, de façon
plus macroscopique et à titre indicatif, pour la release ou le projet dans sa globalité, en se basant
sur les fonctionnalités ou les stories positionnées dans les différentes « boîtes de temps ».
Figure 4-14
Exemple de burndown chart
Cela signifie-t-il que la granularité du product backlog évolue en fonction des niveaux de
planification ?
La réponse de l’expert Jean Tabaka, agile coach chez Rally Software Development, Colorado.
Les équipes agiles travaillent avec la ferme conviction que détailler trop tôt tous les aspects du
système est une perte de temps. Cette conviction repose sur les principes du lean management, qui combattent le gaspillage et luttent pour la création de valeur. De plus, détailler trop
tôt un item peut induire des contraintes sur la conception qui nécessiteront plus tard des ajustements coûteux. Animé par ce souci de réduire le gaspillage, la question pour une équipe
agile devient alors : « Quand et comment détailler chaque item ? » Le client ou le product
owner, avec les autres parties prenantes et les experts métier, gèrent la granularité des items
en appliquant certaines règles qui réduisent le gaspillage et préservent l’apport de valeur.
D’abord, le niveau de détail doit être suffisant pour permettre à l’équipe (développeurs, concepteurs, testeurs, rédacteurs techniques et les autres) de passer à l’étape suivante de planification.
Lorsqu’un projet en est au stade de la vision, la granularité des items du product backlog est
très macroscopique. La position est : « Quelles sont les fonctionnalités qui créent le plus de ☞
Sprint Burndown Chart
0
5
10
15
20
25
30
35
0
1
2
3
4
5
6
7
8
9
1 0
Jours
Estimation du reste à faire
GestProjInform Livre Page 144 Vendredi, 3. avril 2009 12:07 12
144
Un burndown chart (figure 4-14) peut être établi pour l’itération en cours mais également, de façon
plus macroscopique et à titre indicatif, pour la release ou le projet dans sa globalité, en se basant
sur les fonctionnalités ou les stories positionnées dans les différentes « boîtes de temps ».
Figure 4-14
Exemple de burndown chart
Cela signifie-t-il que la granularité du product backlog évolue en fonction des niveaux de
planification ?
La réponse de l’expert Jean Tabaka, agile coach chez Rally Software Development, Colorado.
Les équipes agiles travaillent avec la ferme conviction que détailler trop tôt tous les aspects du
système est une perte de temps. Cette conviction repose sur les principes du lean management, qui combattent le gaspillage et luttent pour la création de valeur. De plus, détailler trop
tôt un item peut induire des contraintes sur la conception qui nécessiteront plus tard des ajustements coûteux. Animé par ce souci de réduire le gaspillage, la question pour une équipe
agile devient alors : « Quand et comment détailler chaque item ? » Le client ou le product
owner, avec les autres parties prenantes et les experts métier, gèrent la granularité des items
en appliquant certaines règles qui réduisent le gaspillage et préservent l’apport de valeur.
D’abord, le niveau de détail doit être suffisant pour permettre à l’équipe (développeurs, concepteurs, testeurs, rédacteurs techniques et les autres) de passer à l’étape suivante de planification.
Lorsqu’un projet en est au stade de la vision, la granularité des items du product backlog est
très macroscopique. La position est : « Quelles sont les fonctionnalités qui créent le plus de ☞
Sprint Burndown Chart
0
5
10
15
20
25
30
35
0
1
2
3
4
5
6
7
8
9
1 0
Jours
Estimation du reste à faire
GestProjInform Livre Page 144 Vendredi, 3. avril 2009 12:07 12