KANBAN: CFD (Cumulative Flow Diagram)

Important: Cet article n’est pas de moi mais de Cyril Tardieu. Je me suis juste contenté de le traduire de l’anglais au français.

Avec le développement des méthodes agiles, le testeur doit savoir travailler avec de nouveaux indicateurs. Il doit les utiliser pour assurer la qualité sans pour autant exploser les budgets. Le testeur doit garder à l’esprit que les indicateurs ont 2 rôles, conduire l’amélioration continue et prévoir les problèmes futurs.

Dans cet article nous allons nous pencher sur le CFD (Cumulative Flow Diagram) et son utilisation dans le cadre de l’amélioration continue. Ce diagramme est le graphique le plus important en Kanban car il permet de rendre évident les dysfonctionnements et les points sur lesquels il faut concentrer ses efforts. Il montre le nombre de User Story (axe vertical) à tout moment (axe horizontal) depuis le début du projet. Il permet également de raconter l’histoire du projet en voyant l’impact du départ et de l’arrivée de testeurs, de changement de politique de test…

Regardons de plus près ce que l’on peut apprendre de ce graphique :

Le Tester « WIP » montre le nombre de US sur lesquelles le testeur travaille en simultané. Le « Cycle time » montre combien de temps cela prend de tester une US. Ces 2 indicateurs sont particulièrement importants en Kanban car c’est en travaillant sur ces indicateurs que le testeur peut montrer son travail sur l’amélioration continue du flux.

Un WIP élevé signifie que le testeur travaille sur trop d’US à la fois. Il perd probablement du temps en passant des tests d’une US à une autre. Une des best practice du Kanban est de minimiser ce WIP sur le Kanban Board et donc de finir de tester une US avant d’en commencer une autre. Le but est donc d’avoir le plus petit WIP possible.

Un haut Cycle Time signifie que le tester passe trop de temps à tester les US. Pour en savoir plus il faut faire une investigation plus approfondie afin de trouver la cause de ce niveau élevé. Une possibilité est le manque de tests unitaires (et donc une faible qualité) avant l’envoi en test des US. Cela entraine un grand nombre de création de bugs ce qui laisse la US longtemps en Test. Ici aussi le but est d’avoir un Cycle Time aussi faible que possible.

Il n’y a pas d’inquiétude à avoir si les 3 lignes (DEV, TEST et DONE) sont parallèles, en effet cela signifie alors qu’il n’y a pas de goulot d’étranglement.

Sur la figure ci-dessus, les lignes DONE, TEST et DEV s’éloignent les unes des autres. Cela est très mauvais parce que dans ce cas le temps de mise sur le marché est de plus en plus long. Cela signifie que le testeur est dépassé par le nombre de US à tester et que cela empire. Une analyse sur la raison de ce problème doit être faite pour comprendre d’où vient le problème. Mon conseil ici est de travailler plus sérieusement sur les problèmes bloquant des US. Si on ne supprime pas ces problèmes alors les développeurs et les testeurs vont commencer de nouvelles tâches au lieu de finir les autre ce qui est contre la sacro-sainte règle : « Arrête de commencer, commence par finir » (“Stop starting, start finishing”). Dans ce cas il y a de grandes chances que le WIP devienne très vite très grand.

Le scénario du 3ème graphique est probablement le pire pour un testeur. Les DEV semblent très rapides mais les US passent beaucoup de temps en TEST et semblent y être bloquées. Cela veut probablement dire que les DEV poussent les US en test sans faire le moindre test unitaire. Tous les bugs sont alors découverts en test et attendent une correction. Le temps gagné en DEV est perdu en TEST lors de l’attente de la correction des bugs. Des solutions possibles sont d’étendre la couverture de test du code avec les tests unitaires, de faire des revues de code. Il est également possible de remettre en DEV l’ensemble des US bloquées en TEST pour montrer d’où le problème vient vraiment. Le peer-coding (coder à 2 développeur) est également possible ainsi que coder en collaboration avec un testeur.

Sur ce 4ème graphique, il semblerait que quelque chose ne va pas. Ce n’est probablement pas le cas ! Les entrées et sorties de DEV, TEST et DONE sont quasiment les mêmes (les lignes sont parallèles), le flux est donc dans un régime de croisière. Bien sûr il peut y avoir des US bloquées en DEV car elles ne répondent pas aux critères d’acceptation pour arriver en TEST ou qu’il n’y a pas assez de DEV par rapport au nombre de testeur. Une analyse est toujours recommandée lorsqu’il y a un CFD qui semble anormal.

J’espère que cette introduction rapide à un indicateur du Kanban vous aidera vous et votre équipe dans le cadre de l’amélioration de votre test flow.

Je vous conseille également ce très bon article (en anglais) sur le CFD : http://brodzinski.com/2013/07/cumulative-flow-diagram.html

N’hésitez pas à rejoindre le groupe Le métier du test

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles