Le coaching, SAV de la formation

Vous avez décidé de vous former au Test-driven development (TDD) : bien vous en a pris !

Nous sommes donc partis 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 design, 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 👏.

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 👏. Nanti(e) de plusieurs années de programmation, vous aurez acquis l'intuition qu'il ne faut pas trop compter sur les tests et qu'il vaut mieux les considérer simplement pour ce qu'ils sont : une aide à l'écriture de code 👏.

Cette nouvelle pratique trouvera ainsi 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 dans l'expression de contraintes métier 👏 (voir à ce sujet l'excellente conférence de Julien Truffaut).

En bref, vous ferez à l'issue de ces 2 journées un usage quotidien et raisonné du TDD, comme on est en droit de s'y attendre à l'issue d'une formation au TDD 👏.

Ou pas.

Ah bon ? Voilà qui est surprenant 😁

Tout est affaire de temps et de pratique bien sûr : "La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information", aimait à rappeler un physicien rentré dans la culture populaire.

Si la formation est un excellent point de départ, elle n'est jamais qu'une étincelle et la marche peut se révéler haute pour passer de la théorie à la pratique. Le changement prend du temps et occasionne de nombreux doutes. Seul(e) face au clavier, les questions sont parfois… angoissantes !

Clairement, 2 journées pleines de formation au TDD sont indigestes et j'évite ce format autant que possible. A l'issue d'une telle formation, on considère qu'un apprenant retient en moyenne seulement 20% du savoir proposé.

Le coaching d'une équipe offre par contraste une grande souplesse. Voyez plutôt :

• Formation initiale d'1 journée par groupes de 2 ou 3 apprenants : bases théoriques et mise en pratique sur quelques exercices simples, appelés kata ;
• Puis accompagnement individuel lors de sessions de 1h30 toutes les 2 semaines pendant plusieurs mois sur des cas concrets issus de leur codebase (+ kata de difficulté croissante) ;
• Quand les apprenants disposent d'un peu de recul sur la pratique, nouvelle 1/2 journée de formation pour mettre en perspective les acquis, introduire de la nuance (quand faire du TDD ?) ainsi que les approches Inside-Out/Outside-In.

L'expérience prouve qu'en 6 mois, les développeurs et développeuses ont intégré le TDD en tant que pratique quotidienne et raisonnée.

Le coaching s'inscrit ainsi dans la continuité de la formation. Le coaching, c'est le service après-vente de la formation 🥁.

Pfiouuu… Tout ça pour ça 😋

À la semaine prochaine 👋 !