Flux – Découvrir les problèmes et les gaspillages en Kanban

[((/dotclear/public/photos/.michael-dubakov_t.jpg|Michael Dubakov|L|Michael Dubakov))|/dotclear/public/photos/michael-dubakov.png]J’ai traduit un billet intéressant de Michael Dubakov ++[« Flow. Discover Problems and Waste in Kanban »|http://www.targetprocess.com/blog/2010/02/flow-discover-problems-and-waste.html|en]++.%%% > Vous ++[kanban-isez votre processus de développement|http://www.targetprocess.com/blog/2009/10/our-development-process.html|en]++ et mettez en œuvre un ++[flux parfait|http://www.targetprocess.com/blog/2009/10/how-do-we-use-kanban-board-the-real-example.html|en]++. 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) :%%% > [((/dotclear/public/traductions/.flow3_weekend_m.jpg|Flux d’une user story complexe||Flux d’une user story complexe))|/dotclear/public/traductions/flow3_weekend.jpg]%%% > 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 ;-)%%% > [((/dotclear/public/traductions/.flow2_weekend_m.jpg|Flux d’une user story simple||Flux d’une user story simple))|/dotclear/public/traductions/flow2_weekend.jpg]%%% > %%% > 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.%%% __Feedbacks :__%%% * Blog Agile Gardener de Tremeur Balbous : ++[« Mettre de la pression sur le système pour faire apparaître le gaspillage »|http://www.agilegardener.com/2010/03/11/mettre-de-la-pression-sur-le-systeme-pour-faire-apparaitre-le-gaspillage/|en]++

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *