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 Aurélien Astou pour Aurélien bonjour.
Bonjour Renoir.
Est-ce que tu peux te présenter en quelques mots pour ceux qui ne te connaîtraient pas ?
Alors, je suis le CTO de la Tribune Donante de Zotri.io,
une boîte de services orientée accompagnement produit et expertise technique.
Donc on est à Nantes, on est à Paris et du coup j'ai pris ces fonctions en janvier.
Donc ça c'est récent, 6 mois à peu près, presque 6 mois de recul.
Et le thème de l'épisode qu'on va aborder c'est comment partager le craft ?
Comment partager ce mouvement, ces valeurs, ces principes, ces pratiques ?
Sachant qu'aujourd'hui tu es dans une équipe qui a...
Donc tu es dans une mode de service, et combien tu m'avais dit de développeur ?
De développeur, on en a une trentaine à Nantes, et presque une dizaine à Paris.
Et toi ta zone d'influence c'est les deux sites ou c'est que Nantes ?
Non c'est que Nantes sur mon poste, après on n'est pas dans des silos, donc il y a de l'influence aussi à Paris etc.
Mais mon scope est Nantes.
Ok, du coup, tu me disais pendant la préparation de l'épisode que tu as adoré,
tu te retrouvais pas mal dans les valeurs du craft, dans ces pratiques, dans ce que ça véhicule.
J'imagine que c'est quelque chose que tu as voulu diffuser en arrivant dans cette nouvelle boîte et quelques mois.
C'est quoi les challenges que tu as eues à affronter pour ça ?
Alors les principaux challenges, je pense la peur de l'inconnu.
Quand on a une boignée d'âge qui est assez jeune, 28 ans je crois de mémoire,
mais qui est un petit peu fossée chez les devs on doit être plus bas.
Et donc quand tu as été formé, que ce soit en école d'ingénieurs, à la FA,
en reconversion via des bootcamps,
où on n'a jamais évoqué tout ce qui est extrême programming, test driven development,
hexagonal architecture etc.
Et bien l'inconnu fait tout de suite peur,
et les principaux fringues je dirais c'est ça.
Et puis après aussi, l'histoire de la boîte fait qu'on est dans une démarche très MVP,
très ligne,
et donc on veut produire le plus de valeur possible, le plus vite possible.
Donc il y a un choix stratégique qui a été fait il y a quelques années
d'être très très bon sur tout ce qui est framework.
Et en faisant le...
le compromis de moins pousser tout ce que j'appellerais deep skill,
d'architecture logicielle, de conception par les tests, etc.
Ouais et comme s'il y avait un peu cette idée que
le MVP il y a vraiment juste le critère de temps qui est important,
il faut aller vite vite vite,
il en s'occupe pas forcément de ce qui va se passer potentiellement après.
C'est ça ?
C'est un peu ça, après j'ai la chance de travailler avec des développeurs
qui sont plutôt talentueux, donc c'est une chance et un inconvénient aussi
parce qu'ils ressentent pas le besoin forcément,
enfin pas tous,
le besoin d'être baqué par leur test,
test unitaire notamment,
et d'avoir un feedback très très court dès qu'ils font un changement.
Donc c'est bien parce que par rapport sûrement à d'autres,
il y a moins de bugs qui sont produits,
parce que comme je disais ils sont assez talentueux,
mais quand il y en a,
il n'y a pas tous ces avantages qu'on connaît
à avoir une feedback loop très très courte.
Et donc tu arrives dans cette nouvelle structure,
comment est-ce que tu fais le constat de là où ça en est,
de l'état de la culture,
et ensuite qu'est-ce que tu dis à ce moment-là,
comment c'est quoi tes premières étapes,
les premières choses que tu mets en œuvre pour faire bouger les choses ?
Alors d'abord je suis arrivé en tant que dev,
donc j'avais été un peu prévenu pendant le process de recrutement,
c'était transparent, c'était clair que la stratégie de test
n'était pas forcément hyper optimisée.
J'ai quand même décidé d'y aller parce que j'aime bien les challenges
et d'essayer d'apporter ça.
Donc pendant 6 mois en gros j'ai fait le constat en tant que dev, lit dev,
et puis j'ai eu l'opportunité de devenir CTO en décembre-janvier, comme je disais.
Et donc maintenant ce que je fais c'est que en gros sur partie de la base
déjà améliorer la définition du besoin avec le client,
puisqu'on n'a pas forcément l'honorship sur le produit,
on travaille avec le client dessus.
Et donc déjà améliorer cette relation parce que je pense que
les problèmes, les principaux problèmes, ils viennent du plus tôt dans l'échange.
Donc tout ce qui est sprint planning etc.
Essayez de l'améliorer en apportant l'exemple mapping,
déchigner un ubiquitous language,
challenge les US,
voir si on a bien des critères d'acceptation clairement compris par tout le monde.
Est-ce que tu peux définir chacun de la termes que tu viens d'utiliser là ?
Alors tous, exemple mapping, ubiquitous language,
juste pour les auditeurs qui ne seraient pas à jour.
Ubiquitous language, ça vient de domaines driven design
et de behavior driven development.
C'est en gros définir un langage commun,
un langage ubiquitaire entre les gens du métier,
plutôt représentés par nos clients,
et nos développeurs, nos UIUX et nos product managers
pour que tout le monde se comprenne et qu'on soit sûr de parler la même langue.
Après j'ai parlé d'exemple mapping.
L'exemple mapping c'est un petit atelier, je dirais,
enfin j'aime bien le définir comme ça,
c'est un petit atelier,
donc pour chaque user story,
aller creuser les critères de validation
que notre user story est bien fait,
et fait correctement, et que le besoin est bien couvert par des exemples.
C'est ce qui est à la base de tout ce qui est bien vu en driving development,
mais si je veux retirer 100 dollars au guichet automatique
lorsque j'en sers ma carte et que je demande à retirer 100 dollars,
je obtient bien deux billets de 50.
C'est un premier sujet qui a travaillé en tant que CTO,
c'est d'occuper de la relation au client et de la formalisation de son besoin.
Exactement, pour qu'on puisse après partir sur des bases plus techniques
avec les devs, d'avoir ce support de critères d'acceptation bien définie
pour pouvoir ensuite adapter une stratégie technique
et petit à petit aller vers des pratiques avancées de conception guidées par les tests,
que ce soit en test driven development,
ou en test commit river.
Tu en fais du TCR ?
Moi, j'en fais sur des projets personnels,
enfin sur des produits personnels.
J'aime bien, après, je n'ai pas encore découvert autant d'efficacité que TDD,
du coup je ne dirais pas que je le préconiserais par rapport à TDD,
mais j'aime bien de temps en temps, ça change un petit peu.
L'image que j'en ai, c'est quelque chose d'assez expérimental,
je regardais des screen cards, des trucs comme ça sur ce truc,
mais je n'entends personne me dire qu'ils l'utilisent dans leur workflow de prod réel.
D'ailleurs, cher auditeur, si toi, c'est ton cas, dis-le-moi,
sur benoîtrobasartisandevelopers.fr,
mais j'entends personne, je vois ça comme quelque chose d'expérimental,
d'intéressant, de formateur, très formateur,
parce que ça t'oblige à prendre conscience qu'il faut vraiment découper à fond,
et du coup, comme tu te prends le river, tu es au moindre test rouge,
tu vas tout doucement, mais je ne l'ai pas entendu de gens l'utiliser en prod.
Je te rejoins dessus, je n'ai pas entendu non plus qui conclut l'utiliser en prod.
J'y verrai pas d'un convenant particulier, il faudrait que l'équipe soit,
c'est comme tout, maîtrise bien la technique,
et je ne verrai pas forcément d'un convenant.
Moi, ce qui me gêne le plus, c'est de ne pas avoir mon autosave,
puisque le principe, c'est quand même de servir de son idéal pour lancer les tests à chaque sauvegarde,
et donc, de ne pas avoir mon watcher sur les tests qui tournent en permanence
pour me dire rouge, vert, rouge, vert, c'est ce qui me pose le plus de problèmes aujourd'hui dans la productivité.
Ok, donc si on revient, les petites parenthèses fermées sur le TCR-C,
si on revient, donc tu arrives, CTO, tu t'intéresses à la relation client,
à comment formaliser son besoin, à partir de là, tu as une base d'éléments plus solides,
plus concrètes, qui permettent vraiment d'appuyer le reste de la démarche,
et là, comment c'est reçu par les débes ?
Parce que jusque là, tu touches finalement pas trop au développeur dans son quotidien,
tu touches aux interactions avec le client, en général, ça, c'est pas facile à faire,
mais disons que c'est quelque chose que tu peux organiser,
sans que les gens se remettent trop en question, alors il y a que celui qui a le pu se souffrir de la remise en question,
et là, éventuellement, c'est le client, parce que d'un coup, tu deviens vachement plus exigeant vers lui.
Par contre, au moment où tu vas rentrer dans les pratiques de dev,
là, tu vas commencer à rempiéter un petit peu sur les petites habitudes des uns et des autres, et là, comment ça se passe ?
Alors, le petit bémol que je disais, c'est comme nos dev, ils sont en frontal avec le client,
du coup, ils ont quand même à gérer ce côté,
ce côté de, justement, d'aller challenger les clients et d'aller apporter,
d'évangéliser un petit peu ce genre de pratique,
et pour les devs après, donc la stratégie jusque-là, on était sur une stratégie assez end-to-end,
donc on écrit nos tests après le code pour faire de la non-régression de manière end-to-end,
et donc on avait des CIA qui tournaient longtemps avec une longue boucle de feedback.
Donc là, pour les devs, ce que j'ai mis en place petit à petit, c'est encore en cours,
le chantier encore en cours, c'est déjà d'architecturer son code pour qu'il soit testable.
Encore plus prioritaires que d'avoir les tests et les pratiques de tests,
ou de conception par les tests, d'avoir un code testable.
Et donc beaucoup d'exagones à l'architecture,
parce qu'on a des applis, sommes tout simples au niveau complexité-métier,
mais même là-dessus, inverser ses dépendances,
commencer à respecter les principes solides et intégrer l'exagone à l'architecture apporte pas mal.
Je repense à une anecdote, l'autre fois, on a dû changer un adapter Stripe, man-gopé.
Si c'est couplé entièrement le code, ça pose problème, si c'est pas le cas, ça pose moins de problème.
Et puis du coup, l'étape actuelle et la prochaine étape, c'est des formations,
via des codings dojo, via des MOOCs en asynchronous pour que chacun puisse y aller à son rythme.
Un peu ce que tu fais avec...
Oui, justement, c'était la question qui suivait, comment est-ce que tu fais tout ça ?
Comment est-ce que tu évangélises ? Comment tu formes les gens ?
Je faisais des sessions de formation, c'était un peu top-down.
Du coup, j'ai un peu changé le format.
On peut se dire concrètement, tu dis à tout le monde, voilà, de telle heure à telle heure,
sur des créneaux de quoi ? D'une heure, deux heures ?
Trois heures, trois, quatre heures.
Trois heures ? En gros, demi-journée, demi-journée.
C'est ça, demi-journée de...
Et comment tu choisissais ce qui venait, ce qui était dispo, ce qui voulait,
ce qui... Tu as pris la liste par ordre alphabétique ?
Non, moi, je fais ce qui veulent venir, viennent.
En gros, c'est vraiment dans une démarche d'amélioration continue.
Je suis pas très à l'aise à imposer les choses aux gens.
Parce que quand tu...
Quand tu imposes quelque chose à quelqu'un, déjà, il y a une partie de lui qui n'est pas là, je trouve.
Alors, s'il vient volontairement, parce qu'il est intéressé, c'est déjà 25% du boulot de fée.
Donc, je faisais des sessions de trois heures comme ça.
Et c'était quand même compliqué avec le boulot du quotidien et tout.
Donc, là, je vais tenter une nouvelle approche plus à 5 crores,
avec des vidéos un peu comme...
comme fait sur YouTube ou autre plateforme.
Des petites vidéos, 15, 30 minutes sur un sujet.
Mais que tu fais toi ?
Ouais, que je fais moi.
D'accord.
Sur notre chaîne interne.
Et du coup, tu vas pousser ce contenu, libre à chacun de venir le consulter et de se former là-dessus ?
Exactement.
Et après, faire une petite permanence pour ceux qui ont des questions sur tel épisode, sur telle leçon,
et bien faire une permanence pour pouvoir échanger dessus, le reprendre en perprog, etc.
À côté, on fait des codings d'ojo aussi toutes les semaines.
On avait pas à y ir avec les volontaires pour essayer de pratiquer un peu sur des catas.
Comme tu le promets souvent, pour justement avoir la mémoire du geste, prendre l'habitude.
Et sur les 30, il y en a combien qui viennent à peu près ?
Ou sur les 30, 40 qui sont sur les dés de gens ?
Sur les codings d'ojo, là, on commence à train une petite moyenne de 5, 8 chaque semaine.
Donc, c'est pas mal.
Ça fait presque un petit 30%, un petit 20%.
Et puis, ça tourne un petit peu.
Sur mes MOOCs, là, j'ai pas encore de feedback.
J'ai pas encore mis en place de tracking.
Je pense pas que je le ferai.
Et sur mes blogs de formation, je faisais des sessions avec 10 personnes maximum
pour qu'il y ait encore la possibilité d'avoir des interactions.
Ok, c'est hyper intéressant.
Le mot de la fin, c'est quoi les prochaines étapes que tu vois arriver ?
Les challenges qui arrivent maintenant ?
Là, on est en train de...
C'est un peu plus organisationnel, mais je pense que ça fait partie.
On est en train de stabiliser un peu les équipes.
On avait des équipes projet de 2-3 devs qui tournaient en fonction des envies et des besoins.
Là, on est en train de stabiliser un peu les équipes pour qu'ils puissent capitaliser en équipe
et changer leur pratique parce que je pense que c'est hyper important.
Donc, voilà, ça, c'est le gros challenge.
Et je pense que ça va beaucoup aider aussi à l'amélioration continue de chacun,
à la progression de chacun.
Écoute, super.
Merci pour ce partage d'expérience.
Et les auditeurs veulent en savoir plus.
Ils peuvent te suivre.
Je suis un peu actif sur LinkedIn, principalement, pour l'instant.
Écoute ton métral, le lien.
Merci, Aurélien, d'être venu aujourd'hui.
Merci à toi, Benoît, avec plaisir.
A plaisir, partagez.
Quant à toi, chers auditeurs, j'espère que tu as apprécié cet épisode comme toujours.
Si tu as envie, toi aussi, de te former.
Si tu n'as pas la chance d'avoir un CTO qui te guide comme ça,
qui te donne des formations internes et que tu as envie de progresser par toi-même,
je t'invite à venir dans la maison des compagnons,
sur maison.artisandevelopers.fr,
et tu y trouveras le cursus Artisan Developer qui t'apprendra à écrire du code durable.
Je te remercie.
Je te dis à bientôt.