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.
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 ?
1 comment:
Je n'ai pour ma part jamais cherché à faire explicitement du "Lean" mais, étant fortement influencé par la théorie des contraintes de Goldratt -qui elle aussi, comme le Lean, vient de la production industrielle- je dirais que le coût n'est qu'une des 3 variables.
Diminuer le coût ne suffit pas. Il faut en même temps
- augmenter le débit c'est à dire l'apport de fonctionnalités aux utilisateurs du logiciel
- diminuer les stocks c'est à dire tous les artefacts intermédiaires qui trainent dans la chaine de production (spécifications en attente, composants logiciels pas encore utilisés, fiches de bugs, releases non installées chez le client...)
Post a Comment