Kanban appliqué au développement logiciel : de l'Agilité au Lean

Résumé

Un Kanban est une petite fiche cartonnée utilisée dans le système de production de Toyota (TPS), permettant un contrôle de production non centralisé, de type "pull". Les Kanban ont été largement repris dans les industries manufacturières du monde entier, comme outil de production Lean. De nos jours, dans le développement logiciel agile, on visualise souvent les projets à l'aide de fiches de tâches collées sur un mur - ce qu'on appelle parfois Kanban logiciel (Software Kanban) ou Kanban de tâches (Task Kanban). Il arrive même que des équipes de maintenance utilisent des systèmes Kanban au sein même d'un processus "waterfall". Alors, qu'est-ce que Kanban ? Pourquoi l'utilise-t-on dans un contexte de développement logiciel ?

Dans cet article, je vais d'abord expliquer ce qu'est le système Kanban dans un contexte de manufacture Lean, particulièrement dans TPS, et formaliser quelques points-clés des pratiques et principes en vigueur dans cette industrie mature, identifiant des concepts pouvant être appliqués au développement logiciel. En second lieu, je ferai le tour de quelques projets de développement logiciel, afin de montrer des exemples d'applications de Kanban. Enfin, j'analyserai les points communs et différences entre les systèmes Kanban de production industrielle et ceux de développement logiciel, et proposerai quelques idées sur comment appliquer efficacement le système Kanban dans un développement logiciel, évoquant notamment le mouvement récent "KSSE - Kanban System for Sustaining Engineering" (un système Kanban pour une ingénierie soutenable), qui a émergé de la liste de diffusion kanbandev. Pour conclure, je fournirai un aperçu de TPS, le contexte originel de Kanban, duquel le développement logiciel peut encore beaucoup apprendre.

Qu'est-ce que Kanban dans TPS?

Un Kanban est un artefact de signalisation (généralement une petite fiche physique glissée dans une enveloppe plastifiée transparente), qui signale un besoin de déplacement ou de création de pièce détachée dans un système de production de type "pull", et qui fut inventé et développé dans le cadre du système de production Toyota (TPS). Avant de plonger dans le Kanban appliqué au développement logiciel, concentrons-nous tout d'abord sur son usage initial, c'est-à-dire au coeur de TPS.

L'objectif de Kanban est de minimiser les WIP ("Work-In-Progress", travail en cours), ou le stock ("inventory"), entre divers processus, en s'assurant que le processus amont ("upstream") ne produise une pièce que si le processus aval ("downstream") en a besoin. "Pull" signifie que les ouvriers en aval retirent, ou "pull", les pièces dont ils ont besoin, auprès de leur processus amont.

Figure 1 Kanban et production pull

La figure 1 présente un modèle abstrait d'un système Kanban. Deux processus s'y trouvent illustrés, un processus amont et un processus aval, avec le processus amont qui fournit des pièces au processus aval. Afin de fournir des produits au client final, le processus doit produire des pièces et les faire passer vers le processus aval, mais en quantité raisonnable, la surproduction étant considérée comme un gâchis. Donc, afin d'éviter la surproduction, le processus amont ne "pousse" pas les pièces terminées dans le flux de production - c'est le processus aval qui vient activement récupérer ("pull") les pièces du processus amont. L'espace où les pièces sont déposées est appelé magasin ("store" - ou "supermarché", Taiichi Ohno eut l'inspiration de Kanban lorsqu'il visita pour la première fois un supermarché américain, où ce n'est pas l'employé du magasin mais le client lui-même qui va chercher ce dont il a besoin dans les rayons). Le magasin se situe dans un emplacement en amont, et fonctionne comme un espace tampon, une sorte de file accumulant des WIP. Lorsqu'un ouvrier du processus aval, un gestionnaire de matière ("material handler"), arrive au magasin et en retire des pièces fraîchement terminées, alors le magasin transmet un signal de production - i.e. l'aval retire des pièces de l'amont, et en même temps pousse des informations vers l'amont, à l'aide de fiches Kanban. C'est impératif, car le processus amont ne produit jamais de pièces sans instructions préalables du processus aval.

Ainsi, la figure 1 illustre l'interaction entre deux types de Kanban:

• un Kanban de retrait - qui représente une entrée sur la liste de courses, que le gestionnaire de matière retire du magasin,
• un Kanban de production - qui demande la production de pièces auprès du processus amont, pour des processus aval.

Comme montré dans la figure 1, les Kanban de retrait circulent entre les processus, alors que les Kanban de production circulent à l'intérieur d'un processus, et ils sont échangés au magasin. Entrons un peu dans les détails de cette mécanique. La figure 2 illustre le fonctionnement d'un "échange Kanban" dans un magasin.

Figure 2 Echange kanban au magasin

1. On demande à un gestionnaire de matière en aval de retirer des pièces. Cette demande est effectuée par le processus aval, soit lorsqu'une certaine quantité de Kanban de retrait a été collectée, soit à l'issue d'une période donnée. La gestionnaire visite l'emplacement amont avec des palettes vides et ses Kanban de retrait comme liste de courses, qui indiquent ce dont il a besoin, et en quelle quantité, pour son processus aval.
2. Les pièces terminées par le processus amont sont chargées sur des palettes, puis placées dans le magasin, des Kanban de production y étant attachés (cette étape intervient indépendamment de la première étape, dans un processus distinct).
3. Le gestionnaire de matière récupère les pièces listées dans sa liste de courses (les Kanban de retrait), vérifiant la concordance avec les Kanban de production attachés aux pièces, puis intervertit les deux Kanban.
4. Le gestionnaire accroche ensuite les Kanban de production collectés sur le tableau de production ("Production Board"), qui servira plus tard de signal visuel de production amont, lorsque les Kanban accrochés dépasseront un certain seuil.
5. Le gestionnaire achemine ses pièces, avec pour chacune le Kanban de retrait attaché, depuis le magasin jusqu'à l'emplacement aval.

Vous pouvez constater que le magasin agit comme une file entre deux processus, travaillant chacun dans un cadre de contrôle distinct, échangeant des pièces et de l'information à travers des Kanban. Sur les Kanban eux-mêmes, sont rédigées des informations telles que le numéro ou le nom de la pièce, sa quantité, un type de palette, une adresse de magasin, de façon à ce que le gestionnaire de matière soit sûr de ce qu'il ait à faire.

L'exécution de Kanban suit une discipline stricte, matérialisée à travers six règles:

1. Le client (aval) retire les pièces dans les quantités exactes spécifiées sur le Kanban.
2. Le fournisseur (amont) produit les pièces dans les quantités et séquences exactes spécifiées par le Kanban.
3. Aucune pièce n'est produite ou déplacée sans Kanban.
4. Chaque pièce est toujours accompagnée d'un Kanban.
5. Une pièce défectueuse, ou en quantité incorrecte, n'est jamais transmise vers un processus aval.
6. Le nombre de Kanban est réduit attentivement, afin de diminuer les stocks et révéler les problèmes.

Comme vu précédemment, le magasin fonctionne comme une file de pièces, les palettes jouant le rôle de "transporteur physique", et les Kanban le rôle de "transporteur d'information". L'ensemble forme un système "pull", qui maintient un équilibre entre la gestion d'un flux tendu (sans temps d'attente) et la minimisation des WIP (sans surproduction). Ce mécanisme de gestion de quantités "correctes" de WIP dans le flux, entre l'acheteur et le vendeur, est exactement celui mis en oeuvre dans un supermarché - sa bonne exécution étant la clé de rentabilité du magasin.

Jusque là, j'ai décrit le fonctionnement de Kanban dans un contexte de manufacture. Cette description demeure toutefois une forme simplifiée d'un système Kanban réel. Une autre chose, non encore mentionnée, est que Kanban fournit une visualisation des flux d'informations et de pièces à tous les ouvriers, et stimule le Kaizen (amélioration de processus) dans le Gemba (le lieu de travail). Le Kaizen commence par l'observation de ce qu'il se passe dans le Gemba. A travers Kanban, chaque ouvrier, et pas seulement les managers, peut observer le flux, et dispose ainsi de l'opportunité de déceler un gaspillage et suggérer une amélioration du processus.

Les propriétés de Kanban

Nous pouvons, des observations détaillées de la section précédente, extraire une liste de propriétés et d'effets du concept original Kanban dans TPS.

1. Physique: le Kanban est une fiche physique, qui peut être tenue dans la main, déplacée, et mise à l'intérieur (ou à la surface) de quelque chose.
2. Limite les WIP: il limite les WIP (travaux en cours), empêchant la surproduction.
3. Flux tendu: il notifie les besoins en production avant que le magasin ne tombe en rupture de stock.
4. Retrait: le processus aval retire des pièces du processus amont.
5. Auto-dirigé: il contient toutes les informations requises pour la production, et la rend autonome, d'une façon non centralisée, et sans micro-management.
6. Visuel: il est empilé/affiché, et montre le statut actuel et l'avancement, visuellement.
7. Signal: les prochaines actions de retrait ou de production sont visuellement signalées.
8. Kaizen: la visibilité du flux de production stimule le Kaizen.
9. Attaché: le Kanban est attaché et déplacé avec les pièces physiques fournies.

La figure 3 est un diagramme d'effets des neuf propriétés énumérées ci-dessus, montrant le réseau de causes et d'effets qu'elles forment. Comme vous le verrez rapidement, il existe en gros deux significations pour Kanban, la première "limitant les WIP tout en maintenant un flux tendu", et la seconde s'articulant autour de Kaizen.

Figure 3 propriétés et effets de Kanban

La partie droite de ce graphique illustre comment les WIP sont minimisés, tout en maintenant un flux tendu. Si les WIP dans le magasin sont trop peu nombreux, le processus aval reste dans l'attente de pièces qui ne sont pas encore prêtes au moment où il en a besoin; mais dans le même temps, les WIP doivent être minimisés pour empêcher la surproduction. Ces deux buts sont donc en conflit, et Kanban peut être vu comme une stratégie de résolution de ce dilemme.

Les Kanban sont physiquement attachés aux pièces, puis sont collectés et réutilisés, donc le nombre total de Kanban reste fixe. Les Kanban indiquent également au processus aval quand les pièces doivent être retirées. Ces deux mécanismes limitent les WIP.

Le premier mécanisme de "Kanban physiquement attaché" fonctionne un peu comme une "loi de conservation de l'énergie". Une fois le nombre total de Kanban défini, à travers le rythme des ventes de produits sur le marché et la variabilité intrinsèque au processus courant, les WIP sont limités proportionnellement au nombre de Kanban, indépendamment des flux entrants/sortants de pièces. Le nombre maximal de Kanban ("l'énergie" du système) est fixe, et conserve physiquement la limite supérieure de WIP à tout moment. Dans la figure 4, vous verrez que le système est le stock entre le processus amont et le processus aval, i.e. les WIP du magasin.

Figure 4 mécanisme Kanban de limitation des WIP

Le second mécanisme, le retrait ("Pull"), limite également les WIP, la vélocité de production du processus amont dépendant directement de la vélocité de consommation du processus aval. Le premier mécanisme se réfère uniquement à la quantité de WIP, et le second se réfère au flux, à sa direction et à sa vitesse.

"Direction": la motivation de production est uniquement donnée par le processus aval.

"Vitesse": les Kanban communiquent les timing et quantité des prochaines productions.

"Pull" limite les WIP en rendant le processus de production amont dépendant du processus de consommation aval, au degré dérivé de premier ordre. Cette dépendance est matérialisée à travers les échanges de Kanban intervenant dans le magasin, l'information de contrôle de production étant poussée depuis le processus aval vers le processus amont.

Revenons à la figure 3. La partie gauche du graphique montre comment le travail devient autodirigé, et promeut le Kaizen. Tout le monde peut comprendre ce qu'il se passe, si le processus se déroule correctement, avec un simple regard aux fiches Kanban affichées sur un tableau. L'observation du flux dans le Gemba est le point de départ de Kaizen. Le côté visuel des fiches Kanban affichées sur le tableau rend le travail autodirigé, sans contrôle centralisé du management. Ce processus autonome fournit des données permettant la mise en place de Kaizen, et incite le management à se concentrer sur des activités Kaizen, plutôt que sur l'assignation et la distribution de tâches détaillées.

Les flèches du graphique, aboutissant aux trois effets, illustrent les trois buts ultimes de Kanban: "limitation des WIP", "flux tendu" et "Kaizen". Ainsi, un système Kanban "limite les WIP" en maintenant un "flux tendu". Via son mécanisme de magasin, il régule la variabilité due aux variations normales de causes, et expose une variabilité de cause particulière, de laquelle on peut tirer des candidats au Kaizen.

La Kanban dans le développement logiciel

Étudions maintenant notre domaine d'activité - le développement logiciel. Dans le développement logiciel agile, certaines pratiques se sont popularisées, comme la visualisation et le partage du statut du projet, à l'aide de fiches collées sur un mur de la salle projet. J'en ai présenté plusieurs exemples dans mon dernier article infoQ La visualisation des projets agiles à l'aide de tableaux Kanban [Hirabane07]. En particulier, l'ensemble des fiches de tâches affichées sur un mur, qui montrent le statut courant, est parfois appelé "Kanban de tâches" ou "Kanban logiciel" [Popendieck03]. La Figure 5 montre un Kanban de tâches implémenté par l'équipe de développement JUDE de Change Vision, Inc.

Figure 5 Kanban agile

Sur le tableau, les tâches d'ingénierie sont représentées par des fiches (des post-its), et leur statut est dérivé depuis l'endroit où ils sont collés, des sections du tableau appelées "À faire" (To Do), "En cours" et "Terminé" (les libellés peuvent différer suivant les sites, on trouve ainsi parfois "Commencé", "Testé", "Accepté", "Bloquant" etc.). Ce tableau Kanban permet de montrer visuellement les tâches et de limiter les WIP (les tâches en cours de production). Cependant, on ne trouve ici aucun processus (amont ou aval), et un nouveau concept "d'itération" est introduit. A chaque itération, de nouvelles tâches sont identifiées en découpant les user stories, et ce sont ces tâches qui sont affichées dans la section "À faire".

Est-ce un système "pull" ? Dans de la manufacture, les pièces sont transmises depuis un processus amont vers un processus aval. Dans l'expression visuelle d'un développement agile, tel que montrée dans la Figure 5, aucun échange physique n'apparaît. Une fiche Kanban est la contrepartie d'une tâche, et l'on y trouve écrit: un identifiant de tâche, un nom, une estimation de temps et le nom de la personne s'étant assigné la tâche. La tâche possède un statut, tel que "À faire", "En cours" ou "Terminé", et est partagée par l'équipe. L'approche de développement agile valorise le travail collaboratif, et réduit les échanges physiques au sein de l'équipe. J'appelle cela le "Kanban agile".

La Figure 6 propose un autre exemple d'un tableau Kanban, implémenté à Yamaha Motor Solution Co, Ltd. (Yamaha Motors possède une ligne de production matérielle, et leurs équipes de développement logiciel sont ainsi dans un environnement favorable à l'apprentissage de la pensée Lean, grâce aux usines. Lors de ma visite à la société, j'ai vu beaucoup de XFDs (Extreme Feedback Devices, appareils "extrêmes" de feedback) facilitant la visualisation de projet dans les locaux, parallélisant "l'Andon" ou les systèmes visuels de management des usines).

Figure 6 Support Kanban

Ici, un système Kanban est utilisé dans le cadre d'un développement traditionnel waterfall, mais au sein d'un flux. Ce projet associe plusieurs processus distincts à la suite, qu'il nomme "conception", "développement", "validation" etc., les fiches Kanban circulant entre les processus. Chaque fiche représente un nouveau besoin ou une évolution, et s'achemine vers un processus aval. Remarquez qu'il ne s'agit toutefois pas d'un développement waterall classique, où l'ensemble des besoins sont collectés et conçus en une fois, puis développés, et enfin validés à un autre moment, ce qui se traduirait par le déplacement de toutes les fiches en même temps, en groupe. Au lieu de ceci, les fiches sont déplacées une par une, comme la transmission unitaire de pièce dans un flux de manufacture. Ici, nous avons bien une phase soutenable et stable du cycle de vie d'un produit, pilotée grâce à un modèle waterfall de transition entre les différents états, au sein d'un flux. Ainsi, le concept de "flux de travail" est clairement visible, bien différent du concept d'itération cher à l'agilité. Cela ressemble plus au Kanban utilisé dans les usines que le Kanban Agile, et peut prendre la forme d'un système "pull" en imposant la règle suivante: seul le processus aval est autorisé à déplacer les fiches. (Dans le schéma, il est intéressant, même si non essentiel, de savoir que les boîtes rouges (processus) sont produites en Chine). J'appelle ce système "Kanban soutenable", et lui trouve un fonctionnement similaire à celui de David Anderson, "Système Kanban pour une ingénierie soutenable", que j'aborderai plus loin.

Un autre exemple, décrit dans la figure 7, est une réflexion montrant l'usage de Kanban dans le flux de valeur d'un processus complet de développement de produit [Poppendieck07].

Figure 7 Lean et Kanban Agile

Supposez l'existence d'une équipe client, d'un product owner, d'une équipe de développement et d'une équipe de QA réunies dans un flux de développement produit, travaillant ensemble en se passant des tâches à travers des files, de façon à permettre un travail asynchrone, et maintenant un rythme de travail dépendant de tous. Chaque section "DONE" joue dans les faits le rôle de file, comme un magasin dans une usine de manufacture, et cela ressemble assez bien à un système Kanban TPS. Incidemment, on a quelque chose qui ressemble à du Kanban agile synchrone au sein de chaque processus, avec un Kanban soutenable asynchrone tout au long du flux de valeur des processus. Je pense qu'un système Kanban peut être étendu pour couvrir tout le flux de valeur, fournissant ainsi une visualisation en temps réel du flux.

Dans cet exemple, les WIP peuvent être limités via la définition de la taille de chaque section. Pour que ce système soit véritablement "pull", il faut un mécanisme permettant au processus aval de signaler un début de travail au processus amont. Pour ce faire, il est possible de définir une règle, stipulant que seul le processus aval peut déplacer les fiches DONE pour notifier le processus amont. Il est également possible de tenir périodiquement des réunions d'itération, qui permettent de synchroniser à la fois les membres de l'équipe et les équipes entre elles. Ces deux options de communication pourraient correspondre aux deux signaux de retrait de pièces discutés dans la première section, c'est-à-dire le signal visuel du compte total de Kanban de retrait (a) et un intervalle de temps périodique (b). Ainsi, un jeu de User Stories pour une itération donnée correspondrait aux pièces retirées sur des palettes de l'itération, et le nombre de pièces (Kanban) correspondrait à la vélocité du projet de l'itération ("le temps d'hier", [Beck00]). J'appelle ceci "Lean + Kanban Agile", et on peut le combiner avec le "Kanban Agile", comme montré dans l'exemple qui suit.

La Figure 8 montre un petit système Kanban portable, que j'ai vu dans un projet de CENTRAL COMPUTER SERVICES Co. Ltd. Dans ce projet, une équipe fonctionne sur la base de plusieurs petites sous-équipes (généralement des paires). L'équipe entière dispose d'un workflow conceptuellement similaire à celui de la Figure 7, ainsi que des petits tableaux Kanban montrés dans la Figure 8 (de type TODO / EN COURS / TERMINE). Lorsqu'une sous-équipe s'attribue une User Story, elle la découpe en tâches, puis colle ces dernières sur leur tableau Kanban portable. Dans ce cas-là, un système Kanban est composé de deux niveaux, un niveau projet où une fiche représente une User Story, et un niveau équipe (ou une paire) où la fiche représente une tâche.

Ce système Kanban, petit et portable, a été très apprécié, et fut nommé "Kanban-nano".

Figure 8 Kanban agile portable (Kanban-nano)

Comme vous pouvez le voir, il existe plusieurs manières d'appliquer le concept Kanban sur du développement logiciel. Le "Kanban Agile" permet à une équipe de partager de l'information et de rendre le travail autodirigé, mais il ne permet pas une gestion de flux. Le "Kanban Soutenable", une autre forme, matérialise un flux de travail entre différents états d'une tâche. Et la combinaison "Lean + Agile" utilise le "Kanban Soutenable" dans le flux de l'équipe, et le "Kanban Agile" au sein d'une sous-équipe.

Il faut bien noter que le premier "Kanban Agile" de la Figure 5, relativement répandu dans les projets agiles actuels, ne voit qu'une seule sous-équipe dans le flux de valeur. Lorsqu'on considère l'ensemble du flux, de client à client, il existe souvent une équipe dans le flux qui vous fournit des spécifications, et une autre qui livre votre production au client. L'un des objectifs de cet article est de proposer une idée pour étendre l'application de Kanban au-delà du "Kanban Agile", à une partie plus large du flux de valeur.

Production et Développement

Le développement logiciel n'est pas une activité de production ou de manufacture [Reves92]. Les ingénieurs logiciels créent des choses différentes à chaque fois, alors qu'une manufacture produit les mêmes choses, encore et toujours. En conséquence, effectuer une correspondance directe entre la production et le développement est dangereux. Cependant, examinons la façon dont les propriétés du Kanban TPS se retrouvent dans les différents types de développement logiciel Kanban. Le Tableau 1 montre si les propriétés Kanban énumérées dans la section 1 sont toujours valables pour les deux types de Kanban logiciel précédemment décrits.

Les propriétés de "Limitation des WIP", "Flux tendu" et "Pull" ne sont pas atteintes par l'exemple de Kanban Agile en lui-même, montré dans la Figure 5. Le Kanban Agile vise plutôt à activer les tâches, travaillant sur les propriétés "Visualisation" et "Auto-direction", afin d'aider l'équipe à devenir autonome et à améliorer son propre processus. Afin de permettre au processus de se dérouler comme un flux tendu tout en limitant les WIP, il est nécessaire de mettre en place des "réunions d'itération", où les informations sont communiquées.

Le Kanban soutenable de la Figure 6 peut limiter les WIP et contrôler le flux, avec un pull à l'unité, sans réunions d'itération. Dans cette approche, la priorité est donnée à la "Limitation de WIP", au "Flux tendu" et au "Pull", simultanément, permettant à l'équipe (ou au manager) d'utiliser Kanban dans une optique d'amélioration continue.

Revenons à la Figure 3. J'ai catégorisé les propriétés et les effets de Kanban en deux grandes zones dans la Figure 9, afin que les deux concepts Kanban logiciel exprimés ci-dessus puissent réaliser leur objectif. La Figure 10, de son côté, révèle la distance entre la Production et le Développement. La production est un processus doté d'un taux de succès très élevé (plus de 99%), alors que les chances de succès du développement sont nettement moindres. L'agilité est l'approche optimale de développement lorsque la probabilité de succès est d'environ 50%; le waterfall est de son côté optimal lorsque la probabilité de succès est supérieure à 90% (si l'on applique la théorie de Shannon, un projet avec une chance de succès de 50% a le plus de valeur). Généralement, lorsque le développement progresse vers un mode de maintenance, la probabilité de succès pour de la correction de bug ou de l'ajout de nouvelles fonctionnalités s'accroît.

Les combinaisons de type "Priorité au contrôle du processus" du système Kanban fonctionnent pour les projets avec une probabilité de succès de type "plus de 90%", et les combinaisons orientées "priorité à l'amélioration du processus" fonctionnent à la fois pour les domaines 50% et 90%.

Il faut noter que l'approche agile fonctionne encore dans un mode de maintenance d'un produit, et les pratiques d'un "processus orienté amélioration" également dans un mode de maintenance.

Figure 9 Propriétés et effets de Kanban

Figure 10 Spectre d'approches avec Kanban

KSSE - Système Kanban pour de l'ingénierie soutenue (Kanban System for Sustaining Engineering)

Je vais maintenant évoquer l'émergence récente de l'application de Lean dans le développement logiciel. Lors de la conférence Agile2007, j'ai participé à une CWAC (Conference-Within-A-Conference, une conférence dans une conférence), au sujet du Kanban logiciel, dirigée par David Anderson. Ce dernier était en charge d'un mode de maintenance plus ou moins Kanban chez Corbis.com, et venait de publier un article sur le sujet, Système Kanban pour de l'ingénierie soutenable [Anderson07]. Son approche se focalise d'abord sur la propriété "Limitation de WIP" de Kanban, comme montré dans le diagramme de la Figure 4, ainsi que sur la propriété "Auto-Direction" qui rend l'équipe auto-organisée, avec un besoin réduit en management. Ensuite, en visualisant les flux à travers des Kanban, il cerna des points de stagnation dans tout le flux du processus, et ajusta ses ressources humaines en conséquence, i.e. déplaça des membres entre les processus. Cela signifie que son approche démarre des propriétés "Limitation des WIP" et "Auto-Direction", pour aller jusqu'à la propriété "Kaizen" de Kanban, comme décrit dans la Figure 3.

Après la conférence, Anderson créa la liste de diffusion "kanbandev", de laquelle a depuis émergé, à travers diverses discussions, un savoir sur les modalités d'application de Kanban au développement logiciel, appelé "KSSE" - Kanban System for Sustaining Engineering (prononcez: "Kissi"). Aaron Sanders est également impliqué dans la construction de savoir lié à Kanban, et s'est lancé dans l'élaboration d'un vocabulaire KSSE.

KSSE fonctionne bien lorsqu'il existe des processus multiples, reliés en série, se passant des livrables à l'aide de files. Notez cependant que KSSE n'inclut pas nécessairement le concept d'itération. Je vois une possibilité de faire grandir un processus agile par autre chose que des "Scrum de Scrums", en utilisant l'approche KSSE. [Ladas07]

Faire couler la valeur

Lorsque l'on étend l'agilité avec Lean, en utilisant Kanban, que doit représenter une fiche Kanban?

Dans un système Kanban Agile, une fiche représente une tâche issue du découpage d'une User Story. Dans une équipe de développement, elle représente une unité de travail, car tous les membres de l'équipe peuvent comprendre ce qu'elle signifie. Mais dans les systèmes Kanban qui fonctionnent avec plusieurs processus (équipes) à l'intérieur d'un flux de valeur, ce qui doit se déplacer doit porter une valeur ajoutée reconnue par le client. Dans ce cas, une fiche Kanban ne représente plus un "travail", mais une "fonctionnalité" (feature), et ce n'est plus un fragment de WBS ("work breakdown structure", découpage des travaux) mais un fragment de FBS ("feature breakdown structure", découpage des fonctionnalités), de telle façon que tous dans le flux, y compris le client, comprennent à la fois la signification et la valeur du contenu du flux. Jim Highsmith favorise également FBS plutôt que WBS dans son ouvrage Gestion de Projet Agile [Highsmith04].

Les "User Stories", les "Items de Backlog" ou les "Cas d'Usage" forment l'abstraction dénommée MMF ("minimum marketable features", minimum des fonctionnalités commercialisables) afin d'affirmer que ce qui circule dans le flux porte de la valeur pour le client. Et le développement Lean peut se comprendre comme "faire circuler les MMFs à travers le flux complet de valeur".

L'exemple de "Kanban Agile" de la Figure 5 est une division du travail, et cela fonctionne bien à l'intérieur de l'équipe. L'exemple de "Kanban Soutenable" de la Figure 6 est une division des fonctionnalités, avec une fiche par MMF. Et l'exemple "Lean + Kanban Agile" de la Figure 7, en conjonction avec la Figure 8, montre une combinaison de découpage de fonctionnalités à haut niveau, et de découpage de travaux à bas niveau.

Une fois le flux de travail établi, les 5 concepts principaux de la "Pensée Lean" [Womack1996] peuvent être directement appliqués à l'ensemble du processus. La conduite du processus Lean suit simplement les principes ci-dessous.

• Spécifier la valeur d'un point de vue client, i.e. spécifier et prioriser les MMFs
• Identifier le flux de valeur et éliminer le gaspillage, i.e. trouver la stagnation (les goulets)
• Faire couler la valeur, en la faisant tirer par le client, i.e. appliquer la règle de retrait de Kanban (pull)
• Impliquer et responsabiliser les employés, i.e. donner plus de pouvoir à l'équipe du Gemba
• S'améliorer continuellement dans la quête de la perfection, i.e. introspection et Kaizen.

TPS, la vue d'ensemble

Ce qui suit est une sorte d'annexe, qui partage ce que j'ai appris du Système de Production Toyota (TPS) et trouvé applicable au développement logiciel. Mary et Tom Poppendieck ont régulièrement constaté qu'un développement logiciel efficace inclut beaucoup d'éléments de Lean ou de TPS - pas au niveau pratique, mais au niveau des principes [Poppendieck03, 07]. Prenons donc un peu de recul et observons Kanban dans TPS, avec une perspective plus large.

On supposerait facilement que Kanban se trouve au coeur de TPS - à tort. La Figure 11 montre la structure conceptuelle de TPS, parfois appelée la "Maison TPS" ("TPS House"). Il en existe plusieurs versions, et celle de la Figure 11 provient de Toshiko Narusawa et John Shook [Narusawa06]. Dans TPS, Kanban est simplement un outil utilisé par un système "pull", afin d'atteindre le Juste-à-Temps. Le Juste-à-Temps peut être paraphrasé ainsi : "fabriquer et livrer ce qui est nécessaire, seulement lorsque cela est nécessaire, et pas plus que les quantités appropriées". Il vise à répondre au besoin client : "un produit de meilleure qualité, au prix le plus bas, dans les délais les plus courts". Remarquez que le Juste-à-Temps est l'un des deux piliers de TPS, l'autre étant le Jidoka. Jidoka, ou "Autonomation", est le pendant industriel du Test-Driven Development en ingénierie logicielle. Mary et Tom Poppendieck interprètent Jidoka comme la "culture d'arrêt de ligne". Les ouvriers de Toyota interrompent réellement la ligne de production plutôt que de transmettre des défauts au prochain processus aval - ce n'est pas seulement une règle, mais presque la culture de Toyota, qui remonte jusqu'au métier à tisser de Sakichi Toyoda.

Figure 11 Structure du concept TPS

Le Juste-à-temps est composé de trois éléments, "Takt Time", "Flux tendu" et "Système Pull".

1. Le Takt Time définit le rythme de production des produits, basé sur le rythme des ventes.
2. Le Flux tendu permet de produire à l'intérieur d'un processus sans stagnation, dans le Takt Time.
3. Le Système Pull déplace les pièces et instruit la production entre les processus, en limitant la quantité en stock.

Remarquez que les deux piliers s'appuient sur Kaizen et les Personnes. Toyota produit presque 10 millions d'automobiles par an, et dans le même temps, améliore ses processus grâce à environ 1 million de propositions Kaizen dans le Gemba (i.e. l'espace de travail). Visualiser ce sur quoi l'équipe travaille est toujours le point de départ de Kaizen.

Conclusion

J'ai analysé la production Kanban au sein d'un système de manufacture, et j'en ai cité les propriétés. Les systèmes Kanban sont utilisés afin d'obtenir:

1. Un meilleur contrôle du processus - permettant de maintenir un flux tendu tout en limitant les WIP

2. Une meilleure amélioration du processus - visualisant le flux et stimulant le Kaizen.

Ce que j'appelle "Kanban Agile" se concentre sur le second point, alors que le "Kanban Soutenable" se concentre sur le premier. J'ai proposé une combinaison des deux afin d'étendre la visualisation et le système pull à l'ensemble du flux de valeur, afin de rendre l'ensemble "Lean".

Crédits

Tom et Mary Poppendieck ont relu cet article et fourni nombre de suggestions et idées, pour lesquelles je leur suis reconnaissant. Yasuharu Terai, le président de Yamaha Motor Solutions Co., Ltd., et Ryuichi Sato m'ont donné la permission d'utiliser la photographie de leur système Kanban. David Anderson a également relu l'article et suggéré un meilleur niveau d'abstraction de Kanban afin de mettre en valeur KSSE. Le groupe de discussions Yahoo! Kanbandev est une source de nouvelles idées sur KSSE. Enfin, je remercie Deborah Hartmann pour ses dernières corrections, qui ont rendu mon propos beaucoup plus clair.

Sur l'auteur

Kenji Hiranabe est le CEO de la société Change Vision Inc., basée au Japon. Il est le créateur de JUDE, un éditeur UML intégré à ERD, DFD et Mind Map, et TRICHORD, un système Kanban intégré avec des Burndown Charts et des Parking Lots pour la gestion de projets agiles. Il a également traduit en japonais les livres "Lean Software management", "XP Installed", "Agile Project Management" et autres ouvrages sur l'agilité et XP. Kenji conçoit le développement logiciel comme une forme de jeu de communication, et a exploré diverses manières de le rendre plus productif, collaboratif et agréable.

Références

TPS

[Ohno78] Taiichi Ohno, "Toyota Seisan Houshiki", 1978 (anglais: "Toyota Production System", 1988). La bible de TPS. Ce livre est une lecture indispensable pour tous les praticiens Lean.

[Narusawa06] Toshiko Narusawa, John Shook, "Eigo de Kaizen, Toyota seisan houshiki", 2007(japonais et anglais). Publication récente d'une traduction parallèle anglais/japonais de TPS.

[Ishii05] Masamitsu Ishii, "Toyota no moto-koujousekininnsha ga oshieru nyuumon Toyota seisan houshiki", 2005. Inclut une version de la structure du concept TPS.

[Monden06] Yasuhiro Kadota, "Toyota Production System", 2006(anglais: "Toyota Production System 3rd", 1998). La bible de l'implémentation de TPS. J'ai présenté dans la section 1 une discussion de Kanban tirée de ce livre.

Agilité et Lean

[Reeves92] Jack W. Reeves, "What is Software Design?" C++ Journal, 1992. Mon article favori sur la conception logicielle.

[Kent00] Kent Beck and Martin Fowler, "Planning Extreme Programming", 2000, Addison-Wesley. Sur la planification de releases et d'itérations. Le temps d'hier, la vélocité projet, sont des idées qui ont été explorées en premier lieu dans cet ouvrage.

[Poppendieck03] Mary and Tom Poppendieck, "Lean Software Development", 2003 Addison-Wesley. Le premier classique, ayant établi un parallèle entre TPS et le développement logiciel.

[Highsmith04] Jim Highsmith, "Agile Project Management", 2004, Addison-Wesley. Introduit FBS comme une pratique de APM.

[Poppendieck07] Mary and Tom Poppendieck, "Implementing Lean Software Development", 2006 Addison-Wesley. Explique le Kanban dans le Lean, et montre son mécanisme de fonctionnement "pull".

[Cockburn06] Alistair Cockburn, "What engineering has in common with manufacturing and why it matters" 2006. Une discussion d'Alistair, établissant un parallèle entre une décision non validée et un WIP dans le processus d'ingénierie logicielle.

Concepts Kanban récents

[Hiranabe07] Kenji Hiranabe, "Visualizing Agile Projects using Kanban". Une collection de méthodes visuelles et de Kanban dans un espace de travail agile.

[Anderson07] David Anderson, "A Kanban System for Sustaining Engineering on Software Systems". Son expérience à Corbis.com, avec un système Kanban.

[Sanders07] Aaron Sanders, "Kanban Ground Rules Example for a Specific Team Kanban System for Software Engineering - KSSE". Etablissant un corpus d'informations sur KSSE.

[Ladas07] Corey Ladas, "Lean scales differently than Agile". Kanban peut être utilisé pour étendre l'agilité de façon Lean et horizontale, à l'inverse des "scrums de scrums".