« Scrum Burndown Chart de Release Amélioré » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 5 : | Ligne 5 : | ||
Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br /> | Traducteur : Fabrice Aimetti<br /> Date : 03/07/2012<br /> | ||
---- | ---- | ||
''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel]. | ''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Le classique [http://www.mountaingoatsoftware.com/scrum/release-burndown Scrum Burndown Chart de Release] ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown1.gif|altrelburndown1.gif]]Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du [http://www.mountaingoatsoftware.com/scrum/product-backlog backlog produit] en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner] ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Avant de démarrer le sprint 6, du travail a été supprimé par le [http://www.mountaingoatsoftware.com/scrum/product-owner product owner]. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.</span><br /><span style="display: block; text-align: justify">Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:altrelburndown2.gif|altrelburndown2.gif]]</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :</span><span style="display: block; text-align: justify"><br /> <span style="display: block; text-align: justify">[[Image:altrelburndown3.gif|altrelburndown3.gif]]</span>Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette [http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls feuille de calcul Excel]. |
Version du 1 juillet 2018 à 11:32
Source : Alternative Scrum Release Burndown Chart
Traducteur : Fabrice Aimetti
Date : 03/07/2012
Traduction :
Le classique Scrum Burndown Chart de Release ne montre qu'une seule valeur, la variation nette de la quantité de travail restante. Dans certains cas, la simplicité de ce graphique est étonnante. Cependant, il peut aussi masquer ce qui est peut-être en train de se passer au niveau du projet. Par exemple, supposons que l'équipe prévoyait de faire un progrès de 40 (heures, points, ce que vous voulez) lors du dernier sprint, mais le burndown chart ne montre qu'un progrès net de 10. Est-ce que l'équipe a été plus lente que prévu, ou est-ce que davantage de travail a été ajouté à la release ? Il est important de connaître la question à cette réponse parce que sans ça nous ne pourrons pas réellement prévoir quand la release sera terminée. C'est ce qui m'amène à vous présenter un nouveau type de burndown chart :
Sur ce burndown chart, la hauteur de chaque barre représente la quantité de travail restante dans la release. Je préfère estimer les items du backlog produit en "points de story", le graphique à gauche montre que la release est estimée à 175 points au départ du sprint 1. L'équipe termine 25 points à la fin du sprint 1, il n'en reste plus que 150 à faire au départ du sprint 2. Il n'en reste plus que 120 au départ du sprint 3. Donc, le haut de la barre diminue de la quantité de travail réalisée par l'équipe au cours d'un sprint. Avant de démarrer le sprint 4, le product owner ajoute du travail au projet. Ce travail supplémentaire est visualisé en bas de la barre du sprint 4. Vous voyez que la barre du sprint 4 va de -40 à environ 95, soit 135 points de travail restant à faire. 40 de ces points sont du nouveau travail.
Avant de démarrer le sprint 6, du travail a été supprimé par le product owner. A l'image de l'augmentation de périmètre, la diminution de périmètre a un impact sur le bas de la barre. Ce travail supprimé concerne aussi bien un travail initialement planifié qu'un travail ajouté durant le projet.
Une manière de prédire combien de sprints prendra le projet est de tracer une tendance à travers les barres et d'étendre la projection. Par exemple :
Le problème ici c'est que prédire la date de fin comme ci-dessus ne tient pas compte du rythme de changement du périmètre du projet. Vous pouvez anticiper le nombre de sprints nécessaires en traçant une tendance à travers les changements visualisés en bas des barres comme illustré ci-dessous :
Pour voir comment créer ce type de burndown chart, jetez un coup d'oeil à cette feuille de calcul Excel.