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.
Sommaire
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 cours / 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
Cela nous dit que pour les nouvelles unités qui entrent dans le système, il faudra en moyenne 2 semaines avant que chacune d’elles ne soit terminée.
Ce que vous voyez ici, c’est que notre débit est le même, nous livrons toujours la même quantité, mais en réduisant le travail en cours, nous sommes en mesure de fournir la même quantité en un temps plus court, et dans le souci d’avoir plus d’agilité, un temps de cycle plus court nous permet de changer de direction plus tôt. Moins de travail en cours n'augmente pas notre débit, mais cela nous rend plus efficaces et plus adaptables au changement.
Moins vous avez de travail en cours, plus vite il sera terminé.
Yorke’s motto
En substance, moins vous avez de travail en cours, plus vite cela sera fait, c'est la leçon à tirer de cela.
Cependant, il devient désormais possible de réduire le travail en cours à un point tel que le débit est impacté (le système peut tomber en famine), ce qui crée une négociations.
Dans certaines situations, le temps de cycle est un facteur critique, il est donc souhaitable de disposer d'un peu de temps de mou, par exemple en cas de besoin urgent de voir un médecin, par rapport à un rendez-vous régulier. Mais dans la plupart des autres cas, nous voudrions limiter notre WIP autant que possible sans impacté le débit.
D'autres termes moins utilisés
Nous abordons ensuite les termes amusants. Ces termes proviennent de l'industrie manufacturière, mais sont beaucoup moins utilisés dans un contexte logiciel, mais il peut être utile de les connaître, car ils peuvent aider à comprendre la composition du temps de cycle et les endroits où vous pouvez agir pour tendre votre processus.
- Temps de traitement
- C'est le moment où quelqu'un travaille à la création de quelque chose : rédaction de code, documents, conception, tests, etc.
- Temps de déplacement
- En termes de logiciel, cela correspond au temps nécessaire pour passer d'un utilisateur à un autre ou d'une action à une autre, cela inclut donc la compilation, le packaging, le déploiement et le partage de connaissances.
- Temps d'inspection
- Il peut s’agir du temps de la QA ou des revues de code, de la démonstration aux Product Owners ou aux parties prenantes, mais cela peut aussi correspondre au temps de traitement car il s’agit toujours d’un travail à valeur ajoutée.
- Temps d'attente
- C'est le moment où une unité (story / tâche) est en cours mais non traitée, par exemple bloquée ou en attente de revue de code, en attente de QA, en attente de démonstration, chaque fois que le travail est suspendu pour une raison quelconque avant de le terminer.
- Temps d'attente
- C’est le temps qu’une demande passe dans le backlog avant que nous nous engagions à y travailler, par exemple le moment où un client identifie une fonctionnalité / un bogue jusqu'à ce que nous commencions à y travailler.
- Temps de valeur ajoutée
- Tout moment dans le système où une activité ajoute de la valeur au produit, donc par exemple ne fait pas la queue, n'attend pas.
Résumé
Le temps de cycle et la loi de Little sont de plus en plus utilisés et, s’ils ne sont pas compliqués à comprendre, ils apportent un nouvel ensemble de termes avec la confusion associée.
Par exemple, j'ai vu plusieurs fois récemment des personnes dire que réduire le temps de cycle augmentait le débit. Mathématiquement parlant, c'est incorrect (bien que l’inverse soit vrai, l’augmentation de débit doit réduire le temps de cycle). De manière anecdotique, moins de changement de contexte augmente le débit. Ce qu’ils conseillent constitue un bon conseil : réduire le WIP. Cependant, leurs attentes et leurs raisonnements sont faux et ajoutent encore à la confusion.
Le temps de cycle n'est pas une mesure de la quantité produite, mais une mesure de sa durée passée dans le système. Il est important de se rappeler que le débit et le temps de cycle sont des mesures différentes.
Le temps de cycle n'est pas une mesure de la quantité produite, mais une mesure de sa durée passée dans le système.
J'espère que cela vous aide et je serais heureux de donner des détails si certaines parties ne sont pas claires.
