Introduction à Kanban (2e partie)
Comme nous l’avons vu précédemment, le système Kanban appliqué au développement logiciel est somme toute assez éloigné de la méthode qui en est la source, inventée au Japon pour fabriquer des automobiles, si ce n’est une certaine communauté d’objectifs et bien sûr l’usage de fiches pour la régulation du flux. La première recommandation pour appliquer le système est la visualisation du processus et du flux des travaux. Dans la pratique, cette visualisation est tout à fait centrale et se matérialise presque toujours sous la forme d’un tableau de bord Kanban.
La limite de TEC/WIP
L’idée fondamentale de Kanban est d’éviter toute surcharge, de maintenir un équilibre entre demande et capacité de production, présupposant que l’on travaille moins efficacement lorsque l’on croule sous les tâches multiples, ce qui peut effectivement souvent se vérifier — même si, contrairement à certaines affirmations, le multitâche n’est pas forcément synonyme de surcharge. Ainsi, la personne qui gère les demandes du métier (user stories), souvent un chef de produit (product owner), doit donc se restreindre dans le nombre de ses demandes simultanées, en fonction des capacités de traitement de la première équipe en aval, généralement les développeurs. Dans le bon fonctionnement de Kanban, une grande responsabilité repose sur les épaules de la ou les personnes qui préparent les tâches en amont, notamment dans le découpage et la hiérarchisation.
Pour ce faire, chaque équipe fonctionnelle se voit affecter un nombre limite de tâches en cours possibles (TEC, ou WIP, Work-In-Progress Limit). Ce système, qui veut rendre impossible d’introduire une charge de travail supérieure aux possibilités, est en partie un système de protection du bien-être des développeurs, permettant d’outrepasser des impératifs supérieurs (du client, du patron, du vendeur, etc.) et d’échapper à une pression excessive, au bénéfice de la qualité selon ses promoteurs.
Le tableau de bord
Le tableau Kanban, pièce essentielle, présente les activités successives par colonnes allant de gauche à droite, l’axe horizontal représentant ainsi le temps. Le processus débute à gauche et s’achève à la dernière colonne à droite. La première colonne à gauche est la file d’attente (backlog) où sont stockées les tâches à réaliser, ces tâches résultant généralement d’un découpage des demandes métier. Entre le début et la fin, chaque équipe fonctionnelle dispose, par ordre d’intervention, d’une colonne. Une colonne d’activité peut être divisée en sous-colonnes, par exemple “à faire” et “fait”, s’il est utile d’avoir un tampon.
Bien entendu, pour créer ce tableau, il faut déjà avoir une idée précise des processus en œuvre pour livrer du logiciel. En collaboration avec tous les acteurs, la première étape est toujours de bien formaliser le processus tel qu’il existe, le cartographier en quelque sorte. Kanban ne propose pas de processus général ou idéal, mais une technique de contrôle du flux à travers le processus, l’objectif premier étant de fluidifier au maximum. Ainsi, Kanban s’adapte à tout processus préexistant et ne nécessite aucune révolution de l’organisation comme la méthodologie Scrum par exemple. Cela dit, il pourra peut-être vous aider ultérieurement à revoir votre processus pour l’améliorer.
Sur le tableau, les tâches arrivent donc par la gauche et voyagent de colonne en colonne vers la droite. Aucune tâche ne peut se déplacer dans une colonne complète, c’est-à-dire lorsque la limite des tâches en cours est atteinte. L’importante idée de base est que l’on doit avoir terminé une tâche avant d’en prendre une nouvelle.
Dans notre exemple, nous voyons le backlog rempli de tâches en attente. Un chef de produit (product owner) va se charger de sélectionner et hiérarchiser les six premières tâches, qui seront prises en charge par une équipe de deux analystes fonctionnels, puis par une équipe de cinq développeurs et enfin, par un chargé du déploiement.
Les sous-colonnes hachurées sont des zones de tampon pour des tâches traitées, dans l’attente de passer à une étape suivante.
La limite de 6 aux tâches sélectionnées est ici arbitraire, elle permet juste de donner une vision à l’ensemble de l’équipe de ce qui va venir dans un proche avenir, surtout si le backlog est touffu. Ici, la colonne “sélectionné” peut être considérée comme la partie émergée de l’iceberg. On a déterminé que les analystes ne peuvent traiter que 2 tâches à la fois, les développeurs, 4 tâches et, on ne peut mettre en production qu’une seule tâche à la fois. Ce sont les limites de TEC/WIP (tâches en cours, Work-In-Progress).
Six tâches ont été sélectionnées et hiérarchisées : la première à traiter est celle en haut de la colonne, soit A en l’occurrence.
Du temps a passé… Les tâches A, B, C et D sont achevées. Chaque équipe est au maximum de ses limites de tâches en cours. Après consultation de l’équipe, le chef de produit décide de remettre P dans le backlog pour pouvoir le remplacer par R devenu plus prioritaire — il s’agit de toujours respecter la limite de 6.
Le tableau permet de repérer vite où sont les goulots d’engorgement dans le flux — une colonne tampon toujours pleine est un bon indice — ainsi que les blocages accidentels. Le but de l’ensemble des acteurs est de limiter la durée du cycle, soit le temps moyen pris par une tâche pour traverser tout le tableau. Contrôler en continu cette durée de cycle est aussi un bon indicateur de gestion.
Gestion d’incident
Allo, Houston, nous avons un problème… Nous n’arrivons pas à mettre E en production ! Ça fait des heures et nous n’y arrivons pas !
C’est l’engorgement majeur. Les développeurs ont terminé leurs tâches et n’ont plus rien à faire, de même que les analystes. Vous pourriez alors penser que dans ce cas, les développeurs pourraient prendre en charge J et K qui sont prêts, et les analystes, L et M, en attendant que le problème à la mise en production soit résolu. Mais cela n’est pas la philosophie Kanban, on ne dépasse pas sa limite de WIP, même si toutes les tâches sont faites. L’objectif premier est d’atteindre et conserver un flux constant, avec des livraisons régulières. La priorité en cas d’incident est donc de rétablir la cadence en résolvant sans délai le problème bloquant la chaine.
Ainsi, dans notre situation, toutes les personnes en mesure d’aider le déploiement s’y consacrent et donnent un coup de main. Ceux qui ne peuvent rien apporter font autre chose, mais ne prennent pas des tâches si leur limite est atteinte. Ils peuvent suivre des cours en ligne, ranger leur bureau, faire un championnat de baby-foot, ou toute autre activité constructive. Mais rien, vraiment rien qui puisse faire dépasser leur limite de TEC/WIP.
Voie d’urgence
Il est possible de créer une voie express sur un tableau Kanban, permettant par exemple de gérer des bogues critiques découverts sur une version déjà en production ; une faille de sécurité serait un bon exemple de situation à traiter sans délai. Cette voie est strictement réservée aux réelles urgences. Une tâche mise sur cette voie oblige à suspendre les tâches en cours pour la traiter immédiatement. C’est l’exception où le dépassement des limites de TEC/WIP est autorisé.
À retenir
Il faut comprendre qu’un Kanban ne peut être parfait et figé dès le début, et que c’est une représentation dynamique qui doit être adaptée et perfectionnée dans le temps. C’est un outil qui peut par exemple révéler des problèmes dans le processus et ouvrir la porte à des améliorations. Les limites de WIP ne sont pas non plus absolument gravées dans le marbre, on peut les outrepasser en cas de force majeure ou encore les ajuster. Kanban est un outil vraiment flexible d’optimisation du flux.
Bien sûr, il y a bien d’autres possibilités et des dispositifs plus sophistiqués avec Kanban, mais nous sortirions du cadre d’une introduction exposant le fonctionnement général.
—
