Moins c’est mieux !

Je suis convaincu depuis longtemps que l’agilité génère moins de bugs que les méthodes traditionnelles et j’avoue avoir souvent argumenté cela par la mise en place d’un socle technique et de pratiques d’ingénierie (Tests automatiques, Intégration continue …)

Dernièrement j’ai eu l’occasion de jouer une demi douzaine de fois le jeu « Artistes et Spécifieurs » dans un contexte universitaire et professionnel, et cela m’a donné l’opportunité de confirmer un argument supplémentaire pour expliquer pourquoi l’agilité génére moins de bugs que les méthodes traditionnelles.

Bien entendu il ne s’agit pas d’une pratique d’ingénierie car le jeu n’en comporte aucune mais bien d’un effet très intéressant lié au processus même de l’agilité.

Lors de la première itération de ce jeu, les équipes n’ont pas vraiment de processus agile et sont mises sous pression par le temps très court de 10 minutes pour réaliser leur objectif qui est une copie d’un dessin prédéfini, et j’avoue contribuer voontairement à cette pression en égrénant les minutes puis les secondes restantes.

Ces derniers temps, j’ai constaté que tous les Artistes (les concepteurs) essayaient systématiquement de rajouter une forme supplémentaire dans les dernières secondes, car en effet, il y a toujours une dernière spécification qui est fournie dans la dernière minute et que les artistes n’ont pas encore eu le temps de comprendre correctement.

Cette dernière forme ajoutée au produit final est toujours fausse puisqu’il n’y a eu aucune analyse du besoin ni discussion avec les Spécifieurs sur le besoin réel. J’en profite alors pour leur faire remarquer qu’ils viennent d’ajouter un bug dans le produit et qu’en tant que client mon attention est entièrement attirée par ce défaut au détriment de ce qui pouvait être bien dans le reste du produit.

La discussion qui s’ensuit est très intéressante car il s’agit de savoir s’il vaut mieux faire plus et moins bien ou moins et mieux.

La plupart des participants pensent généralement qu’il vaut mieux faire plus et moins bien (on me parle de « réflexe » ou « d’apprentissage scolaire » mais sans savoir vraiment expliquer pourquoi) mais lorsque je leur demande si, en tant qu’utilisateurs, ils préféreraient un téléphone avec une icône figée et erronée sur l’écran ou un téléphone sans cette icône, la réponse est systématiquement la 2ème. Etonnant non ?

Lors des itérations suivantes, beaucoup plus agiles, ils arrivent généralement à résister assez facilement à la tentation d’ajouter des bugs à la fin et sont même beaucoup plus sereins vis-à-vis du temps qui passe, car ils savent qu’ils ont toujours un incrément du produit de disponible et donc peu importe le chronomètre et moi qui décompte les minutes.

En conclusion je suis conforté sur le fait que l’agilité introduit moins de bugs dans le produit simplement par le processus qui conduit à faire les choses étapes par étapes (en particulier de petites choses), en les terminant à chaque fois, et en s’affranchissant de la dictature du délai qui conduit à créer des bugs à la fin !