Dans mon dernier billet , j'ai parlé des mesures de base du flux (temps de cycle, débit et encours) et j'ai indiqué quelles données vous deviez collecter pour commencer. Maintenant que vous avez les données, comment les transformer en mesures de flux significatives ? Il vous suffit d'apprendre quelques calculs Kanban simples. Dans ce billet, je vais vous expliquer comment calculer le temps de cycle en utilisant les temps de début et de fin des éléments de travail.
Comment calculer le temps de cycle
L'un des calculs Kanban les plus simples à comprendre est le calcul du temps de cycle. Une définition simple du temps de cycle est : La quantité totale de temps écoulé entre le moment où un élément commence et celui où il se termine. Une définition encore meilleure du temps de cycle est : La quantité totale de temps écoulé qu'un élément passe en tant que travail en cours (WIP) - mais nous y reviendrons dans un prochain billet.
Notez l'inclusion du terme "temps écoulé" dans les deux définitions. Pour le temps de cycle, nous ne nous contentons pas de suivre le temps pendant lequel quelqu'un a travaillé activement sur un élément, et nous ne limitons pas arbitrairement le calcul Kanban au temps de travail normal (par exemple, en ignorant les nuits, les week-ends et les jours fériés - apprenez pourquoi ici).
N'oubliez pas que nous calculons les mesures de flux du point de vue du client. Ce qui intéresse nos clients, c'est le temps total écoulé. Avec cette définition, le calcul Kanban du temps de cycle est très simple :
Durée du cycle = Date de fin - Date de début + 1
Vous vous demandez peut-être d'où vient le "+ 1" dans le calcul Kanban ci-dessus ; il s'agit de tenir compte des éléments qui commencent et se terminent le même jour. Voici un exemple : Si vous avez commencé le travail le 15 décembre et l'avez terminé le même jour, alors 15 - 15 = 0. Mais vous ne diriez jamais qu'un article a un temps de cycle de zéro, n'est-ce pas ? Il est certain que votre client ne dirait jamais cela. Logiquement, ce travail a pris un jour pour être achevé - et non zéro jour.
Mais qu'en est-il des articles qui ne commencent et ne se terminent pas le même jour ? Par exemple, disons qu'un poste a commencé le 1e janvier et s'est terminé le 2e janvier. Le calcul ci-dessus donne une durée de cycle de deux jours (2 - 1 + 1 = 2). Il s'agit d'un résultat raisonnable et réaliste, qui a du sens du point de vue du client : Si nous communiquons un temps de cycle d'un jour, le client peut s'attendre à recevoir son article le jour même. Si nous leur disons deux jours, ils ont une attente réaliste qu'ils recevront leur article le jour suivant, etc. Ce n'est qu'une des façons dont les calculs Kanban peuvent vous aider à communiquer avec vos clients.
Temps de cycle : Exemple de calcul Kanban
Pour illustrer le calcul Kanban ci-dessus, revoyons l'exemple de données inclus dans mon post précédent et ajoutons maintenant le temps de cycle calculé :
| ID de l'élément de travail | Arrivée | Départ de | Durée du cycle (jours) |
| 1 | 01/01/2016 | 01/03/2016 | 3 |
| 2 | 02/02/2016 | 03/03/2016 | 31 |
| 3 | 01/02/2016 | 03/04/2016 | 63 |
Si vous effectuez vous-même les calculs ci-dessus, vous devriez obtenir les mêmes réponses que moi. En fait, j'ai d'abord essayé de faire les calculs dans ma tête (ce qui n'est jamais une bonne idée pour moi) et je me suis trompé dans les deuxième et troisième réponses lorsque j'ai vérifié moi-même avec Excel. J'avais oublié que 2016 était une année bissextile !
Vous pourriez vous inquiéter du fait que la façon ci-dessus de calculer la durée du cycle est biaisée en faveur de la mesure de la durée du cycle en termes de jours. En réalité, vous pouvez remplacer les jours par toute notion de "temps" pertinente pour votre contexte. Il peut s'agir de semaines, d'heures ou même de sprints. (Pour une équipe Scrum, si vous vouliez mesurer la durée du cycle en termes de sprints, le calcul serait simplement Fin Sprint - Début Sprint + 1). Le point ici est que ce calcul Kanban est merveilleusement générique pour s'adapter à tous les contextes.
Avantages de la mesure du temps de cycle
Les avantages du calcul Kanban pour le temps de cycle ne peuvent être exagérés. Voici quelques raisons pour lesquelles apprendre à calculer le temps de cycle peut être utile aux équipes qui pratiquent le Kanban :
- Le temps de cycle est mesuré du point de vue du client, ce qui vous donne un langage commun pour parler du moment où un élément sera terminé.
- Il est facile de commencer à apprendre comment calculer le temps de cycle (vous avez probablement déjà toutes les données dont vous avez besoin).
- Le calcul du temps de cycle lui-même est très simple et direct et nous donne une foule d'informations sur la performance globale de votre processus.
- Le temps de cycle calculé nous permet de faire des prédictions significatives sur les temps d'achèvement des éléments individuels (j'expliquerai cela en profondeur dans un prochain billet).
Ce dernier point mérite une petite clarification. C'est très bien d'utiliser le temps de cycle pour faire des prédictions sur l'achèvement d'éléments individuels, mais que faire si nous voulons faire des prédictions sur l'achèvement de plusieurs éléments de travail ? Plus précisément, que se passe-t-il si nous avons 100 éléments dans notre backlog et que nous voulons savoir quand tous les 100 éléments seront terminés ? Pour répondre à cette question, nous devrons utiliser une métrique de flux complètement différente, dont le calcul devra attendre la prochaine fois. Le nom de cette métrique ? Débit.
Comme toujours, vous pouvez en savoir plus sur la façon de calculer le temps de cycle et d'autres calculs Kanban dans mon livre, Actionable Agile Metrics for Predictability.
Merci de nous lire !
Lectures recommandées
Pour en savoir plus sur les calculs Kanban, consultez ces ressources :
- Utiliser les mesures de flux pour livrer plus rapidement
- 7 Mesures Lean pour améliorer le débit
- What is Continuous Improvement?
