Comprendre le temps de cycle dans le logiciel

Auteur : John Yorke
Source : Understanding cycle-time in software
Date : 07/01/2017

---

Traducteur : Fabrice Aimetti
Date : 13/12/2018

---

Traduction :

Le temps de cycle et le Lead Time, et même la loi de Little, sont des termes qui ont migré dans le contexte du développement logiciel et qui sont de plus en plus utilisés, mais je ne suis pas sûr qu'ils soient parfaitement compris, je vais donc tenter de clarifier ma compréhension de ces termes.

Comment le temps de cycle diffère-t-il du lead time ?

Dans l'industrie manufacturière :

J'ai vu deux manières différentes d'exprimer le temps de cycle :

Le "Temps de Cycle" correspond au temps total nécessaire à la création d'un article. Mesuré à partir du moment où le travail commence jusqu'à la livraison de l'article.

ou

Le "Temps de Cycle" est la durée moyenne entre chaque article livré. Par exemple, 7 articles livrés en une semaine représente un temps de cycle de 1 jour.

Le Lead Time semble être cohérent.

Le "Lead Time" correspond au délai écoulé depuis la commande passée par le client jusqu'à la réception de celle-ci.

Remarque : les différentes utilisations du temps de cycle sont source de confusion et je préfère la première description dans un contexte logiciel, car la seconde ignore l'impact du WIP.

Clairement, les deux descriptions sont plus compliquées d'un point de vue logiciel car les limites ne sont pas aussi claires.

Temps de Cycle

Le temps de cycle est généralement considéré comme le moment où un élément du backlog est validé et qu'il est "en cours" dans notre cycle de développement. En termes Kanban, il s'agit probablement du temps compté à partir du moment où il sort de la colonne "backlog". Nous arrêtons de compter quand il est déplacé dans la colonne "fini". Il peut y avoir tout un débat sur ce que "fini" signifie et cela sera le fruit d'un autre billet. Mais pour des raisons de simplicité, le "cycle" prend fin lorsque votre équipe cesse de travailler dessus (idéalement, ce sera dans les mains du client).

En Scrum, le temps de cycle est généralement fixé à une longueur de sprint, nous nous engageons au début du sprint et nous livrons à la fin. Mais ce n'est pas une vérité universelle certaines équipes ne livrent pas toujours et il faudra consacrer des efforts plus tard pour déployer dans le cadre d'une version planifiée, et certaines équipes livrent dès qu'une story est terminée.

Remarque : le Temps de Cycle est parfois appelé délai de livraison. Mais encore une fois, il est confondu avec le lead time en raison de la correspondance non linéaire entre l'industrie manufacturière et le logiciel.

Lead Time

Le lead time est un peu plus compliqué, il peut être compté à partir du moment où un besoin est identifié en premier lieu par un client, jusqu'à ce qu'il soit satisfait, mais il s'agit rarement d'une correspondance bijective, ou alors il peut être envisagé à partir du moment où le besoin est identifié et affiné en un élément du backlog qui sera traité et livré.

Mais, en réalité, pour les backlogs agiles, nous ne travaillons généralement pas de manière linéaire, le simple fait de répondre plus longtemps à une demande ne signifie pas qu’elle sera livrée plus tôt. Nous établissons des priorités et une demande identifiée la semaine dernière peut donc être livrée plus tôt qu'une demande de l’année dernière.

Par conséquent, le Lead Time n’est généralement pas utilisé aussi souvent que le Temps de Cycle, non pas parce que nous ne pouvons pas le mesurer, mais parce qu’il n’est pas aussi significatif et utile.

Débit

Un autre terme souvent utilisé est le "Débit", il s’agit simplement du nombre d’unités ayant traversé le système (unités terminées) dans une période donnée, par exemple, notre débit est de : 10 stories par semaine, ou 5 clients par heure.

Sauf indication contraire, vous pouvez généralement supposer qu'il s'agit d'une période moyenne ou de la période la plus récente.

Loi de Little

Le Temps de Cycle est une mesure de suivi et nous sommes en mesure de générer des indicateurs et des moyennes à partir de l'historique des résultats. Mais un mathématicien du MIT, John Little, a mis au point une formule mathématique pour calculer de manière prédictive le Temps de Cycle à partir du nombre d'unités dans le système.

Temps de Cycle Moyen = Nombre Moyen d'éléments en cours / Débit Moyen

Temps de Cycle Prévu = Nombre d'éléments en cours / Débit Moyen

Temps de Cycle = Travail en coirs / Débit

par exemple, disons que vous avez 50 éléments en cours et que vous en finissez en moyenne 10 par semaine.



Nombre d'éléments en cours (50) / Débit Moyen (10 par semaine)

Temps de Cycle Prévu : 50 / 10 = 5 semaines

Cela nous dit que pour les nouvelles unités qui entrent dans le système, il faudra en moyenne 5 semaines avant que chacune d’elles ne soit terminée.

Si nous voulons réduire le Temps de Cycle, nous avons deux options : nous pouvons soit réduire la quantité de travail en cours, soit augmenter le débit. Notre débit est souvent limité par d’autres facteurs et peut donc être plus difficile à modifier, comme la taille de l’équipe ou la disponibilité des équipements. Mais le travail en cours (WIP) nous donne généralement plus de liberté d'agir.

Disons que nous réduisons le travail en cours à seulement 20.



Nombre d'éléments en cours (20) / Débit Moyen (10 par semaine)

Temps de Cycle Prévu : 20 / 10 = 2 semaines