MyProjectStuff
Douzième épisode du roman fil rouge du livre Kanban pour l’IT.
Dans le dernier épisode, Sophie a préparé la prochaine rétrospective de l’équipe Aldébaran. Elle a travaillé sur la Value Stream Mapping du projet et analysé les gaspillages.
Rétrospective sprint 3 Aldébaran – Version majeure 4.0
Sophie montre à l’équipe les deux diagrammes de flux, en points et en nombre, du sprint qui se termine :
Diagrammes de flux cumulé du sprint 3de MyProjectStuff
– « Qu’en pensez-vous ? » demande Sophie à l’équipe, après avoir rapidement expliqué comment lire ces diagrammes. Elle insiste notamment sur les temps moyens passés dans les différentes activités d’une story.
Fred se lance :
– « On passe moins de temps en revue à la fin du sprint. C’est bien ça que tu attends comme analyse ? »
– « Oui, continue Fred. » dit-elle.
– « Pendant les deux premiers tiers du sprint, une story passe un peu plus de temps en revue qu’en développement. Par contre, la tendance s’inverse en fin du sprint. » continue-t-il.
– « Qu’est-ce que cela nous apprend ? » demande Sophie.
– « J’ai du mal à comprendre ce résultat car on passe bien plus de temps à développer qu’à faire la revue. On devrait avoir un résultat inverse non ?» demande Michael.
– « Il ne faut pas confondre charge et délai. On visualise le délai sur cette courbe. » répond Sophie.
– « En quoi est-ce un problème, on a bien réussi notre sprint ? » pense tout haut Manu.
– « Tu as raison, ce n’est pas un problème apriori pour nous. ça l’est plus pour Pauline qui, au deux-tiers du sprint, voit moins de la moitié de la vélocité attendue sur le sprint réalisée !» explique Sophie en surlignant, sur le diagramme, le burn up réel et idéal :
Diagramme et burn up
– « Pour sécuriser ce point, il faut faire tendre le burn up réel le plus possible vers le burn up idéal. C’est possible si les stories passent moins de temps en revue. L’analyse de Fred montre que l’on y arrive en fin de sprint. Pourquoi ne pas y arriver tout au long du sprint ? Je vous propose d’identifier pourquoi le délai de revue est long. Alors à vos Post-it ! » lance Sophie.
Bilan du brainstorming sur la revue MyProjectStuff
– « Le problème, ce sont les attentes ! On attend de faire la revue de code, on attend d’avoir passé les tests avant la revue de Pauline. On attend sa disponibilité pour sa revue. » pointe Dominique.
– « Comment réduire ces attentes alors ? » demande Sophie.
– « On ne peut pas tout paralléliser. Pas la revue de code. Il vaut mieux passer les tests après le refactoring. » continue Dominique.
– « Je ne suis pas d’accord, on devrait pouvoir. ça prouve qu’il n’y a pas encore assez de tests automatiques. » rétorque Fred.
– « Et pourquoi faire une revue de code ? On binôme déjà beaucoup. Ce n’est pas redondant ? Je crois que c’est ça qui me gênait depuis que l’on avait rendu visible cette activité de revue !» s’interroge Michael.
– « C’est vrai qu’il y a rarement de retours. On doit pouvoir s’en passer et donc paralléliser les tests et la revue Product Owner. D’ailleurs les deux peuvent être faits en une seule passe ? » avance Dominique.
– « Pauline, serais-tu d’accord pour passer les tests lorsque tu fais la revue ? » demande Sophie.
– « Bien sûr, ma revue est très liée aux tests d’acceptation de toute façon. ça ne change pas grand-chose pour moi. » répond-elle.
– « Si je fais le bilan, on peut supprimer la revue de code grâce au binômage. On peut fusionner les tests et la revue PO. » conclue Sophie. « L’objectif de cette action est que les stories passent moins de temps en revue pour se rapprocher du burn up idéal. Et pour s’aider au quotidien, je propose de diminuer la limite de quatre « en revue » à trois. »
Tout le monde étant d’accord, Fred se propose de mettre à jour le tableau.
Ajustement du tableau Aldébaran
La rétrospective se finit par la célébration de fin de sprint, comme il se doit.
Dans le prochain épisode MyProjectStuff, c’est bientôt l’heure de la réunification des deux équipe Aldébaran et Véga : entre couloirs, classes de service et allocation de capacité.
