Le Kanban pour vos projets

Publié par Martin dans Ayeba

Dans la communauté des méthodes agiles a emergé début 2009 un mot que j’avais jusqu’a présent surtout entendu en cours d’organisation pendant mes études d’ingénieur : le mot KANBAN.

On m’avait alors expliqué que le kanban est un outil du Toyota Production System (aka TPS) ; par extension un outil du lean manufacturing ; qui permet de mettre en place une production en flux tiré.

Le kanban, ou étiquette, est une fiche qui fait la navette entre l’amont et l’aval d’un poste de production pour indiquer si le poste de production situé en amont doit fabriquer une nouvelle série de pièces ou pas. Le principe permet de limiter l’en-cours de stock et donc le gaspillage en cas de défaut détecté en aval de la chaine de fabrication.

Le kanban propose de supprimer la notion d’itération dans le développement. La méthode fonctionne de la façon suivante :

Tableau de bord

Le tableau de bord est composé de plusieurs colonnes qui détaillent les phases du cycle de développement : ici une phase de développement et une phase de déploiement.

Chaque colonne ne peut accueillir qu’un nombre limité de fonctionnalité.

Dans notre exemple :

• On ne peut selectionner que deux fonctionnalités au maximum,
• On ne peut en développer que deux au maximum,
• et on ne peut en déployer qu’une au maximum.

La limite est fixée en fonction de la capacité de traitement des équipes. Pour cet exemple, l’équipe est composée d’un product owner, de deux développeurs et d’un membre de l’équipe chargée du déploiement.

Le tableau peut être enrichi de colonne correspondant à des compétences spécifiques de l’équipe comme l’analyse, la conception, la recette… La limite est toujours adaptée en regard des capacités de l’équipe.

On peut noter que la colonne développement est composé de deux colonnes en cours et terminé. La colonne terminé permet au membre de l’équipe chargé du déploiement d’anticiper les fonctionnalités qu’il doit prendre en charge.

Rôles

Le kanban impose peu de règles pour définir les rôles. Dans l’exemple que je vais développer, je vous propose une organisation type scrum avec un product owner qui choisit les fonctionnalités à réaliser.

On note que le kanban s’adapte bien à un projet de développement classique ou les membres de l’équipe sont souvent spécialisés, un analyste fonctionnel, un architecte, des développeurs, des ingénieurs déploiement …

Cette méthode permet de créer une colonne pour chaque fonction et ainsi formaliser de façon plus réaliste le workflow d’un projet informatique (ou le workflow d’un projet de manière générale).

Fonctionnement d’un projet KANBAN

le plus simple est de vous présenter un exemple de gestion du flux de développement dans le cadre d’un projet utilisant un kanban.

Lancement du flux

Le product owner choisit deux fonctionnalités A et B et les place dans la colonne sélection

Lancement du développement

Chacun des développeurs sélectionne une fonctionnalité à développer.

Le product owner sélectionne deux nouvelles fonctionnalités à traiter C et D.

Changement de sélection

Le deuxième développeur termine la fonctionnalité B et s’apprête à en choisir une nouvelle lorsque l’équipe métier demande le développement d’une nouvelle fonctionnalité E.

Le product owner ne peut pas ajouter une nouvelle fonctionnalité dans la colonne « sélection » qui est limitée à deux items.

il choisit donc de remplacer la fonctionnalité D qui rejoint la backlog, par la fonctionnalité E.

La fonctionnalité B est quand à elle séléctionnée pour être déployée.

Lancement du déploiement

Le deuxième développeur choisit de développer la fonctionnalité E, le premier termine la fonctionnalité A.

Le membre de l’équipe chargé du déploiement sélectionne la fonctionnalité B

Le product owner ajoute de nouvelles fonctionnalité G et H à la colonne « sélection ».

Alerte sur le déploiement

Le deuxième développeur finit la fonctionnalité E. Mais le déploiement de la fonctionnalité ne peut se faire.

Le flux est stoppé :

• La colonne « selection » ne peut contenir que deux fonctionnalités,
• La colonne développement ne peut contenir que deux fonctionnalités,
• La colonne déploiement ne peut contenir qu’une fonctionnalité.

Arrêt du flux - recherche de solution

Pour libérer le flux, il faut remédier à l’anomalie de déploiement. Toute l’équipe se concentre sur la résolution du problème pour relancer le flux.

Les concepts lean mis en oeuvre par le kanban

Mise en place d’un flux tiré – minimiser le time to market.

La création du kanban comme méthode de développement est née du besoin de certaines équipes de pouvoir réduire le time to market, c’est à dire le temps passé entre l’idée d’une fonctionnalité émise par le métier et sa mise à disposition pour l’utilisateur final.

En effet, dans une organisation scrum classique, le time to market ne peut-être inférieur à la durée d’une itération, c’est à dire de 2 à 6 semaines.

Cela parait court si on compare ce délais à la réactivité moyenne d’une équipe organisée en cycle en V mais c’est long si on se réfère à certaines équipes de TMA qui peuvent proposer plusieurs mises en production par semaine.

La réduction de ce qu’on appelle ici le « time to market » se fait ici en mettant en place un flux tiré au sens le plus strict du terme. On ne développe que ce dont on a besoin en limitant au maximum l’en-cours de fonctionnalités à réaliser.

jidoka, andon et stop the line

Le kanban permet donc d’optimiser le time to market.

Mais pas seulement.

Un des concepts les plus brillants du kanban, selon moi, c’est la mise en place d’un autre concept du lean, un concept du jidoka : le stop the line.

Le jidoka n’est pas un pratiquant d’arts martiaux, c’est un concept fondateur du toyota production system qu’on traduit par autonomation (terme assez peu explicite qui explique qu’on utilise surtout jidoka) : c’est un système qui permet à une machine de production de se débrayer seule en cas de problème (surchauffe, production de mauvaise qualité …).

Le concept du stop the line est assez explicite (c’est assez rare dans le lean), lorsque sur une chaine de production un opérateur constate une erreur, ou lorsqu’une machine se débraye, on arrête toute la chaine (parfois un panneau lumineux « andon » s’allume pour signaler la machine concernée) et on s’attèle à résoudre le problème plutot que de continuer à produire coute que coute.

Ce système, pas forcément de bon sens à premiere vue, participe au concept de build-in quality qui évite la propagation de non qualité.

Comment mettre en oeuvre le Kanban ?

Le kanban est un concept puissant qui est particulièrement adapté dans des contextes où la réactivité des équipes de développement est particulièrement sensible.

On pense bien entendu aux éditeurs de logiciel, aux « pure players » internet qui vendent des services ou des biens en ligne, cette organisation est également pertinente pour une équipe de TMA afin de permettre de maximiser sa réactivité, ou bien appliquer le kanban à une équipe d’exploitation pour piloter les processus de mise en production.

Peu de règles sont imposées par le Kanban, il est donc particulièrement nécessaire de bien penser l’organisation de votre projet kanban avec vos équipes pour que le flux modélisé soit réaliste et pas idéal.

Ainsi vous pourrez bénéficier de tous les apports de cette nouvelle méthode agile : optimiser votre réactivité et améliorer votre qualité. Sans oublier bien sur d’améliorer de façon continue le dispositif mis en oeuvre !