Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui, je suis avec Thierry Cross. Thierry, bonjour.
Oui, bonjour Benoît.
Merci d'être là aujourd'hui sur cette émission.
Bah écoute, merci à toi de m'accueillir.
J'avais envie de te proposer, de parler d'un sujet qui, je pense,
se tient à cœur au moins autant que moi.
C'est la question de la responsabilité du développeur.
Qu'est-ce que ça veut dire pour toi en tant que développeur
de se comporter de manière responsable ?
Oui, effectivement, c'est une sacrée question qui est un petit peu à la base de l'agile,
puisque dès le départ, l'agile fait en mise sur l'auto-organisation.
Donc, auto-organisation, cela signifie qu'il y a quand même des questions
de responsabilité qui se posent.
Et c'est une ré… Bon, je pense que, à mon avis, la première chose à dire,
c'est quand même que c'est une question très, très, très complexe.
Parce que, en fait, je pense que le fond de l'histoire,
c'est que il ne s'agit même pas de responsabilité,
il s'agit de co-responsabilité en tant que développeur,
puisque a priori dans une équipe,
nous sommes 3, 4, 5, 6 développeurs.
Et donc la question, c'est la question de la responsabilité
et de la co-responsabilité.
Bah, co-responsabilité de la solution, de ce qui est fait,
du niveau de qualité, etc., sachant qu'on est quand même pris,
je pense aujourd'hui, quand je dis « nous, développeurs »
et plus généralement tous les producteurs, disons tous les fabricants,
nous sommes pris dans quand même une sorte de, je ne sais pas comment,
un peu les sages, une sorte de mouvement un peu là,
un petit peu affolé de… qui se traduit chez nous par de la dette technique,
qui se traduit au niveau sociétal,
parce que, on pourrait appeler la dette écologique,
tu vois, je pense qu'on peut faire en parallèle entre les deux,
c'est-à-dire une certaine inconséquence de la façon dont nous procédons.
Et donc, cette métaphore de la dette, elle suggère bien quand même
qu'un jour ou l'autre, il y a bien falloir payer tout ça.
Et voilà, et donc je pense que effectivement,
cette question, elle se pose au niveau développeur,
par rapport à l'organisation et par rapport au travail qui est fait.
Moi, tu vois, la notion de responsabilité du développeur,
elle me renvoie beaucoup en ce moment sur la notion de « est-ce que je fais du bon travail ? »
et surtout, est-ce que je mets en œuvre ce qu'il faut pour le faire,
malgré parfois un contexte défavorable ?
Il n'y a rien de plus qui m'insupporte que d'entendre des développeurs,
je ne suis pas tendre avec eux qui me disent « ah oui, mais c'est la faute de Intel,
c'est la faute de C, c'est la faute du management, c'est la faute de… ».
Il y a toujours une bonne raison de ne pas prendre ces responsabilités.
Et moi, je suis un peu binaire sur ça.
Soit tu restes et tu fais avancer les choses et tu fais évoluer le contexte
et ça va te demander beaucoup d'énergie.
Soit, tu t'en bas.
Je crois qu'aujourd'hui, en tant que développeur,
il n'y a personne qui est obligé de rester dans la boîte « oui » les quoi.
Je ne vois pas comme ça, tu vois.
Oui, je comprends ce que tu dis.
Bon, je serais peut-être un peu plus.
Alors, je ne sais pas si c'est bienveillant ou nuancé ou autre.
Je pense que parfois, dans sa vie, ce n'est pas forcément facile de démissionner, etc.,
même si effectivement aujourd'hui, il n'y a qu'à même des beaucoup de demandes
au niveau de développement, etc.
Bon, si tu veux, à mon niveau de coach agile aujourd'hui,
dans ma compréhension, en fait, je pense qu'il y a plusieurs choses.
C'est-à-dire que la question, c'est effectivement, quelle est mon intention.
Disons, alors quand j'emploie le terme « intention », tu sais,
c'est un petit peu au sens de la voie « tall tech » puisque tu sais que je m'intéresse
beaucoup à la voie « tall tech », que j'utilise aussi d'ailleurs au niveau coaching.
Et donc, on parle de maîtrise de l'intention.
Donc, l'intention, c'est un petit peu la finalité, le désir, le but, etc.
Ce n'est pas forcément un objectif chiffre, etc.
C'est plutôt qu'à des monintentions.
Ça, c'est quand même la première question.
Et donc, mon intention, du coup, ça peut être, effectivement,
d'avoir un boulot, de gagner de ma vie, mais ça peut être aussi
d'arrêter de faire de la merde, de produire de la dette technique
et donc d'être fiers quand même de ce que l'on fait.
Là, on rejoint quand même clairement, tu sais,
les mouvements un petit peu gravement chips, etc.
Je pense qu'au niveau d'une boîte, il y a au départ,
et là, on est vraiment dans du coaching, de l'accompagnement.
Je pense que la première étape, elle passe quand même par une prise de conscience.
Tu sais, au niveau, finalement, je me suis rendu compte que
au niveau de la planification, disons du pilotage,
au départ, historiquement, tu sais, c'était le fameux triangle de fer, budget,
avec l'extrême programming, il y a une vingtaine d'années.
Donc le planning game posait déjà la qualité,
mais en fait, on pourrait traduire par dette technique
comme quatrième variable d'ajustement.
Aujourd'hui, donc en fait, les variables d'ajustement,
ça donne le budget, le planning, le contenu,
et puis la qualité en termes de dette technique.
Aujourd'hui, je rajoute même une cinquième variable d'ajustement,
qui est ce que j'appelle le respect des personnes,
puisque quand on a, c'est même pas d'ailleurs le manager,
c'est même plus la culture globale d'une société
qui impose justement de produire de la dette technique, etc.
En mon sens, ça, ça veut dire qu'on joue sur le respect des personnes.
Donc je pense que la première étape, c'est déjà,
soi-même au niveau développement, de prendre conscience
que, eh bien, quand on dit que le plan en agit est ajusté,
effectivement, il est ajusté, en particulier,
au travers de la dette technique et au travers de ce respect
ou d'irrespect plutôt des personnes.
Et cette étape de prise de conscience,
après associée justement à mon intention en tant que développeur,
elle me permet de voir bien ce que je fais,
est-ce que je reste,
est-ce que je commence à bosser
avec même deux ou trois collègues,
tu vois en TDD, etc.
Est-ce qu'on commence à se poser des questions,
des questions sur nos standards de codage,
sur notre dette technique ainsi de suite.
Mais je crois que, enfin, si tu veux, pour être honnête,
je me suis rendu compte à la force de faire et d'aider à faire de l'agile,
que l'agile amène à une certaine, je dirais introspection,
c'est-à-dire qu'effectivement, il arrive un moment où
il s'agit de se poser la question,
c'est un peu ce que t'évoquais tout à l'heure,
mais bon, qu'est-ce que je fais, est-ce que je reste, est-ce que je pars,
mais si je pars, c'est pourquoi,
quand même, dans quelle intention.
Et je pense qu'aujourd'hui, des cadres comme SAFE en particulier
sont en tout cas propices,
puisqu'ils mettent clairement en avant cette question de qualité,
mais tout ça, c'est un héritage, un bel héritage du line,
produire de la valeur, mais pas au détriment de la qualité.
Et donc, voilà, je crois qu'aujourd'hui, avec ces cadres,
on n'a qu'en tant que développeur des opportunités
pour mettre en avant ou en tout cas exprimer
ce qu'on pouvait peut-être pas faire,
ne serait-ce qu'avec Scrum,
exprimer donc ce désir, cet envie,
cette intention de faire du Pocode tout simplement.
Bah écoute, c'est génial,
et je te propose que ce soit le mot de la fin.
Ok, merci, merci à toi.
Merci Thierry d'être venu.
Avec plaisir, merci à toi de m'accueillir.
Quant à toi, cher Auditeur, j'espère que tu as apprécié ce podcast.
Si c'est le cas, je t'invite à aller voir le travail de Thierry,
je te mettrai le lien dans la description.
Et puis je te dis à demain.
Sous-titres réalisés par la communauté d'Amara.org