29 septembre 2021
La méthode KANBAN
Principes du système KANBAN
Le système KANBAN (étiquette en Japonais) est à la base un process d’optimisation industrielle mis au point par TOYOTA pour gérer sa production de véhicules en flux tendu.
Dans le cadre du développement web, travailler en KANBAN signifie : adopter un procédé AGILE de collaboration facilitant la visualisation du workflow des tâches à effectuer.
Concrètement et dans sa forme minimaliste, KANBAN se matérialise sous la forme d’un tableau sur lequel on colle des étiquettes représentant des tâches. Ce tableau se matérialise basiquement sous la forme de 3 colonnes (A faire, En cours, Fait). Les tâches se déplacent de gauche à droite. La base est aussi simple que cela, le reste relève du sur mesure.
Ainsi que mentionné plus haut, KANBAN relève de la méthodologie AGILE. Par habitude, on la compare à sa concurrente, SCRUM, pour en comprendre les différences. Comme nous le verrons par la suite, la réalité est un peu plus complexe, puisque ces dernières peuvent se compléter et donner lieu à des process hybrides.
On peut cependant affirmer que KANBAN permet plus de réactivité, car n’est pas assujetti à des sprints de développement.
Les rituels peuvent aussi être épurés. On conserve le Daily Meeting du matin qui se doit d’être court et concis. On y associe parfois l’attribut « Stand Up » Daily Meeting pour renforcer cette notion de brièveté. On sait en effet que pour l’homme sédentarisé, la station debout devient difficilement supportable au-delà de 30 minutes.
Pas d’itération signifie donc flux continu ou tiré et non poussé, par opposition à SCRUM qui ne modifie pas un Sprint en cours et attend systématiquement le début d’une nouvelle itération pour intégrer des User Stories (US).
Pour commencer à adopter un mode de travail AGILE, il est d’ailleurs plus facile de commencer par KANBAN car sa structure est plus « hybridable ».
On reprend ainsi le flux de travail existant et on le transcrit sous la forme d’un tableau matérialisant le workflow du projet.
Une fois ce process modélisé, on travaille dessus pour l’améliorer. Ainsi lorsqu’une colonne accumule du travail, on doit réfléchir à une solution pour l’optimiser afin de ne pas créer de goulet d’étranglement. On s’interdit d’avoir plus d’un certain nombre de tâches à un moment donné dans une colonne donnée. Pour ce faire, on pourra déplacer temporairement les tâches de chacun afin de pouvoir venir en aide sur le sujet source de blocage.
De manière générale, on pose les fondations de KANBAN sur 4 grands principes, eux-mêmes associés à 6 pratiques centrales.
Les principes :
- On démarre en suivant ce que l’on fait actuellement et en y apportant des changements continus
- On respecte les rôles et les hiérarchies actuels afin de ne pas freiner son adoption
- On encourage chaque collaborateur au leadership
- On accepte l’évolution au sein de l’équipe
Les bonnes pratiques :
- On visualise le workflow
- On explique clairement les règles de fonctionnement du flux (DOR/DOD)
- On limite le nombre de taches en cours (WIP) pour ne pas créer de goulets d’étranglement
- On évalue et mesure chaque stade du workflow
- On met en place des boucles de feedbacks
- On s’efforce de créer une dynamique d’amélioration collective
Quand dois-je utiliser KANBAN ?
SCRUM est très adaptée à la construction d’un produit (BUILD). A l’inverse, KANBAN fonctionne très bien lorsque l’on est en phase de RUN. Attention, cela ne signifie pas qu’un projet de BUILD sera automatiquement lié à une méthodologie SCRUM, lorsqu’un projet en phase de RUN se fera systématiquement en KANBAN. L’un comme l’autre peut être adapté à chaque situation. De façon empirique, il est cependant généralement observé que KANBAN se prête mieux au RUN et aux demandes d’évolutions.
Notons que les deux méthodes SCRUM et KANBAN peuvent être utilisées en parallèle car elles se complètent. C’est le cas de l’approche SCRUMBAN qui se veut le meilleur des deux mondes en s’organisant avec des itérations de développement, mais sans backlog. Les user stories (US) et tâches à réaliser sont ainsi incorporées au fil du sprint. Les rituels restent iso par rapport à SCRUM. Quoiqu’il en soit, la règle à retenir dans ces types d’organisations est qu’il n’y a pas vraiment de règles et que la collaboration au sein d’une équipe se détermine collégialement en fonction des aspirations des membres qui la composent.
KANBAN/SCRUM, avantages et inconvénients
Au-delà du fait que la principale différence entre les deux est qu’il n’y a pas de sprint en KANBAN, on pourra répertorier pour chacune des techniques les avantages et inconvénients suivants :
|
|
SCRUM |
KANBAN |
|
Avantages |
· Adaptée lorsque l’on construit un produit (phase de BUILD) · Aboutit très rapidement à un prototype testable (MVP) · Favorise l’autonomie pour accomplir la mission · Encourage la capacité des équipes à s’auto-organiser |
· Très bonne visibilité du workflow · Flexibilité dans la modélisation du flux de travail · Particulièrement adapté pour du RUN · Cadre très léger, très simple à mettre en place. Se prête à « l’hybridation » · S’adapte bien aux grosses équipes · Plus adapté lorsque l’on a moins de vision produit · De fait, mieux adapté à des types de tâches qui ne rentrent pas dans un sprint
|
|
Inconvénients |
· Tendance à « charger la mule » en début de sprint pour être sûr que le maximum soit fait. · Flux poussé : on doit attendre la fin du sprint pour modifier le scope des fonctionnalités à développer (15 jours en général) · Beaucoup de rituels et réunions qui deviennent chronophages pour l’équipe · Cadre lourd, moins flexible |
· Pas de « deadline » matérialisée par une fin de sprint. On avance à son rythme · Parfois lorsque le flux est saturé, il est plus pertinent de ne rien faire. En effet, si on continue de produire, on génère du stock qui contribuera à engorger de plus belle le workflow · On a moins la vision produit, on sait moins où l’on va d’un point de vue macro. |
Un exemple concret
Sur le centre de services Goweb, le cœur de l’activité se centre sur la création d’applications sur mesure avec une partie RUN et des demandes d’évolutions. Il était logique de nous tourner vers une méthode KANBAN garantissant une plus grande réactivité et flexibilité pour nos clients.
Typiquement, le workflow est organisé autour de colonnes suivantes : Product Backlog, Prêt à traiter, En cours, Terminé, Recette, A MEP, MEP DONE.
Le Product Owner intègre ses US au backlog et y note un certain nombre de critères d’acceptation qui permettront de la valider. Ces US sont discutées en daily meeting à l’initiative du Scrum Master puis passent en prêt à traiter. Chaque US se voit attribuer un domaine d’intervention (Intégration, Dev Front, Back, Design…) et les membres de l’équipe viennent « piocher » dans la colonne « prêt à traiter » les US en fonction de leurs compétences et du degré d’urgence. Les cartes sont estimées en Poker Planning et traversent ensuite le tableau de gauche à droite jusqu’à leur mise en production.
Comme le montre la capture ci-dessus, Goweb utilise un support numérique pour son tableau KANBAN (Trello pour ne pas le citer). Il en existe pléthore et nous recommandons vivement leur utilisation vs tableaux et post-it traditionnels, car un post-it qui tombe/traine par terre/s’auto-détruit c’est une fonctionnalité non développée à temps et un client attristé ☹
Liens utiles
SCRUM par Goweb : https://www.goweb.fr/web-sur-mesure/methodologie-scrum/
Manifeste AGILE : https://agilemanifesto.org/iso/fr/manifesto.html
SCRUBAN : https://en.wikipedia.org/wiki/Scrumban
