Relations entre temps de cycle et vélocité
Auteur : George Dinwiddie (@gdinwiddie)
Source : Relationship of Cycle Time and Velocity
Date : 10/12/2014
Traducteur : Fabrice Aimetti
Date : 15/12/2014
Traduction :
Je vois parfois des heurts entre les partisans de Kanban et leurs homologues Scrum. Malgré les désaccords, ces deux approches tendent vers les mêmes objectifs et utilisent de nombreuses techniques similaires. Karl Scotland et moi-même avons mené quelques analyses des causes racines sur les pratiques il y a quelques années et nous en sommes venus à la conclusion qu'il y avait beaucoup de similitudes entre Kanban et Scrum [comme le modèle itératif de l'agilité] vu sous cet angle. J'ai aussi remarqué que, bien que Scrum se concentre explicitement sur les itérations comme un mécanisme de contrôle, les équipes Scrum ont tendance à avoir des ennuis lorsqu'elles ignorent le travail en cours (NdT : le TAF - Travail à faire comme dirait Claude Aubry). Inversement, alors que Kanban se concentre explicitement sur le travail en cours, les équipes Kanban ont tendance à avoir des ennuis lorsqu'elles ignorent la cadence.
Une récente conversation twitter, à laquelle j'ai participé, était centré autour des sujets Temps de Cycle et Vélocité. Puisque ce sont de vieux sujets, j'ai pensé qu'il serait utile de les décrire plus en détail. Encore une fois, je trouve qu'il y a plus de similitudes que de différences entre Kanban (qui utilise le Temps de Cycle) et Scrum (qui utilise la Vélocité) pour prédire à quel moment une quantité donnée de travail sera finie, ou quelle quantité de travail sera finie dans une période donnée.
Le Temps de Cycle est le temps qu'il faut à une seule unité de travail pour progresser d'un point identifié dans la chaîne de valeur à un autre point. Puisque que le terme est apparu dans l'industrie manufacturière, on suppose que les unités de travail sont sensiblement identiques, et que la variabilité du temps de cycle est faible. Le concept suggère également que quelqu'un peut a priori facilement produire plusieurs unités en parallèle, ce qui augmente la capacité de production et diminue le temps de cycle moyen d'un facteur égal au nombre de flux parallèles (en supposant que ces derniers ont la même efficacité). Ces hypothèses peuvent fonctionner dans le domaine du savoir ainsi que dans le développement logiciel, mais nous devons veiller à ne pas les enfreindre.
La Vélocité est la quantité de travail qui peut être accomplie dans une unité de temps donnée. La vélocité est souvent exprimée en "points de story" qui prennent en compte la difficulté perçue dans une story. Cela ajoute généralement beaucoup de bruit dans les données et mesures, si bien qu'il vous semblera probablement et finalement plus facile de travailler en nombre de stories. C'est encore mieux si nous pouvons découper nos User Stories jusqu'à ce qu'elles soient à peu près de taille égale, et que nous les appelions toutes des stories "à un point". Même si vous estimez les stories pour votre reporting, vous pouvez également facilement enregistrer le nombre de stories. Si nous disposons de plusieurs équipes pour produire plusieurs unités en parallèle, alors les vélocités (en nombre de stories) peuvent être ajoutées pour donner la capacité globale. Par contre, je ne recommande pas du tout d'ajouter les points de stories réalisées par plusieurs équipes.
Étant donné que le Temps de Cycle est le Temps par unité de Travail, et que la Vélocité est un Travail par unité de Temps, en ajustant les unités nous constatons qu'elles sont les réciproques l'une de l'autre. Elles sont reliées de la même manière que la longueur d'onde et la fréquence en physique.
Si notre temps de cycle moyen est de 2,5 jours par story, alors la vélocité pour une cadence de deux semaines (10 jours ouvrés) est de 4. De même, si une équipe produit 15 stories en 10 jours ouvrés, alors le temps de cycle vaut 2/3 d'une journée.
Pour la plupart des prises de décision, les gens utilisent le temps de cycle moyen plutôt que le temps de cycle de chaque unité de travail. La vélocité sera toujours une moyenne sur toute la longueur d'un sprint, au minimum. Vous pouvez, bien sûr, mesurer les temps de cycle de chacune des stories. Cela permettra de calculer ou d'estimer en gros la variabilité.
On m'a demandé pourquoi je voudrais faire une telle conversion. J'ai spontanément pensé à quatre raisons :
- Pour regarder une situation sous un angle différent afin de prendre conscience de certaines choses.
- Pour comprendre quelqu'un qui évoque un contexte différent.
- Pour travailler avec des organisations en partant de là où elles en sont, plutôt que d'attendre qu'elles se conforment à mes préférences.
- Pour réfléchir en utilisant les données qui sont disponibles, plutôt que d'attendre de recueillir des données différentes.
Je ne me soucie guère du framework utilisé par un tel ou tel autre, mais je me soucie qu'ils tirent avantage de son utilisation. Parfois, cela nécessite d'emprunter des concepts à un autre framework pour comprendre ce que vous voyez ou pour faire les ajustements nécessaires.
