Agile et Kanban
Dans le monde Agile, on parle souvent de Kanban, qu’est-ce donc ?
Origine du Kanban :
Le Kanban est un outil du lean management qui, selon Taichi Ohno est un des moyens permettant d’atteindre le JIT (Just In Time). Il permet à un ensemble de processus de fonctionner en flux tiré en mettant en place un certain nombre de règles que toutes les équipes travaillant sur un projet se doivent de respecter.
A quoi sert Kanban ?
Le Kanban sert à matérialiser les tâches en cours dans un projet et à savoir qui s’en occupe.
Le Kanban est, à la base, une façon de représenter graphiquement des informations sur des cartes.
Il peut être utilisé pour décrire des tâches ou surveiller des stocks.
Mais il peut également servir d’outil de gestion de l’état d’avancement d’un projet.
Il couvre alors toutes les activités (et tous les départements) de ce projet depuis le département marketing et les premières idées sur un nouveau produit jusqu’à la réalisation et enfin jusqu’à la livraison.
Les 4 principes kanban :
· Visualiser la production actuelle
· Identifier les goulots d’étranglement et les traiter si l’on en trouve pour lisser l’activité
· Améliorer les processus de production en continu par l’utilisation du flux tiré
· Atteindre le « Kaizen » (amélioration continue) à partir des 3 éléments précédents : il faut optimiser la façon dont se déroulent tous les processus pour obtenir l’activité la plus lissée possible et, de ce fait, éviter les à-coups de production et donc les gaspillages de toutes sortes (stocks, personnes inactives …)
5 pratiques Kanban pour améliorer les processus :
• Visualiser le flux
• Limiter le travail en cours
• Gérer le flux de travail
• Rendre explicite les règles de gestion du processus
• S’améliorer de manière collaborative
Comment utiliser Kanban :
Dans le cas de la gestion des tâches à effectuer (dans un projet informatique typiquement), cela prend en général la forme d’un tableau (un peu comme la représentation d’une usine et de ses différentes parties) recouvert de post-it symbolisant des User Stories à compléter.
Le kanban va en général être découpé en plusieurs zones, typiquement selon les équipes (ou les aspects « métier » concernés) :
· Il existe des tâches « normales » et des tâches « critiques » (en général en retard). Pour chaque zone on peut décider de faire passer un certain nombre de tâches en statut « critique ». Ce nombre est désigné à l’avance et est en général fait pour ne pas tomber dans le travers de planification qui consiste à estimer que tout est critique (si toutes les tâches deviennent critiques, la notion de criticité n’a alors plus aucun sens) · S’il y a une tâche « critique » pour une équipe, elle doit se concentrer exclusivement sur celle ci avant d’envisager autre chose.
· Il y a un nombre maximum de tâches que l’on peut faire entrer dans chaque zone du Kanban et ce afin d’éviter les goulots d’étranglement. L’idée sous-jacente est que les équipes de chacun des domaines couverts par le projet ne travaillent pas forcément à la même vitesse (parfois tout simplement parce que cela n’est physiquement pas possible). Cela amène chaque équipe, de façon incidente, à prioriser son travail de sorte à produire très tôt les éléments les plus importants (ceux produisant la plus forte valeur ajoutée) pour que la production à un instant t intègre la plus grande valeur ajoutée possible en fonction de ce que l’on souhaite produire.
· D’autres règles encore peuvent venir se greffer sur un Kanban mais elles sont en général spécifiques à un projet. L’idée est de mettre à disposition de tous un outil adapté plutôt qu’un frein.
Une telle représentation graphique permet à chaque personne qui travaille sur le projet de pouvoir facilement consulter son avancement ainsi que les éventuels points de blocage et ce sans être technicien ou spécialiste en méthodologie. Le principal but d’un tel outil est que l’état d’avancement du projet soit « abordable » pour n’importe qui, y compris quelqu’un ne faisant pas partie de l’équipe projet. Une telle représentation fournit un support autour duquel toutes les équipes travaillant sur le projet peuvent discuter et, au besoin, se mettre d’accord sur les prochaines actions à effectuer avec l’avantage d’être un outil « concret » (on déplace les post-its, les reformule …), et qui oblige à formuler ce que chaque User Story implique.
Le tableau Kanban :
Le tableau Kanban est constitué de 3 colonnes:
– à faire (To Do)
– en cours (In Progress)
– fini (Done)
Quelquefois la colonne « en cours » est séparée en 3 colonnes:
– en cours de développement
– en cours de tests
– en cours de livraison
Kanban et flux tiré :
• la planification ne s’effectue plus par mesure de la vélocité dans une itération
• on cherche à garantir un temps de traversée
• on impose des limites de stock sur les colonnes d’états du tableau des items (par exemple, pas plus de 3 items en cours de développement)
Temps de traversée et de cycle :
• L’horloge du lead time démarre lorsque la demande est faite et se termine lorsqu’elle est satisfaite (délai et non effort). Le lead time est ce que le client voit.
• L’horloge du cycle time démarre lorsque le travail sur la demande commence et se termine lorsque la solution est prête à être livrée. Le cycle time est ce sur quoi l’équipe peut influer.
Le système Kanban :
Là où Scrum tend à se focaliser sur le sprint, un système Kanban se focalisera davantage sur le flux d’un élément individuel au travers du système.
Kanban préconise la limitation :
• des files d’attentes
• du travail en cours
Dans un système Kanban :
– la vélocité est remplacée par le temps de cycle
– il y a disparition des time-boxes
– l’estimation est optionnelle (il se peut même qu’il n’y ait pas d’estimation du tout)
Leave a Reply
You must be logged in to post a comment.