Burn up/down Chart, Velocity, Cycle Time, Cumulative Flow Diagram, Process Cycle Efficiency

Vous utilisez déjà un tableau Kanban pour votre projet Agile. C'est bien. Mais pour le piloter, il va vous falloir des éléments concrets, comme des métriques. Dans ce post, je vais présenter les principales métriques utilisées pour l'amélioration de la fluidité du board. Dans d'autres posts, j'aborderai les métriques plus techniques du logiciel ou encore les métriques plus liées à l'ambiance de l'équipe.

Les métriques présentées sont les Burn Up charts, les Burn Down charts, la vélocité, le temps de cycle, le Cumulative Flow et le Process Cycle Efficiency. Chacun ont leur intérêt et permettent de répondre à des questions bien précises.


Burn up/down Charts

Les burn charts existent en deux variantes :

  • le burn-up chart : il représente la quantité de travail effectuée - il s'élève donc vers la cible
  • le burn-down chart : il représente la quantité de travail restant à faire - il descend donc vers zéro

Les burn charts permettent de s'assurer que l'équipe fait avancer les tickets tout au long du processus. Ils mettent en évidence les moments où l'équipe accumule du travail non terminé, permettant ainsi de chercher à en identifier les causes.

Ils permettent :

  • d'ajuster les limites WIP afin de fluidifier le flux continu de tickets,
  • d'identifier les irrégularités dans le flux de tickets et dans leur traitement
  • de visualiser le travail de l'équipe

 

Vélocité ("Velocity")

La vélocité permet mesurer le travail produit par l'équipe à chaque itération.

La vélocité ("velocity") représente la quantité de travail réalisée par itération. Contrôler cette vélocité permet d'améliorer la prédictibilité de la planification.

Il repose sur plusieurs conditions :

  • Les itérations sont limitées dans le temps ("time-boxed").
  • Les itérations sont de longueur fixe.
  • Les productions de chaque itération ("increments") sont prêts à aller en production ("definition of done").
  • Les tickets ("User Stories") sont estimés en terme d'effort ou ils sont de taille similaire - auquel cas la mesure peut porter simplement sur le nombre de tickets.
  • La composition de l'équipe reste à peu près constante.

La vélocité est une mesure spécifique à chaque équipe. Cette valeur ne peut donc pas être comparée avec celle d'une autre équipe. Sa valeur est basée sur l'observation empirique de sa performance dans le passé récent - donc de la réalité. Elle est donc inconnue - ou non fiable - dans les toutes premières itérations. C'est au bout de la 3ème ou 4ème itération que la valeur de la vélocité commencera à être stable.

 

Temps de cycle ("Cycle Time")

Le temps de cycle ("Cycle time") permet de mesurer le temps moyen pour terminer un ticket. C'est un excellent outils pour mettre en évidence les opportunités d'amélioration des pratiques de l'équipe.

Vous devez avoir deux objectifs sur le temps de cycle.

Le premier est de réduire les variations de temps de cycle. Sa constance permet de réduire le gaspillage. Le second est de réduire sa valeur, ce qui permet d'augmenter la débit, et donc le délai de mise sur le marché.

 

Diagramme de Flux Cumulatif ("Cumulative Flow Diagram")

Le Cumulative Flow permet de représenter visuellement la fluidité du travail, afin de réduire les goulots d'étrangement.

Il permet de représenter visuellement le débit, le délai d'exécution, le temps de cycle, la taille de la file d'attente et le travail restant. Plus une région du graphe devient plus large, plus il y a un goulot d'étranglement dans le process.

L'interprétation du Cumulative Flow permet d'identifier des périodes de ressources insuffisantes perturbant le travail de l'équipe. Il permet aussi d'identifier de possibles phénomènes de "bus number", se produisant quand les tickets sont en attente de compétences rares. Il permet enfin d'identifier les limites WIP les mieux appropriées. Un WIP trop élevé conduit à l'accumulation de travail inachevé. Au contraire, un WIP trop faible conduit à un débit irrégulier. Il faut donc trouver le juste milieux.

Selon la Théorie des Contraintes, chaque système a au moins une contrainte (goulot d'étranglement). Pour exploiter les résultats du Cumulative Flow, on utilise le principe des cinq étapes de focalisation :

  • Identifier la contrainte.
  • Le Cumulative Flow permet de l'identifier.
  • Elle apparaît comme une bande étroite avec une large bande juste devant elle.
  • Exploitez la contrainte : elle définit le rythme de l'ensemble du process.
  • Assurez-vous que toutes les ressources nécessaires sont à leur capacité maximale.
  • Tout retard au niveau de la contrainte provoque un retard dans tout le process.
  • Pour absorber les retards, vous pouvez utiliser des files d'attente entre les étapes.
  • Subordonnez le processus à la contrainte.
  • Evitez que les autres étapes du processus ne fonctionnent plus vite que la contrainte. Pour cela, vous pouvez créer un WIP.
  • Augmentez la capacité de la contrainte.
  • Analysez les causes premières.
  • Faites des changements dans votre process, sur l'allocation des ressources ou sur les pratiques techniques).
  • Répétez.

 

Process Cycle Efficiency

L'Efficacité du Cycle de Processus ("Process Cycle Efficiency") mesure la proportion de temps pendant lequel on crée de la valeur par rapport au temps d'exécution total. Il permet d'identifier où on perd du temps pour une activité sans valeur ajoutée, autrement dit les temps d'attente ou les coûts en temps des changements de contexte par exemple.

En d'autres termes, le PCE permet de mesurer la proportion de jours de travail effectifs sur un ticket par rapport au délai total du traitement du ticket. C'est donc le rapport du nombre de jours pendant lesquels l'équipe a effectivement travaillé sur le ticket sur le Cycle Time. Pour information, sa valeur habituelle dans l'industrie est de l'ordre de 10 à 15%, avant d'être optimisé.

Le PCE repose sur la Loi de Little, issue de la Théorie des files d'attente, qui dit que le nombre moyen de clients dans un système stable est égal à leur fréquence moyenne d'arrivée multipliée par leur temps moyen passé dans le système.

 


Maintenant vous avez tous les outils en main pour pouvoir mieux piloter le board Kanban de votre projet. Il ne vous reste plus que les données à mettre en input de ces outils. Vous pouvez utiliser des outils informatiques comme JIRA ou TFS, ou encore utiliser un simple fichier Excel traçant l'historique et produisant des mesures et des graphes. A vos tableurs !


Pensées pour mieux produire

Soyez prévenu dès que mon livre "Pensées pour mieux produire" sera disponible à la vente !

DevOps, Agile, Scrum, Kanban, XP, SAFe, LeSS, Lean Startup, Lean UX, Design Thinking, Craftmanship, Management 3.0, ...

 

Bruno Delb

Agile Coach and DevOps, with an experience in the Medical Device software domain, Management 3.0, Agile games and development (especially on mobile) are my passion.

Search

Ads