Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Éric Ciber, Éric bonjour.
Bonjour Benoît.
Les auditeurs ne te connaissent pas encore, est-ce que tu peux te présenter en une minute ?
Ben bonjour à tous, je m'appelle Éric, je suis développeur, développeur Java mais aussi agiliste.
Ça fait 14 ans que j'exerce ça, aujourd'hui je suis depuis deux ans freelance.
Et donc en tant que freelance, j'élargis ma palette, je suis aujourd'hui formateur mais aussi auditeur par moment,
mais surtout avant tout développeur, à travers toutes ces facettes.
À côté de ça, parce qu'il n'y a pas que le blog, je fais de l'ultra-trail et puis je blogue un peu sur divers sujets.
Je me mélange, pro, perso, épanouissement sur mon blog.
Super, merci.
Ce qui m'a donné envie qu'on échange, c'était ta réaction en des épisodes qu'on a fait avec Denis Migaud,
où il nous parlait du fait qu'en tant que Scrum Master, il aimait bien donner du temps à l'équipe
pour avoir le temps de travailler les sujets techniques, faire du ménage, travailler les sujets de fonds.
Et moi, ce que j'avais salué, ce que je trouvais intéressant, c'est de trouver un Scrum Master qui était sensible
aux questions techniques, je trouvais ça vachement chouette.
Mais toi, tu relevais aussi à notre point, qui est très vrai aussi, qui était dire,
oui mais à partir du moment où on isole le travail technique,
implicitement on le fait passer pour du travail secondaire en fait,
et donc potentiellement quelque chose qui risque de sauter.
Oui, c'est ça.
Alors le fait de laisser de la place pour la technique, comme tu dis, c'est vachement louable
et parfois, fonction de l'ambiance, fonction du Scrum Master, de son historique,
on n'a pas forcément sous la zire là.
Mais du coup, il y a ce danger à ce que ce soit aussi complètement interprété
comme quelque chose qu'on fait en bonus, quelque chose qu'on peut remplacer par des user stories
plutôt que de garder un sang ou une bande passante
pour pouvoir travailler la qualité en continu.
Oui, parce que finalement, le risque, c'est aussi de doper la vélocité en fait.
Oui, oui, puisque du coup, si on reprend l'exemple de Denis,
où je pense que bon, on est sur un cas de figure peut-être un peu extrême
dans ce qui nous a partagés, c'est 50% du temps du sprint
dédié à produire de la valeur métier.
Ça veut dire que quelqu'un pourrait se dire qu'on pourrait doubler la vélocité
si on mettait de côté la partie entre guillemets qu'elle est sur la qualité.
Donc ça a un effet complètement piégeant, c'est que si il y a un manager qui passe par là
et qui n'est pas forcément complètement à l'aise avec l'agilité et les valeurs,
il va pervertir le truc et penser que l'équipe, elle se tourne épouse
et qu'elle peut en faire de fois plus.
Est-ce que du coup, je dois dire qu'il n'est pas très fan des stories techniques ?
C'est pas que je ne suis pas très fan.
L'expérience me montre que globalement, il faut en user avec parsimonie
et il faut dans la mesure du possible rentrer tout ce qui peut s'apparenter
à des tâches techniques sur un besoin métier.
Idéalement, s'il y a un besoin métier qui émerge dans un sprint
et que ça touche à quelque chose où on sait qu'on a entre guillemets de la dette technique,
ça me paraît légitime de le faire porter par ce besoin métier
en étant très honnête et en expliquant qu'attention, là on va toucher quelque chose
où on a de la dette, où ça a été fait à la va vite, il y a X sprint
et donc ça va nous prendre un peu plus d'énergie pour pouvoir faire bien
la nouvelle chose qu'on nous demande, parce qu'il faut qu'on reprenne
quelques éléments techniques.
Du coup, on n'est pas en train de dire qu'il y a notre user story métier qui vaut 3
et notre user story technique consavante et qu'on impose dans le backlog
qu'il va avoir 5, non on va avoir un truc qui vaut 8
et puis si ce n'est pas entendable, il faut bien expliquer que c'est ça
l'effort à produire pour avoir un logiciel fonctionnel et de qualité à l'issue
de cet incrément-là.
Oui, parce qu'il y a dans les échanges, on parlait aussi d'une...
Moi non plus, je ne suis pas fan des stories techniques.
Pour moi, si on n'est pas capable de raccorder un enjeu technique à un enjeu business,
c'est qu'il y a un gros risque d'over design, d'over engineering
et de tomber dans le piège du se faire plaisir.
Et moi en tant que t'écoute, j'adore me faire plaisir sur la technique.
Donc moi-même, je m'instrains à une certaine vigilance par rapport à ça.
Et du coup, j'essaie toujours de raccorder un objectif business
parce que sinon, tu peux partir dans des délires techniques
qui ne sont pas ancrées dans la réalité du business.
Mais le côté business.
Il y a un moment donné, si le business ne tient pas la route,
tu as un décalage et ça se sent forcément sur le projet.
Oui, mais en plus, c'est une double sponsoring.
En quelque sorte, toi, dans le chantier,
en tout cas, chantier c'est peut-être un grand mot,
mais l'enjeu technique que tu as identifié, parce que tu n'es pas satisfait,
parce que ça a été fait vite à un moment,
tu es sponsorisé par le métier et puis le métier,
il est sponsorisé par l'envie de faire mieux.
Donc si on se dit les choses telles qu'elles sont,
plutôt que de dire, bon ben, à faire le métier,
et puis après, on va faire la technique,
c'est des relations aussi d'adultes
qui forcent le respect ensuite entre les interlocuteurs, je pense.
Après, sur ce que tu dis, oui,
faire des tâches techniques ou des stories techniques,
moi, là, comme ça, tu me poses la question,
les seuls que j'oserais mettre telle qu'elles,
c'est parce que ça fait mal en prod,
parce qu'on a vraiment des signaux qui font qu'il faut agir.
Mais alors, tiens, il faudrait qu'on remplace ceux-ci par cela,
mais finalement, ça marche.
Si ça marche, c'est toujours un peu questionnable
de vouloir changer quelque chose qui marche.
Par contre, si ça ne marche pas bien ou ne marche pas du tout,
là, il n'y a pas le choix.
On ne peut pas attendre qu'il y ait un besoin business
qui coste avec ces problèmes.
En fait, si c'est que le besoin business, il est là,
mais il est tellement évident qu'il est un plus-cit,
il faut que le service soit rendu dans le business, ça va être.
Oui, et finalement, on pourrait même appeler ça plus un bug qui est remonté.
C'est-à-dire qu'il n'y a plus besoin de chercher une légitimité à agir.
Les signaux sont déjà là, en fait.
Mais sinon, après,
le dernier sujet qui peut amener des bas là-dessus,
c'est l'immigration technique.
D'ailleurs, tiens, j'utilise tel framework,
il passe dans telle version, etc.
Mais là aussi, pour moi, est-ce qu'on a besoin de faire,
entre guillemets, à la scrum, un post-it pour ça
ou est-ce que ça fait aussi partie des activités récurrentes
qu'on fait sur chaque sprint ?
On va dire, tiens, il y a une version mineure.
Chaque fois qu'il y a une version mineure,
on prend le temps, on l'a analysé, on la monte,
on a confiance, plutôt que de se dire au bout d'un an
« Ouh, là, on a pris trois versions de retard,
maintenant, il faut qu'on fasse un sprint technique
pour traiter tout ça ».
Après, tu me disais, tu me reconnaissais aussi
que parfois, l'esprit technique,
des fois, oui, tombe bien.
Si on est un peu à court de ce story business,
c'est quand même bien utile.
Moi, j'ai une anecdote là-dessus, c'est que j'étais sur un projet
où séparation maîtrise d'oeuvre, maîtrise d'ouvrage
oblige à respecter un certain mode de fonctionnement
et côté maîtrise d'oeuvre,
on avait vraiment, vraiment envie de faire du scrum.
Ça remonte à sept ans, on était agiliste, débutant,
mais convaincu.
Et au final, on a souffert pendant quatre mois
à faire un lot à la cyclenver.
Et puis, soudainement, on avait fini.
Et pendant que se faisait, entre guillemets, la recette interne
sur ce premier lot, on était là, se tourner les pouces.
Et c'est là où on a pu, entre guillemets,
faire un back-lock technique,
puisqu'on était conscient qu'on avait dû faire des choses
à la va-vite et qu'il y avait des choses qui n'allaient pas
et que, simplement, qu'on n'avait pas mis en place
de démarche qualité.
Et du coup, on en a profité pour caler les principes de scrum
sur ce besoin de back-lock technique
et faire une dizaine de jours
à établir tout ce qu'on pensait être nécessaire
pour que ça fonctionne bien.
Puis, jouer tous les cérémoniaux, tous les événements,
je préfère événements, scrum,
pour rentrer dans cette façon de travailler.
Et puis, le bénéfice derrière, c'est que le deuxième lot,
quand il est arrivé, quand les specs, entre guillemets, sont arrivés,
moi, pour le coup, j'ai joué un peu au proxy PO,
en plus du rôle de Scrum Master.
Et on a embrayé pendant quatre mois à travailler
côté MOE façon Scrum
et à être super enthousiaste de la façon dont vous pouvez travailler.
Donc oui, avoir un back-lock et des user-story techniques
à un moment peut être bénéfique.
Il ne faut juste pas que ça dure,
puisque derrière, on est surtout là pour produire un business
et que les gens vont nous observer surtout sur ça
plus que sur tient à corriger des choses,
pourquoi il y avait un problème au départ ?
Écoute, Eric, je te remercie, je te propose que ce soit le mot de la fin.
Si les auditeurs veulent en savoir plus, ils peuvent venir ou pour voir
un petit peu ce que tu écris, ce que tu publie ?
Moi, j'ai un blog qui s'appelle Eric.ciber.fr,
au plus simple, et puis sinon, je suis assez actif sur Twitter,
eux, cyber, sur Twitter.
Super, merci beaucoup.
Quant à toi, cher auditeur, je t'invite à rejoindre
la communauté des artisans-développeurs
sur artisand-développeurs.fr, et je te dis à demain.
Sous-titres réalisés par la communauté d'Amara.org