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.