LEAN

Aujourd'hui, je suis d'humeur à m'attaquer à quelque chose qui m'a longtemps paru abstrait qui l'est d'ailleurs toujours un peu : le LEAN.

D'un premier abord dans notre métier de développeur d'applications (de gestion) le LEAN pourrait passer pour ce qu'on fait dans le cadre des méthodes agiles. On retrouve des similitudes dans les courants du LEAN IT et de l'agilité, mais je ne sais pas si les gars qui ont écrit le manifeste Agile pensaient qu'ils faisaient du LEAN...

Alors, le lean (je vais l'écrire en minuscules maintenant, ce sera moins fatiguant) est avant tout un paradigme de production industrielle qui a apparemment été lancée par le constructeur automobile japonais Toyota (on l'appelle d'ailleurs parfois Toyotisme). Plutôt qu'aller acheter un livre de Mary Poppendiek, j'ai bien envie de voir ce que nous dit la méthode industrielle proposer une interprétation pour étudier comment cela peut s'adapter au développement logiciel. Les deux domaines étant très éloignés on peut se demander comment une méthode appliquée à l'un serait pertinente pour l'autre.

Jarvis, on passe en mode materiel

Souvent, la philosophie lean est représentée par une maison avec des termes compliqués. Je n'ai pas envie de lancerIinskape, je vais vous en faire une version simplifiée en ascii art :


(Une image car j'ai eu un petit pb de formattage avec blogger...)


Pas mal. Passons aux explications.

Le toit
Je pense que c'est le plus simple à comprendre. L'objectif est de pouvoir soutenir la qualité, dans les meilleurs délais aux coûts les plus faibles. Un classique : on ne parle pas de mettre un temps infini pour sortir des produits chers de qualité merdique.

Les piliers
Pour arriver à nos objectifs, nous nous appuyons sur 2 principes :

• JIT pour Just In Time, comprendre flux tendu. L'idée est que la production n'est pas pilotée par la capacité à produire mais par la demande du consommateur. Je pense qu'il s'agit de consommateur au sens large : le client mais aussi l'ouvrier qui à l'étape N de la chaine de production demande et attend que l'élément produit à l'étape N-1 soit disponible. C'est un point fort d'opposition avec le Taylorisme, l'idée que la production est rythmée par un tapis roulant dont l'action sur l'allure permet de réguler la production. Au push (pousser) est opposé le pull (tirer).


• JIDOKA rien à voir avec la praticien de la planchette japonaise. Souvent on l'associe au fait d'arrêter la chaine dès qu'il y a un problème. Sur Wikipedia, j'ai lu que c'est la capacité des machine a auto-diagnostiquer un problème, arrêter la chaine et appeler l'opérateur pour corriger le problème.

Les fondations
On ne peut pas faire tenir les piliers sans de solides fondations.

• TPM pour Total Productive Maintenance. Ce concept est lié à la discipline des ouvriers. On la connait aussi sous la forme de 5S:


1. Seiri : ranger et trier. Ce terme concerne surtout l'outillage, ce dont on a besoin pour faire le travail. Il faut ranger ses outils, garder à portée de main ceux qui nous servent le plus souvent et se débarrasser ce qui est inutile.


2. Seiton : ordonner. Lorsqu'on a débarrassé et trié ses outils, ils faut les ranger à une place précise, bien définie. Une place pour chaque chose et chaque chose à sa place.


3. Seiso : nettoyer. Seiri concerne l'outillage, seiso concerne les déchets de production (huile, sciure, etc.). Il faut que l'espace de travail soit impeccable.


4. Seiketsu : standardiser. Ces formes de nettoyage représentent des procédures standard, une habitude et non un événement exceptionnel. L'espace de travail doit être toujours être nettoyé lorsque les tâches sont terminées.


5. Shitsuke : maintien de la discipline. La constance dans l'application des 4S doit être contrôlée. Une sorte d'autodiscipline doit s'instaurer au sein des équipes.



Il va sans dire que la TPM, c'est compliqué. Essayez de l'appliquer chez vous avec le ménage. Je me suis amusé à comparer les pages wikipedia en Anglais et Français : les conceptions ne sont pas forcément identiques. J'ai encore un point de vue différent dans la préface Coder Proprement (Clean Code) de Robert C. Martin.


• KAIZEN pour amélioration continue. On veut définir le processus, le lancer, l'observer et le corriger s'il ne donne pas satisfaction (build, operate, check)

Okay, c'est quoi le rapport avec l'IT

Une chose est claire pour moi, le développement logiciel à peu à voir avec la construction de bagnole. Cela a d'ailleurs peu à voir avec la construction de bâtiment, même si on utilise encore le vocable du BTP (architecte, urbaniste,...). Pourtant, ce n'est pas de ma faute, le lean est a la mode dans notre metier. Comment peuvent s'appliquer les concepts du lean pour nous ?

JIT

Une application de JIT dans le domaine du développement est le Kanban, qui est également une pratique issue du lean. On organise les tâches en entrées, elles sont tirées par les acteurs dans différentes étapes d'un workflow ou chaine de valeur (en dev, en test, en livraison, etc.). La règle est que le nombre d'items par étape est limité pour les empêcher de stagner, le but étant de les sortir le plus vite possible. L'usage veut que les tâches et le workflow soient représentés sur un tableau. On retrouve ce système de management visuel dans les méthodes Agile. Ça marche bien. Ce qui est intéressant et que le Kanban peut permettre de voir les goulots d'étranglement dans notre chaine de valeur pour pouvoir l'améliorer, ce qui est déjà un aspect du Kaizen.

Jidoka

Ce qu'en entend par l'application du jidoka en IT est que tout le monde arrête ses actions en cours si une tâche est bloquée dans la chaine de valeur. On cherche à mettre un maximum de ressources pour régler les problèmes. Cela peut aussi s'appliquer à une situation de blocage en production, par extension.

Le concept d'auto-diagnostic est intéressant car on le retrouve dans la pratique d'intégration continue. Un système que se teste en continue et averti les développeur quand quelque chose ne marche plus est une application du Jidoka.

TPM / 5S

Les idées de la TPM peuvent s'appliquer au principe de développement. Le code est maintenu propre, la structure révèle les intentions, les fichiers sont stockés de façon corrélée avec l'architecture, les règles de développement sont respectées. Enfin, le principe de propriété du code cher à l'agilité rentre aussi dans ce principe. Il stipule que chaque développeur doit pouvoir intervenir sur n'importe quelle partie du code. Je pense que cela reflète bien cette idée.

Kaizen

Le kaizen va être représenté par les différentes boucles de feedback que l'on trouve là encore dans l'agilité. On pense d'abord à la rétrospective, qui permet de faire le bilan et tirer des actions à entreprendre entre deux sprints, mais c'est aussi le cas avec les tests d'acceptation, l'intégration continue, le TDD et la programmation en binôme.

Conclusion

Je crois que j'ai fait plutôt un article catalogue sans trop de parti pris. Le lean est quelque chose de pensé au départ pour de la production industrielle. Le lean IT est-il une nouvelle tentative de calquer le processus de développement logiciel sur un modèle connu, comme on l'a fait jusqu'à maintenant avec la métaphore du bâtiment ? Le fait est que les notions offertes par le lean trouvent leur écho dans les pratiques Agiles, qui sont je pense de plus en plus populaires parmi les équipes de développement.

Toutefois, le lean ne doit pas se limiter à une pratique particulière au sein de l'entreprise, adoptée par exemple uniquement dans un département faisant du développement, ou construisant des voitures. Il est censé être adopté à tous les niveaux d'une société, car l'efficacité d'un sous-sytème dépend de ses interactions avec le système global. Le vrai défi du lean est de voir la chaine de valeur dans sa globalité et de l'améliorer constamment. De ce point de vue, quoi de mieux que les pratiques Agiles pour les équipes de développement pour s'accorder avec à une politique lean en entreprise ?

Je pense que les idées seraient bonnes à compléter, je laisse l'espace libre aux commentaires.