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 Romain Fallé, Romain bonjour.
Bonjour Benard.
Est-ce que tu peux te présenter en quelques mots pour ceux qui ne te connaîtraient pas ?
Ouais, alors moi je programme depuis que j'ai 14 ans.
J'ai commencé mon expérience de dev en tant que freelance pendant 6 ans.
Et là depuis ça va faire 10 mois maintenant, je suis le développeur dans une startup qui fait des chatbots.
Donc ça s'appelle The Chatbot Factory.
Et au-delà des chatbots, en fait, le rôle de cette startup, c'est un peu d'automatiser la relation client.
Donc moi mon rôle ici, c'est vraiment d'améliorer la velocité de l'équipe.
Donc comment je mets ça en place, notamment via mise en place de bonnes pratiques de l'artisanalogie-ciel.
Et la première grosse brique que j'ai pu mettre en place, qu'on a commencé, c'est les principes du domaine Driven Design.
Donc essayer de mettre en place de la collaboration métier technique un peu poussée.
Je te propose qu'on continue l'épisode sur ça, sur la lancer.
C'est top. Quand tu parles de pratique du DDD, quelle pratique en particulier est-ce que tu as commencé à mettre en concretement en œuvre au sein de ton équipe ?
Alors la première grande chose, c'est de mettre en place un peu un langage commun, en fait.
De savoir de quoi on parle, de quoi est composé le produit,
quels sont les termes en fait, s'accorder sur des termes, pour déjà être sûrs que entre l'équipe produit, les experts métiers et l'équipe technique, on parle de la même chose.
C'est ce qu'on appelle le big-outus language, c'est ça ?
C'est ça. J'ai pas trop la traduction en français de ce que ça pourrait être, à part langage commun. Je sais pas si c'est la meilleure traduction.
Mais c'est ça.
Et du coup, la deuxième étape, ça va être d'identifier en fait les domaines qui vont être centraux, ce qu'on appelle corps en anglais, ceux qui en gros constituent la différenciation du produit,
sur quoi on doit mettre le focus et puis quelles sont les domaines sur lesquelles c'est moins important, on pourrait potentiellement sous-traiter, ou voir utiliser une solution qui existe déjà tout à peu.
Et donc quand tu parles du big-outus language et quand tu parles là de faire ce travail, est-ce que là on parle des domaines et des banderises et de définir les frontières et tout ça ?
Ouais, on parle des domaines.
Du coup, concrètement, comment tu le mets en neuf ? Tu arrives dans la boîte, tu prends contact avec l'équipe et à un moment donné tu te dis, allez, j'ai envie de lancer ça.
Est-ce que c'est toi qui as envie, est-ce que ça vient de l'équipe, c'est toi qui est force de proposition ?
Et concrètement, tu fais quoi ? Tu organizes une rayue, tu envoies un slag, comment ça marche ?
Déjà, l'équipe, d'un point de vue technique, il y avait déjà un début de réflexion sur le sujet, mais la réflexion était un peu limitée l'équipe technique.
Et du coup, il n'y avait pas trop de collaboration poussée entre le métier et la technique.
Donc première étape, en fait.
Ce qui fait perdre un peu de sa saveur ?
Exactement.
Donc la première étape, en fait, ça a été d'en parler à tout le monde, en fait.
La fois l'équipe technique et l'équipe métier.
Et puis, oui, c'était mis en place de réunion pour en parler, déjà pour présenter les concepts.
Qu'est-ce que ça pouvait nous apporter ?
Et puis, en fait, on a intérêt petit à petit parce que c'est moi-même pas un sujet que je maîtrise à fond et que je maîtrise à fond encore aujourd'hui.
J'apprends en permanence.
Donc il y avait aussi toute une étape où on apprend tous ensemble et puis on essaie de mettre en place les choses petit à petit.
Donc là, concrètement, ça passe par des réunions de travail synchrones, où tu réunis les gens une heure, deux heures, trois heures.
C'est quoi la durée que tu as trouvé qui marchait bien pour faire ce genre d'atelier ?
Alors là, on a commencé avec déjà l'équipe métier, l'équipe produit d'avoir une heure par semaine, où on se dit, voilà, on va essayer de modéliser,
de définir nos cas d'usage, de définir nos domaines, de définir nos nos manclatures, en fait, tout simplement.
Donc on a priorisé, en fait, sur les nouveaux sujets, les nouveaux sujets qui arrivaient.
Et à partir de là, en fait, on essaye ensuite avec l'équipe technique de faire ce qu'on appelle un modèle, en fait,
où on va un peu sous forme du ML, mais de graphique, en tout cas, d'avoir avec un outil visuel,
de modéliser un peu, de les représenter visuellement pour avoir un support,
un support de collaboration qui soit accessible à tout le monde, que ce ne soit pas que du code,
que l'équipe produit puisse simplement avoir un outil, et que ça devienne ça, en fait, notre source de vérité qui drive ensuite la conception technique.
Ok, donc les deux actions clés que tu mets en place, c'est ouvrir à tout le monde et pas juste rester au sein de l'équipe technique
qui est embarquée toute la partie produit, toute la partie métier.
Et il y a l'idée de mettre en place un rendez-vous régulier d'échange qui permet justement de démarrer un travail en amélioration continue, en fait.
C'est ça. Et tu as d'un point de vue sur l'équipe technique, on a tout simplement intégré la modélisation dans nos séances de découpage,
découpage de tâches techniques qu'on pouvait faire auparavant, on dit bah voilà,
en fait avant de faire découpage technique, on va faire découpage métier, ce qu'on appelle la modélisation métier,
qui va en plus ensuite nous permettre de mieux découper techniquement parce qu'on aura une meilleure connaissance du sujet et du métier.
Ça fait combien de temps que vous avez mis ça en place ?
Et de tout ça, alors c'est quoi les insights, les bénéfices que tu commences à sentir au bout de deux mois ?
Est-ce que tu commences à avoir une évolution quelque part ?
C'est quoi un peu les discussions croustillantes que ça a pu générer ?
Alors là, le gros bénéfice, je vais un peu citer les autres développeurs de l'équipe,
parce que c'est eux qui m'ont apporté ça, c'est vraiment d'avoir une vision beaucoup plus claire sur où est-ce qu'il fallait aller en fait.
En fait, souvent c'était un peu compliqué sur des fonctionnalités un peu grosses, un peu complexes,
d'anticiper en amont, pas mal de problèmes notamment pour estimer,
ou pour anticiper des problèmes techniques, du à la complexité, ce genre de choses.
Et là, ça nous permet vraiment d'avoir une vision beaucoup plus claire en amont de comment doit fonctionner la fonctionnalité.
Et on a beaucoup moins aussi d'ambiquité en fait, des fois en fait, il y a des choses où on s'est juste mal compris avec l'équipe produit,
ils avaient spécifié quelque chose et puis on l'avait juste mal interprété.
Et on a beaucoup moins ce travers-là.
Parce que avant, avant que vous mettez ça en place, ça marchait comment l'équipe produit spécifiée sous forme de texte,
sous forme d'un ticket, un machin, et puis vous passez la patate, où il y avait quand même un échange.
Qu'est-ce qui a eu de plus dans le fait de mettre en oeuvre ces pratiques ?
Alors, de base, on a vraiment une super équipe produit.
Notre chaque produit a vraiment un super travail en amont pour prioriser, pour spécifier.
Donc on avait déjà tout une trame avec la jeunesse, la fonctionnalité, éventuellement des tests d'acceptation.
Et ces découpages-là, ces premières spécifications-là, nous sont présentés déjà toutes les semaines,
par l'équipe produit, et ensuite on les retravaille quand on les embarque sur un sprint directement avec l'équipe technique.
Ok, c'est top ça.
Et du coup, tu as déjà réussi à...
Tu m'as dit que tu étais là, tu avais été embauché notamment en trottin pour augmenter la velocité de l'équipe.
Est-ce que pour toi déjà, au bout de deux mois, tu sens un impact sur la velocité de l'équipe ?
Et puis comment tu mesures d'ailleurs cette velocité ?
C'est beaucoup de ressenti, mais en fait, ça va être vraiment...
On le voit assez clairement sur le nombre de sujets qu'on traite, qui passent dans notre colonne terminée tout simplement.
Et puis on va le voir aussi sur le temps nécessaire, à partir du moment où un sujet nous est présenté et nous est spécifié,
et puis le moment où il arrive en production tout simplement.
On donne, ok.
Et donc là, tu mesures ça, c'est des choses que tu mesures, et tu mesures déjà une amélioration de ces choses-là ou pas encore ?
On le ressent dans le ressenti que ça nous apporte des choses.
On n'a pas encore, je pense, des indicateurs fiables pour mesurer, parce qu'on a tout un tas de chantiers en même temps.
L'équipe a beaucoup bougé, donc on est un peu aussi en restructuration d'équipe.
Donc on n'est pas tués sur une base iso pour pouvoir comparer, sur une base déjà fixe et stable pour pouvoir comparer.
Mais pour la salle, surtout du ressenti.
En fait, je te pose toutes ces questions, et je creuse là-dessus, parce qu'en coaching, je me rends compte que c'est assez difficile d'objectiver un petit peu la amélioration.
J'ai parfois des clients en entreprise qui ont besoin d'être rassurés, en fait, ils ont besoin de voir un peu où on va,
de voir quelle va être l'amélioration avec les parcours que je propose.
Et des promesses assez fortes, de réduire le nombre de bugs pour arriver à un moment donné à les supprimer carrément, reprendre le legacy, avoir du code souple.
Mais je sais que c'est quelque chose qui va prendre longtemps et qui va prendre du temps bien au-delà d'ailleurs de mon implication dans l'entreprise.
Et j'ai toujours du mal à donner un timing, un retour sur investissement où on va commencer à sentir des choses.
Et je trouve ça rassurant de voir que les pratiques que vous avez mises en place finalement en quelques semaines commencent déjà à porter leurs fruits.
Donc ça c'est top. Par contre, ce n'est pas évident d'objectiver l'amélioration, c'est ça que tu me dis.
Ce que tu me dis justement, me fait penser à un truc qu'il y a peut-être un critère où j'ai remarqué qu'il y avait vraiment une amélioration tout de suite,
sur la quantité de retour et au niveau des codes review, il y a beaucoup moins de retours qui modifient structurellement le travail qui avait été fait.
On avait moins de gros retours où il fallait par exemple revoir l'organisation des fichiers, la structure de certaines fonctions.
C'était beaucoup plus sur la théorie de l'espace, là il y a peut-être un truc qui est un peu moins bien factorisé, mais peut-être là ce nommage de revoir.
Mais au niveau des retours qui étaient beaucoup plus concis, beaucoup plus fluide, il passe beaucoup moins de temps sur les revues de codes depuis qu'on a mis ça en place.
C'est top. Je vois les équipes, elles ont souvent un point de difficulté de trouver le bon compromis entre passer du temps en amont,
comprendre les choses et investir, échanger avec le métier et faire des réunions où on est nombreux.
Ça peut être tant de temps parfois de croire que c'est du temps perdu parce qu'on est nombreux.
Mais quand tu réfléchis bien, si il n'y a pas un travail de préparation, après tu perds beaucoup plus d'énergie et de temps à courir après l'info, à recouper l'info.
Et finalement c'était une fausse économie.
Il y a des sujets par exemple où on s'est lancé sans trop avoir de vision sur où on allait et on voit qu'on perd facilement 2-3 semaines.
Alors que là facilement une ou deux semaines, on arrive à des résultats.
C'est dingue quand tu me parles de perdre deux-trois semaines sur une feature qui va prendre une ou deux semaines de dev.
C'est pas neutre en termes d'impact sans même parler de quantité et de charge de travail.
Je veux dire juste en termes de délais et de mise à disposition.
C'est dingue de diviser par deux.
C'est une belle progression. Bravo.
Merci.
Moi après c'est pas partout pareil.
Non mais ça fait partie de la progression.
C'était bien la question et c'est cool.
Je pense que ça peut inspirer des gens.
Et d'ailleurs justement, toi comment tu t'es formé à ça.
Si un auditeur dit tiens ça m'intéresse.
Moi aussi j'ai envie d'avoir ces bénéfices-là et d'accélérer les choses, d'avoir un meilleur retour, une meilleure compréhension, plus de fluidité.
Tu lui conseillerais d'aller taper dans quelle ressource ?
Alors moi c'était beaucoup sur des bouquins.
Alors comment il s'appelait ce bouquin ?
Pattern and principle and practices of domain-driven design de Scott Millet.
Et beaucoup, la deuxième ressource en fait c'est, je me suis pas mal documenté sur la mise en place de l'architecture hexagonale.
Et en fait ça va souvent de pair avec le principe du DDD puisque l'architecture hexagonale c'est le découplage du code métier, du code technique.
Donc ça va souvent de pair et il y a beaucoup de ressources en fait qui font référence en fait au DDD quand on se renseigne sur l'architecture hexagonale.
Et ça plutôt des blogs ?
Des articles de blogs ?
Des blogs, même je crois dans le bouquin clean architecture de Robert Cé-Martin, je crois qu'il y a peut-être quelques références, quelques mentions de ça.
Je ne suis pas complètement certain mais on du cas des grandes idées, les grandes idées on les retrouve.
Ok, je te propose que ce soit le mot de la femme, merci Romain, si les auditeurs veulent en savoir plus sur ce que tu fais ils peuvent venir où ?
Et ben pour l'instant, j'ai que mon Twitter à la base Romain Fallet tout simplement.
Ça marche ? Merci, on mettra le lien dans la description.
Merci Romain.
Merci à toi.
Quand t'as toi cher auditeur, j'espère que tu apprécies cet épisode comme toujours.
Je t'invite à nous rejoindre dans la maison des compagnons, tu pourras y découvrir le cursus artisan-développeur qui te permet d'apprendre à écrire du code durable,
c'est-à-dire du code facile à maintenir, facile à faire évoluer.
Si ça t'intéresse, c'est dans maison.artisan-développeur.fr, je te mets le lien dans la description et je te dis à bientôt.
Ciao !