RSS
Follow by Email
Facebook
Google+
http://www.responsive-mind.fr/methode-kanban/
Twitter

Dans les méthodes de développement Agile, c’est Scrum qui fait beaucoup parler de lui, pourtant il existe une autre forme d’organisation au moins aussi souple et qui mérite qu’on s’y intéresse : la méthode Kanban. D’ailleurs les deux méthodes peuvent cohabiter sans peine.

Issue du monde de l’automobile, la méthode Kanban a pour objectif principal d’éviter la surproduction en rationalisant les flux afin de ne produire que ce qui est nécessaire, au moment où c’est nécessaire.

separateur

A l’origine : Des étiquettes sur des containers de pièces détachées

Dans ce titre se cachent trois informations plus ou moins précieuses :

  • La méthode Kanban a été inventée à la fin des années 50 dans les usines Toyota (ça c’est pour briller dans les dîners mondains) – source ;
  • Le terme Kanban est un mot japonnais qui signifie « étiquette », « carte de signalisation » (ça aussi ça donne un air cultivé, mais c’est avant tout la moitié de la philosophie de la méthode) – source ;
  • Dans l’industrie, chaque étiquette est accolée à un container lorsqu’un flux le fait transiter d’un poste à un autre. La transmission d’une étiquette à un poste amont par un poste aval équivaut à un ordre de production – source.

Ça doit vous sembler un peu flou alors nous allons prendre un exemple.

Le poste 1 (usinage) produit des pièces en plastique de type « A », « B » et « C », sur la même machine. Pour optimiser les coûts, la machine ne produit qu’un seul type de pièce par jour. Le poste 2 (assemblage) assemble ces pièces pour en faire un produit semi-fini « D » et le poste 3 (conditionnement) combine ces produits semi-finis avec d’autres pour en faire un objet prêt à commercialiser « Z ». Entre l’usinage et l’assemblage chaque type de pièce est transférée dans un conteneur de 5000 pièces, ni plus, ni moins. En fonction de la cadence de production des postes d’usinage (15000 unités / jour) et d’assemblage (5000 unités / jour) l’usine s’est dotée de 4 conteneurs de chaque type de pièces.

Sur chacun de ces containers se trouve une étiquette détachable, le Kanban. Lorsque le poste 2 commencera à utiliser les pièces d’un conteneur, son responsable détachera l’étiquette et la retransmettra au responsable du poste 1 pour lui demander la production de ce type de pièces. Quand le conteneur sera totalement vide, il sera retourné au poste 1.

Au début d’une journée, le responsable de l’usinage détermine quel type de pièce devra être produit donnant la priorité à celui dont le stock est le plus faible, c’est à dire celui dont il aura le plus d’étiquettes sous les yeux. Admettons que pour ce matin, les stocks soient les suivants :

  • Pièces A : 1 container plein – 3 vides ;
  • Pièces B : 2 containers pleins – 2 vides ;
  • Pièces C : 3 containers pleins – 1 vide.

Le responsable de l’usinage va donc lancer la production de pièces A.

A la fin de la journée, le poste 1 aura produit 3 containers de pièces A. Le poste d’assemblage en aura consommé 1 de chaque type de pièce. Le stock du lendemain matin sera alors :

  • Pièces A : 3 conteneurs pleins, 1 vide ;
  • Pièces B : 1 conteneur plein , 3 vides ;
  • Pièces C : 2 conteneurs pleins, 2 vides.

Je vous laisse continuer cette séquence chez vous, vous verrez que ça roule tout seul, mais mon but n’est pas de noircir des lignes alors nous allons résumer ce process dans un tableau. Ci-dessous vous pouvez voir quelles étiquettes sont en possession de chaque poste au démarrage d’une journée.

Usinage Assemblage Conditionnement
Jour 1 AAA BB C A BB CCC – D DDDD
Jour 2 A BBB CC AAA B CC – DD DDD
Jour 3 AA B CCC AA BBB C – D DDDD
Jour 4 AAA BB C A BB CCC – DD DDD

A travers cet exemple, vous pouvez constater plusieurs points fondamentaux :

  • Le nombre de kanbans en circulation est constant, il n’y en n’a jamais un de plus ou un de moins ;
  • Un poste ne peut accueillir qu’un nombre limité d’étiquettes, par exemple le conditionnement ne peut pas demander plus de 2 containers de pièces D à l’assemblage ;
  • Le but de cette méthode étant  avant tout de limiter le stockage inutile et de limiter la surproduction il ne devrait pas y avoir autant de containers pour la pièce D, ceux-ci restant inutilement sur le poste de conditionnement ;
  • La priorité est donnée à la production de ce dont on a le plus besoin, ici il s’agit de pièces détachées mais ça peut s’appliquer à tout.

separateur

Pour vos projets informatiques : un tableau et des post-its

Comme bien souvent sur ce blog, c’est par l’exemple que nous allons comprendre comment utiliser la méthode kanban à un projet informatique, qu’il s’agisse d’un projet web, logiciel ou IT.

Quittons donc l’industrie pour nous plonger dans un projet web tout simple. Lundi matin 9h00, vous êtes convoqué(e) par Ze Boss qui vous expose sa nouvelle idée géniale : la société va avoir un blog ! Qu’est-ce qu’on va y mettre ? Qui va le remplir ? Aucune idée, mais vous il y a une certitude : ça doit être en ligne vendredi, avec une « béta » pour demain… J’imagine le sourire de quelques uns d’entre vous, eh non vous n’êtes pas seuls, chef de projet in-house ou freelance, je pense que tout le monde a été confronté à ce type de projet hasardeux au moins une fois dans sa carrière (certains en font leur quotidien, d’autres les refusent systématiquement, c’est un autre débat).

Bref, nous avons :

  • Une idée suffisante de l’objectf ;
  • Une équipe de 2 développeurs / graphistes / seo / réparateurs d’imprimante et 1 lead , certainement que d’autres acteurs vont intervenir au moins pour saisir du contenu ;
  • Un calendrier plutôt court.

Comment gérer ce projet ?

  • Un cycle en V, à l’ancienne ? Ça pourrait aller avec une documentation minimaliste, des spécifications rédigées à la va-vite pendant au moins 1/3 du projet (en fait le lundi entier, on pourra développer la béta entre 9h00 et 11h30, la démo de 10h00 attendra un peu)… Ne vaut-il pas mieux se concentrer sur le livrable ?
  • Une gestion type scrum ? C’est à la mode, on y est plus ou moins habitués dans l’équipe et à 3 on peut occuper tous les rôles. Sérieusement, vous avez envisagé un sprint sur 2,5 jours et 2 itérations dans la même semaine ? Non il ne s’agit plus de scrum !
  • Selon la méthode cimmérienne ? Tout dépend de la volonté de Crom, mais finalement c’est comme ça que ça se passe en général.

Sinon il reste toujours la méthode Kanban : on ne livre plus des caisses de pièces détachées, mais des fonctionnalités. Notre objectif ne sera plus de minimiser les stocks pour éviter la surproduction, mais de réduire au maximum le Time To Market (TTM), autrement dit le délai avant la mise en production. Tout ceci a l’air de coller parfaitement avec nos objectifs, alors voyons comment décliner cela.

Comme avec Scrum, tout part d’un backlog : établissez la liste des tâches/fonctionnalités nécessaires (mise en place du serveur, déploiement du CMS, installation du thème, arborescence, plugin X Y ou Z…). Chacune de ces tâches sera représentée par une petite « note adhésive repositionnable » sur laquelle seront notés le libellé et une courte description de la tâche. Vous avez donc la première colonne de votre tableau, qui pourra être enrichie à volonté selon les demandes de l’équipe métier (alias ze boss dans notre cas).

tableau de bord kanban

Ensuite il va nous falloir une colonne qui détermine quelles sont les tâches à traiter. Comme dans une organisation de type Scrum c’est le product owner (ici notre lead developper) qui va les choisir en fonction des priorités. Ces tâches sont déplacées de la colonne « nécessaires » à la colonne « sélectionnées ». Vous vous souvenez que dans l’application industrielle, chaque poste ne pouvait avoir qu’un nombre limité de kanbans ? Ici nous allons devoir appliquer la même règle en fonction de contraintes extérieures, des capacités de nos collaborateurs… et le product owner va devoir sélectionner ses kanbans en fonction de cette limite qu’il aura lui-même fixée, mais aussi des dépendances des tâches les unes par rapport aux autres… Nous allons considérer que chaque développeur ne peut gérer que 2 tâches à la fois, donc le product owner ne pourra en sélectionner que 4 simultanément.

Tableau de bord Kanban 2

Chaque développeur va à son tour déplacer les fiches vers la 3° colonne de notre tableau pour se les attribuer. Cette colonne représente donc les tâches en cours de développement.

Tableau de bord kanban 3

Une fois le développement terminée, une fonctionnalité est mise dans la 4° colonne : le déploiement. Selon toute logique c’est le développeur qui a réalisé le développement qui demande le déploiement de la fonctionnalité. C’est donc lui qui déplace la fiche d’une colonne à l’autre.

Tableau de bord kanban 4

Enfin, on passe à la 5° colonne (sans aucune allusion conspirationniste), j’ai nommé recette utilisateur. Comme pour l’étape précédente, c’est la personne qui a réalisé le déploiement qui fait la demande de validation. Dans notre exemple il pourrait s’agir du lead developper, ce qui permet aux développeurs de se concentrer sur le développement, toujours dans l’optique d’aller le plus vite possible.

Tableau de bord Kanban complêt

Une fois la recette effectuée, la fiche est simplement détruite, la tâche n’étant plus considérée comme faisant partie du projet.

La ligne de production peut s’arrêter

Il peut arriver, pour une raison ou une autre qu’il soit impossible de déplacer une fiche d’une colonne à une autre. Par exemple s’il est déterminé qu’une seule fonctionnalité ne peut être testée à la fois. Dans l’exemple ci-dessus il sera impossible de passer la fiche D en recette tant que la fiche A n’aura pas été traitée.

Que faire ? Les développeurs vont se dépêcher de développer leurs tâches en attente pour être certains de ne pas être en retard par la suite ? Et que va-t-il se passer si toutes les colonnes du tableau se retrouvent embouteillées ? Si vous êtes déjà resté(e) coincé(e) dans un bouchon sur la route des vacances vous savez que plus celui-ci est important, plus il est difficile de le résorber. On peut aussi laisser la recette de côté, décider qu’elle n’est pas vitale à la production puisque le produit est livrable, mais si cette entorse au process permet à un bug de se glisser et de ne réapparaître que plusieurs jours après, il sera d’autant plus difficile à retrouver et à corriger.

Alors en cas d’engorgement ou d’anomalie, c’est toute la chaîne qui s’arrête et travaille à la résolution de l’incident. L’idée de la méthode kanban n’est pas seulement de produire vite, mais aussi de produire de la qualité

De la théorie à la pratique : quelques adaptations

Si efficace soit-elle, la méthode Kanban reste un outil à votre service et non pas un carcan auquel vous devez vous plier. Voici donc quelques adaptations que l’on rencontrer

Vous verrez peut-être des tableaux de bord dont la colonne « développement » est coupée en 2 : en cours et terminé. Pour ma part je trouve cette séparation contraire aux principes de l’organisation kanban dans laquelle les étiquettes ne sont déplacées que par un flux matériel, en clair lorsqu’elles changent de main. Or si entre le développement et le déploiement, la fonctionnalité peut être traitée par deux intervenants différents, ça n’est pas le cas entre « je commence à développer » et « j’ai fini de développer ». Néanmoins ça peut aider les développeurs à visualiser leur todo list, alors pourquoi pas ?

Faut-il détruire le kanban une fois que la recette est validée ? Si vous utilisez git ou n’importe quel autre outil de versionning, vous savez pertinemment que le fait de savoir qui a fait quoi, quand et pourquoi est une règle d’or ! Il me semble donc impensable de jeter une information à la poubelle. Je vais même plus loin en ajoutant aux fiches les informations relatives au changement d’état : pour chaque colonne du tableau je vous propose d’inscrire une ligne sur laquelle l’acteur qui effectue le déplacement de la fiche notera son nom et la date (et éventuellement un commentaire). Ainsi il sera possible de savoir que telle tâche a été sélectionnée par tel développeur tel jour et mise en ligne par telle autre personne. En cas de bug, savoir qui est intervenu sur quelle fonctionnalité peut faire gagner un temps précieux. Inutile de préciser que dans ce cas il ne faut absolument pas jeter vos kanbans, mais les archiver précieusement.

Dans mon exemple, vous avez pu constater que le flux n’est pas continu : une fois qu’un développeur a glissé un post-it de la colonne « sélectionnées » à la colonne « développement », le product owner devrait en théorie sélectionner à nouveau une nouvelle tâche pour maintenir le nombre d’étiquettes constant dans chaque colonne (hormis celle du backlog bien entendu). Mais pratiquer de cette façon peut avoir un effet pervers : si aucun des développeurs ne veut s’occuper d’une tâche, celle-ci restera sélectionnée tant qu’il y en aura d’autres à développer. Comme dans toutes les méthodes Agile, chacun est censé être responsable, mais comme dans toute équipe, le facteur humain est à prendre en compte. De plus, « assoiffer » les développeurs permet d’imposer à l’équipe de faire le point à une fréquence fixée par le product owner. Si dans mon exemple on considère que chaque développeur pourra mettre en place 4 fonctionnalités par jour (parce qu’elles sont simples), le fait de n’en mettre que 2 à disposition de chacun forcera l’équipe à faire un point à la fin de la demi-journée.

separateur

Et Scrum dans tout ça ?

Je vous ai annoncé un peu plus tôt que Scrum et Kanban peuvent cohabiter sans aucun soucis, les deux méthodes sont à la fois Lean et Agile, les différences entre ces deux philosophies sont finalement assez minimes et il faut se pencher sur la question en détails pour faire le tour de la question. Je ne vais donc pas développer ce point ici mais plutôt vous proposer un document qui prend le temps de le faire … en 128 pages. Si vous avez un peu de temps à consacrer à cette lecture, vous verrez que c’est un excellent ouvrage. Rendez-vous donc ici pour le consulter.

separateur

Alors ? N’avez-vous jamais été confronté(e) à un projet aussi bancal que celui-ci ? N’avez-vous jamais utilisé cette méthode sans même savoir comment elle s’appelait ou d’où elle provenait ? Comme toujours les commentaires sont à vous, n’hésitez pas à en abuser !

RSS
Follow by Email
Facebook
Google+
http://www.responsive-mind.fr/methode-kanban/
Twitter
Gestion de projets avec la méthode Kanban

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *