Appliquer Kanban aux processus informatiques (1)
Auteur : Eli Weinstock-Herman
Source : Applying Kanban to IT Processes (Part 1)
Date : 01/12/2009
Traducteur : Fabrice Aimetti
Date : 07/07/2011
Traduction :
Cet article est le premier d’une suite décrivant les fondamentaux du Kanban et son application dans les processus informatiques. Ici, on donne un aperçu de Kanban et la façon dont il est utilisé dans l’industrie. Les articles qui suivront explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte. »
Récemment, j’ai vu une augmentation du nombre d’articles dans les communautés de développement et de gestion de projet Agile et qui vantent les mérites de Kanban, en montrant la valeur que Kanban a permis d’apporter lorsqu’il est utilisé avec des méthodes Agile. La plupart de ces articles se concentrent fortement sur l’aspect visualisation (Visualiser des projets agile en utilisant des tableaux Kanban par exemple), certains font même ressortir quelques autres avantages de Kanban, ou se contentent simplement de revendiquer que Kanban est un "marteau d’argent à la recherche d’un clou". Dans la communauté informatique, il semble que cela soit fortement orienté gestion de projets logiciels et développement, mais Kanban est applicable à de nombreux autres domaines de l’informatique.
Qu’est-ce-que Kanban ?
Kanban est un terme japonais signifiant "tableau visuel" ou "enseigne" et est un outil pour réduire le temps de cycle (Temps de cycle : le temps que cela prend de traiter une commande de sa réception à sa livraison) d’un processus, permettant d’accroître la visibilité dans le flux des processus et de réduire la quantité de travail en cours ([Travail] En cours : produits incomplets actuellement en cours de traitement dans le processus ou attendant de (ré-)entrer dans le processus pour être terminé. Travail non fini.). En tirant le meilleur parti de cette visibilité, nous pouvons voir où le flux de travail stagne, se bloque en créant des goulots d’étranglement ou en réduisant l’efficacité des étapes amonts. Kanban est utilisé dans le Lean Manufacturing pour disposer d’une meilleure visibilité du processus et de son état d’avancement, pour réduire les gaspillages (et les coûts), et pour aider à atteindre une capacité de production juste-à-temps (NdT : JIT = Just In Time).
Le signal Kanban
À son stade basique, Kanban est un système de signalisation qui indique aux étapes amonts d’un processus de production qu’il y a une exigence ou une demande client pour faire X.
Dans un processus de fabrication, la commande client est convertie en une ou plusieurs cartes qui représentent les exigences de production permettant de satisfaire la commande. Chaque carte ou symbole définit le produit à fabriquer et la quantité nécessaire. La carte est communiquée au responsable de l’entité concernée qui va répondre à la demande de production. Si ce responsable a un tableau visuel pour afficher la file d’attente des commandes ou la capacité disponible, il placera la carte reçue dans l’emplacement vide suivant, sinon il met à jour le tableau. Selon la complexité du processus, la réception ou l’exécution du signal Kanban pourra déclencher des signaux supplémentaires dans les étapes amonts du processus ou vers le personnel chargé d’amener le matériel nécessaire à la réalisation de l’étape de production. Chaque étape a un nombre limité d’emplacements sur le tableau qui définit le nombre maximum de cartes qui peuvent cohabiter à un point du processus à un instant donné. Cette limite Kanban contraint la quantité de travail et le nombre d’éléments en cours de travail et empêche que le travail non fini ou les demandes s’accumulent.
Limiter la quantité de travail en cours dans le processus à une petite valeur maîtrisable, nous permet de continuer à utiliser pleinement nos ressources (dans ce cas, les machines et les opérateurs), tout en réduisant la quantité de travail partiellement terminé et en attente d’être terminé. L’application de limites Kanban à un processus nous aide à commencer à réduire la variabilité du temps de production d’un produit, ainsi qu’à supprimer la nécessité (et la tentation) de différer la priorité du travail lors de chaque étape. Bien que cela puisse sembler ralentir les temps de réponse lorsqu’une commande prioritaire arrive, cela accélère en réalité son traitement parce que nous n’avons pas besoin de réorganiser nos ressources pour abandonner 47 tâches en suspens partiellement démarrées. Nous positionnons tout simplement la commande prioritaire dans la file d’attente de la dernière étape (si un emplacement est disponible) et nous laissons le signal remonter à travers les étapes précédentes de manière classique. Puisque nous avons déjà une quantité limitée de travail en cours, nous sommes en mesure de traiter de nouvelles demandes rapidement, sans interrompre les items sur lesquels nous nous sommes déjà engagés.
En supprimant les files d’attente de travaux non terminés et la repriorisation entre chaque étape, nous avons réduit la quantité de non-valeur générée par les opérateurs et amélioré à la fois la précision et (généralement) le délai estimé et communiqué au client. Nous avons également réduit le nombre des changements de priorité parce que nous terminons chaque tâche avant de passer à la suivante, au lieu d’aller et venir entre plusieurs commandes en suspens. La suppression des changements de priorité inutiles constitue une économie immédiate, car ils n’apportent aucune valeur directe au client, la diminution des délais de livraison (NdT : lead times) améliore notre réactivité pour le client final et la diminution des changements de priorité ainsi que du temps consacré au fait de recommencer à travailler sur une tâche (NdT : rework) augmente notre capacité sans coûts additionnels.
Visualisation et Métriques
Visualiser les demandes à chaque ‘poste de travail’ en utilisant un tableau réel est un bon moyen de communiquer à travers le groupe et de gérer votre Kanban. Si votre tableau n’a que 3 emplacements pour les ‘cartes’ alors vous ne pourrez pas prendre plus de 3 demandes. Les personnes situées aux étapes amonts et avales, peuvent voir les progrès réalisés ainsi que la potentielle capacité excédentaire (rien à faire) à votre étape. Le tableau n’est pas seulement une méthode pour gérer vos tâches, mais aussi un outil de communication instantanée, vous permettant de vous concentrer davantage sur le fait de réaliser votre travail plutôt que de faire du reporting et de mettre à jour les métriques des tableaux de bord.
On finit 2 unités/jour, soit environ 14 jours pour traiter une nouvelle commande
Un autre avantage majeur des méthodes Kanban apparaîtra avec la création initiale du tableau visuel. Outre le fait de définir clairement les opérations ou les étapes de production, les tâches actuelles sur le tableau, les demandes actuelles et les travaux en cours vont commencer à mettre en évidence les goulots d’étranglement. Au fur et à mesure que le temps passe et que le système kanban vous oblige à réduire ce backlog, les goulots d’étranglement vont continuer à devenir de plus en plus évidents, montrant les étapes où des améliorations directes auront un impact sur le délai de livraison pour l’ensemble du processus. Dans de nombreux systèmes, lorsqu’une étape n’a plus rien à traiter dans un système Kanban, les personnes affectées à cette étape remontent à l’étape précédente pour aider à terminer les tâches en suspens. Des règles simples ou une réorganisation de l’équipe actuelle peuvent continuer à donner des gains de performance au fur et à mesure que le tableau nous permet de visualiser et détecter les problèmes de ralentissements, les hoquets de production ainsi que les étapes potentiellement sans travail en cours.
On finit 2 unités/jour, soit environ 5 jours pour traiter une nouvelle commande
La communauté du lean manufacturing a des centaines d’exemples de tableaux visuels, mais j’en profite plutôt pour vous donner ici quelques liens sur des articles concernant le développement logiciel Agile. Les tableaux Kanban ne sont pas coûteux et, à mon avis, devraient toujours commencer par un tableau réel avant d’être enfoui dans une solution logicielle (si vous le faites).
- Article "Lean Software Development in Small Teams (lien mort)" - Tableau blanc et aimants
- Article Evolution of a Kanban Board – Tableau blanc et post-its
- Article Visualizing Agile Projects with Kanban Boards – Copieusement illustré et beaucoup d’informations
- Article The Kanban Story – Kanban Board – Résultat final (et simple !) pour un exemple concernant le développement logiciel
Une recherche sur Internet vous donnera de nombreux exemples supplémentaires dans une variété d’environnements.
Appliquer Kanban dans un département informatique
Maintenant que nous avons une idée sur la manière dont fonctionne Kanban, nous pouvons commencer à explorer comment l’appliquer à des processus informatiques, que ce soit dans des environnements administratif, support et développement logiciel. Initialement l’idée d’appliquer Kanban dans un environnement non industriel peut sembler difficile... les exemples couvriront donc un large éventail de situations possibles. En explorant plusieurs exemples de réalisations, nous pourrons avoir un aperçu ou de nouvelles idées sur la façon d’appliquer ces concepts (et voir les avantages qui en résultent) dans nos environnements informatiques respectifs.
A propos de l’auteur
Eli Weinstock-Herman : Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
