Lecture d’un cumulative flow diagram

Ce billet a comme objectif d’expliquer mon interprétation du cumulative flow diagram (CFD), un graphique fortement utilisé par les gens qui appliquent la méthode Kanban.

Table des matières

  • Introduction
  • Lire le travail en cours (WIP)
  • Identifier les goulots d’étranglement
  • Lire le lead time
  • Lire le cycle time (temps de cycle)
  • Prédire la fin du projet avec un CFD
    • Option 1 – Utiliser la pente pour la barre Terminé
    • Option 2 – Utiliser le graphique des temps de cycle (Cycle time scatterplot)
    • Option 3 – Générer des probabilités de complétion
  • Ressources

Introduction

Vous démarrez une itération de 2 semaines avec 10 tâches à faire. Ignorer tout le reste (récits, heures, burndown, etc) pour l’instant. Votre itération débute le mercredi. Elle dure 2 semaines, c’est-à-dire qu’elle se termine mardi dans 2 semaines. Votre tableau sur le mur ressemble à ceci le matin de la première journée.

Départ-Tableau1

On peut aussi le voir de la façon suivante. J’ai 10 tâches dans la colonne À faire, 0 tâche dans les colonnes En cours et Terminé:

Départ-Couleurs2

Illustrons ces trois couleurs sur un graphique Cumulative Flow Diagram (CFD). Mon axe des X est le temps. Dans notre exemple, ce sont les jours de l’itération. L’axe des Y représente simplement les items dans mon tableau. J’ai 10 tâches sur le tableau alors je m’attends à voir une barre qui monte jusqu’à 10 sur le graphique. En somme, le CFD ressemble à ceci en cette première journée d’itération:

Départ-CFD3

Nous sommes maintenant le premier vendredi de l’itération. Le tableau des tâches ressemble maintenant à ceci:

Vendredi-Tableau3

On peut voir ce tableau autrement. J’ai 2 tâches dans la colonne À faire, 6 tâches sous En cours et 2 sous Terminé. Visuellement, ça ressemble à ceci:

Vendredi-Couleurs4

Mon CFD m’indique la même représentation en ce premier vendredi de l’itération. Ma barre bleue À faire a une hauteur de 2 items (10 – 8). Ma barre rouge En cours a une hauteur de 6 items (8 – 2) et ma barre verte, Terminé, a une hauteur de 2 (2 – 0) puisqu’il y a deux items dans cette colonne. En prime, j’ai un historique des jours. Jeudi, j’avais 4 tâches dans la colonne À faire, 4 tâches dans la colonne En Cours et 2 tâches dans la colonneTerminé.

Vendredi-CFD5

À la fin de mon itération, toutes mes tâches sont dans la colonne Terminé.

Fin-Tableau22

Je peux le représenter autrement de cette façon:

Fin-Couleurs6

Mon CFD à la fin de l’itération ressemblera donc à ceci:

Fin-CFD7

Mon CFD me permet d’avoir un historique des items qui ont bougé sur le tableau pendant l’itération. C’est le premier avantage comparativement à un sprint burndown.

Noter qu’on est aussi en ligne avec la première propriété de la méthode Kanban: Visualize the workflow.

Lire le travail en cours (WIP)

La deuxième propriété de la méthode Kanban est Limit Work-In-Progress (WIP). Dans l’introduction précédente, nous n’avions pas mis de WIP dans notre tableau. On a donc eu environ 6 tâches sous la colonne En Cours pendant toute l’itération. Le CFD nous le montre à la fin de l’itération.

PasDeWIP-CFD8

Si on avait assigné un WIP de 2 tâches dans la colonne En cours, on aurait alors eu un CFD avec l’apparence suivante:

BonFlux-CFD9

La barre rouge qui représente les tâches En cours ne sera jamais plus épaisse que 2 tâches puisque le WIP de cette colonne est 2 tâches.

Un système Kanban en santé aura de minces barres de couleurs. Lorsqu’une barre de couleur grossit, c’est un indicateur qu’il y a quelque chose de bloqué dans cette colonne. On appelle ça un goulot d’étranglement.

Identifier les goulots d’étranglement

Dans le CFD suivant, j’aurais tendance à fouiller ce qui bloque dans la colonne En cours puisque la couleur rouge commence à prendre trop de place face aux autres couleurs. Dans ce cas-ci, je n’ai probablement pas défini de WIP sur ma colonne En cours.

MauvaisFlux-CFD44

Une fois que l’équipe se définit un WIP pour la colonne En cours, cela ne veut pas dire qu’elle n’aura plus de goulot. Dans le CFD suivant, l’équipe s’est assignée un WIP de 3 pour la colonne En cours. Remarquer que du lundi au mercredi de la première semaine de l’itération, la barre rouge n’a pas monté. L’équipe était bloquée sur ces tâches. Elle a débloqué à la mi-itération lorsque les tâches 5 et les suivantes ont basculé dans la colonne En cours.

GoulotAvecWIP-CFD10

Donc, lorsque la barre (ou les barres) de couleur ne montent plus, c’est un signe que quelque chose est bloqué dans notre système Kanban.

Le CFD nous permet aussi de voir ces goulots d’étranglements sur le long terme. Dans le CFD suivant, il y a eu deux goulots d’étranglements. Puisque la propriété 5 de Kanban nous dit Implement feedback loops, on tiendra sûrement une rétrospective si ces goulots se répètent pour en identifier la cause.

MauvaisFluxLongTerme-CFD11

Lire le lead time

Pour se comprendre face au terme lead time, je vais prendre la définition de la Lean Kanban University:

This refers to the time a item takes to progress through a process, and is often used synonymously with the more specific customer lead time.

À mes yeux, cela veut dire le temps entre lequel je place une demande dans une liste jusqu’à ce qu’elle sorte de mon processus.

Le CFD nous permet de lire le lead time pour chaque demande. Dans notre introduction, toutes nos tâches sont entrées dans notre système Kanban le mercredi, la première journée de l’itération.

La deuxième tâche a donc un lead time de 3 jours. Elle est entrée le mercredi et en ressort lundi (3 jours = jeudi, vend, lundi)

La sixième tâche a un lead time de 7 jours. Elle est entrée elle-aussi le mercredi. Elle est sortie le dernier vendredi de l’itération (7 jours = jeudi, vend, lundi, mardi, merc, jeudi, vend)

LeadTime-CFD12

Dans un système Kanban où de nouveaux items entrent pendant que d’autres sortent, le CFD aura l’apparence suivante:

BonLeadTimeSansTexte-CFD13

Mon lead time pour mes tâches sera:

  • 2 jours (jeudi, vend) pour la 2ième tâche qui entre dans mon processus
  • 3,5 jours (lundi, mardi, merc + 0,5 jours) pour la 8ième tâche qui entre dans mon processus
  • 4 jours (mardi, merc, jeudi, vend) pour la 11ième tâche qui entre dans mon processus
  • 3 jours (jeudi, vend, lundi) pour la 14ième tâche qui entre dans mon processus

BonLeadTime-CFD14

Lire le cycle time (temps de cycle)

La définition du temps de cycle, selon le glossaire de la Lean Kanban University, est:

Most often this refers to the lead time through the “operational” part of the process (measured from when work starts until it is ready to be delivered),

À mes yeux, le temps de cycle est le moment entre l’instant où on se met à réaliser une tâche jusqu’à ce qu’elle sorte du processus. En d’autres termes, c’est le volet opérationnel du lead time.

Revenons au graphique précédent pour y lire le temps de cycle des demandes 2, 8, 11 et 14.

Capture d’écran 2015-08-06 à 09.32.39

On remarque que le temps de cycle est toujours plus petit que le lead time de la demande.

Lead time = Temps d’attente dans le backlog (ou autre queue de priorisation) + temps de cycle

La conclusion est que le lead time et le temps de cycle se lisent de façon horizontale sur le CFD. Le WIP se limit de façon verticale.

Prédire la fin du projet avec un CFD

Bizarrement, j’ai trouvé peu d’information chez les experts Kanban à propos de la reddition de compte lorsqu’on emploie la méthode Kanban. Si on veut utiliser la méthode Kanban comme façon d’exécuter un projet, il faudra s’outiller en conséquence pour informer (et rassurer) les gens qui paient pour le projet.

Option 1 – Utiliser la pente sur la barre Terminé

Dans mon projet, j’ai 10 items à faire. Mon projet commence un mercredi. Les premiers items sont terminés le lundi. J’ai donc une pente de 2 items / jour pour ma zone Terminé (partie verte du graphique ci-bas).

Progression-CFD15

Si je continue cette pente vers la droite, je prédis que mon 10ième item sera terminé vendredi prochain. Cette approche se complique plus le projet avance. Prenons le CFD suivant qui montre un projet qui roule depuis deux semaines. Si le client m’aurait demandé la date de fin du projet à plusieurs moments depuis les deux dernières semaines, je lui aurais donné plusieurs réponses. Mes droites pour ma zone verte change de jour en jour.

MauvaiseProgression-CFD17

Cette première approche pour prédire la fin d’un projet est faible mais au moins, elle permet d’avoir une conversation avec l’équipe.

Plus le projet avance, plus on aura des temps de cycle différents selon les items qui passent par le processus. On peut alors utiliser le graphique des temps de cycle.

Option 2 – Utiliser le graphique des temps de cycle (Cycle time scatterplot)

Ce graphique fait la moyenne des temps de cycle des items qui passent dans le système Kanban. Lorsque le client se demande combien de temps il faut pour réaliser un item, on se sert de ce graphique pour lui donner une idée basée sur l’historique.

Dans le graphique des temps de cycle suivant, l’axe des X représente les items et l’axe des Y est le temps de cycle pour chaque item. C’est vous qui déterminer l’unité de temps (jours, semaine, année-lumière)

On lit le graphique de la façon suivante:

  • L’item #1 (1ière ligne sur l’axe des X) a pris 2 jours
  • L’item #2 a pris 3 jours
  • L’item #3 a pris 3 jours

Sous le graphique, on calcule la moyenne du temps de cycle. Après 20 items, le temps de cycle moyen est de 3.2 jours. Si un client nous demande combien de temps prendra le 21ième item, on utilise ce graphique pour lui donner une réponse.

TempsDeCycleDesDemandes16

Le problème avec le graphique du temps de cycle, c’est qu’il n’est pas possible de savoir quand le Xième élément va sortir du système. Si mon client me demande quand il aura l’item 33, ce graphique ne m’outille pas pour lui donner une réponse.

On peut toujours inverser le temps de cycle. Dans le graphique ci-haut, le temps de cycle est de 3.2 jours/demande. En inversant ce nombre, on obtient 0,3125 demande/jour. S’il me reste 20 demande à faire, j’obtiens une approximation de la date de livraison en divisant 20 par 0,3125. Mon projet sera terminé dans 64 jours.

Option 3 – Générer des probabilités de complétion

Troy Magennis a un ensemble de fichiers Excel pour faire un paquet de calculs avec les données qui sortent d’un système Kanban. Sur son Github, il a le fichier Calculating Throughput and Cycle Time History.xlsx qui permet de générer des scénarios en entrant plusieurs paramètres.

À partir de ce fichier Excel, j’ai placé les chiffres suivants d’un projet Scrum dans lequel je suis Scrum Master.

  • Durée des itérations: 4 semaines (28 jours)
  • Nombre de points: 280 points
  • Vélocité minimale: 20 points
  • Vélocité maximale: 40 points

J’obtiens des probabilités de réussite, c’est-à-dire le niveau de confiance où je compte terminer mon projet. Je suis actuellement à l’itération 8 du projet et on compte le terminer dans l’itération 10.

CalculDeComplétion20

Remplacer les points par le nombre d’items complétés par semaine et on obtient le même type de graphique.

Contrairement au graphique du temps de cycle qui ne peut pas prédire quand le Xième va sortir du système, le fichier Excel fait une simulation pour donner des probabilités pour compléter un projet.

Ressources

Un article de Mike Griffith expliquant comment extraire certaines informations du CFD

Un article pointant vers un CFD dans Google Spreadsheet

Glossaire des mots-clés de la méthode Kanban

Outil pour générer un graphique de temps de cycle

Github de Focused Objectives

Laissez un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s