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 Élodie Micoulet et Élodie bonjour.
Bonjour. Comme c'est la première fois que tu
passes sur le podcast, est-ce que tu peux te présenter en une minute ?
Je vais essayer. Donc je suis beaucoup de chapeau en même temps. Je suis
actuellement Scram Master et Coach Agile mais je fais aussi de la
facilitation de projet et de la gestion de livraison dans différents domaines.
J'ai commencé en BI et je me retrouve maintenant dans le jeu vidéo.
Ok et tu as t'en compte Téfrélinte ? Non, je suis employé.
J'ai été à mon compte à Inépat. Et du coup aujourd'hui on t'invite dans le
cadre de la battle avec cette question est-ce que du code de qualité coûte
plus cher ? Alors Élodie qu'est ce que tu en penses ? Est ce que du code de qualité
coûte plus cher ? C'est une très bonne question. Je sais que les
gens vont répondre forcément oui ou non et j'aurais envie de répondre oui et non.
Tu as le droit de tricher. C'est sur le podcast. Tu fais ce que tu veux. Dans la
reine, dans la reine non mais sur le podcast fais comme tu veux.
Oui en fait oui ça coûte plus cher à court terme mais non à long terme à mon avis
ça ne coûte pas plus cher. C'est pas toujours évident de le prouver dans le
sens où si je ne fais pas forcément du code de qualité dès le début mon projet
va me coûter de plus en plus cher mais si je n'ai pas fait le même projet en
parallèle avec du code de qualité j'aurais parfois du mal à le prouver au
financier de mon entreprise. Je pense que c'est même une assertion
qui est impossible à prouver. Tu imagines qu'il faudrait deux équipes au moins qui
fassent la même chose. Un qui produisent dans le rush, l'autre qui prennent le temps
de faire bien. Exactement. J'imagine même pas qui va financer un truc pareil quoi.
J'espère qu'un jour il y a quelques chercheurs qui ont envie de s'atteler à ça
parce qu'il y a des chercheurs qui travaillent un petit peu à tous les niveaux
même en agilité. Alors je me dis pourquoi pas sur la dette technique un jour.
Mais c'est un rêve. Le problème des papiers que j'ai vu, il y en a
qui le font. Le problème des papiers que j'ai vu c'est qu'ils le font sur un
échantillon qui n'est pas du tout représentatif. Ils le font sur leur classe
étudiante. Donc tu as deux énormes billes. D'abord c'est des étudiants donc ils
n'ont pas d'expérience, pas de compétences forcément développées sur ces
sujets-là. Et ensuite c'est 20 personnes. Et puis je ne suis pas bien sûr qu'ils
le refassent. Il n'y a pas cette notion d'expérience répétée,
d'échantillonnage, de test à b, tout ça. C'est pour ça que c'est un peu difficile à prouver.
Moi je suis persuadée que ça coûte moins cher sur le long terme.
Alors c'est quoi pour toi le long terme ? Quand on dit long terme, court terme, ça veut dire quoi pour toi ?
Bonne question. J'aurais du mal à te donner un nombre de mois mais c'est plus sur la durée de vie d'un produit.
Donc quand on va faire du développement logiciel, c'est un produit qui est à la fois
technologique et à la fois business. Il est là pour répondre à un besoin quelconque que
des utilisateurs ont demandé. Mais il est aussi technologique et pour que ce produit continue
à vivre dans le temps, je pense qu'il faut faire du quoi de qualité le plus tôt possible. Sinon,
en risque d'avoir un produit qui va tomber obsolète beaucoup trop rapidement, voire peut-être
nous empêcher de continuer notre travail et notre business.
Moi ce que je trouve intéressant, c'est que là tu amènes le point de vue plutôt
Scram Master. Si je comprends bien, tu n'es pas d'être qui ne met pas les mains de danse, c'est ça ?
C'est vraiment cette notion de à quel moment est-ce que ça coûte plus cher, moins cher.
Avec cette idée en filigrane que j'ai, moi personnellement, c'est que clairement le code
de qualité coûte moins cher. Et quand on parle des séances, moi j'ai fait l'expérience une fois
d'essayer de dire « vas-y, écrire un morceau de code ». J'avais l'objectif d'écrire le morceau
de code le plus crade possible. Et donc je m'étais dit « vas-y, oublie toutes les bonnes pratiques que
tu mettrais en œuvre, considère que c'est un petit morceau que tu vas ajouter et vois jusqu'où tu peux
aller ». Et je n'ai pas réussi à dépasser une heure de dev, sans me sentir mal, de ne pas avoir
tous les filets de sécurité, tous les trucs de bonne pratique que j'avais. D'un coup,
je me suis mis à imaginer une évolution, ça m'a donné une sur-froid et je me suis dit « wow ».
En fait, quand on sait faire, moi l'expérience que j'ai vécue, c'est qu'au-delà d'une heure,
c'est rentable. Donc tu vois, cette notion de court terme, long terme, elle m'interroge vachement
et je la mets en corrélation avec « est-ce qu'on sait faire ou est-ce qu'on sait pas faire ». Comment
ça fait écho ou pas chez toi ? Ben, je trouve ça intéressant en fait comme exercice. Après,
je me dis « se déconstruire pour arriver à faire quelque chose », c'est certainement plus difficile.
Donc c'est peut-être pour ça aussi que ça prend plus de temps. Alors que si je sais pas faire à la
base, je vais forcément peut-être faire du code de « moi bonne qualité » parce que je savais pas
faire. Puis ça, c'est aussi quelque chose qui va forcément être à payer plus tard. Puis malheureusement,
on n'y peut rien. Des fois, on sait pas faire. Donc c'est pas trop comment répondre à ça, mais
je trouve qu'il faut essayer de faire du mieux qu'on peut dans le temps qu'on a.
Puis si malheureusement on est forcé à faire du code de « mauvaise qualité », il faut
repayer le plus rapidement possible cette qualité-là, je pense.
Et toi, en tant que scrum master, comment tu amènes tes équipes ? Comment tu les mets sur le
chemin de l'amélioration technique ? Est-ce que c'est quelque chose dont tu te préoccupes ?
Est-ce que tu considères que c'est pas du tout ton business et le leur à eux de se démerder ?
Est-ce que tu fais en sorte de veiller à ce qu'il fasse un peu de veille justement ou de s'entraîner ?
Comment tu perçois ton rôle de scrum master vis-à-vis de cette question de la compétence technique ?
La partie veille puis apprentissage technologique. Je vais vraiment laisser ça à mes équipes.
Je pense que ça leur appartient de savoir jusqu'où est-ce qu'ils veulent avancer. Moi,
je vais surtout leur amener des outils pour ne pas se retrouver mal pris quand ils ont
justement cette notion-là de « de code de moins bonne qualité » qui s'est accumulée dans un
produit. Donc, ça va être plus de les aider à comprendre l'importance de faire de la qualité,
d'être au goût du jour pour ne pas avoir trop de lacune quand on est en train d'écrire son conne,
et surtout de mettre de la visibilité là-dessus, non pas pour justement se faire taper sur les doigts
parce que c'est de la mauvaise qualité, mais plutôt pour montrer qu'on a fait tout ce qu'on
pouvait. Et voici les choses qu'on n'a pas réussi à faire ou qu'on n'a pas encore atteint.
Cette sensibilisation, tu la mènes comment ? Concrètement, ça ressemble à quoi ?
C'est des suggestions ? Tu leur envoies des liens vers des confs ? Comment tu t'y prends concrètement ?
En fait, on a commencé avec certaines de mes équipes à faire des ateliers pour parler
de quel est l'état de notre produit. Je les laisse en discuter parce que c'est pas moi qui
ai la connaissance technologique, mais on passe à travers les composants du produit, on regarde
où est-ce qu'on pense qu'il y a des problèmes, où est-ce qu'on aimerait améliorer les choses,
puis moi je vais aller les challenger par contre sur la criticité des choses qui sont accorrigées.
Parce que le code de qualité peut coûter cher, je pense, si on veut être plus catholique que le
PAP. C'est trouver un équilibre aussi de jusqu'où on veut aller dans le temps qu'on a pour que ce soit
vraiment de la qualité qui sert le produit. J'essaye d'imaginer la scène. Vous êtes
toute l'équipe autour d'une table, vous passez au travers du produit, du code, d'imagines,
ou je ne sais pas comment vous représentez ça, et vous dites « Tiens, dans telle zone, ça craint un
peu, là, non, ce n'est pas grave, ce n'est pas grave, il n'y a pas trop de dette ». Et puis,
vous discutez des enjeux de chaque point, ça ressemble à un truc comme ça ?
C'est un petit peu ça. En fait, souvent les devs en amont vont avoir logué des tickets de
debt dans le back-lug, donc ils ont leur propre back-lug de debt. Et le problème qu'ils avaient,
c'était d'arriver à les prioriser et à les faire valoir devant leur product owner. Donc,
c'est là où j'interviens beaucoup pour les aider à expliquer quel est le besoin business,
qu'est-ce que ça va aider ? Parce que des fois, on veut changer un bout de code,
mais on n'est pas capables d'expliquer qu'en fait, ça va aider à avoir une meilleure maintenance du
produit, ça va enlever des problèmes de sécurité, ça va améliorer la productivité à chaque fois
qu'on touchera ce code-là. Donc, c'était vraiment ce chose-là qu'on peut regarder ensemble.
Alors ça, c'est un point super important. Est-ce que tu penses que c'est au product
owner de décider de ces choses-là ? Non, je pense que c'est au product owner d'être conscient de l'état
de son produit qui importe des choses technologiques ou des choses qui sont pour le client final.
Donc, il faut qu'il sache à quel niveau est son produit. Après ça, c'est à mon avis,
à l'équipe de lui rapporter ça parce qu'il n'a pas forcément la connaissance. Donc, c'est un travail
conjoint et de la beaucoup de confiance. Lui apporter la connaissance, oui, mais après, si on lui demande
son avis de le faire ou de ne pas le faire, est-ce qu'il n'y a pas le risque que le product owner
privilégie toujours des choses qui vont livrer une valeur métier ? Et pas forcément ces choses qui
sont importantes, certes, mais tu sais comment que dans le flux du quotidien, on va être tenté peut-être
de appeler par le côté business ? Oui, ça a été un travail. Justement, pour moi, c'est là où mon rôle
de Scram Master a de l'importance. Ça a été de conscientiser le product owner à l'importance et
en arriver à avoir une entente à chaque sprint pour prendre des points de dette technique, pour être
sûr qu'on garde le produit en santé. Donc, c'est là où je pense que moi, je peux apporter de la valeur
et aider les gens dans l'équipe. Ok, donc là, dans cet équipe, le deal, c'est qu'à chaque
iteration, on se met d'accord sur une petite quantité de velocité qui consacrait à la résorption de
dette technique. Et du coup, tout le monde est, c'est clairement explicite et tout le monde est au courant
de la quantité d'énergie qu'on alloue à ça. Oui, en fait, c'est pas forcément la même chose sur
chaque sprint. On va vraiment faire, on va travailler pour avoir beaucoup de métriques sur l'état de
notre produit, la dette urgente et importante, celle qui met à risque notre produit. Puis ensuite,
on s'est entendu sur une moyenne à travers le temps, mettons-nous, c'était un tiers de notre
velocité. Mais ça peut arriver que certains sprints ont des zéro points qui soient mis dans
de la dette parce qu'il fallait qu'on livre une fonctionnalité. Donc ça va être une entente qu'on
a et qu'on réajuste en fonction des besoins et du temps. Mais en moyenne, on a une entente.
C'est excellent. Malheureusement, on arrive à la fin de la boîte de temps, mais j'adorerais creuser
sur comment est-ce que tu définis ces différents niveaux et comment vous mettez d'accord sur ça.
Mais écoute, il faut respecter le jeu de la boîte de temps. Un grand merci, Elodie,
pour ta participation. Si les auditeurs veulent en savoir plus sur ce que tu fais,
ils peuvent venir où ? Ils peuvent aller taper à privoiser la dette technique sur YouTube et
ils pourront voir ma conférence ou sinon sur LinkedIn. Tout simplement, taper mon nom. Elodie
Miculé. Merci Elodie. Merci. Quant à toi chers auditeurs, je t'invite. Evidemment,
viens rejoindre-nous dans l'ARENne.AREN.ArtisanDeveloppeur.fr. Est-ce que du code de qualité coûte
plus cher ? C'est la question. Viens rentrer dans l'ARENne avec nous pour voter sur cette question,
donner ton argument et lire le champion de ton camp choisir parmi les meilleurs arguments pour
dire qui te semble plus pertinent pour représenter ton camp. Je t'ai remercié, je te dis à demain.