Kanban : définition du Lead Time et du Cycle Time

((/dotclear/public/photos/.photo-stefan-roock_t.jpg|Stefan Roock|L|Stefan Roock))Lorsque j’ai présenté ++[avec Claude et Antoine « Kanban et Scrum : tirer le meilleur des deux »|/dotclear/index.php?post/2010/10/21/Retrospective-de-l-Agile-Tour-2010-Toulouse]++, nous avons écrit sur les slides de notre présentation le terme « Lead time » et à l’oral j’ai parlé de « Cycle time ». J’incarnais le personnage du « Kanban », et dans le feu de l’action je pense avoir utilisé ces deux termes à tort et à travers, ce qui n’a pas forcément aidé les participants à bien comprendre la distinction… mea culpassima même si le public ne semble pas m’en avoir tenu rigueur. Avec ce weekend pluvieux de novembre, j’en ai donc profité pour traduire l’article de Stefan Roock ++[« Kanban: Definition of Lead Time and Cycle Time »|http://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/|en]++ qui a le mérite de bien remettre les choses à plat et très simplement.%%% > Quand vous utilisez Kanban pour le développement de logiciels, mesurer le lead time$$NdT : on dit aussi délai de livraison$$ et le cycle time$$NdT : on dit aussi temps de cycle$$ est important, mais souvent les termes sont confondus ou définis de manière floue. Voici une ++[définition utile tirée du blog « Lean and Kanban »|http://leanandkanban.wordpress.com/2009/04/18/lead-time-vs-cycle-time/|en]++ :%%% > %%% >  »L’horloge du lead time démarre lorsque la demande est faite et se termine lorsqu’elle est satisfaite. L’horloge du cycle time démarre lorsque le travail sur la demande commence et se termine lorsque la solution est prête à être livrée. Le cycle time est une mesure plus mécanique de la capacité d’un processus. Le lead time est ce que le client voit. »%%% > %%% > Jetons un coup d’œil plus attentif et supposons que nous travaillons avec Kanban dans une équipe de maintenance. Les bogues sont signalés via les tickets ouverts dans un système de suivi de tickets comme Bugzilla, Jira ou Mantis. Lorsque le bogue est détecté, un ticket est créé et lorsque la correction est livrée, le ticket est fermé.%%% > %%% > ((/dotclear/public/traductions/sr_leadtimes1.png|sr_leadtimes1.png))%%% > %%% > La période de temps totale est appelé le  »lead time ».%%% > %%% > ((/dotclear/public/traductions/sr_leadtimes2.png|sr_leadtimes2.png))%%% > %%% > Le lead time représente un délai et non un effort. Vous pouvez avoir un lead time de 100 jours et seulement 1 heure de travail pour corriger le bogue.%%% > %%% > Un jour donné, vous commencez à travailler sur le bogue. Le  »cycle time » est le délai qui s’écoule entre le début des travaux jusqu’à ce que la correction soit déployée.%%% > %%% > ((/dotclear/public/traductions/sr_leadtimes3.png|sr_leadtimes3.png))%%% > %%% > De même, le cycle time ne mesure pas un effort. Le lead time ne peut pas être plus court que le cycle time. Le lead time est souvent beaucoup plus long d’ailleurs.%%% > %%% > Dans le cadre de la maintenance, il y a souvent des SLA ( »Service Level Agreement »$$NdT : Accords sur des niveaux de services ou Engagements de services$$) qui sont en place et qui définissent dans quel délai maximum vous devez corriger un bogue. Souvent, le SLA définit également un délai de résolution. C’est la même chose que le lead time :%%% > %%% > ((/dotclear/public/traductions/sr_leadtimes4.png|sr_leadtimes4.png))%%% > %%% > La plupart des SLA définissent également un délai de réponse. C’est-à-dire le délai maximum sous lequel l’équipe doit répondre suite à l’ouverture d’un ticket pour signaler un nouveau bogue : est-ce vraiment un bogue et quelle est sa priorité.%%% > %%% > ((/dotclear/public/traductions/sr_leadtimes5.png|sr_leadtimes5.png))%%% > %%% > Avec ces définitions, il devient évident que le lead time concerne ce qui est pertinent du point de vue métier/client. Le cycle time est ce sur quoi l’équipe peut avoir de l’influence en changeant son processus de travail. Pour réduire le lead time, on peut (et doit) réduire le cycle time. Mais si, comme souvent, le délai qui court avant le démarrage des travaux est très long, alors on doit également chercher à réduire ce temps d’attente.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Une réflexion au sujet de « Kanban : définition du Lead Time et du Cycle Time »

  1. Claude AubryA mon avis, ton autocritique n’est pas nécessaire. Notre présentation n’était pas confinée à la gestion de tickets en Kanban, mais bien plus générale.
    L’article est clair, mais ce qui y manque, ce sont les états d’un ticket (le workflow). Avec ces états, on voit mieux sur quoi peut porter un engagement. Par exemple, il me paraitrait plus logique que le SLA sur une résolution ne commence pas à la création du ticket, mais à son acceptation (il peut être nécessaire de dialoguer pour éclaircir le problème du client s’il s’est mal exprimé dans le ticket).

Laisser un commentaire

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