Kanban, premier problème rencontré

Depuis maintenant 1 mois, mon équipe de maintenance est passée à Kanban dont j’ai écrit une présentation sur le blog tech. Nous rencontrons un problème de modélisation des colonnes et du flux.

Quand une validation fonctionnelle a échoué, faut-il revenir en arrière, à la manière d’une boucle ou avoir des colonnes qui ne serviront que dans le cas d’une non-validation ?

Voici nos colonnes :

 

Colonnes de mon Kanban (les [x] représentent des étiquettes)
  TODO   Dév. en cours Valid métier Dév. Fini
max 10 max 4 max 6 max 4  
  Réalisation Valid Tech Prêt pour valid Validé Ready for merge Mergé (todo backport) Fini
  [x] [x] [x] [x][x] [x] là => [X] [x] [x] [x] [x] [x] [x][x] [x][x] [x][x] [x][x] [x][x] [x][x] [x]

Quand l’étiquette est en « Prêt pour valid », et que le ticket n’est pas validé, où le mettre ?

3 réflexions sur “Kanban, premier problème rencontré

  1. Mes retours d’expérience :

    Trois colonnes : à faire, en cours, terminé. Il est de la responsabilité de toute la boite que de faire en sorte d’aider à faire passer un « en cours » à « terminé », autant fonctionnels que techniques voire commerciaux. Le « terminé » implique que plus personne n’aura rien à faire : tests, configuration, déploiement, annonce, etc. Si vous faites des déploiements par versions majeures (et non continus) alors on peut imaginer une colonne juste avant qui s’intitule « attente release » par exemple.

    Dès qu’on ajoute des colonnes, on déresponsabilise le workflow. C’est à dire qu’on laisse quelqu’un considérer qu’il a fait son boulot et que la suite ne le concerne plus. C’est particulièrement vrai pour les validations et les tests. On voit les zones d’attente devenir des trous noirs.

    Si on veut s’assurer de réduire au maximum le nombre d’histoires en cours et la latence entre le début et la fin d’une histoire, le mieux AMHA est de refuser les zones d’attente. On sort du « en cours » de quelqu’un que quand il n’y a rien à faire et que ça rentre dans le « en cours du suivant ». Charge au développeur d’aller faire le sitting auprès du fonctionnel pour avoir la validation, ou le menacer avec son nerf (ou à l’inverse lui promettre café et croissants) – et inversement.

    Là aussi c’est particulièrement vrai pour les tests et les validations. Un développement non validé c’est un développement non terminé, potentiellement erroné ou incomplet. Le faire avancer d’une case est un mauvais signal.

    Tout au plus si vraiment il faut montrer le changement de responsabilité dev/fonctionnel tu peux faire plusieurs colonnes « en cours » en fonction du responsable, mais la zone d’attente me semble dangereuse (bien entendu tout ça est sans connaitre votre organisation, et chacun voit forcément les choses différemment)

    Si je dis tout ça c’est qu’on est en plein dedans. Ton fonctionnel n’a qu’une opération de validation ? Alors pourquoi sors-tu de la colonne « en cours » ? Si tu n’en sors pas la question que tu te poses n’a plus lieu d’être.

    Maintenant pour répondre à ta question :

    * Pas de colonne pour la non-validation. Soit tu as un boulot à faire, soit tu n’en as pas. Que ta tâche soit non finie parce que tu es toujours dessus ou non finie parce que tu la croyais finie mais en fait tu as oublié des choses, quelle importance ?

    * Si ça peut partir en prod tel quel, quitte à ce que ça soit imparfait, alors on clos la ligne tel quel. Les détails ou améliorations restantes iront sur une toute nouvelle ligne. Très probablement cette toute nouvelle ligne sera plus loin dans ton backlog, parce que justement il s’agit de détails et plus de trucs prioritaires. Ça entraine à se dire « oui on veut le faire, mais on a des tâches à plus grande valeur ajoutée à faire maintenant ».

    * Si ça ne peut pas partir en prod tel quel à cause d’un manque fonctionnel ou d’un manque qualité, alors on repars dans ta colonne « en cours », quel que soit le nom que tu lui donnes. Ce n’est pas tant qu’on regresse, c’est juste la remettre au bon endroit : elle n’aurait jamais du avancer en premier lieu (ben oui : elle n’était pas ou mal finie)

    Perso sur votre board, je ne comprends pas pourquoi le « réalisation » est différencié de « valid tech ». Je ne comprends pas le rôle de « validé » – si c’est en fin de validation, autant la pousser directement au statut suivant, et si c’est en cours de validation, j’aurai tendance à la renommer.

  2. Merci pour ta réponse, je viens de la lire, mais je pense la relire plusieurs fois.
    J’ai évité de contextualiser ma question, mais on parle d’une équipe avec peu de développements et qui ne représente pas du tout l’ensemble de l’entreprise, au contraire, c’est une mini-équipe.

    « Tout au plus si vraiment il faut montrer le changement de responsabilité dev/fonctionnel tu peux faire plusieurs colonnes « en cours » en fonction du responsable »
    => c’est pourquoi il y plusieurs colonnes, en fait🙂

    « Perso sur votre board, je ne comprends pas pourquoi le « réalisation » est différencié de « valid tech ». »

    => pendant la Valid. Tech, tu peux réaliser autre chose, car chez nous, la validation technique implique
    – l’attente de Code Review des autres dév,
    – et l’attente de la fin des builds Jenkins.
    Tu es donc disponible, en tant que dev, pour t’engager sur un autre développement (tenant compte de la limite de colonne Kanban).

    « Je ne comprends pas le rôle de « validé » – si c’est en fin de validation, autant la pousser directement au statut suivant, et si c’est en cours de validation, j’aurai tendance à la renommer. »

    => C’est un changement de rôle. La personne qui dépose dans Validé est un fonctionnel et la personne qui le reprend en Ready for merge est un dév. Ces deux colonnes concomittentes sont la même colonne mais la différence marque le rôle. Comme une frontière : la ligne est la même pour les deux pays, mais selon l’emplacement, tu la considères différemment. (J’ignore si c’est clair, ce que je raconte, là.)

  3. Pour la valid tech, sauf si vous avez vraiment des problèmes à réunir les gens nécessaires à la code review dans des délais raisonnables, pourquoi ne pas laisser dans « en cours » ? Parce que finalement c’est ce que c’est. Et oui, ça veut dire que potentiellement un dev peut avoir deux tâches en cours s’il y en a une de bloquée.
    Si à l’inverse vous avez du mal à réunir les gens, alors votre problème et là et la colonne supplémentaire n’est qu’un moyen de le masquer.
    (encore une fois, je parle sans connaitre votre organisation interne, donc j’essaye de m’imaginer par rapport à ce que j’ai vu ailleurs, seuls vous pouvez être juges au final).

    Mais c’est vraiment le « validé » qui me gêne. Je vois bien le changement de responsabilité mais finalement soit ton fonctionnel met dans la boite « à faire » du développeur (et on supprime la colonne « validé », cas qui me semble le plus cohérent) soit c’est ton développeur qui prend dans la boite du fonctionnel et il n’a plus besoin de son « ready for merge » vu que dès qu’il prend la tâche c’est pour faire le merge.
    Là tu sembles avoir deux zones d’attentes l’une après l’autre sans réelle action entre les deux.
    Tu vas juste les avoir d’un côté ou de l’autre en fonction du nombre de tâches en cours qu’a chacun pour valider artificiellement le critère « nombre maximum de tâches »

    (oui, je sais, ce n’était pas le sujet de base de ton billet🙂

Ajouter mes idées

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s