Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante. Prêt à passer au niveau supérieur ? C'est parti.
Aujourd'hui je suis avec Frédéric Leguédois. Frédéric bonjour.
Bonjour. Tu m'avais dit que dans ce que tu faisais,
parfois il t'arrivait de faire du coaching craft. Est-ce que tu peux rappeler aux auditeurs ce que
tu fais dans la vie ? J'ai une activité de conseil, que ce soit du coaching agile ou craft,
ou une activité de conception, de réalisation, de logiciel sur les mesures ?
Ce qui m'intéressait particulièrement, c'est d'avoir ton retour d'expérience quand tu
accompagne des équipes en binôme. Parce que ce que je constate, c'est qu'en tant qu'experts,
on attend souvent de nous de tout savoir. Et il y a quelque chose qui est plus ou moins bien compris
quand j'accompagne les équipes. C'est que en tant qu'experts, moi je suis expert d'un certain
processus et puis j'ai une certaine zone d'expertise. Par exemple, je vais pouvoir aider quelqu'un à écrire
des tests unitaires ou des tests automatiques tout simplement et mettre en œuvre une démarche TDD
parce que je suis expert de ce processus-là. Par contre, souvent je travaille avec des gens
qui sont meilleurs que moi dans leur langage ou leur framework. Et c'est justement la jonction des
deux qui donne une alchimie intéressante. Mais parfois, je me retrouve avec des gens qui attendent
de moi d'avoir presque le même niveau que eux en fait sur leur langage. Comment tu gères ça ?
Je le gère en toute transparence en indiquant effectivement mon niveau de compétences exactes
ou d'incompétences exactes et en précisant dès le début que sur effectivement la manipulation
d'un framework ou la manipulation d'un langage ou d'un IDE, la personne qui est quotidien dessus,
qui plus est quand on intervient sur un projet existant, la personne qui est quotidienne
dessus sera très probablement plus veloce, plus réactive. Mais effectivement, c'est une question
qu'on a de manière quasi systématique parce que la différence n'est pas faite entre finalement
maîtriser très bien la technique d'un projet ou les détails d'un framework et ce que tu pouvais
évoquer, comprendre les tenants, les aboutissants de la TDD, de la programmation au binôme, du moppe
programming, tout ce genre de choses qui ne sont pas forcément compréhensibles. La manière dont
je le gère le plus souvent, c'est en précisant bien quel est le domaine de compétences et ce
qui n'est pas le domaine de compétences. Ça me paraît être assez salutaire et en t'écoutant.
Je me dis que je le marque peut-être pas assez dans les échanges, finalement de commencer les
échanges en reprécisant les rôles, clairement disant voilà ce que je viens amener, voilà ce que je viens
pas amener, voilà ce que t'amènes et voilà ce que l'addition des deux va faire une multiplication
plus qu'une addition. C'est vrai que ça mérite d'être marqué peut-être. Et du coup dans les
échanges, dans le travail ambinome, c'est quoi les... je ne sais pas, est-ce que tu auras une
sujet là de peut-être de déstabilisant ou de troublant dans les expériences que tu as pu faire ?
Ce qui est toujours délicat, c'est d'expliquer à certain nombre de pratiques qui auront des effets
bénéfiques sur le long terme à des équipes qui n'ont jamais travaillé de la sorte et du
coup qui ne peuvent pas percevoir les effets bénéfiques sur le long terme. Ça c'est compliqué.
La programmation ambinome, pour en ressentir les bienfaits, faut la pratiquer pendant plusieurs mois.
C'est le jour où il y a un développeur qui va être absent et que l'autre va pouvoir prendre
au pied le projet parce qu'en fait il a binommé pendant des dizaines d'heures sur le projet,
qu'on comprend que c'était intéressant. Mais avant ça on ne le comprend pas et donc il y a un peu
cette difficulté, il faut avoir une certaine forme de confiance pour se lancer dans des pratiques
où on a beau l'expliquer et le démontrer et l'argumenter. La vraie conviction va arriver avec le vécu.
Même sur des sujets comme ça, sur le binommage, même moi, alors que je suis ultra convaincu,
j'arrive encore à m'émerveiller après une séance de binommage, de la qualité, ce qui
produit de l'écart de qualité entre ce que j'avais en tête à un moment donné pendant le
travaillant de binômes. Au début de binommage, on a un problème à régler, j'ai commencé à me faire
une idée de comment je pouvais envisager de l'attaquer et tout ça. Et puis à l'issue du
truc, à force de robots ou de ping-pong, j'arrive encore à me dire, mais c'est incroyable la différence.
Et à propos des petites anecdotes, j'ai animé pas mal de Kata ces derniers mois,
même ces dernières années, et très souvent effectivement, quand on arrive dans une organisation,
on reprend un peu un Kata de base, fondamentale et on le fait. Et j'ai même évoqué merveillement sur
la multitude des solutions à porter. Non seulement la multitude des approches,
mais la multitude des solutions à porter. C'est clair, moi j'entends un gars dire,
non mais ce bon skatage l'est déjà fait, j'ai envie de dire, mais vas-y,
justement, essaye de faire autrement, tu verras comme c'est riche.
Et du coup, c'est même très perturbant parce que déjà, il n'y a aucune équipe qui le fait
de la même manière, aucune. Très souvent, en prenant le temps, elles arrivent tout à le résoudre.
Donc déjà, on a une multitude de solutions et on peut dire qu'il y en a des mauvaises,
mais c'est difficile de dire qu'il y en a une qui est vraiment très supérieure à l'autre.
Et donc du coup, on en arrive à une approche où finalement, à un même besoin exprimé par un client,
je ne parle même pas de différence technologique, je parle du principe que c'est la même technologie,
le même framework et le même historique du projet, il y aurait une multitude de solutions
et donc du coup, la question de la qualité du logiciel, là, elle est préniente.
C'est-à-dire qu'il n'y a pas une voie unique, il n'y a pas de corriger au Cata.
On fait un exercice, il n'y a pas de corriger.
C'est ça, c'est extrêmement troublant.
Et tu repartes les Cata, c'est intéressant parce qu'en ce moment-là,
j'ai mis en vente le cursus complet et j'ai parfois des retours de gars qui me disent,
« Ah, t'es Cata, c'est gentil, mais j'aimerais bien une solution clé en main pour moi,
pour pouvoir demain écrire des tests. »
Et je lui pose la question, mais tu les as fait les Cata ?
Ah non, ben ouais, mais tu vois, il y a un truc hyper frustrant,
c'est vrai que le Cata, c'est un côté un peu bacassable et jeu d'enfant,
mais en fait c'est hyper puissant et je vois des gars qui essaient d'écrire des tests ou de faire du TDD
sans être passés par cette phase-là.
Du coup, ils n'ont pas le déclic parce que souvent, j'ai des gars qui me disent,
« Oh non, c'est bon, t'as des diamétries, puis tu fais un Cata et puis tu te rends compte qu'en fait,
pas du tout, c'est pas parce qu'il y a trois tests que tu es vraiment dans cette démarche-là.
Comment tu fais toi pour valoriser le Cata et puis pour ramener les développeurs à ce déclic,
ce que j'appelle le déclic du TDD ?
En fait, j'ai énormément de mal, je le confesse.
Ah, ça va, je me sens moins seul.
Voilà.
Et j'ai une réflexion avec d'autres développeurs,
dernièrement, on se pose cette question, est-ce que le Cata est suffisant
et est-ce qu'il ne faut pas envoyer en immersion un développeur expérimenté mettre en place avec ?
C'est plus je montre ou je fais émerger deux heures par semaine auprès d'une équipe,
c'est on va directement au cœur des projets, on le met en place ensemble.
Le truc, c'est que ça coûte une blinde de faire ça, j'imagine, le prix d'un consultant.
Oui, bien sûr.
Après, je vais être taquin, ça coûte combien de pas le faire ?
Oui, en fait, je ne te parle pas de la valeur générée pour l'entreprise,
parce que par définition, l'entreprise ne l'a pas encore trop bien perçu,
je te parle de le vendre, il faut que l'entreprise ait un sacré niveau de confiance
et dans la démarche et dans le bonhomme, pour se lancer vu les TGM des consultants.
Et d'un côté, on ne va pas avoir le temps d'évoquer ça,
mais c'est toute la question de à quel point, à un moment, on veut forcer les gens à se transformer.
Et on pourrait en parler aussi sur les démarches agile,
est-ce qu'on peut forcer les gens à se transformer ?
A quel point il ne faut pas plutôt faire du bon casting à l'origine
et de se dire qu'il y a un moment où je vais avoir besoin dans mon casting, dans mon équipe,
quelqu'un d'un peu mur.
Je donnerai toujours cet exemple sur le comparatif entre le management et l'éducation canine.
Je ne devrais pas le faire, mais à un moment, dans une meute, on met un chien qui a l'expérience.
Et il y a un paraif et de mimétisme, les gens, c'est la pauprie.
Alors je sais que ça fait toujours clier.
Oui, effectivement, la comparaison canine me paraît un petit peu borderline,
mais on va dire un alpha, quelqu'un qui mène le groupe, peut-être à un espèce de teglide.
Oui, peut-être le teglide, mais vraiment par mimétisme,
ça fonctionne beaucoup mieux que par donner de l'air.
Oui, un leader inspirant plus qu'un leader ordinateur.
Oui, et puis voir que sur le terrain, il y a des gens qui le font, ça marche,
voir les effets bénéfiques et avoir ce ressenti, ce vécu,
et du coup, les gens vont basculer parce qu'ils vont l'avoir vu sur un projet.
Et bien écoute, Frédéric, je te propose que ce soit le mot de la fin.
Merci de ta contribution, si les auditeurs veulent en savoir plus sur ce que tu fais, ils peuvent venir où ?
Alors leguedois.fr, il y a un site internet et puis aussi un compte Twitter et un compte clean que les mines.
Et bien écoute, merci beaucoup.
Merci à toi.
Quant à toi chère auditeur, j'espère que tu as apprécié cet épisode.
Si c'est le cas et que tu as envie de faire un point sur tes pratiques,
voir où est-ce que tu en es, je t'invite à venir sur artisan-developpeur.fr slash diagnostic.
Tu as une vingtaine de questions qui te permettent de faire le point sur là où tu en es
et puis de comparer tes résultats et puis enfin d'avoir des suggestions de contenu
pour t'améliorer petit à petit, jour après jour.
Si tout ça t'intéresse, c'est sur artisan-developpeur.fr slash diagnostic
ou sur companion.artisan-developpeur.fr.
Je te remercie et je te dis à bientôt.