The Lean Code Challenge au Software Craftsmanship 2011

La dernière session de la conférence Software Craftsmanship 2011 m’emmène sur les pentes du Lean Software Development avec « The Lean Code Challenge ». 

Très bon slot de Chris Parsons avec au programme, du code bien sûr, une fois n’est pas coutume dans cette conférence.
L’objectif de cette session est de nous faire réfléchir sur le Lean Software Development. En particulier, la session aborde les aspects suivants :

• Eliminate waste.
• Focus on value.
• Deliver fast.
• Decide late.

Le programme

7 itérations de 10 minutes sur le développement d’un scanner d’articles pour lequel on calcule le montant total à payer en fonction de règles de plus en plus complexes. Un jeu de tests d’acceptation est fourni à chaque itération.

C’est timeboxé et plutôt rapide, pas le temps de se poser sur cette session. Les binômes se forment et c’est parti !
On ajoute des bananes, des pommes, des cerises, à partir du nom. Le temps de mettre en place l’environnement, de me mettre d’accord avec mon binôme, et houla mais il ne reste plus que 4 minutes, on est un peu en retard! Pas grave, on va se refaire.

Chris passe entre les tables et nous demande quel langage nous utilisons.

« En Java ? Mmmm… C’est plus long en Java… » Ahahah même pas mal… Je regarde autour de moi, effectivement la population semble affectionner d’autres langages comme Ruby, Python, Clojure.

Itération 2, promotion! Réduction de 2£ pour 2 pommes achetées. Mon binôme n’arrive pas à utiliser mon clavier français, ni mon mac… il m’abandonne et part tenter sa chance en Clojure… Je change les tests (TDD oblige), implémentation au minimum, ça tombe bien, on a pris un peu de retard.

Itération 3, on doit maintenant gérer un pseudo-format CSV avec des entrées sous forme « Apple,Banana,Apple,Cherry ». Simple, test, début d’implémentation et là paf, changement de programme, le client décide que ce n’est plus prioritaire! Retour arrière, maintenant 1 banane offerte pour 1 achetée, en plus de la réduction sur les pommes! C’est déjà les soldes ? Virage à gauche toute, je conserve mon implémentation de côté pour plus tard, mais le temps restant est court, je m’arrache et termine dans les temps. Tout est green… ouf.

Itération 4, le support du CSV est toujours en discussion et par conséquent remis à plus tard, il faut maintenant pouvoir parler français, anglais et je ne sais quoi d’autre. Je duplique mes éléments de reconnaissance. Pas très joli mais efficace, je suis dans les temps.

Itération 5, toujours pas de CSV, cette fois-ci les promotions sont localisées. Les réductions sont différentes si on scanne une « Pomme » ou une « Apple ». Mon design commence sérieusement à être limite, je craque et refactore en profondeur. Cette fois-ci je sors de la route, mes doigts fument mais je ne respecte pas le timing.

Itération 6, le CSV arrive enfin, facile, j’ai déjà une partie du code de l’itération 3. Je rattrape mon retard, mais j’ai un test qui plante… comprends pas, debug, damned… l’itération 7 commence.

Bilan

Et le Lean dans tout ça me direz-vous ? Faisons un petit bilan de la session.

Eliminate Waste : qu’est-ce qui a posé le plus de problèmes sur l’élimination des gaspillages?
Les réponses s’enchaînent « le client! », « les changements de décision », « la qualité du code », « le stress », « le refactoring du code et des tests ». Sur ce point Chris demande: « qui a testé son code ? » Les 3/4 de la salle lèvent la main, signe d’une audience particulièrement acquise au TDD et à la qualité en général.

Focus on value : on se concentre sur les fonctionnalités à implémenter, on ne s’embarrasse pas à définir des implémentations inutilement complexes, on va à l’essentiel. YAGNI!

Deliver fast : une bonne conception, un code évolutif et testé pourront facilement et rapidement être adaptés, enrichis. Chris demande : « qui a utilisé un gestionnaire de version ? » Un bras se lève. La question ne se pose pas en général, tout le monde en utilise un au travail. Dans notre cas, l’intérêt était minime. Néanmoins, lors du retour arrière sur la gestion du CSV, un revert aurait peut être permis un gain de temps. Encore un fois, il est évident que sur un développement normal, la question ne doit pas se poser.

Decide late : la décision du support du CSV aurait dû être différée. Son introduction trop tôt et son retrait prématuré a perturbé fortement le développement. Inversement, une fois écrit, la décision de supprimer le code n’était pas urgente et ne pas le faire a même fait gagner du temps par la suite lors de sa réintroduction.

Conclusion

Le Lean Software Development se concentre sur les besoins des clients pour délivrer de la valeur, le plus rapidement possible. Dans cet exercice, pour implémenter les différentes stories dans le temps imparti, il faut aller à l’essentiel, mais aussi délivrer un système capable d’évoluer, de s’adapter sans pour autant sacrifier la qualité.

Enfin Chris termine sur cette phrase polémique de Robert Martin : « quality is proportional to how often you have to say no to your customer » que j’interpréterai de 2 manières. La première, c’est que si la qualité de notre application est bonne, et plus particulièrement son niveau de maintenabilité et d’évolutivité, les adaptations de celle-ci aux besoins du client seront plus aisées. Il sera par conséquent possible de délivrer des fonctionnalités dans un délai raisonnable, sans mettre en péril le projet. La deuxième interprétation que j’en fait est inverse. Il est, en effet, bien souvent nécessaire de dire non à un client. Non pas parce que l’on n’a pas envie de délivrer les fonctionnalités qu’il demande bien sûr, mais pour conserver le niveau de qualité de l’application. Accepter sans cesse des adaptations de dernière minute génère du code souvent mal testé, mal conçu, avec des hacks pour adapter l’existant à un cas inadapté. Si cette opération se produit trop souvent et si une phase de refactoring n’est pas planifiée juste après, il est fort probable que le projet parte à la dérive avec comme conséquence une incapacité à faire évoluer efficacement l’application et donc à délivrer de la valeur au client.