Lean software: ne vous trompez pas de cible

Au détour de mes lectures sur divers blogs et des échanges avec mes pairs au sujet du Lean Software Development, je trouve qu'il se répand une idée reçue assez dangereuse: faire du Lean signifie éliminer les gaspillages. Dans les faits cela se traduit souvent par une chasse aveugle et impitoyable au moindre gaspillage. Les résultats vont parfois du désastre à souvent une amélioration molle et peu durable. Pourquoi ?

A tous ceux qui pensent que Lean signifie supprimer les gaspillages, je souhaite suggérer un retour aux fondamentaux, c'est à dire au monde de l'automobile d'où nous vient le Lean. Certes, dans un précédent post je me gaussais des parallèles périlleux entre domaines d'ingénierie, mais je ne suis plus à une contradiction près. Et puis comme le souligne le commentaire de PIF, il faut savoir cross-fertiliser, si je peux me permettre le néologisme.

Mura, muri, muda
Fondamentalement donc, la "pensée lean" consiste à éliminer 3 facteurs d'inéficience: le mura (surcharge), le muri (variabilité), le muda (gaspillage volontaire). Dans une lettre datée du 6 Juillet 2006 (traduite en français), Jim Womack nous éclaire sur la façon d'aborder ces facteurs. NB: Jim Womack fait partie des 3 rédacteurs du livre fondateur du Lean The Machine That Changed the World. Jim nous suggère d'adresser d'abord la variabilité et la surcharge, et ensuite le gaspillage volontaire. Il confesse lui-même avoir initialement abordé ces facteurs à l'envers. Son constat est sans appel, si vous commencez par supprimer les gaspillages, vous allez générer de la variabilité et de la surcharge de manière incontrôlée et par conséquent ré-introduire d'autres gaspillages ailleurs dans votre système par effet de compensation. C'est un cercle vicieux. Le message est donc clair: maîtrisez la variabilité et la surcharge dans votre processus, ensuite diminuez ces facteurs à mesure que vous éliminez les gaspillage. C'est la meilleure façon d'implémenter des améliorations durables.

Qu'est-ce que la variabilité dans l'ingénierie logiciel ? Les livraisons sans cesse décalées, des petites livraisons suivies de très grosses releases suivies de petits patchs, etc.

Qu'est-ce que la surcharge ? Des équipes qui travaillent 12h par jour, les week-end d'astreintes, des serveurs de dev en permanence au taquet, etc.

Agilité, agilité, agilité

Je ne vois qu'un moyen simple d'éliminer ces 2 facteurs variabilité et surcharge: passer à l'agilité. Que vous soyez Scrum, XP, Kanban, ou autre, vous livrerez des petits lots de tailles similaires avec des échéances fixes, cela adresse pour partie le problème de variabilité. La surcharge est adressée par les valeurs de ces différentes méthodes, il faut évidemment une certaine discipline pour éviter le surengagement, mais la diminution de la variabilité permettra de réduire l'effet de "bourre" avant des grosses livraisons.

Un conseil en forme de conclusion: ne faites pas de Lean Software Development sans passer par l'agilité, les résultats risquent d'aller à l'encontre de vos objectifs. Et vous, quel est votre expérience du Lean Software ?

Le goût des autres ... domaines d'ingénierie !

C'est le buzz du moment: le software craftsmanship est sous toutes les plumes des bloggers agiles qui se respectent, notamment là ou là. Et je ne vais pas me priver de relayer le buzz car d'une part je me respecte (ouf), et d'autre part le sujet semble être hautement polémique et donc j'aime ça.

Il est toujours amusant de voir les réactions vives et parfois étayées de semi-insultes que provoquent ces discussions. L'arrivée de l'agilité avait donné lieu à des diatribes enflammées dans la blogosphère. Je trouvais à l'époque qu'un profil particulier se mettait régulièrement en lumière dans ces échanges: l'ingénieur en bâtiment refoulé. Celui qui voulait utiliser la même méthode pour construire un immeuble que pour construire un logiciel. Je n'ai pas encore compris pourquoi. Un exemple ici dans le commentaire n°9. NB: il y avait aussi la catégorie ingénieur civil refoulé qui voulait construire des ponts comme des logiciels. Les plus audacieux d'entre eux n'hésitaient pas à clamer vouloir construire une centrale atomique de la même manière qu'un logiciel ! Si si, je vous jure, c'était dans un commentaire sur le numéro 1 (le seul numéro d'ailleurs) du Valtech Mag en Décembre 2006, dommage qu'il ne soit plus en ligne, ça devrait passer à la postérité ! Bref, l'ingénieur en bâtiment refoulé avait raté sa vocation et était arrivé dans l'ingénierie logiciel avec l'ambition ferme d'y mettre un peu d'ordre et de relayer ses développeurs au rang d'ouvrier, ses concepteurs au rang d'architectes, et ses leaders techniques au rang de chefs de chantier. Malheureusement l'agilité compromet ses plans et on ne l'entend plus tellement de nos jours. NB: évidemment il va être le premier à me laisser un commentaire.

Mais voilà, le software craftsmanship a réveillé une autre catégorie d'ingénieur : les industriels malheureux. Un exemple ici (Gregory, sans rancune). Porté par la vulgarisation des termes "industrialisation", "usine logiciel", et "lean software development" qu'on utilise à tours de bras de nos jours dans l'informatique, l'industriel veut croire qu'un logiciel est fabricable en grande partie mécaniquement, depuis les plans de son concepteur ou selon un processus immuable, et avec une intervention réduite à la portion congrue "d'opérateurs" (autrement dit peu qualifiés). Il semble oublier que le développement informatique n'a pour but que de produire une pièce unique qu'on fait évoluer au cours du temps, et pas des milliers, voire des millions de pièces identiques, et que donc les procédés, méthodes, outils, ou pratiques utilisés pour produire la pièce N, ne sont plus tout à fait applicables pour produire la pièce suivante. Le modèle de l'industriel est la fabrication d'automobiles, un monde idéal qui doit nous montrer l'exemple. On y trouve pourtant des faillites vertigineuses, des ratages monumentaux, et des loupés en tout genre (même pour les meilleurs), dont fait rarement état l'industriel malheureux lorsqu'on en vient à comparer l'automobile et le logiciel.

Personnellement j'ai hâte de voir arriver les prochaines vagues d'ingénieurs malheureux qui vont nous expliquer comment développer du logiciel en se calquant sur les autres domaines d'ingénierie. Ainsi on pourra peut-être entendre:

• l'ingénieur agricole qui va nous expliquer comment labourer et fertiliser des systèmes d'exploitation avant d'y planter des graines de code qui vont pousser lentement chez les hébergeurs pendant l'hiver et donner leurs fruits d'expérience utilisateur au printemps. L'amélioration d'un SI passera par des boutures systématiques des vieux systèmes pour donner naissance à de jeunes applications que l'on pourra éventuellement greffer entre elles afin d'obtenir des systèmes plus productifs et de meilleure qualité, le tout abondamment arrosé d'engrais générateur de code,
• l'ingénieur en biologie qui va nous expliquer comment procéder à des tests cliniques sur des bouts de code souche pour évaluer les effets d'une crème de refactoring avant de l'appliquer sur des applications vivantes en production,
• l'ingénieur chimiste qui va nous expliquer que comme rien ne se perd et tout se transforme, si vous voulez dissoudre votre ancien SI dans une solution acide de nouvelles technologies, les émanations de gaz de changement vont fortement incommoder vos utilisateurs. Attention, si ce gars là devient copain avec l'ingénieur agricole, les effets risquent d'être désastreux sur votre SI et contaminer progressivement votre infrastructure avec du code "générétiquement" modifié,
• etc.

Bref, sortons-nous de ces comparaisons fatigantes avec les autres domaines d'ingénierie et continuons de réfléchir à comment faire les choses dans notre propre domaine. Les sources d'inspiration sont certes bonnes à prendre mais ont leurs limites qu'il faut savoir accepter. Le mouvement du Software Craftsmanship est une étape importante dans notre réflexion qui a le mérite de replacer les connaissances techniques au coeur du processus de création d'un logiciel. Elément qu'on a tendance à oublier avec la généralisation des méthodes agiles.

Un dernier point qui me chiffonne dans ces discussions autour de notre profession: pourquoi nous généralisons   souvent à partir de l'observation de notre propre nombril ? J'avais traduit il y a bientôt 9 ans un article très intéressant de JoelOnSoftware qui distinguait les différents mondes du développement logiciel. Il est toujours tellement d'actualité ! Dans toutes nos discussions sur le software craftsmanship nous réduisons systématiquement nos constats à notre propre monde. C'est un peu comme comparer le job du plombier et du menuisier. Ils ont bien sûr des points communs, de là à appliquer les mêmes règles à l'un et à l'autre, le raccourci est hasardeux...