“S’engager”

Pendant un planning d’itération, il est commun de demander à l’Equipe de fixer/choisir/établir son “engagement”. Et la plupart du temps, le comportement attendu consiste à choisir un ensemble de fonctionnalités à livrer au client à la fin de l’itération qui commence ce jour là.

Dans Scrum, ce rituel de planning se répète à chaque commencement d’itération.

Pendant l’itération, c’est le temps de la réalisation. C’est là que les artistes-artisans informaticiens réalisent le miracle de leur art pour livrer un morceau de logiciel d’une qualité exceptionnelle. Hum… Mais au fait, c’est quoi pour vous la Qualité ? Autour d’un café on devrait probablement s’entendre sur le fait que des professionnels de l’informatique devraient livrer des logiciels de qualité. Voire, que leur “engagement” a quelque chose à voir avec “livrer un logiciel de qualité”.

Durant les dix dernières années, une technique appelée TDD s’est développée. J’imagine que vous connaissez ça très bien, ainsi que sa représentation la plus populaire :

La couleur pour le côté du refactoring est parfois le vert pour exprimer que pendant une opération de refactoring, “les tests passent toujours”. J’ai pris ici le gris surtout parce que sur ma magnifique casquette tdd, le refactoring est en gris.

Mais au fait : quelle est la vocation du refactoring ? Parce que si le test passe, je pourrais livrer le code et n’en parlons plus ! Bien sûr la plupart du temps le logiciel n’est pas fini ; il faut continuer. Pour pouvoir continuer, on met à profit ce temps de refactoring pour transformer le code que l’on a écrit à la va-vite pour faire passer le test en un “code de qualité”. L’objectif semble donc être la qualité. Autrement dit, l’artiste-artisan informaticien professionnel construit un code de qualité pendant le refactoring. Encore autrement dit : l’artiste-artisan informaticien respecte son engagement de qualité pendant le refactoring.

Maintenant si je dessine le cycle du TDD plutôt comme ça, est-ce que vous me voyez venir ?

En mélangeant les notions d’engagement du planning d’itération et de refactoring du tdd, on pourrait vivre la situation suivante : pendant un planning d’itération, l’Equipe considère les premiers éléments de carnet de produit, écrit les tests et les fausses implémentations qui font passer les test, et réfléchit à son engagement : quel part du code écrit pendant le planning pouvons-nous transformer en code de qualité pendant l’itération ? Par exemple pendant le planning on a fait passer 4 tests mais notre engagement ne couvre que la livraison du code faisant passer les 3 premiers.

Cette approche met au premier plan les notions de qualité et de professionnalisme des équipes on affichant que la valeur des professionnels de l’informatique va se chercher pendant le refactoring. “Pisser du code” ne s’appliquerait plus qu’au code écrit le plus vite possible pendant le planning pour faire passer les tests, pas au code que l’on livre.