En KANBAN, pourquoi ne faut-il pas déplacer un ticket mal implementé de droite à gauche pour le corriger?
Lors de la phase de vérification d’ un ticket, j’ ai un collègue qui renvoie systématiquement le ticket dans le colonne de développement, plutôt que de laisser le ticket à sa place et de créer un nouveau ticket de type bug pour venir corriger l’ erreur d’implémentation.
Mon opinion penche en faveur de la création d’ un nouveau ticket et de laisser la user story mal implementé à sa place.
Mais est-ce que sa pratique est fondamentalement mauvaise ou bonne?
Quels seraient vos argument pour expliquer qu’ il ne faut pas déplacer les tickets de droite à gauche sur un Kanban Board svp?
C’est un mythe qu’on ne peut pas faire reculer un ticket dans le workflow Kanban. Par contre il faut bien comprendre pourquoi le faire et pourquoi ne pas le faire. Je trouve la conversation dans cette vidéo intéressante : https://youtu.be/AH9ccDS7-N0. Voici les points que j’ai trouvé utiles :
On recule un ticket généralement parce qu’on n’aurait jamais dû le faire avancer : on a fait avancer par erreur.
Lorsqu’un ticket recule, aucune courbe ne diminue dans le CFD si l’on le construit correctement.
Dans le cas d’une phase de test où un bogue est rencontré, une option potentielle est de laisser le ticket dans cette phase de test sans créer de ticket de bogue. Le plus possible, on corrige les anomalies là où on les détecte.
Lorsqu’on recule un ticket à cause d’une erreur, n’oublions pas de discuter de cette erreur et de comment l’éviter à l’avenir.
Je propose une autre approche :
En kanban, le tableau représente le flux de travail, qui va dans un sens unidirectionnel de gauche à droite. Tout comme une rivière coule dans une direction, aborder le travail de la même manière vous aidera à identifier rapidement tout problème dans votre débit.
L’eau ne remonte pas si elle rencontre une pierre, elle peut-être bloquée, mais ne remontera pas.
Si vous mettez un testeur qui est là pour valider un ticket, il va soit mettre le tampon accepted, votre ticket est donc terminé, soit il va mettre un tampon refusé, et votre ticket va à la poubelle.
C’est ainsi que la notion de créer un nouveau ticket pour corriger le problème identifié par le testeur peut avoir un sens.
Mais ne pas oublier que rien n’est interdit, l’outil est là pour aider l’équipe à avancer, il n’est pas là pour interdire les choses, donc si vous considérez que remettre le ticket dans la colonne précédente est plus simple pour vous, libre à vous de le faire. Vous pouvez également la laisser dans la colonne test et le développeur corrige le cas identifié par le testeur. Elle est bloquée dans cette colonne.
Ce qui ne sera pas visible dans ce cas est le taux de livraisons rejetées et qui vous empêchera à la prochaine itération d’améliorer la livraison des développeurs pour éviter de vous retrouver dans cette situation.
Donc si vous essayez de jouer le jeu du ticket accepté ou rejeté, vous verrez les points d’amélioration à apporter avec une mesure de la quantité de déchet et des sources d’erreurs dans chacune des colonnes.
Mais encore une fois, le tableau kanban est une représentation du flux de travail, pour identifier où positionner les ressources pour optimiser le temps de passage dans chacune des colonnes tout en améliorant la qualité au maximum, c’est à dire en éliminant les déchets.
Peut-être qu’avec ce vue à l’esprit, ta question @fbrun te paraitra différente et les comportements à adopter te paraitront plus clair ? Alors, est-ce vraiment utile, nécessaire, de remettre le ticket dans le colonne en cours de dev après cette explication ?
dans mon entreprise, on peut faire reculer les cartes, mais on ne le fait que dans le cas où on s’est trompé, le ticket a été avancé à tort.
on préfère laisser le ticket en pair test et remédier rapidement, et si on arrive pas à remédier rapidement, oui, on crée un bug.
à la base, on se refusait de faire reculer les tickets car ça fausse le calcul de cycle time et certains autres graphs
aujourd’hui, les graphs sont fait avec EazyBI, plus une tâche manuelle, du coup, on pourrait lever cette contrainte, mais bon, psychologiquement, j’aime bien cette limitation, le but de l’équipe est de faire avancer le ticket, pas de le faire reculer
Un ticket qui remonte dans le tableau fait réagir, car ça a sur les gens le même effet de surprise qu’une barre de progression qui reculerait subitement, ou un pourcentage de progression dont la valeur se réduirait dans le temps.
Il y a 4 cas de figure à distinguer à mon avis :
Le ticket a été inséré dans la mauvaise colonne par erreur (en fait on voulait pas le mettre là). Déplacer le ticket est une simple action corrective sans conséquence ;
Le ticket a été inséré dans la bonne colonne, mais il n’aurait pas dû avancer car il n’a pas satisfait aux critères de contrôle de sortie du poste de travail : « on a oublié de vérifier le parachute, tu veux vraiment le passer en phase de saut ? » Non ! On le remet à sa place et on finit le travail qu’on aurait dû faire. Ca peut être intéressant de comptabiliser ces cas, et s’ils sont nombreux ça veut dire qu’on devrait améliorer l’organisation pour réduire les erreurs ;
Le ticket fait des cycles dans le flux de travail parce que la responsabilité fait réellement des aller-retours entre deux postes de travail. Le flux de travail est bel et bien unidirectionnel, mais il y a un problème quelque part dans l’organisation qui fait que les postes se renvoient la responsabilité. Le poste A considère que son travail est terminé, mais le poste suivant considère que non. Une seule solution, il faut revoir l’organisation et clarifier la limite entre ce qui est terminé ou pas, pour que tout le monde ait la même définition et fluidifier le travail ;
Le flux de travail est circulaire, et la responsabilité doit bel et bien faire des aller-retours (à l’issue du test échoué, je remet le ticket en dev). Là, à mon avis on n’a juste pas vraiment appliqué Kanban.
D’abord, ce n’est pas parce qu’on a mis 2 colonnes « dev » et « test » qu’on fait du Kanban. Ce qu’on a fait c’est deux liste de tâches et on passe les tickets de l’un à l’autre. On peut donner pas mal de noms à ce genre d’organisation mais certainement pas Kanban, en tout cas pas stricto sensu.
Dans la pensée toyotiste, on s’intéresse d’abords aux produits (les tickets) et non pas aux gens. Kanban est donc avant tout le moyen de visualiser la progression du produit dans un contexte de flux unidirectionnel. Donc soit on fait rentrer l’organisation du travail de développement dans un workflow vraiment unidirectionnel, soit on envisage d’autres solutions que Kanban. Et là, je parle pas des colonnes du tableau, parce qu’en soit on met bien les traits là où on veut. L’élément important c’est que cette visualisation est avant tout un symbole de l’organisation du travail. Quand on fusionne des colonnes, c’est qu’on fait travailler les gens ensemble sur la même tâche, et quand on sépare, c’est qu’on sépare aussi les équipes, les objectifs et les cadences. Donc la question fondamentale c’est : « linéariser ou ne pas linéariser le flux de travail du développement logiciel ? »
Or la tendance, depuis le Manifeste pour le développement Agile de logiciels, c’est au contraire d’aller vers moins de linéaire, plus d’itératif, et de maximiser les boucles de feedback. Alors, chercher à appliquer une méthode de travail industrielle, conçue pour les flux de production unidirectionnels, pour une activité intrinsèquement itérative, ça en dit long sur la maturité de l’industrie du logiciel …
Après, si on fait le deuil de Kanban à proprement parler, un board peut être très utile pour s’organiser. Mais là c’est une autre paire de manche, la question c’est comment on s’organise et comment on communique au sein d’une équipe de développement. Vaste programme !
Non ! On le remet à sa place et on finit le travail qu’on aurait dû faire. Ca peut être intéressant de comptabiliser ces cas, et s’ils sont nombreux ça veut dire qu’on devrait améliorer l’organisation pour réduire les erreurs ;