Coding-dojo ou l'apprentissage du TDD

Introduction

Dans le cadre de mes interventions en entreprise, j'ai eu il y a quelques temps une demande pour « pousser » une équipe de développements vers le TDD. M'a réponse a été de proposer une solution en 3 étapes sur une journée entière.

Cette journée s'est déroulée le lendemain d'une journée de formation, ou plutôt comme je préfère dire, d'information « Agilité et Scrum ». Les participants à la journée « TDD » avaient donc connaissance des valeurs et principes de bases de l'agilité et de Scrum, véritable pré-requis pour aller droit au but du TDD.

Étape 1 : théorie

La première partie de la journée est une présentation théorique sur base d'un diaporama.

On commence en abordant le sujet des tests : tests unitaires, tests d'intégration, tests fonctionnels, automatisation des tests, etc ... Pour faire du TDD, il faut évidemment être d'abord convaincu de l'intérêt d'avoir des tests, et qu'il est plus facile de les écrire avant plutôt que après le code de production, le système étant alors forcément « testable ». On revient notamment sur le coût de correction des bugs qui sera d'autant moins élevé que le bug est décelé tôt (cf Scott Ambler).

On évoque ensuite les outils : les frameworks de tests (JUnit pour Java, PHPUnit pour PHP, Hunit pour Haskell, etc …) et les frameworks de mocks (Mockito, Easymock, JMock, PowerMock, etc …). C'est l'occasion d'expliquer l'intérêt des mocks quasiment indispensables si on fait une architecture bien découpée, à couplage lâche et injection de dépendances.

On ne peut parler de tests sans poser les règles de base, ainsi que les bonnes pratiques : 1 test pour 1 cas, des tests structurés, rapides, évolutifs et propres, du refactoring avant toute chose, etc …

Vient ensuite la présentation du TDD proprement dit : pourquoi du TDD, principes, cycle (rouge-vert-bleu), les variantes, les difficultés, les erreurs à ne pas commettre, les conseils, etc …

La partie théorique se termine par la présentation du coding-dojo : c'est quoi ? Pour qui ? Le Kata et le Randori, organisations et logistique, conseils, etc ...

Étape 2 : démonstration

Pour illustrer le propos, comme on dit, la matinée se termine par une démonstration. Je me met au clavier avec mon environnement de développement, et en partant de sources vides, je montre comment se déroule le TDD.

La démonstration se déroule sur plusieurs exemples de difficultés progressives pour montrer les bases du TDD : un exemple basique, la mise en œuvre sur un exemple plus complet mais toujours simple, et enfin, l'utilisation de mocks sur une exemple bâti sur plusieurs classes, donc des tests sur une classe ayant besoin de collaborateurs.

J'ai constaté des intérêts multiples à cette phase de démonstrations : la possibilité pour les développeurs de concrétiser les explications précédentes, la preuve par la pratique de la faisabilité, un gain de crédibilité et de légitimité en mettant les mains dans le cambouis.

Étape 3 : coding-dojo

L'étape suivante, qui se déroule sur au moins 3h l'après-midi, est la plus ludique et souvent la plus attendue. C'est le moment du « conding-dojo », que j'appelle également « séance de développement en groupe ».

Ma mise en pratique est assez proche des principes que je ne rappelle pas ici, et qui sont facile à trouver sur internet. Par expérience, et après avoir testé différentes durées, je fais des « tours » de 6'. Par contre, je n'hésite pas à mettre le chrono en pause si une discussion prend place pour ne pas pénaliser et frustrer le pilote en place.

Côté sujets, je propose des choses extrêmement basiques, selon les niveaux de l'équipe présente, l'important étant de bien mettre le focus sur le TDD, et non sur une problématique algorithmique ou autre. Ça n'est pas l'objectif d'un dojo « TDD », mais ça pourrait l'être pour un autre dojo. En effet, le coding-dojo est assimilable à une séance de formation, par la pratique, extrêmement instructive. L'objectif d'un dojo doit être unique et clair, et les sujets doivent être en accord avec cet objectif : découverte d'un langage, d'une techno, étude collective de solutions algorithmiques, etc …

Pour bien démarrer la séance, je n'hésite pas allouer le temps nécessaire à l'équipe présente pour échanger sur le sujet pour définir une approche collective. Selon le niveau d'expertise des participants, je les conseille et les guides vers des approches d'architectures « agiles », tout en les laissant maîtres de leurs choix pour qu'ils restent à l'aise pour la mise en pratique ...

En ce qui me concerne, je n'interviens pas en tant que pilote pour permettre un maximum de passage pour les participants. Je joue donc les rôles d'animateur (tours de rôles, timing, …), et de Product Owner (pour les questions sur le sujet et les éventuels choix à faire, en apportant des réponses rapides et claires). Je n'hésite pas non plus à guider les intervenants en suggérant des solutions ou des pratiques, sans s'écarter de l'objectif principal du dojo : mettre en œuvre le TDD.

Mais tout cela ne suffit pas ...

Et oui, ça n'est pas en quelques heures de théorie, démonstrations et mise en pratique qu'on devient maitre du TDD. C'est pour cela que je conclue la journée en donnant quelques conseils aux développeurs : n'attaquer pas forcément dès demain matin, attendez une bonne opportunité, un bout de code qui vous semble favorable au TDD, que vous sentez bien. Mais ça n'ira pas tout seul ...

Alors je propose aux développeurs d'essayer le TDD, de noter les difficultés, les opportunités, etc ... et que nous nous revoyions de temps en temps, régulièrement, pour aborder individuellement ou collectivement ces opportunités, les essais réalisés, les succès, les échecs, etc ...

Pour moi, cette approche globale est la meilleure solution pour accompagner une équipe vers la pratique du TDD, ou du moins vers une approche plus « agile ».

Et vous ?

Quelles sont vos expériences en matière d'apprentissage du TDD, de coding-dojo, etc .... merci pour vos retours et commentaires !

Pour ceux qui peuvent ...

... je serais à l'Agile Tour à Marseille le 13 octobre 2011 pour animer un atelier participatif de 2h sur ce sujet, l'occasion de mieux se rendre compte de quoi il s'agit, et d'échanger sur le sujet !

A bientôt ...