Flux, valeur, chaîne de valeur

Introduction

Objectifs du chapitre :

Le concept de flux est l’alpha et l’oméga de la méthode Kanban. Pour en donner une définition, il convient d’abord de distinguer la notion de flot de celle de flux. Dans un cadre focalisé sur la manipulation d’éléments tangibles comme la production industrielle, le flot fait référence à une quantité de matière et le flux à son mouvement, chacun de ses constituants étant caractérisé par sa position, sa vitesse et son accélération. Dans le cadre de la manipulation d’éléments intangibles comme le sont les éléments de travail d’un procédé de développement de produits logiciels, le flot est constitué de ces éléments de travail, et le flux caractérise leur déplacement entre les étapes du procédé de développement.

Commençons par une remarque terminologique :

Flot vs flux De manière générale, le flot est une quantité...

Approche systémique pour modéliser un procédé et la gestion du flot

La démarche Kanban repose sur une modélisation du procédé de développement et sur une gestion du flot des entités qui le parcourent.

Considérer un procédé de développement et les éléments qui le parcourent comme un système nous permet de modéliser, étudier, voire expliquer leur comportement selon diverses perspectives et à différents niveaux d’organisation.

Pourquoi le flux est-il si important ?

Le défi d’une organisation est de trouver comment faire travailler ensemble un groupe de personnes en vue de livrer un produit capable de générer de la valeur pour ses utilisateurs.

En séparant les personnes dans des silos fonctionnels, et en organisant le travail en en faisant une course de relais, l’organisation promeut de facto une situation où l’équipe est composée de coureurs ne se préoccupant que de leur propre performance : le métier décrit son besoin, les analystes le transforment en exigences, les développeurs l’implantent, les testeurs valident l’implantation, etc. La firme encourage de fait l’équipe de développement non pas à agir comme une seule équipe, mais comme une suite d’équipes séparées, chacune avec ses objectifs et contraintes. C’est comme si, dans une course de relais, chaque équipier s’était entraîné seul, de son côté, en cherchant à optimiser sa seule performance, oublieux que la transmission du bâton est un des facteurs primordiaux dans la performance de l’équipe.

Dans une telle organisation silotée, chacun ne voit qu’un morceau du flot de travail : le sien. Améliorer ce morceau est au mieux du gaspillage, la partie la plus inefficace...

Flux poussé vs flux tiré

Dans un système à flux poussé, le travail est déclenché par une planification a priori basée sur la demande réelle ou estimée. Dans un système à flux tiré, comme l’est Kanban, le travail est autorisé à démarrer à partir de l’état interne du système. Un système à flux poussé déclenche le travail à partir d’une information émise depuis l’extérieur du système alors qu’un système à flux tiré autorise le travail à partir d’une information issue de l’intérieur du système de production lui-même.

Ce qui rend aussi efficace un système à flux tiré, c’est l’information (endogène) utilisée pour déclencher le travail. Le fait de seulement tirer le travail entre étapes n’affecte pas en soi la performance du système : la clé du succès du flux tiré réside dans la qualité de l’information qui pilote le déclenchement. Cette information interne au système indique l’état du travail en cours dans le susdit système : toutes les approches à flux tiré reposent sur le fait qu’elles peuvent, grâce à cette information...

Ce qui perturbe le flux

Une organisation ou une équipe qui met en place une démarche Kanban doit examiner le flux des éléments de travail qui parcourent le procédé de développement en s’attachant à vérifier que le résultat permet aux clients d’obtenir ce qu’ils considèrent comme une valeur. Pour cela, le flux doit être mesuré, géré et amélioré.

Or, les interruptions, le multitâche, l’organisation en silos, les conflits de priorités et les dépendances entre équipes sont des sources de perturbations. Ces perturbations autour du flux naissent de ce que la culture et la structure de l’organisation dictent le comportement du flux : la façon dont la firme est architecturée et les règles par lesquelles elle définit comment agir en son sein déterminent en grande partie comment le flux traverse le système de développement de produit. Pour optimiser le flux, il faut donc modifier l’architecture et la culture de l’organisation et les règles explicites et implicites qui la gouvernent. C’est au flux de déterminer les règles et non l’inverse. C’est ce à quoi l’approche Kanban se consacre.

La firme s’organisera pour minimiser les passages de témoins entre silos. Un passage de témoin...

Le reflux

Il arrive qu’un élément de travail lors de son parcours du procédé doive être renvoyé vers l’amont pour être amendé (pour correction, amélioration ou ajout notamment). On parle alors de reflux.

Un tableau traditionnel kanban possède des colonnes dont la structure est semblable à celle présentée sur la figure 3.1.

Fig. 3.1 : L’élément de travail en cours de test présente des anomalies. Où le (dé)placer ?

Où le ticket dont l’étape des tests est en échec doit-il être placé ? Par exemple, l’étape En Test peut détecter qu’une retouche de développement est nécessaire. Comment repositionner l’élément de travail ? La limite supérieure TEC de l’étape Développement doit-elle être vérifiée, au risque d’interblocage ? Imaginez que ces deux étapes ont atteint leurs limites supérieures respectives : l’élément de travail dans l’étape En Test ne peut être repositionné dans l’étape Développement, et aucun élément de l’étape Développement ne peut franchir la transition vers l’étape En Test ! Ou bien faut-il accepter que la limite supérieure...

La fuite

Il arrive qu’un élément de travail en cours de traitement dans le procédé (c’est-à-dire présent dans une de ses étapes) termine abruptement. C’est le cas par exemple lorsqu’il n’a plus de raison d’être développé et livré suite à l’évolution du contexte du client ou lorsqu’une autre solution technique plus simple pour l’implanter a été identifiée.

L’équipe doit définir la politique de gestion de ces fuites. Comment gérer un ticket qui sort du procédé en plein milieu du traitement ? Une fuite, c’est-à-dire un ticket qui disparaît du procédé en plein traitement, génère en effet divers problèmes :

Qualifier le flux

Cette section définit les concepts élémentaires liés à la notion de flux. Nous préciserons au chapitre Mesurer le flux les définitions données ci-dessous afin de les rendre acceptables comme mesures, c’est-à-dire quantifiables et pouvant être amenés à une analyse statistique.

1. Les diverses notions liées au temps

Kanban (et la gestion manufacturière dont elle découle) propose diverses notions capturant des durées.

Parmi celles-ci, citons dès à présent les notions de temps de cycle et de temps d’écoulement. Ces notions seront précisées au chapitre Mesurer le flux car de leurs définitions dépendent les mesures et les analyses statistiques possibles.

Le temps d’écoulement est la différence entre le moment où est livrée au demandeur la réalisation d’un élément de travail et le moment où ce dernier l’a donné à faire. C’est la durée qui importe au client !

Temps d’écoulement
	Le temps d’écoulement est la durée qui sépare le passage de la commande à la mise à disposition du produit au demandeur.

Le lieu d’entrée de la commande dans le procédé est appelé point de pénétration de la commande ou point de découplage (customer order decoupling point). Il est représenté sur le tableau kanban par la colonne Bac à sable (ou équivalent). L’entrée dans le Bac à sable déclenche le chronomètre mesurant le temps d’écoulement. Ce chronomètre s’arrête, en général, lorsque la demande réalisée est livrée au demandeur. Il faut bien comprendre que l’équipe ne commence pas à travailler sur la demande quand cette dernière arrive dans le Bac à sable, pas plus qu’elle ne termine son travail au moment où l’élément de travail correspondant à la demande est livré au client. Les bornes délimitant dans le temps la période où l’équipe travaille sur l’élément de travail sont le temps de cycle.

Le temps de cycle...

Notion de valeur

La notion de valeur est polysémique. La valeur peut être définie comme l’ensemble des multiples avantages perçus et hiérarchisés selon un système de préférences par un acteur ou un groupe d’acteurs en situation de décision dans un contexte spécifique.

Dans le cadre de cet ouvrage, les acteurs concernés sont en premier lieu les (futurs) utilisateurs du produit en développement²⁶. Il sera donc plus juste de parler de valeur pour le métier. J’ai abordé cette notion, ainsi que la notion concomitante de chaîne de valeur, dans le chapitre Premiers pas.

Flux tiré vs itération

L’approche Kanban est une démarche adaptative, au même titre que les approches Agile itératives. J’ai longuement présenté dans mon Dictionnaire commenté de l’agilité [43] les tenants et aboutissants de ces approches, ce qui les rapproche et ce qui les distingue. Bien que je ne répète pas ici cette présentation, je souhaite toutefois insister sur l’intérêt de la gestion par le flux du développement de produit.

Du côté des avantages des approches itératives, l’itération est un mécanisme qui permet de définir et partager une cadence régulière sur laquelle synchroniser les travaux. Elle oblige l’équipe à découper les éléments de travail de façon à pouvoir mener sur eux les travaux entièrement dans cette parcelle de temps : analyse, codage, test, documentation, intégration à l’incrément consommable… Sa durée, courte, permet d’obtenir également un retour d’informations proche dans le temps sur les résultats des travaux menés pendant cette tranche temporelle.

Mais d’un autre côté, l’itération est un mécanisme voleur de temps, en ce qu’elle abaisse l’efficacité du flux....