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.
Bonjour, bonjour Bonoing.
La dernière fois on avait échangé sur SAFE et on avait laissé un peu en suspens un point que je te propose de développer dans cet épisode,
c'est qu'elle est la place du développeur dans SAFE.
Imaginons que ma boîte sont en train de mettre en place SAFE, qu'est-ce qui va changer dans ma vie concrètement en fait ?
Alors en fait bon la réponse elle est évidemment pas évidente et je vais certainement pas répondre de façon catégorique.
Je pense que si tu veux au niveau en tant que développeur je le vois plutôt comme une opportunité en fait,
c'est-à-dire qu'il y a quand même quelque chose qui est disons consubstantial à SAFE qui est la première valeur donc qualité intrinsèque, built in quality,
que l'on retrouve disons implémentée ou en tout cas réalisée en particulier au niveau de chaque équipe par un cadre qui est ScrumXP
dans lequel on reprend explicitement, enfin il suffit d'aller voir le site, dans lequel on reprend tu sais les pratiques historiques disons de l'extrême programming type intégration continue, test first etc.
Donc ça c'est clairement disons établi, explicit dans le cadre SAFE donc c'est en ce sens que je dis que c'est une opportunité qui n'existe pas forcément dans d'autres cadres
même si c'est possible je pense par exemple à ScrumXP ou à Camban ou après tout c'est beaucoup plus large.
Alors après la question qui se pose effectivement c'est comment je me positionne par rapport à ça et qu'est-ce qui se passe avec le management etc.
Et qu'est-ce que tu entends par c'est une opportunité sur le built in quality, c'est-à-dire que c'est une manière de mettre en avant le fait qu'on va arrêter de faire de la merde ?
Alors effectivement oui j'emploie souvent ce terme, effectivement il faut arrêter de faire de la merde parce que la merde de façon plus en langage soutenu on appellerait ça la dead technique.
Oui pardon excuse moi, ça revient pas ça.
Sachant qu'après effectivement c'est quand même moi développeur qui ai agéré cette dead technique et c'est quand même ensuite les clients utilisateurs etc.
qui ont appellé le prix, sachant aussi je pense que là le débat c'est pas la dead technique mais je suis pas en train de dire qu'il faut pas de dead technique.
La question c'est plutôt comment on la maîtrise, comment on vit avec etc.
Quand je parle d'opportunités c'est parce qu'il est clairement établi dans safe que ce soit au travers de la valeur built in quality, qualité intrinsèque ou bien que ce soit au niveau de pratique.
Tout ça c'est clairement dans safe.
Donc quand je dis opportunités c'est simplement que si ma boîte est en train de passer à safe, à ce moment là j'ai quand même des billes pour aller voir le management, pour travailler avec mes collègues,
sur qu'est ce qu'on fait, comment on fait justement pour arrêter de faire de la merde etc.
Sachant que le fond de safe on parle de cadre d'agile à l'échelle mais en fin disons que si tu veux en faire un deux mots, autant safe sur l'aspect équipe,
au jour le jour, ça appuie sur ScrumXP en fait ça c'est aussi explicite, très clair dans safe.
Autant l'agile à l'échelle ou en tout cas la mise à l'échelle avec le portfolio etc.
Là on est plutôt sur ce qu'on appelle du Lean Enterprise, c'est-à-dire qu'on va retrouver un étage portfolio avec clairement du Lean Management,
en tout cas du Lean Budgeting et ainsi de suite.
Et donc tout ça pour dire que dans Lean, si tu veux comment dire ce principe et même au-delà cette valeur de qualité intrinsèque,
tout ça ça nous vient du Lean avec du Lean Manufacturing et on va dire que l'apport incroyable de l'extrême programming à l'époque fin des années 90,
ça avait été justement au travers de pratiques typiquement TDD d'implémenter ou en tout cas de traduire, de pouvoir pratiquer qualité intrinsèque dans le logiciel.
Et c'est quelque chose qu'on retrouve dans safe.
Mais du coup alors ça veut dire qu'une boîte qui met en œuvre du safe et qui a l'ambition de vraiment le mettre en œuvre, on va dire quelque part un peu by the book,
tu veux dire et normalement devrait mettre en œuvre du TDD et toutes ces pratiques là quoi.
Exactement, et encore une fois, ça c'est pas, si tu veux, je...
Ça va être un chantier monumental de formes et tout le monde parce que je pense que des boîtes qui passent sous safe, il devait en avoir quelques-unes non ?
Exactement. Alors oui, oui, safe aujourd'hui je pense que si tu veux dans la...
Comme une hôté agile disons il y a une dizaine d'années, on vivait ce qu'on appelait à l'époque la Scrum Mania, je pense qu'aujourd'hui on peut parler de safe mania.
Parce qu'effectivement l'agile ou en tout cas la demande de l'agile évolue. Aujourd'hui, quand je prends mes clients disons depuis plusieurs années,
donc dans les années 2000 je travaillais essentiellement avec des équipes de dev, aujourd'hui ce sont des...
Enfin des managers, enfin des personnes qui ont des équipes de 100, 200, 300 personnes qui demandent de l'agile. Donc safe est une réponse dans ce sens.
Et donc effectivement, comme tu dis, c'est un sacré chantier mais enfin la question c'est comment en tant que développeur je peux profiter de cette opportunité ?
Et je sais pas si je réponds vraiment à ta question d'accord.
Et clairement non mais c'est clairement ça. Et quand je t'écoute je me dis qu'il y a aussi...
Je me dis qu'il y a l'autre au revers de la médaille, c'est-à-dire parce que le TDD et toutes ces pratiques-là peuvent faire peur.
Moi j'ai encore des endroits où je vais où on me dit non mais le TDD tu crois vraiment que ça marche.
J'entends pas mal de scepticisme si elle est là et du coup je me dis Scrum c'était facile à faire passer
parce que tu remettais pas en cause le développeur indépendamment dans son travail ou quotidien.
Là ça veut dire que ça va assez loin en fait la transformation.
Et oui, oui, tu poses bien la question. C'est-à-dire que Scrum qui proposait depuis plusieurs années, depuis les début des années 2000
je crois donc cette fameuse définition vous donne, ça te déodait à la le méritre d'exister en tant que tel.
Si ce n'est que derrière suivant moi, alors je sais pas comment appeler ça, professionnalisme c'est pas être un peu exagéré
mais en tout cas, suivant ma façon de voir mon métier de développeur dans ma DOD je vais mettre ou pas de la gestion de cons,
je vais mettre ou pas des revues de code, des verifs de standard, tout cet type de check-style, etc.
Et donc là effectivement quand safe reprend toutes ces pratiques d'XP, là effectivement on met la barre assez haut
et je pense que la question c'est effectivement cette question de transformation, de sensibilisation,
pour pas dire de lobbying au niveau management, etc.
Sachant que moi honnêtement, dans mon expérience, je rencontre quasiment,
enfin pratiquement je dirais quasiment autant de dizonnes de managers pour le dire vite que de développeurs qui se posent des questions sur le TD.
Alors après, enfin je pense qu'il faut faire attention à quelque chose, on n'est pas dans du tout tournier,
on est quand même sur des transformations qui, sur des grosses équipes peut-être pluriannuelles en fait.
Donc comme disait ma grand-mère, le mieux est l'un de mes dubiennes, c'est-à-dire que si nous commençons à faire un petit peu de TDD,
y compris sur du legacy avec des évolutions qui arrivent, etc.
Et bien c'est toujours ça, on va commencer à accumuler 10, 20, 30, 40 tests
et puis dans quelque temps on va se retrouver avec des centaines de tests
et ça va qu'elle donne un sacré confort dans le développement.
Eh bien écoute, c'est vraiment très intéressant et je te propose que ce soit le mot de la fin.
Je te remercie d'être venu pour cette émission.
Eh bien écoute, merci à toi, merci à toi.
Quant à toi cher auditeur, j'espère que tu as apprécié ce podcast.
Si c'est le cas, tu peux le manifester en le partageant avec un ami, un, plusieurs, la terre entière comme tu veux.
Et puis je te dis à demain.