Publié par

Il y a 7 ans -

Temps de lecture 5 minutes

Mesurer la Prédictibilité en Kanban – Part I : Le Cycle Time

La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations.

Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système kanban à produire des métriques permettant une visibilité forte sur la capacité des équipes projet à tenir leurs promesses.

Une des métriques les plus intéressantes reste sans conteste la prédictibilité, dont vous pouvez retrouver un retour d’expérience dans l’excellent article de Yannick Quenec’hdu « La Prédictibilité au pays de kanban« .

La prédictibilité est mesurable via deux métriques, le Cycle Time et le Débit des Cartes.

Dans cette première partie, je vous propose une description du calcul de la prédictibilité de votre projet, au travers du Cycle Time.

Le Cycle Time

Le Cycle Time, aussi appelé «Temps de Cycle», permet de mesurer la durée nécessaire à la réalisation d’une fonctionnalité, en partant des travaux d’ingénierie jusqu’à sa validation, en passant par la phase de tests.La date de démarrage du Cycle Time est la date de passage vers les activités d’ingénierie. La date de fin est la date à laquelle la fonctionnalité a été validée, selon la « Définition de Terminé » (Definition of Done).

Exemple :

  • Etant donné un développeur devant réaliser la fonctionnalité « En tant que client, je dois m’authentifier afin d’accéder à mon compte dans l’application www.myprofil.fr » ;
  • Lorsqu’il prend en charge le développement au 09 Juillet 2013
    Et que la fonctionnalité est validée le 15 Juillet 2013 (selon la Définition de Terminé) ;
  • Alors le Temps de Cycle (Cycle Time) est de 5 jours.

Le Cycle Time moyen, sur une période, est obtenu par la somme de tous les Cycle Times de la période, divisée par le nombre de fonctionnalités concernées.

Exemple :

  • Cinq (5) fonctionnalités ont été réalisées, sur une somme de Cycle Time de 31 jours.
  • Cycle Time Moyen = 31/5 = 6,20 jours/fonctionnalité.

La Prédictibilité par le Cycle Time

La force d’un Management Visuel et d’un processus Kanban est de permettre une mesure de la prédictibilité d’une équipe, au travers des éléments suivants :

cycle-time-01

3 niveaux de Prédictibilité sont mesurables dans un projet IT :

  • Niveau 1 : Temps nécessaire à la réalisation des Stories restantes ;
  • Niveau 2 : Temps nécessaire à la réalisation des potentielles anomalies issues des Stories restantes et du ratio d’anomalies générées par Story Done.
  • Niveau 3 : Temps nécessaire à la réalisation des anomalies restantes.

Ces 3 niveaux sont représentés par les formules suivantes :

Ces 3 niveaux sont associés afin de permettre la mesure de la prédictibilité d’un projet IT, au travers de la formule suivante :

cycle-time-03

A partir de cette formule, nous pouvons définir le nombre de mois nécessaires à la réalisation des Cartes restantes, Stories et Anomalies, avec une estimation du nombre de nouvelles anomalies pouvant potentiellement apparaitre et basé sur le Ratio.

De là, à partir de la date de mesure de la prédictibilité, de la date de fin de Release fixée (TTM : Time To Market), nous obtenons la date d’atterrissage estimée et ainsi le nombre de jours d’écart qui sera positif si la date d’atterrissage est inférieure au TTM et négatif dans le cas contraire.

Ci-dessous un exemple de calcul de prédictibilité par le Cycle Time :

cycle-time-04

La mesure de la prédictibilité par le Cycle Time est un élément important dans l’estimation du temps nécessaire à la réalisation des Cartes Kanban restantes, une aide à la priorisation et à la prise de décisions, dont l’objectif reste de permettre à l’équipe Kanban de tenir ses promesses. Néanmoins, il peut arriver que la mesure de la prédictibilité par le Cycle Time soit faussée, pour les raisons suivantes :

  • Mesure des cycle times réalisée de façon non rigoureuse ;
  • Cartes Kanban se retrouvant bloquées en phase de développement en raison de problèmes techniques ou d’adhérences externes ;
  • Tout autre blocage non imputable à l’équipe de développement.

Dans l’exemple suivant nous pouvons vérifier l’impact d’une mesure faussée du cycle time, que ce soit sur les Stories que sur les Anomalies.

  1. La prédictibilité précédente mesurée correspond à celle incluant les perturbations rencontrées dans le traitement des Stories et des Anomalies et fournissant un retard de 21 jours estimé ;
  2. La nouvelle mesure de prédictibilité va porter sur un cycle time des Stories et des anomalies, auxquels les jours de blocage ont été retirés.

cycle-time-05

Nous constatons un écart de 4 jours entres les deux mesures.

Conclusion

La prédictibilité par le cycle time est un outil puissant dans la mesure de la capacité d’une équipe à tenir ses promesses. Elle est une aide forte à la prise de décisions.

Néanmoins, celle-ci se doit d’être utilisée avec discernement et tenir compte des perturbations pouvant influer sur son résultat.

Une analyse reste toujours nécessaire afin d’identifier les causes ayant permis d’obtenir cette mesure et l’impact des perturbations sur celle-ci.

Les mesures présentées dans cet article sont issues d’un projet réel. Les perturbations rencontrées l’ont été sur une instabilité de l’environnement de développement au démarrage du projet. Cette instabilité a été résolue au bout de 2 à 3 semaines, ce qui a permis de débloquer les cartes en attente et également de réduire le cycle time par la suite. C’est sur la base de ce constat qu’il a été décidé de mesurer non pas un nombre de jours d’avance ou de retard, mais une tendance. Dans ce cas précis, la tendance affichée, avec ou sans perturbation est un potentiel retard par rapport à la date de fin de Release fixée, mais qui reste absorbable, soit par une purge des cartes non prioritaires sur cette Release, soit par un renfort raisonnable de l’équipe de développement.

Cet article vous a décrit une manière de mesurer la prédictibilité de votre projet, au travers du Cycle Time. Dans la seconde partie, je vous présenterez comment effectuer une mesure de prédictibilité au travers du débit des cartes kanban.

Publié par

Publié par Couthaïer Farfra

18 années d’expériences, dont 14 années en pilotage et direction de projets Mainframe et NTIC (Forfait, Assistance Technique, TMA, Centre de Services). Depuis 2009, j'ai découvert avec enthousiasme le monde de l'agilité, au travers de la réalisation de projets IT Scrum ou je suis intervenu en tant que Scrum Master et Consultant Agile (Crédit Agricole S.A., GENERALI, Banque de France, CNSA). En 2012, j'ai rejoins la société XEBIA ou j'interviens en tant que Consultant et Formateur (BI-SAM ; Voyage SNCF.com ; SFR ; Française Des Jeux ; Europcar ; AXA) sur les pratiques Agile et plus particulièrement le Kanban.

Commentaire

9 réponses pour " Mesurer la Prédictibilité en Kanban – Part I : Le Cycle Time "

  1. Publié par , Il y a 6 ans

    Salut,
    Merci pour cet article, ça donne à réfléchir. Cependant, je trouve étrange de diviser la somme des cycle times par le nombre de jour que peut produire l’équipe : le cycle time inclut le temps que la carte passe à attendre que quelqu’un soit disponible pour la prendre à l’étape suivante. Si l’équipe QA est surbookée et qu’elle a dû faire attendre une carte 3 jours, cela fait partie du cycle time. Mais personnes n’a effectivement travaillé sur cette carte pendant ce temps là. Donc aucune charge n’a été consommée.

    Est-ce que j’ai mal compris le calcul ?

  2. Publié par , Il y a 6 ans

    Bonjour Antoine,

    Merci pour ton commentaire.

    Le cycle time inclus effectivement les temps d’attente, sur la phase de réalisation et de test de la carte kanban.

    Le temps d’attente, inclus dans le cycle time moyen, représente pour moi le gaspillage réalisé sur la réalisation d’une carte, mais également les perturbations que rencontre le système (équipe QA bloqué par exemple).

    Je pense qu’il est intéressant de tenir compte de cet élément dans la mesure de la prédictibilité, car elle permet d’apporter une image plus réaliste de ce que l’équipe Delivery est capable de produire, avec sa charge disponible (depuis cet article, j’ai fait évoluer la formule pour utiliser plus un nombre d’ETP-Equivalent temps plein, qu’une charge), en tenant compte des perturbations et des gaspillages affectant le temps de réalisation d’une carte.

    Comme je l’indique, dans mon article, la prédictibilité affiche une tendance et doit ensuite faire l’objet d’une analyse plus approfondie, afin d’identifier les éléments de perturbation les gaspillages et les actions d’améliorations pouvant être mis en oeuvre.

    J’espère avoir répondu à tes interrogations.

  3. Publié par , Il y a 6 ans

    Et merci pour ta réponse !

    Effectivement, je pense qu’il est très intéressant de prendre en compte tous ces aléas et le Cycle Time les comptabilise bien. Donc le Cycle Time est un mix de jours effectivement travaillés et de jours de « gaspillage ».

    Cependant, on divise un nombre mixant ces deux types de jours par des jours travaillés, efficaces. Du moins c’est comme ça que je comprends la charge.

    Si je prends un exemple simplifié à l’extrême pour illustrer cela : une équipe a un projet de 10 « tickets » à traiter (stories + anomalies). On imagine que chaque ticket prend 20 jours dont 10 jours en attente de l’étape suivante et 10 jours de « travail effectif », soit un total de 200 J de cycle time, mais seulement 100 J.h. Une équipe de 5 personnes a traité ces tickets en 1 mois.

    Si je me sers de cet historique pour estimer le sprint suivant qui fait aussi 10 « tickets », je vais donc calculer, en comptant 20 jours dans le mois : T * N / C = (20 * 10) / ( 5 * 20) = 2. Donc je calcule que mon prochain sprint prend 2 mois, alors que le précédent, identique a pris un mois.

    Est-ce que je fais une erreur dans mon raisonnement ?

  4. Publié par , Il y a 6 ans

    Antoine,

    L’exemple que tu présentes est effectivement poussé à l’extrême :).

    Il est difficile de répondre au problème posé comme cela. S’agit-il d’un état factuel d’un projet réalisé ou une vue de l’esprit ? La formule proposée se base sur un état factuel, reposant sur une mesure du CT moyen sur les Stories et sur les anomalies et sur une composition d’équipe sur un mois.

    Autre point à prendre en compte. Le CT expliqué dans cet article est celui mesuré sur l’étape Delivery jusqu’au Done et non celui pris du démarrage du WIP jusqu’au Done, c’est pour cela que je tiens compte du nombre de personne intervenant sur la phase de développement.

    La formule n’est peut-être pas encore « parfaite », elle permet néanmoins de mesurer une tendance et d’aider à une prise de décision. Elle doit également être complétée par une mesure de la prédictibilité par le débit, qui par expérience de révèle plus pertinente.

    C’est un sujet encore « jeune » qui reste à affiner, challenger et sujet de nombreuses discussions passionnées dans la communauté. Nous sommes d’ailleurs en cours d’étude pour encore améliorer cette mesure et la rendre plus efficace, tout en supprimant cette notion de j.h.

    Couthaïer.

  5. Publié par , Il y a 5 ans

    Bonjour,
    comment calcul-t-on la capacité en heure de l’équipe projet ?
    Merci

  6. Publié par , Il y a 5 ans

    Comme je reçois des notifications pour ce post, j’en profite pour répondre :o)

    À mon sens il ne faut pas la mesurer : elle est en fait variable d’une semaine à l’autre en fonction des imprévus, des congés, du temps passé sur des tâches autres que le développement, etc… De plus, il n’y pas de lien démontré entre le nombre d’heures que peut passer l’équipe sur un sujet et la date de livraison : la productivité peut varier énormément et on se rend compte que très souvent, la majorité du temps de cycle est en fait passé à attendre que de la capacité se libère.

  7. Publié par , Il y a 5 ans

    Bonjour Abou,

    La capacité d’une équipe est un rapport entre un volume d’éléments produits (nombre de user stories, nombre de points de complexité, …) et une unité de temps (cadence kanban, sprint, semaine, mois, …). De ce fait, l’unité de mesure de la capacité est forcément un rapport (points de complexité /sprint, nombre de story / semaine, …) et pas simplement des heures.

    Pour mesurer cette capacité il suffit donc de compter régulièrement les éléments qui sortent du processus sur lequel on souhaite calculer cette capacité, puis de faire ce rapport.

    Si on prend l’exemple d’un systeme kanban présentant le processus suivant :

    Ecriture des US | Rédaction des tests | développement | tests | en attente de mise en prod

    pour calculer la capacité de l’équipe on va compter toutes les semaines le nombre d’US qui arrivent dans l’état « en attente de mise en prod ».

    Semaine 1 : 4 US
    Semaine 2 : 6 US
    Semaine 3 : 5 US

    Dans ce cas notre équipe à une capacité moyenne de 5 US / semaine. Cette information nous permet alors de faire des projections. Ainsi, s’il reste 50 US à produire pour boucler notre périmètre fonctionnel nous pouvons dire qu’il nous faudra 10 semaines pour y arriver.

    En Scrum la capacité de l’équipe s’appelle la vélocité.

  8. Publié par , Il y a 12 mois

    Bonjour,

    L’image « cycle-time-02 » semble manquante dans l’article, ce qui nuit à sa compréhension.
    Vous est-il possible de la remettre ?

    Merci !

  9. Publié par , Il y a 12 mois

    Bonjour,
    L’image a été réintégrée. Bonne lecture.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.