Est-ce un point de non retour sur l’acceptation par les équipes de développement de la méthode. De nombreux retours d’expérience vont dans ce sens où la non adhésion complète des principes remettait en cause le résultat de cette méthode.
Dans un séminaire Agile, Greg Hutchings avait évoqué les patterns/anti patterns de l’agilité, le premier anti pattern étant de ne pas appliquer complètement la méthode, mais par petit bout.
Le post de Claude Aubry remet en cause le burndwon au profit d’un suivi des tâches par état.
Pourquoi remettre en question les bases de Scrum et délaisser le burndown au profit d’un suivi par état. Le suivi par état en plus du burndown, je suis d’accord, mais pas en remplacement.
Scrum est basé (comme beaucoup) sur la notion de charge : estimée, produite, consommée, restante à faire,… en d’autres termes de productivité.
- Xébia rappelle que « Scrum a été conçu pour atteindre une productivité de 5 à 10 fois supérieure… »,
- Une itération en Scrum s’appelle un sprint, ce n’est pas pour rien.
Je préfère l’approche « complément » présentée par Mike Cohn. qui propose des solutions visuelles améliorant la lisibilité du burndwon par adjonction d’information sur la priorité, ou celle présentant le backlog produit avec une Treemap, une présentation surfacique relative aux poids de chaque user story.
Mais dans les deux cas, Mike garde la notion de charge : poids, estimation, reste à faire.
Je sais qu’il est difficile dans notre contexte très dirigé par les contrats au forfait de parler de charge. C’est quand même la base d’une gestion de projet, sans parler de leur conversion en euros.
Que l’on parle de jours, d’heures, ou de points (de toute façon représentation relative d’un temps), je ne vois pas comment suivre efficacement un projet sans se préoccuper du reste à faire, du consommé.
J’ai trouvé dans Scrum une manière particulière et innovante d’intéresser les développeurs à ce qu’ils font, par le fait des les responsabiliser. Non pas pour les culpabiliser, mais les rendre responsable au sens propre du terme.
Se passer du burndown et donc de ses données intrinsèques me parait un risque majeur sur la compréhension et l’adhésion des équipes, voir des clients à la méthodologie Scrum.
2 commentaires:
Bonjour,
Je découvre ce blog par l'intermédiaire de celui de Claude Aubry et j'aimerais rebondir sur cette histoire de burndown chart de sprint et/ou suivi des taches par état.
Une des recommendations historiques des agilistes est de ne pas laisser le soleil se coucher sur du mauvais code ("don't let the sun set on bad code" en VO). Cela signifie implicitement qu'un bon découpage en taches ne doit pas définir de taches dont la durée est supérieure à la journée.
A partir de là, quel est l'intérêt d'une quelconque mesure d'un "reste à faire" qui ne sera qu'une estimation erronée ?
Comme le rappelle le manifeste agile, la seule mesure valable d'avancement est le logiciel qui fonctionne : une tache qui n'est pas terminée ne peut donc pas servir pour une telle mesure.
En fait, non seulement un suivi des taches par état est équivalent à un burndown chart de sprint mais c'est le *meilleur* burndown chart qui soit : soit une tache n'est pas terminée et son reste à faire correspond à son évaluation initiale, soit elle est terminée et son reste à faire est nul.
Pour ma part, je préfère pousser la logique encore plus loin : en ne définissant que des taches qui ne dépassent pas la journée, on s'affranchit de toute évaluation erronée :
- soit une tache n'est pas terminée et son RAF est 1
- soit elle est terminée et son RAF est 0
Le burndown chart correspondant est très facile à tracer et bien plus juste qu'un burndown chart basé sur des estimations hasardeuses !
Bonjour Olivier.
Effectivement, si les estimations sont hasardeuses, ça n'a aucun intérêt. De même que sur le suivi de l'"actual". Tout est là.
Mais le sujet abordé est de trouvé un moyen d'avoir une estimation cohérente (vraie étant par définition impossible).
La pratique énoncée de n'avoir que des tâches de moins d'une journée est tout à fait juste. Et dans ce cas, effectivement, le suivi par état peut totalement se substituer au burndown par reste à faire, puisqu’il y a égalité.
Il n’est toutes fois, pas toujours possible d'avoir un découpage des tâches de cette granularité.
La aussi, nous devons nous adapter.
En tout cas, merci de ton commentaire, ça permet de multiplier les points de vue et retours d’expériences.
Enregistrer un commentaire