La méthode Kanban

La méthode Kanban apporte au monde de l'agilité un focus particulier sur l'amélioration des processus et la fluidité des flux de production. Ses artefacts es plus connus sont le tableau kanban et les limites du travail en cours.

Vue d’ensemble

Article

Proposé dans les années 1950 par Taiichi Ōno, et formalisée en 2010 par David Anderson, Kanban est une méthode dérivée des systèmes de production industriels de Toyota.

Le mot « kanban » (かんばん) signifie en japonais « étiquette composée de signes ».

Elle a été adoptée par le monde du développement logiciel et des systèmes d’information pour son apport dans la gestion des processus : en informatique, nous ne travaillons pas avec des chaînes de production, mais cela ne nous empêche pas d’avoir des processus… qu’il convient d’optimiser !

Les cinq grands principes de Kanban

Kanban se fonde sur 5 principes fondamentaux, que nous allons détailler ci-dessous.

Limiter le travail en cours

C’est un élément très important, si ce n’est le plus important de Kanban : plus on fait de choses en même temps, plus on a tendance à perdre de la productivité, aussi Kanban recommande de limiter intelligemment la quantité de travail en cours.

Ce travail en cours est appelé WIP, pour work in progress.

La loi de little n’est pas une petite loi…

La science a rigoureusement étudié les files d’attentes, et en a produit des théories.

Parmi elles, la loi de Little (théorie des files d’attente), montre que le temps moyen de traitement d’une tâche dans un système est proportionnel au nombre de tâches en cours de traitement dans ce système.

Ça veut dire quoi ? – Concrètement, cela signifie que l’on va plus vite pour livrer x fonctionnalités si on ne les traite pas toutes en même temps !

OK, donc comme les hommes (en tout cas la perception qu’en ont les femmes !), les systèmes de productions ne sont pas bon en multitâche !

Nous allons donc instaurer des limites dans le système.

Finir de que l’on a commencé !

De manière plus pragmatique, il parait logique qu’il est intéressant de ne pas engager de développements sur un nombre important de choses à la fois, et on s’efforce de terminer ce que l’on a commencé, pour délivrer de la valeur tôt.

Pull vs. push

Kanban instaure un moyen permettant de limiter le WIP dans une étape de processus, par un système de « pull » : le flux tiré. Contrairement à d’autres méthodes agiles comme Scrum ou XP, Kanban n’est pas vraiment centré sur la notion d’itération. Le travail se fait au fil de l’eau : schématiquement parlant, quand une équipe a fini un travail (par exemple coder une fonctionnalité), elle se manifeste auprès de l’équipe qui travaille en amont (par exemple spécifier une fonctionnalité) pour lui dire « hey, je suis disponible, envoie moi du travail ! ». C’est le contraire d’un système « push » où une équipe terminant un travail dirait à l’équipe qui travaille en aval : « tiens, j’ai fini ça, il faut que tu le traites ! ». À une étape x, on ne produit jamais plus que ce que x+1 peut traiter.

On limite ainsi le coût lié au fait d’avoir des choses en suspend (dans les usines, c’est de la place pour stocker des pièces en cours d’usinage, dans les équipes informatique c’est plutôt le coût lié au fait que le travail en cours non livré devient vite caduque et ne produit pas de valeur), et on accroît la qualité globale de ce qui est livré.

La visualisation du workflow

Les workflows sont les processus qui interviennent dans les projets. Ils sont parfois évidents, parfois intangibles, et beaucoup plus difficiles à expliciter.

Pour cette raison, la méthode kanban préconise de mettre en œuvre des moyens visuels et explicites pour visualiser les processus. Il est ainsi plus facile de les surveiller, de les analyser et de les optimiser en repérant à quel endroit quelque chose pourrait être amélioré.

Cette visualisation peut se faire par des graphiques, mais surtout par des tableaux sur lesquels on affiche les différentes tâches des processus.

Documenter explicitement les processus

La manière dont les choses fonctionnent, c’est à dire les règles liées à chaque processus, doivent être clairement identifiés et documentés.

Ceci permet notamment à tout membre de l’équipe de comprendre ces processus, mais aussi d’en parler, et de chercher à y apporter des améliorations sur la base d’éléments concrets.

Gérer les flux

Chaque processus doit être monitoré et analysé, pour identifier rapidement et précisément quels sont les points faibles (goulots d’étranglement par exemple) et comment les supprimer. On utilise pour cela des indicateurs de capacité du système.

L’objectif ultime est de mettre en cohérence la demande client et la capacité de production, en rendant le flux de production de plus en plus fluide.

Travailler ensemble pour améliorer les choses

Toutes les mesures, aussi bonnes soient-elles, ne sont bénéfiques que si les gens qui sont censés les mettre en œuvre en partagent le sens. L’équipe est beaucoup plus impliquée dans un changement si c’est elle qui en est à l’origine, collectivement.

Le tableau Kanban

Le fameux tableau kanban est aujourd’hui bien connu, parce qu’il s’est imposé comme radiateur d’information dans bon nombre d’équipes agiles.

Le tableau

Voici à quoi ressemble un tableau Kanban, une forme que l’on retrouve par exemple dans les équipes Scrum :

Tableau kanban

Les cartes

La carte kanban regroupe des informations utiles pour le traitement de la tâche, comme une description de la fonctionnalité, un identifiant permettant de tracer l’exigence, la date d’entrée dans le système et sa date de sortie :

Carte kanban

Le tableau comme moyen de visualiser le processus

Ce tableau est simple à lire… On y liste les tâches, sous la forme de cartes kanban, qui évoluent au cours des étapes du processus.

Processus kanban et étapes

Les limites kanban

La différence fondamentale introduite par Kanban par rapport aux autre méthodes agile est celle de limite sur le travail en cours, comme nous l’avons vu plus haut. Voyons maintenant comment ceci se matérialise concrètement.

Le système peut être caractérisé par son débit, c’est à dire le nombre moyen d’éléments produits par unité de temps. Tout système a un débit, et le débit diffère d’un système à un autre, d’un projet à un autre.

Pour chaque étape du processus, l’équipe kanban va fixer des limites de quantité d’éléments pouvant se trouver à un instant t à une étape du flux :

  • La limite haute permet de réguler le flux tiré en interdisant que le nombre d’éléments traités à une étape soit supérieur à un certain nombre. Cela s’applique au travail en court (ex. : développement) qu’aux files d’attente (ex. : todo list).
  • La limite basse permet de planifier le travail juste à temps (« just in time »), en garantissant qu’il y a toujours au moins un certain nombre d’éléments en cours de traitement à une étape.

Voici ce que devient notre tableau kanban, avec l’instauration de limites :

Kanban limites haute et basse

Il ne peut à présent plus y avoir plus de 4 éléments en cours de réalisation. Les autres doivent attendre à l’étape « étude ». Et comme il ne peut pas non plus y avoir plus de 2 éléments en cours d’étude, le reste attend dans les « choses à faire ».

Commentaires