Bienvenue sur le podcast Artisan Developer, l'émission qui combine technique et agilité
pour partager la passion du code.
Thierry, tu m'as dit que tu étais allé te former à l'extrême programmier aux États-Unis.
Je suis très curieux d'en savoir un petit peu plus.
Est-ce que tu peux nous raconter comment tu es à te découvrir ce mouvement, comment
tu t'es retrouvé aux États-Unis et avec qui tu as appris là-bas ?
Oui, en fait, c'était vraiment une très très belle aventure.
Si tu veux, au départ, je suis développeur, je l'ai développé
plutôt dans le monde industriel, tu sais, en temps réel pour des images de synthèse,
des choses comme ça au niveau professionnel.
Et donc, je me suis évidemment toujours intéressé au dev.
J'ai vu, disons là, ce qu'on me rappelait, la vague objets dans les années 90,
avec le C++ qui est arrivé, puis un peu plus tard Java,
et puis également surtout des environnements, on va dire, type Borla Homme,
tu vois, Turbo C++, etc., qui, en quelque sorte, populariser, quoi, tout ça.
Et du coup, j'étais très très branché sur, évidemment, tout ce qui touchait,
disons, à la conception objets.
Donc, j'étais fan absolu de Freddy Blue, de Bob Martin, et qui, d'ailleurs,
on je crois, m'ont aidé à comprendre ce qui était vraiment l'objet.
Et pour répondre à ta question, en fait, c'est au travers, justement,
de Mailing List avec UML qui est arrivé en 97,
que j'ai commencé à être branché, disons, sur Kenberg, Martin Foller, etc.,
et c'est eux qui, donc, sur ces Mailing List, objets UML,
commençaient à évoquer cette chose assez extraordinaire
qui était en train de naître, donc qui allait s'appeler l'extrême programmée.
Et, bien, ça m'a tellement, disons, excité,
je dirais que j'ai décidé d'aller me former.
Et effectivement, je me suis formé, donc, dans le cadre d'un séminaire, disons,
qui durait une semaine, qui, à l'époque, était organisé par Object Mentor,
de Uncle Bob, et donc j'ai participé à ce qui s'appelait XP Immersion 2.
Et donc, je me suis retrouvé, nous étions peut-être 50 ou 60,
effectivement, donc, c'était en Californie, juste au sud de San Francisco.
Et c'est là que, bon, ça a été vraiment, si tu veux,
comment dire, l'effet ouah, ou quoi, puisque j'étais formé par...
Il y avait toute une équipe, Ken Beck, Bob Martin, Martin Foller,
Bart Cunningham, je crois, qui était venu, qui était passé aussi.
J'en oublie certainement.
Et donc, voilà, Jean-Gardin, sous-venir absolument extraordinaire.
Et c'est là, donc, que j'ai découvert, ce qui allait devenir l'année suivante, l'agile,
et que j'ai découvert sous forme de, ce qu'on appelait, d'ailleurs, à l'époque,
une discipline empirique de développement de logiciels.
Et c'est, c'était en Kalané, ça ?
Donc ça, c'était début 2000, c'était en février 2000 que je suis parti...
Ah oui, avant même le manifeste, en fait.
Oui, oui, c'est ça, c'est ça.
Et donc, il faut qu'elle me dire, au travers, si tu veux, puisque tu évoques le manifeste,
il faut qu'elle me dire qu'à l'époque, Scrum était inexistant en France,
ferme ma connaissance, en tout cas, on n'entendait absolument pas parler.
D'ailleurs, pratiquement, on n'entendait pas parler d'autre chose,
que ce soit cristal, etc.
Et effectivement, donc, j'ai vu arriver ce fameux manifeste qui allait changer le cours.
On pourrait dire que c'est un manifeste qui allait changer le cours,
le cours de l'histoire au niveau informatique et peut-être même au-delà, au-delà aujourd'hui.
C'est ça.
Ok, incroyable, t'as été formé.
Et avec Ken Beck, Bob et la bande.
Martin Foller, oui, oui, c'est ça, c'est ça.
Et Ron Gephrys, mon premier TDD, on va dire, d'île de ce nom.
Je crois que je m'en souviendrai toujours.
Je l'ai fait avec Ron Gephrys, pas très loin.
J'en garde encore, d'ailleurs, même la sensation, tu vois, à propos de TDD, puisque c'est vraiment
un typique, que ce soit d'ailleurs de l'extrême programmier ou même aujourd'hui de safe.
Je garde encore, tu vois, la sensation de l'effet barre-verte, tu vois, lorsque le test
passe au vert, une sensation super agréable et super excitante.
Écoute, ça prend une direction qui n'est pas prévue, mais je trouve ça vachement
intéressant. On peut un petit peu creuser sur ça ?
Oui, oui, bien sûr.
Parce que moi, je découvre l'extrême programming en 2002-2003 au travers d'un petit
bouquin vert. Alors, attends, je l'ai derrière moi, je vais le prendre et je retrouve les auteurs.
Donc, c'était le bouquin de Jean-Louis Ménard, Laurent Bossaville, Régime Edina, Dominique Williams.
Oui, oui, oui.
Moi, c'est à travers ce livre, en fait, que j'ai découvert l'extrême programming qui m'a servi
de, vraiment servi de Phil Darian, parce que j'étais plutôt à Marseille.
Puis je voyais tous ces groupes qui faisaient des dojo et je bavais devant la liste des dojo,
les exercices que vous faisiez. Moi, tout ce que j'avais, c'était ce livre.
Et je l'ai tellement usé, la première version de ce livre, que les pages finissaient par se détacher
une par une tellement que je l'avais potassé, travaillé.
Moi, le TDD, je l'ai plutôt mis en œuvre tout seul.
Et je me dis, wow, ça me donne des frissons, ce que tu me racontes là.
Être avec les perfondateurs du mouvement, ça devait être quelque chose.
Et du coup, donc toi, tu te formes, 2001 le manifeste et toi, tu rentres en France.
Et comment tu vois les choses évoluer derrière, du coup ?
Alors si tu veux, oui, je rentre en France.
Enfin, je pense que je sais pas si tu souhaites y revenir,
mais je crois que c'est vraiment important de comprendre vraiment ce qui est l'extrême
programmé parce qu'aujourd'hui, ce que l'on, comment dire, ce que l'on garde,
quand je dis, on, globalement dans la communauté agile, ce que l'on garde
d'image, disons, de dix-pays, c'est essentiellement, justement,
les pratiques de développeurs type intégration continue, etc.
Alors qu'en réalité, l'extrême programmé est beaucoup, beaucoup plus riche que ça,
que ce soit la première version, ce qu'on appelle les XPE2E,
donc l'extrême programmé Expline, première édition ou deuxième édition.
Ce sont des choses très, très riches.
Donc pour répondre à ta question, ensuite, quand je suis rentré,
donc, enfin, j'ai fait plusieurs voyages, j'ai bossé très, très peu,
mais un petit peu avec Object Mentor puisque mes premières formations XP,
mes premiers accompagnements, justement, en fin 2000, c'était avec du matériel
d'Object Mentor, d'ailleurs.
Au passage, avec quelques potes sur Toulouse, nous avions créé
l'association Extreme Programming France, donc ça devait être en fin d'été ou
au tonne 2000.
Cette association XP France qui allait devenir d'ailleurs agile France en 2008,
autant que je me souvienne.
Et donc, et donc, alors ce qui, à mon avis, en tout cas, tel que je l'ai vécu,
ce qui s'est passé dans ces premières années, c'est que,
étant donné que l'Extrême Programming était, disons, quasiment révolutionnaire,
enfin extraordinaire au niveau développement puisque le soft devenait,
on va dire, une sorte de matériau très plastique, très maléable,
avec lequel on pouvait s'amuser justement au travers du refactoring,
du TDD, etc.
Donc, XP a été ensuite porté
plutôt par des développeurs et on a, je dis on, parce que, bon,
je pense, on faisait partie aussi, on a plutôt mis l'accent là-dessus.
Et donc, les aspects, les autres aspects de l'Extrême Programming,
puisque dans l'Extrême Programming, on retrouve les rôles de manager,
de coach aussi, etc.
Mais enfin, surtout de manager, évidemment, de clients, ce qui correspond au...
De testeurs aussi.
Voilà, de testeurs, de trackers, etc.
Mais si que veut, les trois rôles principaux qu'on retrouve dans un bouquin
qui s'appelle XP, je crois, quelque chose comme ça, qui date de 2001,
c'était vraiment le client avec une pratique qu'on appelait client sur site
et qui était là justement pour piloter en optimisant la valeur.
Et donc, ces choses-là, au travers du planning game, puisque c'était
donc cette pratique de planning game qui intégré d'ailleurs la spécalité
qu'on pourrait appeler directement dette technique dans la planification.
Donc, ces choses-là, donc qui existaient, qui existent toujours finalement,
d'ailleurs, dans l'Extrême Programming, qu'on retrouve justement un petit peu
d'incev, c'est pour ça que ça m'intéresse beaucoup.
Ces choses-là, donc petit à petit, petit à petit et en particulier,
en à partir de 2006, avec l'arrivée en France de Scrum
et ce qu'on va appeler fin des années 2000, la Scrum Mania.
Tout cela va se diluer un petit peu dans la communauté, en mon sens,
au profit de ces rôles, donc de Product Owner et de Scrum Master.
Voilà. Et puis, pour continuer l'histoire, au passage,
il y a Camban, Lean Software, développement qui apparaît aussi.
Mais encore une fois, l'Extrême Programming, c'est vraiment déjà de
Lean Software très, très abouti puisque, par exemple,
c'est quelque chose qu'on retrouve aussi d'incev,
mais justement, on évoquait le TDD.
Le TDD, c'est vraiment une mise en œuvre du principe de qualité
intrinsèque du Lean, qui est justement adapté au logiciel.
Et je crois que ça aurait été vraiment l'un des, comment dire,
l'une des évolutions, même je dirais, d'XP, tout à fait extraordinaire
d'être, de pouvoir, comment dire, donner à la communauté des développeurs
ces outils de qualité intrinsèque.
Juste une parenthèse, je me souviens quand je suis rentré en France
et que je présentais, donc en 2000, 2001, avec des premières conférences,
des premiers ateliers, etc.
Lorsque je présentais les TDD, je me souviens que j'avais des développeurs
qui me disaient juste, mais c'est pas possible, d'écrire un test avant
d'avoir développé le code. Donc tu vois, on revient de loin quand même.
Bon, je te rassure, je l'entends toujours ça.
Il y a encore beaucoup de travail.
Ah, OK. Voilà, donc vite selon vous.
Voilà. Et donc,
et donc pour continuer l'histoire, et bien, je crois que bon, on peut quand même
remercier Scrum sur l'effet au travers du business model, au travers
de beaucoup de choses sur, on va dire, la généralisation,
la vulgarisation de l'agile, bien qu'il faille, je crois qu'il faut vraiment
distinguer Scrum et Agile.
Et ce qui fait qu'aujourd'hui, en tout cas, depuis quelques années,
on voit apparaître un besoin, en fait, chez les utilisateurs,
chez les clients, disons, chez les utilisateurs de l'agile,
un besoin d'agile à l'échelle.
Et c'est là que vont apparaître des cadres, donc comme les, il y a
une dizaine d'années, mais les c'est un petit peu particulier parce que quand
on les parle, c'est plutôt adapté à de gros produits, alors que des
cadres comme le SAFE vont bien au delà puisqu'ils sont adaptés
plutôt à des portfolios de produits.
Et donc aujourd'hui, la question qui s'oppose, à mon avis, dans la
communauté agile, c'est justement cette question qui est,
qu'est-ce qu'on fait face à cette demande qui émerge et qui est en
quelque sorte la rensoignement du succès, finalement, de l'agile,
qui est cette demande de cadre, en tout cas de réponse en termes d'agile
à l'échelle.
Si tu me permets, je voudrais juste dire quelque chose qui me paraît
important quand même pour comprendre l'extrême programming et cette
révolution disons que fut l'extrême programming.
Je pense qu'il y a d'ailleurs Ken Beck s'en cachait pas, il disait
qu'il s'était inspiré de méthodes issus de l'industrie.
Donc c'est vraiment du lignes de software au sens pilotage par la
valeur, au sens donc qualité intrinsèque, au sens éviter les
gaspillages.
Quand on disait dans l'extrême programming, on fait attention au
dock, etc.
Ce n'était pas juste pour dire, on s'en fout des docks, c'était pour
dire tout simplement ce qui apporte de la valeur dans la
fabrication du logiciel.
C'est une activité qui s'appelle la programmation, d'où le nom
d'ailleurs extrême programming.
C'est un nom encore une fois très, très lignes et d'où cette
vigilance, disons, pour toutes ces activités qui n'apportent pas
de valeur ajoutée.
Et puis un autre point aussi pour comprendre quand même au niveau
développement, ce qui s'est passé la fin des années 90, c'était
justement, j'évoquais tout à l'heure des environnements type à
l'époque, je me souviens de Turbo C++, des environnements comme
ça, c'est-à-dire à la fois des becans et à la fois des
environnements de dev qui nous permettaient de faire des
compiles en quelques secondes, etc.
Et XP est arrivé à ce moment-là.
Je dis ça parce que pour nos raisons simples, moi, mes
premiers programmes, donc ça ne t'atteint pas d'hier, mais tous
premiers programmes fin des années 70, début des années 80,
c'était en carte perforée.
Alors je ne sais pas si t'as connu les cartes perforées.
Non, non, je ne suis pas connu ça.
Bon, voilà, donc c'était une autre époque où si tu veux,
bon, grosso modo par rapport à ce qui nous intéresse, ce qu'il
faut voir, c'était que le cycle de développement de
compilation, si tu veux, et d'exécution pour vérifier un
programme, etc., c'était facilement de plusieurs heures.
Tu vois, on avait nos cartes perforées qu'on fabriquait
grâce à des sortes de machines à écrire, disons-le comme ça.
Donc le programme, c'était un jeu de 100, 200, 300 cartes
perforées. Ces cartes ont les mettées dans un bac,
donc un opérateur, quand il pouvait récupérer ce bac.
Et puis donc, si tout allait bien, une heure, deux heures,
au voir le lendemain, on avait le listing de résultats avec
des éventuellement des erreurs de compile, avec les résultats
de l'exécution, etc. Donc ce que je veux dire, c'est que
il faut vraiment mesurer, à mon homme la vie, en fait,
ces pratiques, disons, type intégration continue,
test driven, développement refactoring, à Lone ou en
tout cas, en regard de ces capacités de développement
que l'on a depuis deux ou trois décennies, qui n'aurait pas
été possible avant, en fait, TDD. Je ne vois pas comment
on aurait pu faire du TDD avec les cartes perforées à l'époque.
C'est super intéressant. C'est l'évolution technologique qui a
permis l'évolution des pratiques qui était autour.
C'est exactement ça. Et je pense qu'il y a vraiment une question
à se poser. Tout à l'heure, tu disais qu'encore aujourd'hui,
il y a des développeurs, en tout cas des personnes qui se posent
la question de la possibilité de ce qu'on appelle,
finalement, de façon générale, les pratiques de type test
first programming. Je pense qu'il faut vraiment mesurer
cette évolution et du coup se poser la question,
est-ce qu'aujourd'hui, on ne serait pas en train,
pas forcément au niveau vraiment purement de dev, parce que
bon, en tant que dev, évidemment, on profite des
environnements, mais plus généralement au niveau de
ce qu'on pourrait appeler un cadre método, tout simplement,
est-ce qu'on n'y quand même pas encore avec ces, on va dire,
ces survivances, ces reliquats de cyclanvées,
ce qui donne du vrôme, etc.
Est-ce qu'on n'est pas encore aujourd'hui en 2018,
en train de développer, comme on le développait dans
les années 70, sachant qu'effectivement, les
techniques ont vraiment évolué?
C'est vachement intéressant ce que tu dis, parce que tu donnes de la
profondeur à des espèces d'acquis.
Moi, je me souviens, surtout dans les années 2000, on pouvait
même pas, enfin, remettre en cause le cyclanvée,
c'était de l'ordre du blasphème, tu vois, c'était blasphématoire.
Ah bien, bien sûr, tout à fait.
Et on a hérité ça, alors que la question que tu poses est
tout à fait légitime, qui est de dire, mais les gars,
est-ce qu'on est toujours obligés de développer de la même manière?
C'est ça, c'est ça.
Alors, encore une fois, à mon humble avis, je pense qu'au niveau
vraiment purement de dev au quotidien, bon, ça va, on a quand même
plus trop gaffe au point virul, parce qu'on sait très bien qu'on aura
une qu'on aura trois secondes après ou deux secondes après une
marque dans la marche qui nous l'indique.
Donc, je pense que ça se pose vraiment au niveau au niveau
plus global de, on va dire, la perception, la compréhension
de façon générale que globalement, une organisation, un client,
etc. peut avoir de ce qu'est un logiciel.
Juste, si tu veux pour te donner un exemple, enfin, que j'utilise
beaucoup avec mes clients ou en tout cas pour essayer de
faire comprendre, je trouve qu'à l'époque, j'étais aussi un petit peu,
disons, photographe, amateur et pour être honnête, d'ailleurs,
justement, un peu au même moment.
D'ailleurs, là, au tournant 2000, apparaissait donc la photo numérique.
Et aujourd'hui, on n'a plus que de quasiment que de la photo numérique.
Et je dis ça parce qu'il se trouve que personnellement, en réalité,
j'ai eu un petit peu de mal à passer à la photo numérique.
Mais c'est vraiment le même, je pense, le même rapport, c'est à dire
que un soft est toujours un soft comme une photo est toujours une photo.
C'est à dire, on va retrouver les questions de cadrage, de luminosité,
de contraste, etc.
Simplement, grâce au numérique aujourd'hui, on démultiplie les possibilités.
Enfin, je me souviens à l'époque, donc ça, c'était fait
en des années 70, aussi 80, quand je partais avec des j'étais dans des clubs.
Enfin, quand on partait faire comme ça des sorties photos, bon, même si on
prenait, par exemple, 10 pédécules, des 24-36, bon, 10 pédécules,
ça nous donnait grosso modo 400 photos.
Donc, 400 photos, c'est énorme, mais tu vois, dans la journée,
on pouvait shooter 400 photos.
Bon, aujourd'hui, avec le moindre appareil ou même un téléphone portable,
ça se chiffre en milliers.
Donc, ça veut dire qu'il y a quand même un rapport
on va dire à l'objet, à ce que l'on manipule, qui, voilà, qui est modifié.
Ça, c'est un temps mieux, enfin, un temps mieux, ça s'appelle le progrès.
Et c'est super, ça donne, ça démultiplie les possibilités.
Et bah, écoute, je te propose que ce soit le mot de la fin.
Je te remercie, Thierry, pour ce flashback et ce retour sur les racines
de l'extrême programmée.
Pour en savoir plus sur ce que tu fais et sur ton travail, on va où ?
Ah, voilà, une question.
Alors, aujourd'hui, j'ai un site web.
Bon, je dois dire que, autant pendant des années, j'ai vraiment, je crois,
quand même, été plutôt au Prolix, là, au niveau blog et tout.
Aujourd'hui, j'ai un site qui s'appelle le ToltecAgil.com,
puisque, bon, ça pourrait encore être
une autre discussion, mais à la même époque, je découvrais la voix Toltec.
Et donc, voilà, donc je publie quelques billets aujourd'hui sur ToltecAgil.com.
Ben, je te remercie, Thierry, pour sa participation et cet échange.
Quant à toi, chère auditeur, si tu as apprécié cet épisode,
je t'invite à revenir dès demain, puisque Thierry nous reparle.
Et cette fois, dans notre sujet, il nous parle de SAFE,
cet espèce d'objet qui fait pas mal de débats dans la communauté.
Et il va nous expliquer ce que c'est, à quoi ça sert,
pourquoi le safe bashing et on pourra y voir un petit peu plus clair.
Merci à toi et à bonne journée.
À demain.