Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Yoann Martinson. Yoann bonjour.
Bonjour, bonjour, bonne soir.
Merci d'être là. Les auditaires ne te connaissent pas encore.
Est-ce que tu peux te présenter en une minute ?
Oui, donc je suis développeur.
Ça fait 17 ans maintenant.
Je pense que je travaille de façon professionnelle dans le développement.
Les 7, 8 dernières années, j'ai passé à aider des équipes à faire le pas,
à travailler en TDD, à livrer de façon plus continue et plus généralement,
développer avec des tests sans se plaindre.
J'interviens quelques mois et parfois une dizaine de jours sur 3 mois
pour aider les équipes à faire ce pas-là qui n'est pas facile,
surtout quand on a la pression du quotidien qui nous pèse dessus.
C'est clair. Et d'ailleurs, tu me parlais d'une pédagogie
que tu avais eu le temps d'affiner au cours du temps,
ou tu es en immersion forte avec l'équipe.
C'est quelque chose que je trouve très intéressant.
J'ai arrêté de faire des formations ponctuelles d'un jour ou deux
sans qu'il y ait un suivi parce que je trouve que c'est inutile.
Les équipes se retrouvent livrées à elles-mêmes
et il n'y a rien qui va pénétrer dans le quotidien.
Tu me racontais qu'il y a une manière assez engagée de transmettre ça.
Oui, j'ai hésite.
J'essaye de ne pas faire que des formations
parce que le pas entre la formation et les étudiants notamment
et le quotidien est tellement fort que beaucoup de gens échouent.
Donc la chose qui marche le mieux c'est de faire effectivement une formation
parce qu'il faut ça pour bien apprendre les concepts
et bien apercevoir où on veut aller.
Mais après, de s'asseoir avec eux en perprogramming
pendant quelques jours, dans le quotidien,
à travailler sur leur story en prenant la prochaine story
et le faire ensemble.
Et ça, il faut l'étaler aussi un peu dans le temps.
C'est-à-dire qu'il y a beaucoup de concepts à apercevoir,
beaucoup de différentes difficultés qu'on peut rencontrer.
Et justement, de faire ça toutes les deux semaines pendant trois mois,
ça permet de lisser ce passage.
Oui, ça permet d'éviter de consommer trop d'énergie
et de rendre ça digest pour l'équipe.
Totalement, oui.
Tout comme ça permet aussi de voir un petit peu
quelles sont les difficultés précises de cette équipe-là,
de cet environnement technique-là.
Et du coup, choisir des catas, des dojos,
c'est-à-dire des mini-information qui peuvent durer deux heures,
une demi-journée, au fur et à mesure,
mais qui reprend le mieux au niveau de l'équipe
et à son environnement technique.
Et tu me parlais d'un livre qui avait pas mal marqué
et qui était à pédagogie, qui était Training from the Back of the Room.
Quel est...
Si tu avais une idée clé que tu as envie de transmettre
de ce que tu as appris dans ce livre et de ce que tu as mis en œuvre,
ce serait laquelle ?
C'est que quand le formateur n'est pas le centre de tout,
alors les élèves apprennent mieux.
C'est-à-dire que l'enseignant est là pour construire le matériel
par lequel les gens vont apprendre par eux-mêmes
à leur propre rythme et à leur propre niveau de difficulté souhaité.
Ça permet d'accueillir une différence de niveau dans le groupe même,
donc ça c'est bien parce que quand on est en train de parler devant des gens
ou enseigner, pousser des connaissances,
il y a des gens qui sont nus parce qu'ils le connaissent déjà
et il y a des gens pour qui c'est trop élevé.
Il n'y a jamais un optimum.
Alors que quand les gens sont...
Quand c'est un appart de décentralisé,
les gens avancent comme ils le sentent.
Et ça tu l'as mis en œuvre dans les équipes que tu as accompagnées, je suppose ?
Oui, c'est avant tout dans la partie formation de cet accompagnement-là.
Et tu arrivais à accompagner des équipes qui atténuaient, je sais pas,
les ordres de grandeur typiques des équipes que tu avais.
Parce que moi je constate qu'au-delà de...
On va dire 20 personnes dans une salle,
quand on les fait travailler en binôme, ça fait 10 groupes individuels.
Pour moi c'est un petit peu la limite pour que ça reste gérable.
C'est même déjà beaucoup.
Toi, c'est quoi pour toi les ordres de grandeur que tu arrives à gérer
en appliquant ce type de principe ?
Oui, ça dépend un peu de certains facteurs,
mais le nombre de 15, j'aime pas aller au-delà de 15.
Après ça dépend si c'est une seule techno, c'est une chose.
Si c'est une techno que je connais, voilà, ça va mieux.
Si les gens sont assez autonomes, ça va aussi mieux.
Voilà, mais entre 10 et 15, ça se passe très bien.
Ça se passe très bien et j'ai le sentiment d'avoir assez de temps
pour tourner et fournir un temps de qualité à tout le monde.
Après ça dépend évidemment aussi de la préparation du matériel.
À quel point on sait où est-ce que ça va poser problème à tout le monde
Est-ce que tu peux nous donner un exemple de matériel
que tu as eu préparé, qui te permettait de gérer
autant des gars qui sont tout à fait nouveaux, assez pratiques,
qui ont un peu du mal ?
Et à côté de ça, tu as un gars qui est déjà sensibilisé,
qui est déjà un peu testé, qui va capter ça super vite.
Concrètement, comment ça se traduit ce principe d'enseignement décentralisé ?
Par exemple, un simple exercice de construire un bout d'application en TDD,
enfin un petit bout de algo, on va dire, par exemple,
ça laisse beaucoup de place à ça parce que les gens,
on peut leur demander une fonctionnalité,
puis il y en a autre, puis il y en a autre,
et donc ils vont avancer jusqu'à là où ils peuvent.
Après, ils vont peut-être avoir beaucoup de tests
et un problème de maintenance de ces tests-là,
donc ça permet d'avoir un challenge différent.
Donc on peut aussi poser certains contraintes à certains groupes,
quand on voit qu'ils vont très loin.
Comme par exemple, un exemple ne pas avoir de conditionnel.
Tu peux donner un problème,
puis pour ceux qui vont vraiment très très vite et qui explosent les compteurs
et qui vont beaucoup plus vite que les autres,
derrière tu leur refais refaire avec toute une série de contraintes
qui là va leur tordre les neurones et qui va les obliger à sortir de leurs habitudes.
Oui, toutes les exercices que sont conçues pour qu'ils n'ont pas le temps de finir,
à part le minimum quelque part qui est l'essence de l'exercice.
Donc tout le monde va aller jusqu'à la fin de l'essence de l'exercice
et certains gens vont aller plus loin.
Parfois, quand on part avec une base de code existante,
typiquement, une chose c'est test sur legacy.
On commence avec des tests
et pour les gens qui n'ont pas le temps d'écrire tous les tests,
on peut faire un checkout d'un état où il y a tous les tests
et après il y aura factor.
Et s'ils n'ont pas le temps de finir leur refactoring,
il y a un autre checkout où c'est entièrement refactorer
là où je demande quelque chose de plus de leur part.
Ça permet d'anémer tout le monde.
Tu crées des niveaux comme des handicapes au golf.
Oui, on peut faire ça comme ça.
Quand tu as des facilités douées,
quand tu as déjà été sensibilisé à ces concepts-là
et que tu as déjà une idée,
tu as un niveau où c'est plus dur
et quand tu n'es plus néophyte ou novice dans ces sujets-là,
tu as des niveaux plus faciles pour t'aider
à bout de se raper plus vite.
Après, on peut leur donner aussi du matériel.
Ça veut dire qu'on peut décrire certaines choses,
on peut décrire des techniques,
on peut leur donner un peu de matériel que peuvent lire et foiter.
On peut leur donner des liens vers différentes solutions
qui regarderont après,
si ils ont du temps.
J'ai fait une formation sur les tests smell,
les codes smell pour les tests.
Et là, l'objetif c'était justement de se former
sur un test smell suffisamment pour pouvoir l'expliquer à son père.
Je te remercie, je vois que la Timebox arrive à la fin.
Je te propose que ce soit le mot de la fin.
Si les auditeurs ont envie d'en savoir plus sur ton travail,
ils peuvent venir où ?
Ils peuvent venir sur mon site changeit.fr
chanjitt.fr
Il n'y a pas de O dans Change It.
Ok, Change It, c'est tout dans le salle mot.
Merci, Johan.
Merci à toi.
Quant à toi, chère auditeurs, j'espère que tu as aimé ce podcast.
Je ne peux pas résister à la tentation de t'inviter dans la maison des compagnons.
La maison des compagnons, c'est l'endroit où les artisans développeurs peuvent progresser
au travers de tout un cursus, tout un ensemble de formations
qui se veulent ultra pragmatiques, très concrètes, pas de blabla,
5 minutes de théorie et beaucoup de pratique.
Donc si ça t'intéresse, viens jeter un oeil, c'est sur maison.artisanddeveloppeurs.fr.
Je te dis à demain.