Il y a 13 ans -
Temps de lecture 4 minutes
Devoxx – Jour 1 – Kanban in action
Après un petit café revigorant, voici déjà venir les premières sessions de l’édition 2009 de Devoxx et, le sujet de cet article, Kanban in action par Olav Maassen.
Après un petit rappel sur les origines du mot (qui en kanji signifie kan=visuel et ban=tableau, carte, fiche), le deuxième slide donne le ton de cette conférence qui sera interactive (plusieurs travaux pratiques sur les 3h) avec une première question : donnez quelques exemples quotidiens de système Kanban. Plusieurs réponses affluent dont :
- le parking avec un flux de voitures entrantes bloqué si toutes places du parking sont pleines ;
- la toilette des enfants avec une baignoire qui ne contient qu’un enfant à la fois (dès qu’un enfant a terminé, l’autre prend sa place) ;
- le speaker retiendra Mac Donalds (et oui) avec la gestion du stock de burger disponible : une pancarte métallique qui, une fois déplacée au dessus des rails de burgers vides, signifie qu’un burger n’est plus disponible, il faut alors en produire.
Ces exemples tournent autour de 2 principes : la capacity constraint (par exemple une autoroute, toujours disponible mais dépendante du flux) et la non-instant availability (par exemple un ferry qui une fois en mer n’est plus disponible). Un des principes du Kanban est de rendre certaines choses visuelles : voir l’indisponibilité de hamburgers marqués par un token en est un bon exemple.
Les freins
La présentation se focalise ensuite sur les mauvaises pratiques de nos projets d’entreprise faisant que Kanban sera difficile à mettre en place.
Les projets avec deadline (surtout quand celle-ci se rapproche) ont fait débat dans la salle. Pour les conférenciers, les mauvais choix qui peuvent être faits par l’entreprise sont : le report du projet, engager plus de personnes ou faire beaucoup d’overtime :) Et quel que soit le cas, des choix malheureux risquent d’être faits : ne plus rédiger les spécifications, réduire voire supprimer les tests unitaires, privilégier la vitesse de production à la qualité du code (tout ceci dans un but de gain de temps) ! Vous l’aurez compris, et ce n’est pas forcément spécifique à Kanban, nous sommes ici en présence de mauvaises pratiques reconnues et difficilement récupérables par la suite.
Pour rester dans les mauvaises pratiques, Olav nous propose un TP, comment construire ou détruire la confiance dans une équipe. Cacher de l’information, manquer de confiance en l’équipe, ne pas donner de responsabilité à l’équipe… La destruction est assez facile à illustrer, la construction ressortira surtout de l’implication de l’équipe dans le projet et les décisions.
Une petite comparaison orale (pas de trace !) avec Scrum ou Lean nous permet de constater qu’il n’y a pas de planning poker ou de session d’estimation. En effet, cela ne représente pas une valeur fonctionnelle métier pour le client (<troll>c’est du temps perdu !</troll>). Au niveau des réunions, et plus particulièrement le stand-up meeting, les 3 questions habituelles de Scrum sont remplacées par un bref regard global sur le tableau afin de voir si tout se passe bien. En général, voir s’accumuler des post-it dans une colonne n’est pas bon signe et c’est ici que l’équipe intervient et que le stand-up devient plus animé.
Kanban à la rescousse !
Le décor est planté, la salle a les idées claires sur ce qui va, ne va pas ou peut encore être amélioré sur nos projets, il est grand temps de présenter formellement le sauveur Kanban (avec au passage un bon article de présentation sur InfoQ). Kanban insiste sur plusieurs points :
- la qualité,
- réduire le work in progress, livrer le plus possible,
- équilibrer demande / livraison,
- prioriser,
- réduire les variables et améliorer les processus.
Les étapes de mise en place sont résumées ainsi :
- s’accorder sur les objectifs,
- définir la value stream mapping (analyse des flux de besoins),
- définir des inputs de contrôle,
- définir le done,
- définir un set de tâches de travail,
- rencontrer les parties prenantes du projet (amont et aval),
- créer votre tableau Kanban (Kanban board) qu’il soit physique ou électronique (idéal pour les équipes distribuées).
A cela, il est possible d’ajouter différentes métriques telles que le Work In Progress, la qualité de code, la durée moyenne des tâches, le temps perdu (obstacles, bugs, manque d’information…).
Tout comme Scrum, Kanban arrive avec plusieurs bonnes pratiques mais ne pourra pas résoudre certaines lacunes comme un manque total de communication dans l’équipe, ou une organisation qui freine les changements… Dans un souci d’amélioration continue, Kanban propose plusieurs étapes afin de résoudre les fameux bottleneck du Lean (trouver la contrainte, définir une résolution possible, appliquer, trouver la contrainte suivante).
Conclusion
Tout ceci (qui ressortira plusieurs fois durant la présentation) a pour but d’obtenir les effets positifs suivants : confiance (Trust), travail d’équipe (Teamplay), transparence (Transparency).
Plusieurs questions sur la difficulté de mise en place de Kanban sont posées lors du Q&A de fin de session. Le speaker insiste sur le fait qu’en effet cela n’est pas trivial, mais les gains sur le long terme sont plus qu’avantageux.
Quelques liens pour approfondir ce sujet:
Commentaire