Comment rendre une app intestable au top de la qualité avec Guillaume Téchené
Comment rendre une app intestable au top de la qualité
César : Guillaume, bonjour, ravi de te recevoir dans ce podcast
Guillaume : Bonjour César, merci à toi de m’inviter.
César : Avec plaisir. Alors nous nous étions rencontrés il y a quelques années aux NCraft. On a eu l’occasion d’échanger à plusieurs reprises notamment sur des projets autour de Coaching Crafts. Et je me dis que pour évoquer ton parcours, le plus simple serait de te présenter.
Guillaume : Ça marche, donc je m’appelle Guillaume Téchené, j’ai 43 ans et je travaille dans le développement logiciel depuis l’an 2000. Donc bientôt 22 ans d’expérience et comme j’aime me le rappeler, je suis à peu près à la moitié de ma carrière. Donc bon, peut-être que l’on reparlera plus tard du jeunisme dans notre industrie, mais je parlais en plus tout à l’heure sur Twitter d’un sondage qui disait que l’on était senior avec 6 ans d’expérience, et ça me fait un peu rigoler.
C’était dans une start-up des années 2000 donc là en l’occurrence c’était un fournisseur d’accès à Internet qui s’appelait Frisbee (ça parlera peut-être aux plus anciens d’entre nous). Je ne suis pas resté très longtemps, mais l’ambiance était super après une fin d’étude, je bossais avec des copains c’était une ambiance start-up donc parfois on travaillait toute la nuit puis on allait se coucher très tard, on dormait 24h… Enfin c’était génial.
César : Qu’est-ce que faisait Frisbee pour le contexte ?
Guillaume : Alors c’était un fournisseur d’accès à internet. Je ne sais pas si tu te souviens des pubs qu’il y avait à l’époque, ils étaient connus pour quelques pubs un peu déjantées. Ils ont été vite rachetés par Libertysurf dans un premier temps au tout début de 2001 et 3 mois après Libertysurf s’est lui-même faire racheter par Tiscali. Juste pour la petite histoire Frisbee derrière Tiscali s’est fait racheter par Alice qui s’est fait racheter par Free donc aujourd’hui, c’est une marque de Free. À partir de là, comme à chaque fois qu’il y avait un rachat, on gelait les projets, dès qu’il y avait un truc qui commençait à se remettre en place ça se regelait, donc c’était un peu la galère.
C’est là que je suis parti pour une plus grosse structure. Là, ça a été un gros changement : je suis passé chez Dassault Systèmes, un gros éditeur logiciel. Je ne sais plus aujourd’hui en termes de taille en Europe, mais je crois qu’ils sont les 2e ou 3e. Dans l’industrie, ils sont connus essentiellement pour tout ce qui est cadre conception assistée par ordinateur C.A.O. avec Katia, etc. C’était très encadré donc plus du tout le monde de la start-up. Ils étaient très fiers de leur cycle en V qui, à l’époque n’était pas complètement déconnant et surtout, qui mettait un gros accent sur les tests.
C’est-à-dire qu’en plus à l’époque tout ce qui était livraison était rarement fait par Internet, c’était surtout gravure de CD etc. Quand on est éditeur de logiciels on essayait de livrer un minimum de bugs.
César : Quand tu parles de tests chez Dassault à cette époque, ça correspond à quoi ?
Guillaume : Alors il y avait un peu de tout en termes de tests, de manière générale parce qu’ils regardaient la couverture de tests. On codait essentiellement en C++ et en Java donc il y avait tout un C++ limite propriétaire avec toute leur architecture à eux derrière mais bon, c’était “facile” d’enregistrer tout ce qui pouvait se passer dans Katia. On était sur du test End to End où tu voyais un ordinateur qui lançait les tests, il lançait et faisait tourner un petit viewer 3D, il enregistrait, etc. Ça comparait des screenshot enfin, c’était la grosse artillerie, mais ça a fonctionné plutôt pas mal. Cela étant, il y avait aussi des tests unitaires ou ce genre de chose. Donc quand la couverture du code n’était pas suffisante, tu te faisais rapidement rappeler à l’ordre par les gens qui étaient chargés de surveiller ce genre de choses.
César : À ce moment-là, c’est ta première expérience professionnelle où tu vois des éléments autour de la qualité ou tu as déjà vu ça en étude dans ta carrière un peu avant ?
Guillaume : Alors oui et non. Pendant mes études, il n’y avait pas vraiment de cours basés sur la qualité. Cependant, il y avait des profs ou des intervenants qui nous challengeaient un peu. Je me souviens typiquement en TD, on avait quelqu’un qui nous faisait faire un programme tout simple, où il fallait rentrer ton nom en ligne de commande, et il appuyait directement sur entrer pour tester le code. Il chopait les trois-quarts des élèves, qui se prenaient un gros carton parce qu’ils n’avaient pas géré.
Donc, il y avait quand même un peu ce background où malgré l’absence de cours académiques sur le sujet, on avait un petit peu cette vision des choses bien faites et de faire attention. Cela m’a pas mal servi par la suite, notamment chez Dassault. J’y suis resté à peu près 6 ans et demi. Il y avait vraiment le côté un peu lourd qui me pesait sur la fin et puis techniquement, je ne m’amusais pas vraiment.
Alors voilà, après 6-7 ans, j’avais envie d’aller voir ailleurs, et j’ai intégré le monde de la finance via une ESN qui s’appelle Nexo, c’était en 2007. Là, le premier truc qu’on m’a dit quand je suis arrivé dans la finance, c’est : “tu vas voir la finance, c’est sympa, mais par contre en termes de gestion de projet informatique, ils sont à peu près 10 à 15 ans de retard sur l’industrie”. Ça m’a fait rigoler sur le moment et puis après coup, je peux confirmer oui, même si ça a pas mal changé.
César : C’est avec Thomas Pierrain qu’on en discutait, qui avait commencé chez CA CIB en 2005, qui était en fait un des précurseurs malgré tout sur l’eXtreme Programming. Toi dans quel contexte est-ce que tu arrives en 2007, sans forcément parler du client ? En tout cas qu’est ce qui fait dire qu’à ce moment-là, il y a vraiment un retard qui est plus fort et quel est le contexte de changement là-dessus.
Guillaume : Alors je suis arrivé dans une banque de financement, le Crédit Agricole, c’est CA CIB. Il y avait pas mal de choses qui avaient changé, c’est-à-dire que mon N+1 et mon N+2 venaient d’arriver, c’est eux qui m’avaient recruté en décembre 2007. Et donc le contexte, ce sont des services pour des pluggin Excel, pour des applis clientes. On leur montrait des infos, des données de marché, des prix, etc. Et c’était assez la galère. D’abord, parce que techniquement, c’était l’enfer. Il y avait un service en prod qui tombait tout le temps, au point que les anciens élèves qui étaient sur le projet avaient créé ce qu’ils appelaient un watchdog.
C’est-à-dire un autre exécutable qui alertait quand la couche de service était en carton, il le relançait. Il y avait plusieurs couches architecturales qui étaient très critiquables, enfin, il y en avait une qui faisait uniquement un passe-plat, il y avait un autre balanceur qui était random, il savait qu’il y avait trois machines en dessous, dès que ça tombait sur 1 ou 2 ou 3, il envoyait les requêtes sur la machine 1, 2 ou 3. Mais elles étaient en carton donc une requête sur trois plantait. Et fonctionnellement, c’était des speak sous forme de screenshot par mail. Donc tous les binaires étaient créés sur les machines des développeurs. Il n’y avait pas d’intégration ne continue ni ce genre de chose.
César : Et toi tu arrives dans ce contexte on devait changer les choses ou tu arrives et l’on te dit il va y avoir des évolutions à faire et comment se passe l’évolution justement sur ce projet là ?
Guillaume : Alors au départ, on ne m’a rien dit de particulier, il fallait maintenir le truc. L’avantage, c’est que comme mes supérieurs venaient d’arriver eux aussi, ils prenaient mieux la mesure du bazar. Quand on a commencé avec un ou 2 collègues motivés à proposer des améliorations, tout s’est passé très vite. Les gens étaient très clients parce qu’ils avaient enfin une certaine notion de la qualité.
Du coup, on a mis en place tout plein de choses, une vraie usine de build. On créait un peu ce qui aujourd’hui est assez courant avec Azure DevOps ou autre, mais on l’a recréé, et là, nos supérieurs étaient vraiment preneurs. Ils étaient motivés. C’est comme ça que ça s’est mis en place. On a vu qu’on avait affaire à un management qui était intéressé par la qualité qui ne voulait pas de solutions boiteuses. On voulait déjà investiguer les bugs, on était plus motivés pour des solutions pérennes. La première année a été compliquée, on avait des gros sujets de tension avec les équipes de support. Enfin, avec toutes les équipes qui mettaient en prod.
Il y a une mauvaise communication donc on a aplani un peu tout ça, en rencontrant d’abord les gens et ça fait la différence. Tu essayes de comprendre leur problème, et ça parait le simple, mais c’était fondamental pour nous. À partir de là, on a pu vraiment construire des choses. C’était ça pendant 3 ans.
César : OK, donc après cette première année qui est un peu difficile dans la mise en place mais malgré tout à l’écoute, vous mettez de plus en plus de choses en place, mais jusqu’où est-ce que vous allez en termes de qualité dans les pratiques ? Est-ce que c’est déjà à partir de ce moment-là où tu mets en place certaine méthodologies et il te reste combien de temps dans cette mission ?
Guillaume : Alors je suis resté pratiquement 3 ans. Il n’y a pas eu de bonnes pratiques à proprement parler, on partait sur du bon sens ou des connaissances que certains pouvaient avoir dans l’équipe. Moi, je ne connaissais pas trop les usines de build, mais ça ne me paraissait pas très malin de faire du copier-coller dans un répertoire pour que ce soit pris en charge par les gars de la production. Donc voilà ce que l’on a mis en place, mais des bonnes pratiques type agilité, TDD, BDD, etc. On était pas du tout au courant quoi.
César : Et ça intervient quand dans ton parcours justement ? Dès cette mission au Crédit Agricole ou finalement, c’est quelque chose qui se construit petit à petit ?
Guillaume : Alors ça s’est fait à la fois petit à petit et d’un coup. J’ai commencé à entendre parler dans ma mission suivante. C’était à la Société Générale au service des matières premières et j’ai pu rencontrer Bruno Boucard qui faisait partie de la cellule architecture. Un jour, il nous a fait une présentation sur les principes SOLID, vers 2010-2011. J’ai appris pas mal de trucs, parfois des choses un peu tirées par les cheveux, où l’on se dit “Est-ce que c’est bien nécessaire ?”.
Finalement, ça va commencer à implanter des choses chez moi que j’ai essayé de réutiliser dans la mission d’après, chez Natixis, entre fin 2011 et fin 2014. J’avais la chance de rencontrer les utilisateurs en direct, on avait des points assez réguliers, et je pouvais suivre l’avancée des projets et d’un de vue technique, c’était du .NET avec de la spécialité web.
César : Petite question, tu dis “je rencontre les utilisateurs en direct” est ce que dans le mindset c’est un changement fondamental pour toi par rapport à ce que t’as pu faire en cycle en V à l’époque chez Dassault, je ne sais pas si on pouvait vraiment parler de l’agilité à l’époque au Crédit Agricole. Je pense que ça se mettait en place un petit peu après côté Société Générale. Là, tu arrives dans un contexte où t’es en direct avec l’utilisateur qu’est-ce que ça change sur ta perception du travail que tu dois faire au quotidien ?
Guillaume : Pour moi, ça a changé beaucoup de choses. C’est là que tu vois vraiment comment est utilisé ce que tu fais, l’impact que pouvaient avoir certains sujets qui pour moi étaient négligeables. Typiquement, il y avait une fenêtre en fin de traitement de Workflow et de mon point de vue ça marchait bien. Et un jour, je vais voir un utilisateur pour un problème tout autre et il me montre cette fenêtre de Workflow qui pour lui est son quotidien.
Il fait une action particulière qu’il utilise tous les jours et là ça lui prend 8 minutes. Là moi, j’ai été complètement atterré par l’attente qu’il a tous les jours à attendre 8 minutes. Moi, je serais devenu fou. De toute façon, on devient tous à peu près fou dès qu’il y a quelque chose qui prend plus de 30 secondes sur notre ordi, alors 8 minutes.
César : Tu te dis qu’il est ultra résilient.
Guillaume : Oui c’est ça ! En fait-on ne se rend pas compte tant qu’on n’a pas le point de vue utilisateur. La patience qu’ils peuvent avoir sur des sujets que nous on néglige de voir dont on n’est même pas au courant, ça m’a vraiment secoué. Derrière, je suis allé retrouver le problème de performance et je l’ai fixé assez rapidement. Ce qui fait qu’au lieu de passer 8 min, il attendait 15 secondes. J’avais moins honte. Mais c’est là que je me suis dit qu’il faudrait que j’aille voir les gens un peu plus souvent.
César : Ouais en fait, c’est le changement de mindset. Finalement, tu produis des choses pour des gens et donc il faut discuter avec eux.
Guillaume : C’est ça. Et on est souvent engoncé dans nos problèmes techniques. Tant que l’on n’a pas confronté ça a un cas d’utilisation réelle la technique, c’est complètement secondaire.
César : Et justement, ça me donne envie de te demander quelque chose avant qu’on ne rentre un peu plus dans le concret des méthodes que tu as pu mettre en place. Est-ce que tu ne constates pas, aujourd’hui de l’over engineering, du « CzrgoCult » autour de sujets ? Où l’on produit des choses pour des personnes et d’avoir cet aspect-là en tant que dév au quotidien ?
Guillaume : Alors oui et non. J’ai probablement un avis biaisé, parce que je choisis mes missions. J’ai cette chance de pouvoir travailler avec des gens qui vont matcher un peu mon profil. Quand tu regardes un peu les réseaux sociaux, que ce soit LinkedIn, Twitter ou autre, tu vas avoir quand même une grosse appétence pour la technique. Ne serait-ce qu’au travers des entretiens techniques. Avant une mission, on a l’impression qu’à chaque fois, le job en question, c’est la NASA. Ils te mettent en difficulté sur des points techniques qui seront finalement triviaux.
Donc oui, je pense qu’il y a trop de focus sur la technique et pas assez sur le besoin sur des utilisateurs sur le métier, etc. Tu t’aperçois rapidement que la technique, ce n’est pas le sujet. Le sujet, c’est le métier et ce qui est important, c’est de parler le même langage que le métier dans ton code. Comme ça, tu comprendras ce que fait ton code et tu comprendras si tu réponds au besoin ou non.
César : Donc à ce moment-là, tu es chez Natixis tu as dit que cela fait partie des déclics que tu eus. Tu me parlais de la prés des principes SOLID de Bruno Boucard à la Société Générale. Est-ce que tu as cette approche autour du métier où directement, tu te poses plein de questions pour rendre le code le plus simple possible ? Quelle est la next step ?
Guillaume : À partir de ce moment-là, j’ai commencé à revenir un peu sur les histoires de tests automatiques. Je me suis dit : “Si je veux livrer quelque chose qui correspond aux besoins des gens ça serait pas mal que je teste les scénarios en avance”. Faire des tests end to end sur toute une appli web pour chaque scénario, c’est vite la galère donc là, j’ai commencé à faire des tests automatisés. À rajouter des tests unitaires. J’ai commencé à construire ce genre de choses et à me rendre compte à partir de quel point mon appli était stable, ou non. C’est là que tu te poses des questions que tu ne t’étais pas posées avant. Je me suis rendu compte que j’étais devenu l’utilisateur de mon code.
César : Guillaume, pour rentrer un petit peu dans le détail, ça m’est arrivé à de très nombreuses reprises de discuter avec des gens pleins de bonne volonté, qui te disent : “Franchement, l’appli est tellement intestable, ça n’aura pas d’impact sur l’application”. Qu’est-ce que tu réponds au gens qui comprennent l’importance des tests, mais qui ne les applique pas ?
Guillaume : Alors, il y a plusieurs axes de discussion. Oui, ton appli est intestable, ça m’est déjà arrivé. Typiquement, sur la partie Natixis, j’ai rajouté des tests unitaires, mais je n’ai pas fait grand-chose pour faire évoluer l’architecture. Si on est tout seul sur le sujet, sans soutien, on a la pression de la livraison et ce n’est pas simple de prendre le temps de faire les choses correctement. Il faut voir ça comme un investissement. Cela étant, il ne faut pas tout refaire. Dans un refactoring de 3 mois, ça ne marchera pas d’une part parce que tu vas tout bousiller sans avoir fait de test, et d’autre part, parce que personne n’acceptera de payer quelqu’un 3 mois sans valeur ajoutée à la fin.
Quelle que soit la bonne volonté du client, même en nous laissant x mois pour refactorer, la pilule a quand même du mal à passer. Ce que je veux dire, c’est que cela dépend beaucoup plus que de la volonté et de la personne à vouloir faire de la qualité et plutôt du contexte client qui te laisse ou pas du temps. C’est plus simple de le faire dans une équipe plutôt que tout seul après. Avec le regard de plusieurs personnes, ça permet d’éviter la plupart des erreurs. Je ne sais pas si c’est avec le télétravail, mais l’année dernière, on a quand même réussi à beaucoup bosser à plusieurs. Il ne faut surtout pas isoler les développeurs. Je pense que Thomas avait dû mettre l’accent là-dessus sur le Pair Programming et pour moi, c’est clairement la clé.
Aujourd’hui, je travaille chez Louvre hôtels dans la même équipe que Thomas Pierrain et je pense qu’entre mars 2020 et juin 2021, on a réussi à être probablement plus productif que si on avait été en présentiel. Il y a eu quelques obstacles au début, mais on était bien organisé, même l’autre équipe qui s’occupait du front. Tu ne peux pas demander à des gens qui ne se parlent jamais de basculer en télétravail et en mode Pair Programing direct, ça ne fonctionnera pas. On était une équipe qui voulait aussi bien faire les choses aussi, ça explique beaucoup.
César : C’est un peu de l’expérience Coach Crafts, ça dépend un petit peu de la typologie du projet et du rôle qui est demandé. Mais justement, tu disais qu’on peut leur dire “On va faire de l’eXtreme Programming tout de suite”, comment est-ce que les choses peuvent se mettre en place quand t’as des gens qui sont plutôt bons volontaires, mais qui n’ont pas nécessairement l’expérience ?
Guillaume : Alors, un truc qui marche à tous les coups, mais qui pique un peu, ce sont les mauvaises expériences. Typiquement un problème de prod qui arrive avec un seul gars qui a travaillé dessus, et qui est en vacances, c’est compliqué. On galère tous pendant quelques jours, mais après, on s’en sort et on se dit peut-être que ce serait pas mal qu’on partage les connaissances. On se demande si, lorsque l’on démarre une nouvelle appli ou un nouveau projet, est ce que c’est bien nécessaire qu’un seul architecte soit dans son coin ? Qu’il donne les tâches et que chaque élève en prenne une dans son coin ? Est-ce que ça ne serait pas plus intéressant qu’on soit à 3 ou 4 en Mob Programming pour mettre en place l’architecture du projet ? Il y a des choses comme ça qui peuvent se mettre en place assez facilement.
César : Donc c’est vraiment d’abord dans une dynamique de partage des connaissances. De se dire, on ne va pas faire une architecture où seulement une personne comprend, et on va tous s’entraîner ?
Guillaume : C’est ça, c’est une sorte de collective ownership. Souvent, comme tout le monde connaît le sujet, tout le monde est légitime à prendre le lead sur l’architecture. Et donc après tu essayes d’étendre ça à d’autres projets. Pour ce qui est des tests, cela dépend aussi beaucoup de l’équipe. Il faut attendre le go du management pour le mettre en place. C’est d’ailleurs pour ça que c’est mieux de le faire en premier, pour mieux tester et mieux s’organiser. Le TDD et autres, faites-le, après il y aura des limitations. Aussi, le pair et le Mob peuvent apporter pas mal, il y a toujours quelque chose à gratter quand on a des gens volontaires à côté.
César : Mettons que tu aies la possibilité d’avoir un peu de temps pour refactorer une appli à priori pas testable, comment est-ce que tu t’y prends ?
Guillaume : Les tests ! Il faut partir du plus gros grain. De toutes façons, tu vas rarement livrer quelque chose sans avoir testé quoi que ce soit. Au pire, tu vas tester, ça va prendre 15 min, mais tu as un test end to end. Tu peux aussi juste tester le moteur avec du back-end. Il y a toujours quelque chose que tu peux tester, même si c’est inexécutable. Comme des Kata, des petits exercices de programmation, dont un qui s’appelle le Trivial Poursuit, je crois. l va aider à savoir ce que dit le programme, tu stockes ce qu’il dit, et dès qu’il y a une modification, tu lances le Kata. Comme ça, tu peux comparer et c’est un début.
Après, il y a du refactoring, avec de bons outils, comme ReSharper. Celui-ci, il permet de rendre le code plus lisible, c’est automatisé et on a tendance à avoir plus confiance en cet outil. Donc il faut commencer par tester le gros grain, la sortie du programme. Puis après petit à petit, on aiguise les tests, pour les rendre automatisables. Même s’il faut toujours rester dans le test du comportement. Il faut faire attention à les délimiter, pour ne pas avoir à tester toute l’application à chaque fois.
César : Pour revenir un peu à cette époque chez Natixis, tu rencontres les utilisateurs. Ensuite, la mission se termine, j’imagine en 2014. C’est quoi la prochaine étape pour toi ?
Guillaume : Fin 2014 oui. J’ai mis un peu de temps à savoir, parce que je ne comprenais pas vraiment ce qu’était le Crafts exactement. J’avais fait des Kata, etc. Mais la notion restait floue. Et là, j’ai eu la chance de tomber sur un ancien collègue, qui lui sortait de mission. Il me raconte qu’en 4 ans, ils ont tout déchiré. Ils ont fait une grosse transformation agile, du Scrum et autres. J’ai pu intégrer son équipe en le remplaçant et découvrir une équipe super à la SG CIB. J’ai énormément appris. C’était du TDD à fond, un manager au top, du Kanban, etc.
On a viré toutes les séances de poker planning qui nous cassaient les pieds. Enfin, on est vraiment parti sur une approche complétement Agile. On a adapté les méthodes, non seulement selon les besoins du client, mais aussi à la façon de fonctionner de l’équipe. C’est là que j’ai pu monter en compétences sur les bonnes pratiques. On était une équipe de 6-7 personnes.
César : D’accord. Et comment ça s’est fait, pour toi, la première approche de ces pratiques un peu tournées autour du TDD ? Dans ce contexte-là particulièrement.
Guillaume : Ça va dépendre de ta motivation. Moi, j’étais déjà intéressé par tout ça, donc j’étais demandeur. On faisait des Kata toutes les deux semaines, je commençais à pas mal aller dans les meetup et conférences et NCraft. C’est là que j’ai pris mes habitudes, j’étais à fond pour apprendre. C’était donc, le pairing, un peu moins de mobing, beaucoup de tests, et aussi le contexte du métier. On travaillait avec des traders dans le secteur de l’énergie, et il fallait passer une journée avec eux. Donc pareil que chez Natixis, pour comprendre leur utilisation, mais j’ai encore été gênée par des erreurs.
Par exemple, ils commençaient leur journée par un point, il se finissait 15 min plus tard, et seulement là, l’appli venait de se lancer. C’était vraiment toute cette ambiance, ces gros challenges qui nous ont poussés. À partir du moment où les développeurs et le métier arrivent à se parler, tu as fait une grosse partie du chemin.L’autre partie pour moi, cruciale, c’étaient les discussions avec l’équipe de développeurs. Les DevOps maintenant. Et pareil, si tu ne sais pas communiquer avec eux, tu n’avances pas.
César : Oui donc ce que tu dis, c’est que l’on ne code pas pour soi, mais pour les autres. Et ça implique plein de gens avec nous avec qui il faut échanger. Ça me fait penser en retour du Pair Programming, qu’il ne faut pas être dans sa bulle. Il faut être un développeur ouvert au métier, aux autres personnes techniques, et aux autres développeurs de l’équipe. C’est la meilleure manière de travailler.
Guillaume : C’est ça. Tu travailles avec des gens et pour des gens. Et avec des gens ne veut pas dire que l’équipe de développement. Cela veut aussi dire les utilisateurs en face. Gérer une prod, c’est un vrai métier. Et j’ai un peu honte de le rappeler, mais il y a tellement de développeurs qui se croient supérieurs. Il ne faut pas oublier de toujours se placer dans un contexte.
César : Est-ce que ce n’est pas un peu de l’overengineering tout ça ? Comme c’est un peu la devise des New Crafts de se replacer dans un contexte collectif. Cette notion de : « tout seul, je ne suis pas grand-chose, mais en embarquant tout le monde j’aurai plus d’influence ».
Guillaume : Oui c’est ça. Pas forcément en embarquant tout le monde, mais juste de discuter et de ne pas forcer. Par exemple, à partir du moment où l’on a commencé à communiquer, beaucoup de choses se sont réglées d’elles-mêmes. Pour finir, être développeur, c’est beaucoup plus de la com que de la technique. Et ça, beaucoup de gens ont du mal à l’envisager.
César : Petite question, ce serait quoi ton conseil aujourd’hui à un développeur, pour trouver les meilleures missions ? Les questions a poser dans un entretien, les formations, etc. ?
Guillaume : Il faut se répéter à l’avance ce que l’on veut. Quel est le job idéal, est-ce que c’est full présentiel, dans une équipe qui maîtrise l’agilité ou juste introduite ? Est-ce l’on est proche du métier ou non, si l’on a la main sur la prod, etc. ? Toutes ces questions sont fondamentales quand on veut changer de boulot. Si on est là juste pour apprendre des choses, ça coincera à l’entretien. À l’inverse, si l’on arrive et que l’on connaît tout, c’est nous-même qui allons-nous demander “mais pourquoi je suis là” ? S’il y a des freins au management, ou un manque de représentativité du métier, etc. Il n’y a pas vraiment de réponse universelle à ta question, c’est à chacun de trouver les siennes. Qu’est-ce qu’on a envie de faire ?
César : Ça me fait penser à une chose, il n’y a pas longtemps, j’ai fait un podcast avec une recruteuse tech, et elle me disait qu’il fallait faire un score card. C’est-à-dire identifier les critères selon nous les plus importants. De ton côté, c’est la même chose, mais d’un point de vue développeur. Et ce n’est que quand les deux côtés sont en accord que cela peut fonctionner.
Guillaume : Exactement. Après à garder en tête qu’il n’y aura pas forcément la mission idéale. Donc il faut prioriser nos envies : est-ce que c’est grave si je ne fais pas de TDD ? Ou autre. Il y a aussi la matrice santé. En gros, c’est une liste de nos compétences, et en fonction de la valeur de chacune de nos compétences, cela nous donne une base assez large où l’on peut se tester et se fonder. Il faut que tous les membres de l’équipe le fassent pour que l’on sache les compétences de chacun. À partir du moment où l’on a ça, je pense qu’on a un bon départ. On sait ce que l’on apporte, ce que l’on veut, et ce que l’on vaut.
César : Tu disais justement tout à l’heure, quand on parlait de qualité, qu’il peut y avoir des freins à certains projets. C’est quoi les plus gros freins ou anecdotes à ce sujet que tu as ?
Guillaume : Alors, en termes de frein, cela peut être à tout niveau. D’un point de vue technique avec des applications intestables, ou la complexité accidentelle, on peut en trouver. Pour la complexité, tu en rajoutes des couches et prends le risque de perdre les autres développeurs dans la foulée. Un peu comme les micro-services. Un autre frein, plus sur l’organisation, c’est la communication. Ça paraît évident, mais pourtant, ce n’est pas si simple. La mission dans laquelle je suis actuellement par exemple, nous n’avons pas d’échange avec le métier, les utilisateurs.
De manière générale aussi, tout ce qui est release management, etc. Mais sur le plan du management, c’est plus compliqué. Parce que cela dépend de leurs objectifs et des moyens qu’ils se donnent. Il peut y avoir des conflits d’intérêts. Ensuite, il peut y avoir des désaccords dans une vision. Par exemple un Product Owner qui était totalement axé métier et fermé aux problèmes techniques. Ça causait un turn-over énorme et la pression grandissait. C’est le genre de cercle vicieux à perdre en crédibilité et à empêcher la réalisation du projet. Aussi, être dans son coin, mais ça rejoint ce que l’on disait.
César : Si tu devais parler au Guillaume de Dassault, qu’est-ce que tu dirais ?
Guillaume : *rire* La première fois que j’ai entendu parler d’approche Test First, j’aurai peut-être du moins rigolé et plus m’y intéresser.
César : Tu penses que si tu l’avais su plus tôt, cela aurait changé quelque chose ? Ou qu’il te fallait passer par l’expérience dans tous les cas ? Parce que si demain, tu devais donner un conseil à un ou une développeur.euse, est-ce que tu souhaiterais en parler directement ou leur faire vivre ces moments-là ?
Guillaume : Oui l’approche test first est très importante, mais je dirai aussi que la technique est un piège. Faites attention à ce qui est dit de la part du métier. La technique, tu en apprendras toute ta vie, en revanche les besoins, les experts n’ont pas un temps infini. Ne vous laissez pas aveugler par tout ce qui brille comme les framework, le « CargoCult », etc. Aussi être moins négatif quand il y a des changements. Où l’on râle parce que le métier change, alors que c’est une bonne chose. Oui, sur le moment, on y a passé du temps, mais c’est la preuve que le métier vit et tente de comprendre son marché.
César : Tu parlais d’approche test-first, pourquoi est-ce que c’est si important pour toi ?
Guillaume : Tu te poses en tant que développeur pour quelqu’un. Tu n’es pas dans la machine de code, tu te poses des questions sur ton code. Tu prends du recul et ça, c’est très important. On veut toujours aller très vite, trop vite et l’on s’émerveille dès qu’un outil nous aide à aller plus vite. Mais il faut prendre du recul, le développeur a besoin de comprendre ce qu’il a écrit et ce qu’il fait, pas d’aller plus vite. Pour le TDD par exemple, c’est de la sécurité à long terme. Moi, c’est mon quotidien d’avoir des lignes rouges et de casser mon code. C’est normal et c’est super important. On comprend beaucoup mieux le code et le but.
César : Allez une dernière question, elle me titille. Qu’est-ce que tu rétorques au chef de projet qui te dirait “Mais voyons Guillaume, on doit livrer le 30 avril. Le TDD c’est bien, mais on n’a pas le temps”.
Guillaume : Cela va dépendre de mon niveau d’affection avec eux. Il y a le fameux triangle de fer de l’agile, avec les trois axes : Qualité, la Date et le Scope. Donc si tu veux garder la date, ok, mais on taille dans le scope. Même si tu as des ressources et dois rendre des comptes auprès de la hiérarchie et du budget, ce ne sont pas les pratiques, mais l’équipe le plus important. Il faut délimiter la valeur et la faire sortir, pour rassurer le chef de projet. Un peu comme une roadmap. Il faut se dire que sur, par exemple, ces deux semaines, on a traité ces sujets.
Maintenant, quels sont les nouveaux sujets prioritaires ? Mais il faut veiller à ne pas imposer de deadline dans la deadline, ce n’est pas toujours très sain. Et aussi évidemment, avoir une bonne communication avec ton équipe et le métier. Pas besoin d’être rythmé tout le temps, mais c’est bien d’avoir une routine. Il ne faut pas que ce soit un sprint, où tout le monde panique et néglige la qualité. Ça m’était arrivé chez Engie. On nous donne deux mois pour faire un projet de zéro avec la moitié de l’équipe en vacances. On est resté à 2 dessus, mais on s’est axé sur le Pair Programming, le Trunk Base Developpement et le TDD forcément. Pour rappeler comme ça, le Trunk Base Developpement, c’est qu’il n’y a pas de branche. Pas de branche, pas de pull request.
Ça a beaucoup de valeur, car tu as un retour direct quand tu codes. A grande échelle, c’est possible, il faut juste que les équipes soient d’accord entre elles. Et avoir une culture et une discipline. Oui, ça peut faire peur, mais il faut quand même avoir de l’appétence. Mais pour finir l’histoire d’Engie, on a tout de suite prévenu que les délais ne seraient pas tenus, en expliquant pourquoi. On l’a rendu un mois après la date d’origine et tout le monde était très content. Puis on a appris qu’il n’en n’aurait pas besoin avant septembre. *rire*
César : La leçon des joies du code ! En tout cas merci beaucoup Guillaume pour cet échange, on aura traité plusieurs sujets en dérivant un peu. *rire*
Guillaume : Eh bien merci à toi César !
Retrouvez-nous sur :
Linkedin , Blog , Twitter , et sur Spotify et SoundCloud pour écouter nos podcast !
