Introduction
Cette 2ème partie fait suite au 1er article sur la création d'un Workflow de développement orienté Feature Team DevOps afin de rapidement mettre en production avec un niveau de qualité optimal. Nous avons vu dans la première partie qu'un workflow pouvait avoir de multiples étapes, mais chacune des étapes dans JIRA correspond à un méta-état afin de savoir comment comptabiliser les points :
- Todo : Les issues ne sont pas démarrées
- Active : Les issues sont en cours
- Done : Les issues sont terminées, et on peut comptabiliser les points (donc avoir une influence sur le Burndown).
Voyons comment quelle proposition d'amélioration de Burndown nous pouvons faire pour tirer parti d'un Workflow complexe :
Amélioration du Burndown
Types de Burndown classiques
Il y a deux types de Burndown principaux utilisés en Scrum avec des avantages et des inconvénients :
- le Burndown en points qui est classique
- Avantages : Les points engrangés ne sont pas de l'estimation mais bien du concret, donc pas de problème d'estimation du reste à faire
- Inconvénients : il y a un certain "retard à l'allumage", en effet si les User Stories durent 2 / 3 jours, on peut avoir l'impression qu'on n'avance pas, puisque les points ne sont pas engrangés
- le Burndown en tâche / temps restant estimé, qui est notamment celui poussé par TFS (Team Foundation Services), l'outil d'ALM de Microsoft
- Avantages : pas de "retard à l'allumage", dès lors qu'on met à jour régulièrement (en général le soir) le temps restant sur chaque tâche
- Inconvénients : celui-ci est basé sur les estimations de reste à faire en J/h, qui sont chez les développeurs un peu optimistes, pas assez réalistes. Cela produit parfois alors des mauvaises surprises en milieu ou fin de sprint, et le reste à faire trop conséquent ne permet pas la validation complète d'une User Story. On peut avoir donc l'impression que le Sprint se passe bien, mais pas forcément d'engranger les points à la fin.
Notre point de vue est que l'estimation du Burndown en points reste la meilleure stratégie, mais nous avons construit à Cegedim Insurance Solutions un graphe un peu plus précis que le Burndown de base de JIRA, pour prendre en compte le WIP (Work In Progress).
 |
| Burndown simple |
Si jamais on ne regardait que la courbe Verte foncée (courbe réelle en point du Burndown), on constaterait un écart de 3.5 jours (appelé Drift ici), par rapport à ce qu'on souhaiterait avoir. Or on sait aussi que le "retard à l'allumage" lié au fait qu'il faut un certain temps pour valider une User Story peut expliquer cela. Néanmoins, difficile de dire si ce temps est acceptable ou pas. Peux-être que tout vient d'être validé, et qu'on n'a pas pris dans le backlog de nouvelles User Stories, auquel cas, on est vraiment en retard d'environ 3,5 jours. Ou à l'inverse, peut-être que de nombreuses User Stories sont largement entamées et de nombreux points seront bientôt validés. C'est là que le Burndown amélioré donne une meilleure visibilité et est très utile :
 |
| Burndown amélioré |
Légende :
- En rouge : la courbe de burndown réelle en points engrangés (Done)
- En gris : la courbe idéale de burndown (le burndown ne peut jamais être celui-là, car les User Stories ont des points en valeurs discrètes, donc forcément la courbe réelle est en "escalier").
- En Vert foncé : la courbe de tendance du Burndown en fin de sprint si jamais on continue à progresser à cette allure
- En Vert pâle : la courbe de tendance en fin de sprint si jamais le Product Owner validait à l'instant l'ensemble des User Stories (Completed à Done)
- En Vert kaki : la courbe de tendance en fin de sprint si jamais le Mister T ainsi que le Product Owner validaient à l'instant l'ensemble des User Stories (QualityReview -> Completed -> Done)
- En Orangé foncé : la courbe de tendance en fin de sprint si jamais le Leader technique, le Mister T, le Product Owner validaient à l'instant l'ensemble des User Stories (TechnicalReview -> QualityReview -> Completed -> Done)
- En Orange : si jamais l'ensemble des US actives allaient passer à Done
On voit qu'en réalité, ce Sprint de l'équipe "Bleue" se déroule finalement bien même avec un burndown qui descend même avec un peu de retard :
- Il y a des User Stories à l'état Completed, qui devrait rapidement être validées par le Product Owner
- Il y a pleins de User Stories à l'état TechniqueReview, et si jamais toutes étaient validées à l'instant (peu probable qu'elles le soient toutes, mais probable qu'au moins la moitié le soient rapidement), on aurait même de l'avance puisqu'on passerait alors sous la courbe idéale en gris.
- Moins probable, mais très intéressant est de savoir ce qui se passerait si jamais tout ce qui était "actif" venait à se terminer et être validé instantanément, et là on voit qu'on serait très en avance. Evidemment, c'est très hypothétique, mais cela donne une bonne indication du volume de User Story pris en parallèle par chacun des développeurs.
Analyse du Burndown amélioré pour un bon pilotage de Sprint
Maintenant que nous disposons de cet outil, voici quelques exemples théoriques de typologie de Burndown qui montrent un Sprint bien maîtrisé (voir Burndown ci-dessus) et des Sprints en risques :
Burndown maîtrisé
La ligne grise est au milieu de la courbe de tendance du Burndown et de la courbe "optimiste" de l'en-cours.
On voit que la quantité d'en cours (représenté par l'arc noir) n'est pas trop importante, et que si on finit l'en-cours raisonnablement vite, on a de bonnes chances de converger en fin de sprint sur la courbe idéale grise.
Action : RAS, on continue de bien suivre pour garder à peu près la même tendance voire mieux si possible
Sprint qui a de bonnes chances de ne pas être fini
Les deux lignes de tendance "Verte" et "Orange" sont au-dessus de la courbe du Burndown idéal : on voit que même si on finissait l'en-cours immédiatement, on ne serait pas en dessous de la courbe idéale, c'est-à-dire, que même si on est super optimiste, on est déjà en retard !
Action : Comprendre les points de blocages, peut être que plusieurs personnes butent sur le même sujet et perdent du temps inutilement. Essayer de redistribuer les User Stories en priorisant celles qui apparaissent plus aisées afin d'engranger les points liées à celles-ci et ne pas risquer la catastrophe en agilité : un Sprint à zéro point ou presque ! Cela a un effet psychologique désastreux sur l'équipe et en général un impact sur plusieurs Sprints, qui va hésiter à s'engager. Certains recommandent de terminer le Sprint si vraiment il est catastrophique, c'est un point compliqué à trancher de notre point de vue.
Sprint où on commence tout, mais où on ne finit rien
Les deux lignes de tendances "Verte" et "Orange" entourent bien la courbe grise de Burndown idéal, mais on a des gros risques de ne pas faire converger le Burndown en fin de Sprint, car il entame beaucoup de choses, et le risque est que les validations risquent de se télescoper en fin de Sprint, avec un engagement à la fin qui ne sera pas tenu.
Action : le Scrum doit veiller à ce que les développeurs ne soient pas affectés à plusieurs User Stories à la fois, ou faire du Pair Programming pour valider au plus tôt des User Stories et réduire le nombre de Stories actives.
Les deux lignes de tendance "Verte" et "Orange" sont bien en dessus de la courbe du Burndown idéal.
Cela peut être dû :
Action : le Scrum doit veiller à ce que les développeurs ne soient pas affectés à plusieurs User Stories à la fois, ou faire du Pair Programming pour valider au plus tôt des User Stories et réduire le nombre de Stories actives.
Sprint où on a probablement minimisé l'engagement, ou alors "Tout va bien"
Les deux lignes de tendance "Verte" et "Orange" sont bien en dessus de la courbe du Burndown idéal.
Cela peut être dû :
- à une augmentation de la maîtrise de l'équipe (récente sinon on aurait engagé davantage de points)
- à un engagement très faible de l'équipe (souvent à la suite d'un Sprint désastreux)
- à un reliquat important de User Stories qui n'ont pas été validées au Sprint précédent et qui étaient quasi prêtes
Action : bien en tirer les enseignements en rétrospective d'équipe, et rester vigilant car la tendance peut malgré tout ne pas rester la même tout au long du Sprint
Conclusion
Nous verrons dans un futur article comment une télévision au milieu d'un Open Space peut permettre facilement d'opérer ce partage et cette responsabilisation ...
@svanacker
Aucun commentaire:
Enregistrer un commentaire