lundi 3 octobre 2011

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

7 commentaires:

  1. C'est vrai que le TDD c'est un principe auquel on adhère assez vite mais qui met longtemps à s'appréhender !
    J'ai l'impression que c'est plus facile à prendre en main avec les autres. Ainsi ne pas hésiter au début (et même après !) à le faire en pair-programming, ou après en avoir fait un peu à le soumettre à la revue d'autres développeurs de son équipe. Dans une formation tout le monde ne retient pas la même chose, et pour la mise en pratique à deux c'est plus motivant, chacun amène une vision et en plus ça leur rappellera le coding-dojo ;)

    RépondreSupprimer
  2. Très bien, oui, le pair-programming pour commencer.
    Bon, et le TDD en javascript ? Car le nombre de lignes de js ne diminue pas, ces derniers temps...

    RépondreSupprimer
  3. Salut,

    J'ai également passé une journée comme celle-là, mais malheureusement je n'ai pas eu l'effet escompté. C'était la première fois que je "formais" au TDD et ce n'est pas simple, surtout quand dans le public il y a un gourou du code, et qui a une emprise technique sur l'équipe.
    En tout cas un conseil, il faut un bon exemple, càd suffisamment simple et suffisamment complexe. Mais pas trop quand meme sinon on tombe dans des cas qui sont tellement spécifiques que ça casse la dynamique.
    Bilan de ma journée pas terrible, mais bon depuis j'ai appris moi aussi des trucs.

    Sinon je serais ravi de pouvoir assister à ton dojo à Marseille, mais j'ai moi aussi une conf de prévue au même moment ! dommage... ah non ! Karine a pu me la décaler pour que je puisse être là ! Je serai donc ravi :) On se voit le 13 !

    RépondreSupprimer
  4. Intéressant, je n'ai jamais fait de "journée d'introduction", seulement du hands-on de suite dans la base de code de tous les jours.

    Si je devais en faire une (car c'est sûrement un bon commencement). Je tenterais d'inverser la chronologie des étapes et d'introduire la notion d'itération.
    1 démo ultra-simple
    2 coding dojo
    3 un peu de théorie

    puis recommencer avec une exercise plus compliquée.

    La théorie à la fin (ou milieu) car avec quelque chose d'aussi contre-intuitif comme le TDD mieux vaut accrocher la théorie à compte goutte aux expériences du cerveau droit.

    RépondreSupprimer
  5. Merci pour vos commentaires, quelques réactions ...

    @Rémi : malheureusement, l'adhésion n'est pas si rapide que ça, le scepticisme est très présent. Par contre, tu as raison, la mise en pratique sera plus motivante à plusieurs, donc pair-programming à bon escient !

    J'en profite pour préciser qu'une journée comme celle-là ne permet pas forcément de savoir faire du TDD, ça donne une idée de ce que c'est, et j'en profite surtout pour donner des pistes, des conseils, des mises en garde. Le suivi individuel qui suit est quasiment indispensable ...

    @Thierry : le TDD n'est pas lié au langage. Je propose du Java qui est un langage que je maitrise bien pour n'avoir ni doutes ni obstacles de ce côté-là. On peut donc faire du TDD en PHP, C, C#, et bien sûr, JavaScript, pour lequel il existe plusieurs frameworks de tests (Firebug, sa console et ses assertions, JSUnit, ...).

    Pourquoi ta remarque sur le nombre de lignes de code en JS ? Tu veux parler de node.js ? Les avis sont contrastés ...

    @Jérôme : effectivement, le choix du sujet est primordial. Par exemple, pour une introduction, il faut vraiment des sujets extrêmement simples mais tout de même didactiques ! Pas si simple. Et pour le gourou, il faut maitriser son sujet et être force de persuasion, et lorsque le message passe, c'est gratifiant !

    On se voit à Marseille, cool !

    @Johan : ton idée est intéressante, mais la journée passe vite, difficile d'interrompre le dojo, et ma partie théorie du début ne dure pas trop longtemps, 2h grand max, mais sur un rythme vivant, et des thèmes variés, ça passe vite et l'auditoire est en général accroché jusqu'au bout ! ;-)

    RépondreSupprimer
  6. Hello Xavier,

    J'étais tombé sur une série d'articles vidéo : let's play TDD il y a peu, peut être que ça peut t'intéresser si tu ne connais pas déjà ?
    http://jamesshore.com/Blog/Lets-Play/

    Cheers

    RépondreSupprimer
  7. Salut !

    Oui, je connaissais ce site, je l'avais oublié. Sympa, mais je trouve que ça parle beaucoup, et je l'avoue, mon niveau d'Anglais ne me permet pas de bien tout suivre .... :-(

    Par contre, c'est une idée sympa, ce serait intéressant de faire ça en Français, court et concis, pour promouvoir le TDD dans le monde Francophone ...

    Xavier

    PS : qui es-tu "FSB" ... ?

    RépondreSupprimer