Flux - Découvrir les problèmes et les gaspillages en Kanban
Auteur : Michael Dubakov
Source : Flow. Discover Problems and Waste in Kanban
Date : 01/02/2010
Traducteur : Fabrice Aimetti
Date : 14/03/2010
Traduction :
Vous kanban-isez votre processus de développement et mettez en œuvre un flux parfait. Vous voyez le flux et ressentez sa puissance. Vous mesurez même le temps de cycle et vous souhaitez le réduire. Mais ce n'est pas aussi facile que prévu. Certains des problèmes de votre processus de développement sont difficiles à trouver et à mettre à jour au niveau de l'équipe. Je vais ici vous décrire une technique intéressante qui peut vous aider.
L'idée est assez simple. Prenez une seule user story et enregistrez ses différents états du début à la fin, ainsi vous visualisez le flux entier d'une unique story. Inscrivez tous ses états sur un axe Y et les jours sur un axe X. Vous obtenez finalement le tableau suivant (cliquez pour agrandir) :
C'est une user story réelle du projet TargetProcess. Elle était assez complexe et son temps de cycle était de 19 jours. Laissez-moi apporter quelques détails.
La user story est restée dans l'état Planifié pendant seulement 1 jour, puis les développeurs l'ont prise et déplacé dans l'état En cours. Jusqu'ici ça va. 4 jours de développement et la user story est déplacée dans l'état Codé, mais elle est resté là pendant 2 jours. Pourquoi ? Pourquoi les testeurs ne l'ont-ils pas tout de suite traitée ? De toute évidence, nous venons de constater 2 jours de retard et le motif du retard doit être trouvé, car cela augmente le temps de cycle de la story.
Ensuite, les testeurs ont testé la story pendant 2 jours. Puis la story a été déplacée dans l'état En cours de nouveau et les développeurs ont travaillé dessus pendant 2 jours de plus (y compris le samedi). Pourquoi ? Cela représente la moitié de la charge initiale de développement. C'est clairement un signe de gaspillage, mais nous avons besoin de plus d'informations. Il apparaît que les testeurs ont trouvé 11 bogues. La moitié des bogues a été causée par une spécification insuffisante de la story, les autres bogues doivent faire l'objet d'une enquête. Nous devrions ici appliquer l'analyse de cause racine (NdT : root-cause analysis) pour trouver les vrais problèmes.
OK. Ensuite, les testeurs ont vérifié la user story pendant 2 jours et l'ont passé dans l'état Prêt à intégrer. Elle a été intégrée assez rapidement (en 1 jour), mais là encore il y a peut-être du gaspillage à éliminer. Finalement, la user story est restée dans l'état Intégrée pendant 5 jours et a été livrée le 29 Janvier.
Au total (et au minimum !) nous avons découvert environ 9 jours de gaspillage. Cela signifie que nous pouvons réduire le temps de cycle de manière significative par l'élimination de ce temps d'attente (gaspillage). Si vous vérifiez plusieurs user stories en utilisant cette technique, je crois que vous trouverez des résultats comparables pour des stories simples et complexes.
Voici un autre exemple avec une user story assez simple. Nous voyons encore clairement apparaître des temps d'attente dans notre flux ! Nous pouvons réduire le temps de cycle à 2 jours au lieu de 6 en éliminant simplement les temps d'attente dans le flux. Mais ce n'est pas facile :)
Ce graphique est un outil très puissant. Il est facile à créer et vous pouvez l'utiliser pour trouver des gaspillages dans votre cycle de développement.
