MyProjectStuff

Dixième épisode du roman fil rouge du livre Kanban pour l’IT.

Dans le dernier épisode,  Sophie construit le tableau Kanban pour le Marketing.

L’équipe de Charles poursuit son expérimentation sur le management visuel et le Plugin MyAgileStuff depuis quelques semaines. Un motif récurrent commence à se profiler :

Thierry, le testeur, teste moins vite que les développeurs ne développent. Leurs capacités respectives ne sont pas bien équilibrées. Les cas d’utilisation stagnent entre le développement et le test. Un goulet d’étranglement se forme et se visualise très bien sur le tableau :

Visualisation du goulet d’étranglement des tests
  • Twitter
  • LinkedIn
  • Google+
  • Facebook

MyProjectStuff : visualisation du goulet d’étranglement des tests

Sur les versions précédentes, la gestion de projet se faisait par phases, ce qui ne rendait pas visible ce déséquilibre. Cette fois, l’équipe a pu réagir en affectant des développeurs sur la partie « Test » le temps de dépiler les tests. Charles sent bien que l’équipe est en mode réactif et subit ce goulet d’étranglement.

Charles n’est pas complètement à l’aise à l’idée de laisser les développeurs tester eux-mêmes leur code. Il pense qu’il y a un risque de passer à côté d’anomalies. « On ne peut pas être à la fois juge et partie. », pense-t-il. En attendant, il faut bien gérer les blocages et avancer.

Il en parle avec Sophie au cours d’une pause café.

          « Passer aux cas d’utilisation a permis à l’équipe de paralléliser le travail. Nous avons commencé les tests avant de finir les développements. Mais cela nous pose un nouveau problème. Thierry est surchargé. Les cas d’utilisation prêts à être testés s’empilent. Je n’avais pas ce problème là avant. Comment gères-tu cela ? » demande Charles.

          « J’ai eu le même problème avec une équipe précédente passant à Scrum. Tous les tests étaient passés par un testeur expérimenté. Cela devenait un problème pour l’équipe dès le milieu de chaque sprint. Au cours d’une rétrospective, l’équipe a jugé que son expertise fonctionnelle n’était pas pleinement utilisée. Les tests simples pouvaient finalement être passés par n’importe qui, dans la mesure où il n’avait pas développé le code qu’il testait. Le testeur expérimenté se concentrait sur les tests fonctionnels plus complexes. Cet aiguillage était identifié lors du Sprint Planning Meeting. Ainsi, l’équipe a libéré du temps pour le testeur et le problème a disparu. » explique Sophie.

          « Merci pour cette piste, je vais la soumettre à l’équipe. Mais j’ai l’impression que cela ne va pas suffire pour l’instant. Les développeurs vont devoir monter en compétence sur les tests. Tu n’as pas un moyen d’anticiper les blocages et de savoir quand il faut aider Thierry ? » demande Charles. « On est un peu trop en mode pompier sur le sujet… »

          « Tu peux essayer de mettre un buffer entre le développement et les tests. L’idée serait d’avoir toujours un volume suffisant de tests à passer par Thierry et de prévenir l’équipe quand il n’y en a plus assez. » propose Sophie, puis explique le principe du buffer à Charles.

Dans le prochain épisode MyProjectStuff, Sophie prépare la prochaine rétrospective de l’équipe Aldébaran. Elle travaille sur la VSM du projet et analyse les gaspillages.

Restez informé

Restez informé

Actualité Agile - Kanban - Lean startup à ne pas rater, chaque semaine

Merci pour votre inscription.

0b1d6d005fb6edac7fb4bd334b66948c5555555555555