Bienvenue sur le podcast Artisan Developer,
l'émission dédiée au programmeur,
qui parle de techniques, bien sûr, de codes durables,
mais aussi du métier en lui-même, de recrutement, de développement personnel,
ou encore d'entrepreneuriat,
pour t'accompagner dans une vie de développeur épanouissante.
Alors, est-tu prêt à passer au niveau supérieur ?
C'est parti !
Aujourd'hui, je suis avec Mickael Aguarelli et Jonathan Duberville.
Bonjour les gars.
Salut Benoît !
Aujourd'hui, on va travailler autour de la notion de pérennité d'équipe,
comment rendre une équipe pérenne sous l'égide de cette question de l'arène de cette semaine,
préfère-tu développer ta polyvalence ou ton expertise ?
Bien évidemment, rejoins-nous dans l'arène pour participer à cette question,
arène.artisan-developpeur.fr.
Je vous passe la parole les gars.
C'est la première fois que vous passez sur le podcast.
Est-ce que vous pouvez vous présenter ?
Alors en général, je dis une minute, mais vous êtes deux,
donc ça vous fait 30 secondes chacun.
Ok.
Alors, je vais commencer.
Moi, c'est Mickael.
Je travaille pour Octo.
Je suis dans le campement Provence.
Ça fait 6 ans que je bosse chez Octo.
Et donc, j'ai commencé en tant qu'expert fonte et aujourd'hui, je fais plus de TechLeading.
Ok.
Donc moi, je m'appelle Jonathan.
Je suis dans le campement qui est à l'opposé de la Provence à Lille.
Et je suis aussi TechLead chez Octo.
Je suis arrivé déjà sur un poste de TechLead.
Et avant, effectivement, j'ai eu aussi ma petite tendance expertise.
Alors là, tout de suite, j'ai envie de vous poser une question.
C'est quoi un expert ?
Parlement, justement, pas un expert en TechLead chez Octo.
Il fait quoi ?
C'est quoi ces missions ?
Alors, nous, on a ce qu'on appelle une posture.
On demande d'adopter une posture.
Enfin, c'est quelque chose qui se fait assez naturellement.
Mais on a quatre pentes dans la posture d'un TechLead chez Octo.
On lui demande d'être un expert, d'avoir un pan, un domaine sur lequel il a une très bonne connaissance.
Mais ce n'est pas tout.
Il faut aussi qu'il sache être un bon facilitateur,
faire que les interactions dans son équipe se fassent de manière naturelle.
Il faut qu'il sache aussi coacher les gens, qu'il sache les faire monter en compétences.
Et le dernier que j'oublie toujours, Jonathan.
Mentor.
Mentor.
Oui.
En fait, dans cet aspect-là, on part du principe qu'un TechLead, en général, il va devoir aussi faire,
enfin aider ses collègues dans justement les décisions de carrière,
quelles expertises je devrais développer, dans quel sens je dois aller, etc.
Et on accorde beaucoup d'importants de ça, effectivement.
Sur l'aspect expert, ce qui est cool, c'est que,
officiellement, entre guillemets, dans Culture Code, qui est un de nos ouvrages blancs,
qui est disponible, on dit clairement qu'un TechLead doit au minimum coder 30% de son temps, au minimum.
Donc effectivement, cet aspect expert, on y tient quand même beaucoup.
Ok.
Et pendant la préparation de l'épisode, vous aviez un angle d'attaque,
justement, de cette question de l'expertise versus la polyvalence que j'aimais bien.
Vous l'attaquez sous l'angle de la pérennité de l'équipe.
Est-ce que vous pouvez développer un peu l'idée qui est derrière pour vous ?
Oui.
Alors, en général, quand on arrive sur une mission,
quand on nous appelle, c'est surtout pour tacler un problème technique,
ce qui fait qu'on va faire appel à des experts, des experts en front, des experts javas,
pour aider une équipe qui est déjà existante à résoudre certains problèmes.
Le problème de cette approche, c'est que souvent, l'expert vient, va faire son travail,
et une fois qu'il sort de la mission, l'équipe qui est elle présente,
n'arrive pas forcément toujours à reprendre ce qui a été fait par l'expert.
Ce qui manque, c'est surtout une montée en compétence de l'équipe complète.
C'est ce sur quoi on essaie de faire très attention,
et de faire en sorte qu'on vient d'abord pour apporter une expertise.
Mais très souvent, quand on est en mission, on se rend compte qu'il n'y a pas que ce petit point qui pose problème,
et que c'est beaucoup plus vaste, et là où on va assurer la survie,
ou la pérennité de notre mission, c'est quand tout le monde prendra aussi en compétence avec nous
sur les différents sujets qui a attaqué.
Peut-être qu'on peut même aller un peu plus loin,
parce que Mickaël nuance beaucoup en disant ce petit point.
Moi, j'ai même la sensation que sur la plupart des projets où on arrive,
sous cette bannière expert, ça va nous aider à passer la porte.
Une fois qu'on est arrivé, on se rend compte que le problème, c'est quasiment jamais l'expertise.
C'est beaucoup d'autre chose.
C'est quoi les exemples que tu as en tête, par exemple, récemment,
que tu as eu, c'était quoi les problèmes profonds ?
Un problème assez courant, c'est une fois qu'on arrive dans l'équipe,
on se rend compte que les développeurs ne comprennent pas le métier pour le calicone.
C'est assez courant.
Les besoins sont formalisés sur un format assez à la mode, c'est la user story.
Sauf que cette pratique-là, ça accompagne d'autres pratiques
autour qui aident à justement avoir un besoin métier
qui soit le plus affiné possible pour pouvoir commencer à travailler.
Déjà, un premier biais ou un premier problème qu'on peut observer,
c'est que ce besoin métier n'est jamais suffisamment travaillé.
Le développeur commence à coder.
On se retrouve potentiellement avec des bugs en production
qui ne sont pas liés au fait que le développeur code mal,
qui fait mal son travail de code,
mais qu'il a eu une mauvaise compréhension de ce qui avait été exprimé à la base.
C'est un biais que je vois souvent, effectivement,
où on a remplacé la vieille spec d'avant.
Les spécifiaires, ils l'ont bien compris, leur intérêt.
Des post-it, c'est vachement plus léger.
Mais ce n'est pas pour autant qu'il y ait l'échange, voire même,
et je le vois parfois des kip où c'est les devs eux-mêmes
qui disent que vos sprint planning, vos machins,
c'est long, c'est barban.
Je les vois qui sont un peu impatients de retourner à leur clavier et de commencer à coder.
Et tu dis, mais si on n'a pas passé un minimum de temps,
comment vous allez comprendre ce que vous allez devoir coder ?
Parce que je veux dire, il y a des métiers qui,
à l'arrigueur, qu'on peut s'approprier facilement parce qu'on le comprend bien,
et puis il y a des métiers, ce n'est pas tout à fait la même.
Comment ça te fait réagir par rapport à ce que vous voyez sur le terrain ?
C'est souvent ça. Quand on rentre sur une mission,
enfin, souvent, le client, quand il nous appelle,
c'est souvent pour des problèmes techniques.
Et par expérience, c'est le plus gros des soucis
et plutôt dans la communication de l'équipe,
enfin, entre le métier et la technique.
C'est là, surtout, qu'il y a des efforts à faire.
Ce qui fait que la technique en elle-même,
c'est quelque chose qui devient secondaire
dans l'approche qu'on a du technique de ce qu'on doit apporter
en tant que consultant sur une mission.
Ce qui est paradoxal, quand même, parce que finalement,
c'est quand même pour ça que vous êtes appelés à la base.
Donc, il y a ce truc, il faut rentrer,
mais une fois qu'on est rentrés, on vient traiter autre chose.
Je pense que le fait d'avoir une expertise
nous donne une certaine légitimité
par rapport à l'équipe dans laquelle on va intervenir.
Donc, on ne montre un peu pas de blanche,
on montre qu'on n'est pas des rigolos
qui venant un peu leur apprendre la vie de manière top-down,
mais plus se mettre à leur côté,
travailler avec eux, comprendre leur manière de faire
et petit à petit les amener vers une approche
beaucoup plus large et de pointer les réels problèmes.
On part sur des problèmes très techniques,
et petit à petit, on amène les gens à lever la tête,
à dire, vous êtes sûrs que vraiment,
le problème, il vient de la qualité de votre code
et est-ce que ce n'est pas plutôt, parce que,
comme dit Jean-Tan, vous n'avez pas compris
ce qu'on vous demandait de coder.
Et du coup, si on revient sur la question de la battle,
préfère-tu développer ta polyvalence ou ton expertise ?
Il nous avait un point que j'y mets bien,
qui était en début de carrière,
souvent on va avoir envie de s'intéresser à l'expertise,
et puis après, à un moment donné, on se rend compte qu'il n'y a pas que ça.
Est-ce que tu peux réélaborer là-dessus, Jean-Tan, ou Mika ?
En fait, quand on commence à coder,
tu le disais tout à l'heure, c'était marrant,
parce que je me retrouvais pire dans ça,
quand on commence sa carrière de développeur,
en général, on a juste envie de manger du code,
et ça fait tellement de bien de décrire
un million de lignes de code dans la journée,
surtout, on a l'impression d'être productifs,
et de mettre des trucs en prod,
et de pouvoir montrer à ses potes en disant,
c'est trop cool, regarde ce que j'ai codé,
tout le monde va l'utiliser, ça va être génial.
Cette forêt-là, en fait, elle va pouvoir persister un moment,
mais en général, quand on commence à prendre des responsabilités
autres au sein de l'équipe,
nous, on met ça sous le rôle de TechLead,
on se rend compte qu'en fait,
au-delà d'avoir des collègues
qui maîtrise bien leur environnement technique,
on note qu'il y a d'autres problèmes,
et c'est là où je trouve qu'en général,
on va avoir les développeurs qui, entre guillemets,
sont assez matures pour passer à la phase d'après,
phase d'après qui est comment je fais maintenant que je sais coder,
maintenant que je maîtrise mon environnement technique,
comment je fais pour coder la bonne chose et de la bonne façon.
Et ça, c'est un peu plus challenging,
parce que ça fait entrer des pratiques
qui ne sont pas forcément du développement,
on a beaucoup de pratiques humaines,
non, on parle beaucoup de CNV,
communication non violente,
comment je fais pour dire à mon collègue,
par exemple, qui a fait une fonctionnalité,
que cette fonctionnalité n'est pas de la meilleure qualité
qu'on puisse offrir,
sans le vexer, sans le blesser,
et sans en faire un ennemi au sein de l'équipe.
On arrive très rapidement et très maladroitement
à briser les équipes,
juste en ayant pas les bonnes approches sur ces pratiques.
Et ça, l'expertise technique ne nous aidera pas.
Ce que je vois, c'est des techniques qui rebondissent
sur des équipes qui sont soudées.
J'ai des exemples en tête de techniques qui arrivent,
qui ne sont pas forcément avec le statut de technique,
mais qui ont une manière de faire beaucoup plus élaborer,
et qui se font rejeter leur PR,
parce qu'on peut trop refactoriser de choses,
et ça ne passe plus auprès de l'équipe.
Et sur ça, il y a des choses qu'on peut mettre en place
pour un peu diluer la responsabilité.
La responsabilité ne tient pas qu'au TechLead ou calexpert,
mais faire en sorte que tout le monde participe
à l'élaboration de la fonctionnalité
ou de la nouveauté qu'on veut apporter.
Et on peut parler notamment du mode programming.
Je sais pas si tu connais Benoît.
Ça me parle.
Ça me parle.
Le mode programming, c'est mettre tout le monde
autour d'un écran qui diffuse le même code,
et tout le monde réfléchit au problème en même temps,
et tout le monde essaie de tacler le problème en même temps.
Ce qui fait que l'expert et le junior seront au même niveau,
et réfléchiront ensemble.
Quel est la grande vertu que tu vois de cet exercice
avec cette logique-là ?
L'intelligence collective,
c'est que le code appartient à tout le monde.
Tu renforces le sentiment d'appartenance qu'en partenance ?
On renforce le sentiment d'appartenance.
Les choix sont faits de manière collégiale,
ce qui fait que tout le monde a son mot à dire
sur la conversion de nommages
ou la structuration du projet,
sur tout l'ensemble.
Donc on évite les débats un peu stériles
qui peuvent apparaître dans certains cas,
ou quelqu'un qui est en position d'expert
doit...
On le considère comme celui qui va prêcher la bonne parole
et qu'on ne peut jamais remettre en question,
alors que d'abord, un projet, c'est une équipe,
donc il faut tout le monde à son mot à dire
sur la manière de faire.
Ecoute, Micka, je te propose que ce soit le mot de la fin.
Merci Micka, merci Jonathan.
Merci à toi.
Quant à toi, chère auditeur, je t'invite à nous rejoindre
dans l'AREN, aren.artisan-developer.fr
préfère-tu développer TAPOLIvalence ou ton expertise ?
A tout de suite.
Et en fait non, à demain.