Processus non séquentiels en Kanban

La représentation utilisée dans les tableaux Kanban est basée sur une séquence d'activités, qui correspondent généralement aux colonnes; l'activité qui s'exécute en premier est à gauche et celle qui termine le processus est à droite.

Par exemple, avec un élément de travail qui est la story, on peut avoir un système Kanban qui porte sur ces 3 activités :

  • préparer,
  • développer et
  • accepter (comme fini).

Pour le représenter, c'est facile, une colonne pour chaque activité, une colonne d'entrée pour la story pas prête, une colonne de sortie pour la story finie et éventuellement des colonnes entre les activités pour des buffers. C'est séquentiel[1].

Dans une autre vie, j'ai fait de la modélisation de processus, en utilisant des langages basés sur UML ou du BPMN. Je ne me souviens pas d'avoir rencontré un processus constitué uniquement d'une séquence d'activités. Le flot de contrôle des activités comportait en plus de la séquence, d'autres opérateurs[2] comme (de mémoire) le parallélisme, la synchronisation, l'alternative, la fusion, la répétition...

Quelques exemples concrets, variations de la séquence précédente :

Boucle

Première rupture de séquence : quand on travaille sur l'activité accepter (comme finie) il se peut qu'on se rende compte qu'il faut développer à nouveau. C'est une question typique en Kanban, qui avait fait l'objet d'un débat enflammé lors d'Agile Open Sud : un élément de travail (ici la story) peut-il remonter le flux de la droite vers la gauche ?

Option

Imaginons que pour certaines stories, on ait à écrire une documentation, faite par un rédacteur. La réaction est alors d'ajouter une colonne Documenter. Mais les stories qui n'ont pas besoin de documentation peuvent-elles sauter cette colonne ?

Parallélisme

Pour accepter une story finie, il faut d'une part passer avec succès ses tests d'acceptation et d'autre part que les contrôles tirés de la signification de fini soient positifs. Tester et contrôler sont deux activités qui peuvent être faites en parallèle, par des personnes différentes. Pour que la story soit acceptée comme finie, il faut que les 2 activités soient terminées. Comment représenter cela sur un tableau Kanban ?

Fork et merge

Les activités Préparer, Développer et Accepter comme fini vont bien pour les "user" stories, mais on a aussi à s'occuper de stories techniques pour lesquelles préparer et accepter ont un sens, mais pas développer auquel on doit substituer 2 activités : étudier (plusieurs solutions) et préconiser (une solution). Donc nos stories techniques suivent un processus différent des user stories après préparer et reviennent dans le pot commun pour accepter. Ca se représente en Kanban ?

Les réponses à ces questions, et à bien d'autres sur Kanban (et ScrumBan), seront données au cours de la formation Kanban, que j'animerai avec Laurent Morisseau, l'auteur du livre Kanban pour l'IT.

Notes

[1] En fait c'est une partie du 2ème tableau présenté dans ce billet, mais il faudrait changer les noms des colonnes pour qu'elles correspondent plus à des activités, en utilisant des verbes.

[2] Il est probable que l'utilisation de ces opérateurs ait contribué à complexifier la représentation des processus.

Commentaires

1. Le mercredi 17 octobre 2012, 15:35 par Arnaud

On reste sur sa faim, il aurait fallu mettre dès le début "Publi-reportage" :)

Repassez sur le blog, j'en parlerai après la formation. Vous pouvez aussi proposer des réponses...
2. Le samedi 24 novembre 2012, 09:34 par Ronan

je rencontre la pluspart des ces problématiques dans la mise en place de Kanban de mon entreprise, j'attend donc avec impatience un début de réponse.