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...

Stratégie d'automatisation des tests: un filet de pêche ou une fusée ?

Jusqu'à récemment j'avais l'habitude d'utiliser la métaphore du filet de pêche pour illustrer la stratégie d'automatisation de tests que l'on applique le plus couramment sur les projets agiles. Cette stratégie est illustrée par la pyramide de Mike Cohn: une forte base de tests unitaires, un étage plus restreint de "spécifications exécutables", et un petit chapeau de tests "bout-en-bout". La métaphore du filet me vient d'un article que j'ai lu il y a quelques années *, qui parlait plutôt d'un filet de sécurité, et que j'ai tenté de m'approprier et remettre à la sauce pêcheur. Ça donne quelque chose comme ça:

"Une stratégie d'automatisation de tests est comme un filet de pêche, plus le filet est grand et ses mailles petites, plus la capacité à attraper des poissons est forte. NB: pour les esprits les moins vifs, les poissons représentent les anomalies. Le filet se doit d'être suffisamment solide pour permettre une utilisation pérenne, et suffisamment bien attaché au bateau pour ne pas perdre sa récolte.

Les tests unitaires représentent les petites mailles de votre filet à attraper des anomalies. Il en faut beaucoup pour couvrir une surface suffisante, et il faut qu'il soit bien unitaire pour que la maille de base soit suffisamment fine, sinon on laisse passer les petits poissons. Ce petit maillage est fait d'un matériel souple qui s'adapte à son environnement: les courants, les bancs de poissons, la résistance de l'eau. Le test unitaire l'est également: les outils et les pratiques (TDD) doivent permettre de le faire évoluer facilement dans son environnement (le code) . Tout comme les petites mailles d'un filet de pêche, un test unitaire peut "casser" sans remettre significativement en question votre capacité à attraper les poissons, il y a beaucoup d'autres mailles dans votre filet. De plus il est facile à réparer pour peu que le pêcheur consciencieux le fasse rapidement.

Ce filet de petites mailles nous paraîtrait presque suffisant. Mais voilà, va-t-il résister aux gros poissons ? Que se passe-t-il si un thon ou un requin blanc se pointe ? Et si l'on accroche le fond ? On risque de perdre tout simplement un gros morceau de son filet, ou d'en jeter une partie parce que "ça ne sert plus à rien". Il faut donc renforcer ce filet avec une structure plus rigide, fait d'un maillage plus large mais dans un matériel plus solide. Cette structure représente les spécifications exécutables. Les tests y sont d'ordre fonctionnel ou métier, ils sont moins fins au regard du code, mais plus solides car ils portent sur des vérifications plus stables dans le temps (le métier). Le code est lui soumis à un remaniement incessant et les vérifications des tests unitaires sont donc moins stables. Le métier, lui, ne change pas tous les jours, le cycle d'évolution est plus long. Néanmoins, le matériel utilisé reste souple pour ne pas subir négativement les contraintes de son environnement. Il faut également trouver le bon dosage de ce maillage afin de ne pas alourdir inutilement notre filet mais de le rendre suffisamment solide. De la même façon les tests des spécifications exécutables doivent représenter les exemples clés, qui facilitent la compréhension des exigences.

Alors, a-t-on maintenant un filet de pêche suffisant ? Non bien sûr. Mais que lui manque-t-il pour être utilisé ? Des fixations pardi! Des câbles, des cordes, des poulies, bref des attaches qui lui permette d'être relié au bateau et d'être manipulé dans son environnement cible, la mer! Ces attaches sont faites d'un matériel lourd et rigide et paraissent solides à première vue, mais elles sont aussi fragiles que les petites mailles car elles centralisent l'ensemble des contraintes de l'environnement. Ces attaches sont les tests de bout-en-bout automatisés. On teste ici l'application déployée dans son environnement (presque) réel. Ces tests ne sont pas nombreux mais indispensables. On teste ici ce qui ne peut pas l'être dans les 2 maillages précédents, comme l'interface graphique ou la performance par exemple."

Finalement je suis revenu à quelque chose de plus simple il y a quelques jours lors d'une soutenance: une métaphore basée sur le principe de la fusée à étage. C'est plus proche de la pyramide et cela s'explique plus rapidement que le filet de pêche. Chaque étage contribue à la mise en orbite du satellite, mais chacun a un rôle bien précis que les autres ne sauraient endosser. Plus on monte dans les étages, plus sa fonction se sophistique et se rapproche de l'objectif final. J'aime également le fait que les étages de la fusée servent directement un objectif métier, la mise en orbite du satellite, alors que le filet de pêche sert plutôt un objectif compensatoire à un système défaillant, la pêche aux anomalies. C'est plus proche de la vision moderne des tests que j'essaye de transmettre.

Et pour vous, l'automatisation des tests est-elle un filet de pêche ou une fusée à étage ?

*Brushing Up On Functional Test Effectiveness, Jennitta Andrea, Better Software Magazine Nov/Dec 2005

Webcast des MS Techdays 2010

Les webcast des derniers MS techdays sont disponibles depuis quelques semaines. On y retrouve notamment la table ronde à laquelle j'ai participé. Il y avait du beau linge autour de cette table, qui ressemblait d'ailleurs plus à une brochette d'experts étant donnée la configuration des tables :

• Laurent Bossavit, membre du bureau de l'Agile Alliance et Agile France,
• Véronique Rota, ex-Valtech et auteur d'un livre référence sur le management agile,
• d'autres anciens Valtech comme Xavier Warzee, l'animateur Microsoft de cette session, et Jean-Laurent Fabre de Morhlon, team leader chez Vidal,
• des experts de sociétés de conseil, comme Eric Mignot, coach agile chez Pyxis, et Luc Legardeur, fondateur du French Scrum User Group et de Xebia,
• et donc moi, en tant que coach en transformation agile chez Valtech.

Le webcast de la session s'apparente plus à un podcast car seuls les slides de la session sont visibles, slides qui n'étaient là que pour appuyer les changements de sujets. Il faut donc reconnaître les voix des uns et des autres. Cette session fût enrichissante au niveau des sujets abordés et des questions posées. L'agilité reste un paradigme qui soulève encore beaucoup de scepticisme et de blocages. Malgré tout, on sent bien que la révolution est en marche et que la plupart des organisations participantes se demandaient "comment y aller" et non plus "est-ce qu'il faut y aller".

=> Voir le webcast

Suis-je un mauvais coach agile ?

C'est la question que je me suis posé en lisant un n-ième article de blog américain sur le coaching agile avec, en vrac, 4 citations de bouquins faisant "autorité", 3 références à des modèles comportementaux, 9 utilisations de termes japonais, 2 métaphores sur les arts martiaux, et 1 signature prétentieuse. Je me suis senti quelque peu "nanifié" de ne pas connaître la moitié des références exposées.

Car oui, je clame haut et fort mon ignorance:

• je ne connais pas le modèle de Tuckman
• j'ai fait du judo quand j'étais jeune et je ne vois aucune similitude avec le développement informatique
• shu ha ri est un concept vague dont j'essaye de percer le sens lorsque je propose des sujets à des conférences agiles
• Kano est le nom du restaurant en bas de chez moi
• je n'ai jamais réussi à lire un livre sur l'agilité jusqu'au bout; le seul que j'ai terminé concerne le Lean (The Machine That Changed theWorld) et ne parle pas du tout d'informatique

Une telle étendue d'ignorance et de mauvaise volonté devrait me conduire droit à l'échec sur mes missions de coaching agile.

Et pourtant ...

... mes différentes missions de coaching agiles se passent bien et atteignent leur objectif (jusqu'à preuve du contraire). Je vous propose donc mon top 5 de ce que je mets en oeuvre dans mon coaching d'équipe agile (garantie sans termes japonais):

1. pas trop de changement d'un seul coup: ce qui compte c'est l'application des 4 principes agiles, le reste c'est de l'enrobage à distiller au compte-goutte et dont une grande partie relève de l'initiative de l'équipe. Si certaines techniques ne sont pas bien appliquées dès le départ ce n'est pas grave, il faut se concentrer sur les quelques éléments clés qui caractérise une équipe agile. A mon sens ce sont les itérations en time box, les démos avec du logiciel qui fonctionne pour de vrai, et la communication directe. Il y en a bien sûr beaucoup d'autres, mais cela vient progressivement,
2. du pilotage opérationnel: il faut que l'équipe, et plus largement mon client sache où il va et quels sont les mécanismes de gestion d'un projet agile. La période de coaching ne doit pas générer d'effet tunnel. Par exemple, quitte à me brouiller avec des agilistes chevronnés, je fais en sorte que les itérations atteignent leurs objectifs, et surtout la première itération. L'échec est un luxe que se permettront les équipes rompues à l'agilité. Egalement, il est utile d'organiser des comités de pilotage du projet, celui sur lequel intervient l'équipe coachée, à chaque fin d'itération et avec des participants qui vont au delà du PO (typiquement la hierarchie). C'est là qu'on présentera les indicateurs, les projections de budget à terminaison, la variation du périmètre, bref les mécanismes de pilotage. C'est en quelque sorte la démo de la mission de coaching agile.
3. de l'écoute, de l'écoute, de l'écoute, et encore de l'écoute: il me semble très important de prêter une oreille attentive à tout le monde c'est-à-dire bien sûr l'équipe, le Scrum Master, et le Product Owner, mais aussi son chef, les collègues, les utilisateurs, le commanditaire de la mission de coaching, son chef, les instances transverses, bref tous! Je ne jette aucune information ni n'écarte d'un revers de la main les réactions inappropriées. Tout commentaire est bon à prendre, toute réaction a son fondement et cache parfois des informations capitales pour la réussite de la transition vers l'agilité
4. de la communication: expliquer en permanence les principes de l'agilité à toutes les parties prenantes (direction, organisations transverses, équipes métier, contributeurs, prestataires, etc). On s'aperçoit vite que l'équipe coachée est entourée d'un nombre insoupçonné de personnes qui ont un rôle à jouer ou qui influencent d'une façon ou d'une autre le travail de l'équipe
5. de l'empathie: les membres de l'équipe coachée vont traverser un changement parfois très profond de leurs habitudes de travail. Cela apporte son lot d'incertitude, d'angoisse, voire de souffrance dans certains cas. Je ne suis pas là pour torturer mes clients mais pour leur faciliter la tâche, j'essaye de ne jamais l'oublier.

Bon, tout ça pour dire quoi ?

Pour dire que je suis prêt à entendre qu'il faut sans cesse se cultiver pour améliorer ses pratiques, mais il faut pouvoir ... mettre sa culture en pratique!! Je trouve qu'il y a quand même un bonne partie de toute l'agitation autour du coaching agile qui tient de la démonstration mathématique voire parfois de la masturbation intellectuelle, et qui ne sert pas à grand chose concrètement.

Sayonara !
NB: ce message ne s'adresse pas aux bloggeurs pragmatiques qui adressent également tous ces concepts dans leur messages. D'ailleurs, j'envoie mes remerciements à JC qui reste ma première source d'information pour comprendre le baragouinage de certains :)

Dojo TDR @ XP Day France 2009

This is a late feedback on my session:

+ good attendance, room was full but not overcrowded, great :)

? this was my fifth experiment of this type of dojo, we started the first experiment with a colleague last November; I still had high expectations on the output

+ the subject (Blackjack) was an excellent base to work on, thanks to Gojko whom I stole the idea from

+ thanks to the XP Day goodies, I got a much better timer than I used to have for timekeeping

- I proposed the fitnesse wiki to record the tests, not a very efficient tool for authoring, but that's all I had on my laptop

+ the audience was very dynamic trying to help the keyboard holder

? I started the 5mn turns, intentionally choosing a test that was not at the heart of the problem, just to check whether the participants come back to the core topic, they did not, so I'm not sure that was a good idea

- the participants started quite late to identify interesting tests, actually that was half-through the session when I asked them whether the tests roughly illustrated the Blackjack rules

+ towards the end, one participant got rid of FitNesse and grabbed a pencil to draw some tests on the paperboard, that helped a lot to share an understanding on blackjack rules

+ the conclusion that I made to the audience was something like: "if you want to learn about the domain and the requirements, don't pay too much attention to the rules, they're distracting you from the objective"

+ finally, I received very good feedback about the session from the participants, if you attended the workshop and have some more feedback, please let me know

Outils de tests open-source

Les slides de ma présentation au dernier afterwork Valetch sont sur slideshare:

Outils de tests open-source