top of page
Rechercher

Définir les limites WIP (Work In Progress) de travail en méthode agile "KANBAN".

Photo du rédacteur: Abdellah MANNIOUIAbdellah MANNIOUI

Parmi les cadres de travail agiles les plus fréquemment utilisés on trouve la méthode "KANBAN" qui a été lancé officiellement par "David Anderson" en 2010, cette méthode se base sur la visualisation du processus et du flux des travaux en cours à travers un tableau de bord Kanban affiché sur le mur (Management visuel).


L'objectif principal de la méthode "KANBAN" est d'éviter toute surcharge du système pour établir un équilibre entre les demandes entrant et la capacité de production du Workflow en question à travers le principe du flux tiré et pas le flux poussé. C'est pour cette raison qu'il est fortement recommandé d'éviter le multitâche qui consomme plus de temps par rapport au travail mono-tâche.


Lors de la définition et l’initialisation de notre système Kanban dédié à note projet, l'équipe doit se mettre d'accord sur les étapes séquentielles constituant le Workflow (Exemple : To Do, In Progress, In test, DONE), sachant que l'ensemble des tickets à traiter doivent passer par l'ensemble des étapes de ce Workflow. Et c'est où intervient une notion intéressante dans "KANBAN" qui est la limitation du travail par étape, ou le "WIP" (Work In Progress).





Le principe de la limitation du travail consiste à définir un nombre limité de tâches (cartes, ou tickets) en cours possible dans chaque colonne de notre système Kanban, ou bien sur ensemble des étapes à la fois. Ce principe de limitation présente plusieurs avantages, en occurrence :


  • Identifier et visualiser les problèmes et les perturbations.

  • Favoriser le mono-tâche sans avoir trop de tickets à traiter à la fois.

  • Occuper les ressources à 100%.

  • Identifier rapidement les goulots d'étranglement.

  • Réduire le temps de traversée des tickets dans le Workflow.

  • La satisfaction du client (Qualité et délais).

Afin d'optimiser notre flux et Workflow de travail en Kanban, on peut définir les limites WIP soit sur une étape ou un groupe des étapes selon le besoin, aussi bien on peut faire appel à deux types de limites "WIP", on parle des limites basses et hautes, du coup on a deux cas de figure :


Limites basses :


On définit une limitation minimum sur une ou plusieurs étapes afin d'occuper toute l'équipe qui travaille sur cette étape, ainsi que par exemple pousser les gens qui travaille dans l'étape précédente à préparer suffisamment de travail à faire. comme ça on peut s'assurer qu'il y'a assez de tâches à prendre en charge par l'équipe. aussi bien c'est pour définir une activité minimale sur une ou plusieurs étapes du Workflow.


Cela a un autre avantage, c'est le fait de donner la possibilité à l'équipe qui travaille sur une étape du Workflow d'ajouter d'autre tâches complémentaires (Exemple : Remaniement du code, Traitement de la dette technique, Développement des composants techniques réutilisables, la documentation, ...Etc.).


Limites hautes :


On définit une limitation haute sur une ou plusieurs étapes du Workflow afin de ne pas surcharger l'équipe en respectant sa capacité de production, et pour éviter ce qu'on appelle les "Goulots d'étranglement" que j'ai traité dans un autre article sur mon blog agile. Et cela dépend du nombre de participants et intervenants sur chaque étape du Workflow.


Conclusion :


Le principe des limites WIP est très important dans la vie d'un projet gérer avec la méthode agile Kanban, et on peut même s'inspirer de cette pratique afin de l'appliquer sur un projet agile en Scrum par exemple ou géré par une autre méthode agile (XP, RAD, DSDM, Scrumban, ...Etc.).


Les limites WIP sont différentes pour chacun des projets et équipes, et en effet il n'y a pas de règle générale permettant de définir les valeurs de ces limites (hautes et basses), mais c'est l'expérience sur terrain qui va permettre à chaque équipe de trouver la bonne combinaison de ses valeurs, et cela à travers des discussions, des expérimentations, et des mises en situation, et tout ça dans le cadre du processus empirique de l'agilité.

24 vues0 commentaire

Posts récents

Voir tout

Comentários


Post: Blog2_Post
bottom of page