[Total : 0    Moyenne : 0/5]

Le Kanban, outil clé de Juste A Temps, a été adapté pour servir d’outil de gestion de projet.

Introduction

La méthode Kanban, un terme qui signifie “étiquette” en japonais, est un outil de gestion de projet. Dérivé du Kanban utilisé dans le Juste A Temps, il a été adapté pour améliorer la visualisation et la planification de projet.

Le Kanban est l’outil de Agilité le moins normatif. Il est très ouvert et les seuls « contraintes » sont la visualisation du travail et la limite du WIP. Beaucoup moins contraignant que les dizaines de règles de la méthode RUP et un peu moins que le SCRUM qui nécessite, entre autres, la mise en place d’une équipe multidisciplinaire (Product Owner, Master SCRUM, SCRUM Team),et l’obligation d’itérations.

Etape 1 – Diviser le cycle de travail

La première étape consiste à créer une norme pour la progression des actions. Nous pouvons choisir les étapes Conception, Test, Validation … Néanmoins, la plupart du temps, nous trouverons le cycle de type PDCA :

  1. Plan – A faire : Liste des actions à effectuer.
  2. Do – En-cours : Toutes les tâches que nous faisons.
  3. Check – A vérifier : Ensemble des tâches terminées que nous surveillons et vérifions.
  4. Act – Fini: Des tâches qui sont OK et que nous avons livrées au client.

 

Il faudra détailler les critères pour passer d’une étape à l’autre :

  • Plan : Le but de la tâche et les critères d’acceptation sont clairs.
  • Do : L’action est correctement effectuée et nous sommes sûrs à 90% qu’elle sera validée.
  • Check : Nos tests internes sont OK et le client a validé.
  • Act : Les éléments sont livrés et intégrés au reste du projet.

Etape 2 – Identifier la limite du WIP

De la même manière que pour un Kanban «traditionnel», celui-ci utilisera le principe de flux tiré.

L’adaptation de ce principe à la gestion de projet entraîne la mise en place d’une limite de tâches à chaque phase du développement. C’est la différence entre un diagramme d’avancement standard utilisé dans la méthode SCRUM et la méthode Kanban :

  • Le SCRUM  limite l’encours au SPRINT dans son ensemble, car nous demandons de réaliser un certain nombre de Story Points au cours du SPRINT.
  • Le Kanban limite la quantité de travail en cours dans le flux de travail, indiquant ainsi que nous ne pouvons pas tout bouger en même temps, mais avancer progressivement.

Notez que cette limite s’applique à la user story et non au nombre de tâches résultant de la user story (story point). De plus, seule la dernière étape n’a pas de WIP.

L’utilisation de WIP n’a de sens que si nous avons des tailles cohérentes de User Story. En effet, si nous mettons une limite à 3 User Story en C mais que nous en avons 2 d’une taille de 1 et 1 d’une taille de 100, nous risquons de subir une forte variabilité dans notre processus et de perdre l’intérêt de son utilisation. Pour éviter cela, nous pouvons :

  • redécouper la plus grande user story en plusieurs user story.
  • définir la limite WIP en termes de Story Point et non de User Story.

Quel est le bon WIP ?

Il n’y a pas de règle définissant la bonne valeur du WIP. Tout est une question d’ajustement. Quelques exemples :

WIP

Description

What to do ?

Do : 1

Check : 1

Le travail avance très vite et la carte kanban passe rapidement en phase de vérification. Mais la phase de vérification est plus longue. Ainsi, les équipes en charge de Do attendent que la fiche de contrôle passe à Act.

Augmentez le WIP de la phase Check ou engagez plus de personnel pour effectuer le contrôle et vous rapprocher ainsi du système One Piece Flow.

Do : 8

Check : 2

La phase de vérification ne peut pas être effectuée car l’équipement de contrôle est en panne. Les équipes de la phase Do avancent jusqu’à ce qu’elles aient 8 Kanban terminées qu’elles ne peuvent pas transmettre. Ils réagissent ensuite pour aider à réparer l’équipement.

Nous pourrions alors réduire le WIP de la phase Do. Cela aurait pu nous permettre de résoudre le problème plus rapidement, donc obtenir un meilleur délai d’exécution global.

Etape 3 – Mettre les cartes

Ensuite, nous mettrons le Kanban sur le tableau (un espace d’environ 1 m de haut et 2 m de long sur un mur). Initialement, toutes nos cartes seront dans la phase de planification, le nombre étant égal à la limite WIP que nous avons fixée pour le moment..

Au fur et à mesure que le projet avance, les Kanban avanceront au tableau. Pour savoir quel est le prochain kanban à traiter, nous allons donc définir des règles de fonctionnement. Voici quelques exemples :

  • Utilisez le principe FIFO premier entré, premier sorti, en fonction des dates sur les cartes.
  • Prendre une story liée à une nouvelle fonctionnalité plutôt qu’à celle liée à la maintenance.
  • Prendre la story ayant la plus grande taille en premier.

Etape 4 – Mesurer le temps de cycle

Pour chaque user story, nous déterminons le délai moyen de réalisation qui représente le délai qu’il a mis entre son entrée dans la phase de planification et sa sortie de la phase d’acte. Cet indicateur est directement lié à Velocité :

  • Le temps de cycle représente le temps moyen nécessaire pour terminer une tâche.
  • La vélocité est le nombre de tâches par unité de temps
  • En d’autres termes, si notre temps de cycle est de 3 jours, notre vitesse de travail pour 2 semaines de travail (10 jours) sera de 3,33. Inversement, si une équipe a une vitesse de 15 tâches en 10 jours, notre temps de cycle sera de 0.66..

Le challenge consiste à calculer un délai moyen de réalisation prévisible et à s’engager à respecter les délais de livraison..

Il est recommandé de recalculer le temps de cycle moyen à chaque fois qu’une carte termine la phase Act. Cela permet de disposer des données les plus récentes possibles et d’améliorer notre réactivité en cas de problème..

Etape 5 – Itérer pour améliorer

Le coeur du Kanban est de s’améliorer continuellement. À différents moments, nous effectuerons des itérations pour améliorer nos processus. Cette phase n’est pas structurée de la même manière que la méthode SCRUM, mais est cependant largement incluse dans la philosophie..

Plusieurs moyens sont possibles pour améliorer le processus :

  • Réduire le temps de cycle : nous pouvons étudier le temps moyen d’achèvement et analyser pourquoi certains ont été plus longs que d’autres.
  • Identifier les goulots : IIl est possible que plusieurs fois au cours du projet, la phase DO soit pleine alors que la phase CHECK est vide par exemple. La phase Do est notre goulot d’étranglement, ce qui nous empêche de rendre le travail plus fluide.

La carte Kanban

Au minimum, la carte Kanban doit contenir les éléments suivants :

Date d’entrée dans la phase PLAN
Date de sortie de la phase ACT
Une brève description de la user story et des tâches associées, ainsi que sa taille.
Le responsable Kanban pour la phase en question. En effet, il est possible que la personne pour la phase CHECK ne soit pas la même que la personne en phase DO.

La méthode Kanban est très flexible. C’est à l’équipe de construire son Kanban. Si par exemple vous voulez respecter le FIFO entre chacune des phases, vous devrez alors ajouter sur la carte les dates pour chacune d’elles (principe adapté si les temps de traitement sont similaires).

Kanban, un outil d’aide à la planification

L’un des grands intérêts de l’outil Kanban d’aide à la planification est de pouvoir visualiser les différents niveaux de priorités. Pour cela, l’outil propose d’ajouter des logos sur chaque carte en fonction de son statut..

Le tableau ci-dessous donne un exemple de logo et de cas spécifique. Bien sûr, vous pouvez l’adapter à votre contexte.

Indique le niveau de priorité de la story. Ce n’est pas sa priorité générale au niveau du projet, mais par rapport aux tâches en cours.

Indique que ce qui devait être fait est fait et que la carte peut être prise par l’équipe de la phase suivante lorsqu’elle sera prête.

Indique qu’il existe un point bloquant pour cette action. La personne qui met ce logo doit indiquer pourquoi le kanban est bloqué. Les raisons peuvent être très diverses : on attend des informations d’un fournisseur, le kanban n’est pas bien défini et nécessite un examen….

Vous pouvez également définir différentes couleurs de cartes Kanban en fonction du type de tâche à exécuter. Par exemple, pour les tâches liées à de nouveaux projets, elles peuvent être placées sur une carte bleue et les tâches liées à des problèmes de projets plus anciens sur une carte verte. Il sera plus facile de créer les règles de décision avec par exemple: les 2 cartes bleues, je prends un green.

Source

H. Kniberg, M. Skarin (2010) – Kanban et Scrum – Tirer le meilleur des deux

J. W. Reeves (1992) – What is software design ?

M. Poppendieck et T. Poppendieck (2007) – Implementing Lean Software Developement

T. Ohno (1978) – Toyota Seisan Houshiki

Share This