2 jours de formation, 6 mois de doutes

• Accompagnement

Vous avez décidé de vous former au Test-Driven Development (TDD) : excellente initiative !

Vous voilà donc parti(e) pour 2 jours, à l’issue desquels vous saurez écrire des tests ayant toutes les qualités F.I.R.S.T. et maîtriserez les 3 règles fondamentales du TDD ainsi que leur mise en œuvre (red/green/refactor). Convaincu(e) des bienfaits de cette méthode en termes de qualité, de couverture et de documentation du code, votre pratique s’en verra changée du tout au tout dès votre retour au bureau le lundi suivant, après un weekend récupérateur. Bravo.

Ces 2 jours de formation vous auront également permis d’explorer diverses variantes de TDD (Inside-Out, Outside-In, test && commit || revert), que vous utilisez maintenant à bon escient en fonction des situations. Parce que vous êtes une personne follement intuitive, vous aurez rapidement compris qu’il vaut mieux ne pas trop compter sur les tests et les considérer simplement pour ce qu’ils sont : une aide à l’écriture de code. Bravo.

Cette nouvelle pratique trouvera sa place de manière harmonieuse dans l’ensemble des outils dont vous disposez, à côté d’autres types de tests et d’un usage avancé du typage, alternative puissante quand il s’agit d’exprimer des contraintes métier. Ainsi, vous ferez au terme de ces deux jours un usage aussi nouveau que raisonné du TDD, comme escompté à la lecture des objectifs de la formation. Bravo.

Bravo, vous êtes très fort… mais la réalité est un peu plus compliquée.

Tout est affaire de temps et de pratique : « La connaissance s’acquiert par l’expérience, tout le reste n’est que de l’information », aimait à rappeler un physicien entré dans la culture populaire. D’autant qu’il faudrait déjà retenir l’information. Deux journées pleines de formation au TDD sont indigestes pour beaucoup. On ne retient que peu d’une telle session : 20% dit-on (la statistique n’est pas suffisamment étayée).

Par ailleurs, la marche qui va de la théorie à la pratique peut se révéler haute. Les exemples proposés en formation sont généralement bien circonscrits, les problèmes sont bien posés et la complexité est bornée. Alors que de retour face à la codebase, il faut faire avec la dette technique, les urgences qui ne manqueront pas d’arriver et, plus généralement, la « vraie » vie. Tout est plus compliqué. C’est justement là qu’il faut de la méthode, mais aussi de l’accompagnement. Le changement prend du temps et occasionne de nombreux doutes. Seul(e) face au clavier, les questions sont parfois angoissantes.

L’accompagnement d’une équipe dans la durée est, par contraste, synonyme de souplesse et d’adaptabilité. Voici un exemple d’interactions :

• Formation initiale d’1 journée par groupes de 2 ou 3 : bases théoriques et mise en pratique sur quelques exercices simples (katas) ;
• Accompagnement individuel au fil de l’eau, 1h30 toutes les 2 semaines, pendant plusieurs mois. Katas de difficulté croissante et cas concrets apportés par le développeur ;
• Au bout d’un certain temps, 1/2 journée de formation en groupes pour mettre les acquis en perspective, introduire de la nuance (quand faire du TDD ?) et un peu plus de théorie (approches Inside-Out/Outside-In), si le moment est bon.

Surtout, ce format permet d’identifier avec précision les sujets sur lesquels travailler : peut-être le TDD n’est-il pas la priorité pour tout développeur ? Mieux vaut d’ailleurs éviter de définir un accompagnement par un ensemble de pratiques, aussi bonnes soient-elles, et plutôt partir des difficultés observées au quotidien, individuellement et en équipe (lead time élevé, bugs, régressions etc.)

Pour que le coaching fonctionne, il faut un soutien managérial fort, et que cette volonté se traduise dans les faits par du temps dédié (à concurrence avec l’opérationnel durant la phase d’investissement). Je recommande de travailler à petite échelle (2, 3 équipes maximum) et impérativement sur base du volontariat, avec des personnes en recherche active de réponses. Par la suite, on constate souvent un effet « tache d’huile », par lequel le savoir diffuse de proche en proche, par des pratiques informelles (pair programming) ou plus organisées (communautés de pratiques, Brown Bag Lunches etc.)

Dans tous les cas, cette transformation prend du temps. Les bénéfices réels ne peuvent être escomptés avant 6 mois, voire 1 an. Le coût est bien sûr sans rapport avec celui d’une formation, mais le bénéfice non plus. Quand la formation est ponctuelle et sert parfois à cocher des cases, un tel accompagnement est a contrario un investissement.

Si la formation est un excellent point de départ, elle est, au mieux, une étincelle. La formation ne saurait, à l’évidence, être suffisante – probablement n’est-elle d’ailleurs pas plus nécessaire.