Adoption des pratiques du craft par une équipe de 100 développeurs !

0:02 Benoît Ganto, comme il aime à se définir, est un artisan développeur, ce qui en dit long sur son approche du développement et plus particulièrement un de ses sujets fétiches qui est le craft at scale. D'ailleurs, il partagera son expérience dans la salle technique sur l'adoption des pratiques de craft dans des équipes de plus de 100 personnes. Salut à tous, je suis ravi d'être avec vous aujourd'hui. Cette présentation est enregistrée, mais si tout va bien, je suis normalement connecté et je répondrai à toutes vos questions juste après. Dans cette conférence, je vais vous partager un retour d'expérience sur la transformation d'une entreprise qui veut embrasser les principes de l'artisanat logiciel à l'échelle de toute l'équipe de développement. Alors, il y a déjà plusieurs choses à préciser. D'abord, c'est quoi pour moi l'artisanat logiciel, aussi appelé software craftsmanship en anglais? Et puis pourquoi y intégrer cette idée de passage à l'échelle? Je vais répondre à ces questions, mais avant ça, je vais me présenter. Je m'appelle Benoît Gantaume et mon parcours professionnel s'articule en deux grandes périodes.

1:05 La première va de 2000 à 2010 et se déroule dans une start-up, enfin plusieurs même. J'ai le plaisir de m'épanouir dans cet environnement qui correspond bien à mes ambitions, mais je me prends rapidement des murs. En effet, j'avais beau avoir une certaine facilité pour coder, au bout de quelques mois à bosser sur mon premier vrai projet, je suis submergé par le monstre spaghetti. Concrètement, l'application est instable. A chaque bug que je corrige, j'en rajoute trois. Je ne parle pas des estimations qui déraillent complètement. Chaque semaine est la dernière avant de boucler le dev de la V1. Sauf que cette semaine va durer plusieurs mois. Alors quand on finit par abandonner ce projet faute de débouchés commerciaux, j'en profite pour me faire une promesse, échanger radicalement ma manière de travailler. Je mange un livre sur l'extrême programming, je le lis plusieurs fois, des dizaines de fois pour certains passages, et à ce point que les feuilles se détachent tant j'ai usé le livre. Au bout de quelques semaines d'expérimentation, j'ai le déclic. Et à partir de là, rien n'est plus pareil.

2:08 Mon code devient robuste, les démos marchent, toutes. Et on finit par décrocher un beau contrat. Cette histoire va durer jusqu'en 2010. En 2010, je démarre une nouvelle carrière de consultant pour faire profiter les autres de ce que j'ai appris pendant toutes ces années. Et c'est dans ce cadre-là que j'en arrive l'année dernière à accompagner une équipe d'architectes convaincus par l'artisanat logiciel et cette équipe veut faire évoluer la culture d'entreprise. Alors, c'est quoi pour moi l'artisanat logiciel? On peut le définir comme une philosophie, une manière de concevoir le travail. On peut aussi le définir comme un ensemble de pratiques. Pour ce qui est de la philosophie, on peut s'appuyer sur les valeurs qui me semblent importantes. La fierté du travail accompli, une démarche d'excellence et un pragmatisme à toute épreuve. Quand je parle de fierté, je ne parle pas d'une fierté déplacée, arrogante, mais la satisfaction. du travail accompli. Vous savez ce sentiment particulier en fin de journée quand on est content de ce qu'on a fait dans la journée. Vous voyez de quoi je parle, enfin je vous le souhaite, j'espère en tout cas.

3:10 Pour ce qui est de l'excellence, ce n'est pas non plus une position arrogante de sachant, mais une démarche d'amélioration continue. C'est une attitude d'ouverture à la recherche de comment faire mieux chaque jour dans tout ce qu'on fait. Enfin, le pragmatisme est important pour contrebalancer les deux premiers points. Sans lui, on risquerait de se perdre dans des considérations techniques sans fin et faillir à notre mission. Notre job n'est pas d'écrire du code, mais d'apporter de la valeur ajoutée à nos clients par le biais d'un logiciel. Ça, c'était pour ce qui concerne ce qu'on pourrait appeler la philosophie. Pour les pratiques, j'ai essayé de commencer à recenser tous les mots-clés et il y en a beaucoup. Clean code, TDD, solide, binomage, refactoring, BDD, ATDD, couverture de code, métrique de code, intégration continue, guide flow, déploiement continu, design pattern, architecture hexagonale, revue de code, kiss, dry, mocking, stubbing, backlog, responsabilité collective, ubiquitous language, DDD, event storming, baby step, walking skeleton, unit test, scénario, gherkin. User story, no estimate, etc.

4:13 Et encore, je suis sûr d'en avoir raté beaucoup. Mon but là est de vous montrer que le craft regroupe beaucoup de choses et qu'on peut facilement s'y perdre pour un néophyte. Alors j'ai synthétisé ça en une phrase, pour moi le craft, c'est savoir écrire du code durable. Le code durable, c'est du code durable. code qu'on va pouvoir faire évoluer sereinement et à moindre coût au fur et à mesure du temps. En début de présentation, je vous ai parlé de mon parcours. Ce n'était pas juste pour parler de moi, mais pour planter le décor. Peut-être que vous aussi, vous avez des problèmes de stabilité de code. Peut-être que les délais sont rarement respectés, et ce, dans des proportions qui mettent le business en péril. Il existe aussi un symptôme que je n'avais pas vu à l'époque. Ce genre de projet a aussi le don de faire fuir les développeurs. Du coup, le turnover explose, ce qui n'arrange rien. Au contraire, et continue à dégrader la plupart du temps la qualité de la base de code. Chacun arrive avec sa manière de faire. Soit on passe beaucoup de temps à former les nouveaux arrivants, soit le code diverge et perd son homogénéité. Concrètement, tout ça a un impact direct sur deux choses très importantes à mes yeux.

5:17 D'abord, la motivation des équipes. Ce type de contexte génère beaucoup de souffrance. Ensuite, et ça c'est le deuxième point, la rentabilité de l'entreprise se dégrade très vite. Et là encore, les impacts sont très concrets. Pénalité de retard, contrat annulé, retard de trésorerie ou perte financière directe. Dans les cas les plus graves, le support et la maintenance au sens large prennent de plus en plus d'énergie. Je vois des équipes passer 20, 30 à 40% de leur temps à fixer des problèmes. Et le pire, c'est qu'ils finissent par trouver ça normal. Le stade terminal, c'est quand toute l'énergie disponible est absorbée pour maintenir le logiciel à flot. A ce stade, l'entreprise ne peut plus du tout faire évoluer son produit et se retrouve condamnée. La seule issue devient alors de tout réécrire, de tout refaire. Non seulement ça coûte une blinde, mais en plus rien ne garantit que l'on ne va pas se retrouver dans la même situation quelques années plus tard. Je dirais même a priori que c'est ce qui se passera si rien ne change vraiment. Les mêmes actions produisent les mêmes résultats. Sauf qu'avec l'explosion de technologies dont le cycle de vie s'accélère, combiné avec des modes dangereuses si elles sont mal employées, comme les microservices, la complexité évolue de manière exponentielle et explose.

6:28 Donc le mur risque d'arriver encore. plus vite la seconde fois que la première. Revenons-en à notre projet de transformation. L'entreprise qui m'a contacté s'approchait dangereusement d'un stade avancé. L'équipe comptait plus de 100 développeurs avec un renouvellement de 20% par an de ses effectifs. Alors oui, il y avait au sein de cette centaine de développeurs plusieurs passionnés qui poussaient les bonnes pratiques. Et c'est là qu'arrive le second point de la présentation. Pourquoi chercher à passer à l'échelle? Est-ce une réponse à la mode de l'agilité qui veut elle aussi passer à l'échelle? Non, pas vraiment. Le titre est un peu clickbait en fait, mais il y a un élément plus important. Quand tu améliores tes pratiques et que tu réalises que le niveau autour de toi est très moyen, qu'est-ce qui se passe? Soit tu espères faire progresser les copains et tu restes, soit tu vas voir ailleurs si l'herbe n'est pas plus verte. Et chez le client qui m'a appelé, il se passait quelque chose de terrible.

7:30 Après avoir passé plusieurs semaines, ou moins, à former quelqu'un à ses pratiques, la plupart partaient. Je ne sais pas si vous réalisez à quel point c'est épuisant. Aussitôt les futurs ambassadeurs formés, dès qu'ils prenaient conscience de la situation, ils préféraient tenter leur chance ailleurs. Impossible dans ce contexte d'atteindre une masse critique qui permette un changement global. D'autant plus que le chantier était énorme. Je vous laisse imaginer un projet qui a vu passer des centaines de développeurs pendant plusieurs années. Quel niveau de complexité le code peut avoir s'il n'y avait pas une culture technique forte et cohérente? Et comme tout le monde bosse sur un même pot de code, ça devient vraiment vite compliqué. C'est pour ça que la dimension à l'échelle est importante. Si vous cherchez à convaincre les gens un par un, vous risquez de les perdre. Et même s'il reste, ces pratiques n'ont de sens que si elles sont partagées par une majorité de développeurs. C'est là que j'interviens. Pourquoi m'avoir appelé moi? Tout simplement grâce au podcast Artisan Développeur. Depuis 2018, j'anime une émission de podcast qui compte aujourd'hui plus de 256 épisodes et cumule un demi-million d'écoutes.

8:36 J'ai créé un espace de formation en e-learning qui permet à des centaines de développeurs de progresser sur ces sujets. Ce sont ces outils qui ont motivé mon client à travailler ensemble car ils permettent de faire bouger les choses à l'échelle de toute l'équipe. Bon, si l'e-learning a l'avantage de bien passer à l'échelle, les humains, moins. Il ne suffit pas de dire aux gens... Voici un espace de formation, débrouillez-vous. Si vous faites ça, c'est l'échec assuré. Donc on a construit un parcours d'accompagnement équipe par équipe. Et le but de cette conf est de partager avec vous les résultats, les doutes et les interrogations que j'en garde. Mais avant d'entrer dans le détail de la mission, voyons ensemble ce qui motive en général les équipes ou les entreprises à passer au craft. On a d'abord l'objectif de supprimer les bugs. Et là, je parle bien de les supprimer, pas juste de les réduire. On vit encore à une époque où les bugs semblent normaux, alors que j'en vois qui font même des blagues, comme si c'était inéluctable et qu'il suffisait d'en prendre son parti. Je ne suis pas d'accord. Un bug, c'est anormal. Et c'est d'ailleurs bien pour ça qu'on l'appelle une anomalie.

9:38 D'ailleurs, quand j'arrive dans une entreprise, c'est intéressant de voir comment sont gérés les bugs. Il y a celles qui ne s'en occupent pas, mais en mode autruche, ils ne savent même pas que l'app est bugué et ne font aucun suivi. Autant dire que ces boîtes ne vivent pas très longtemps. Ensuite, il y a ceux qui s'en occupent. Ils s'en occupent tellement bien qu'il y a tout un process super évolué et des gens déconcertés. dédié à ça. On peut voir un backlog de bugs à résoudre et il y a toute une ingénierie autour de savoir si tel ou tel bug a tel niveau de criticité, est-ce qu'il est critique, quand il faudra le résoudre. Quand le suivi des bugs est un problème, c'est que l'entreprise a un méta-problème, c'est-à-dire un problème encore plus large dont le premier n'est que le symptôme. Et je vois un troisième niveau d'équipe, celle qui ne suive pas les bugs, tout simplement parce qu'il n'y en a pas. Ils ont des outils de suivi qui lèvent les crashs, qui notifient du problème, et puis quand un bug survient, ils résolvent le bug, point. Du coup, il n'y a pas vraiment de process de gestion de bug puisqu'il n'y a pas de bug à gérer. Donc oui, c'est possible d'avoir un soft sans bug.

10:40 Après, si vous partez d'une situation chargée, ça va prendre du temps, peut-être plusieurs années, mais c'est possible. L'autre but souvent poursuivi dans un passage au craft est de pouvoir accélérer les livraisons. Quand l'équipe est en maîtrise de son code, elle peut aller vite et rester véloce. Vous noterez que le souci n'est pas tant l'habitude initiale de délivrer, mais plutôt que celle-ci tend à s'allonger au fil du temps. On peut aussi chercher à améliorer la prédictibilité des équipes. Vous savez, cette fameuse question du« combien ça va coûter? » Alors oui, c'est vrai, il faut admettre qu'au fond, on ne sait pas vraiment. Et une estimation n'est jamais un coût, mais une estimation de coût. Par contre, je connais plusieurs équipes capables de prévoir ce qu'elles vont livrer à 20% de fiabilité, et même mieux parfois. Donc quand l'équipe met 2, 3... ou 4 fois plus de temps que prévu, et de manière répétée, c'est soit qu'ils sont mauvais, il faut appeler un chat un chat, et c'est plus souvent le cas, Ou alors c'est qu'ils ont perdu la maîtrise de leur code. Et ce n'est pas remettre en cause leur qualité de développeur que de dire ça, c'est simplement qu'à un moment donné, l'équipe perd la maîtrise.

11:47 C'est comme dévaler une pente à vélo, si vous n'avez pas de frein, même le meilleur cycliste va finir dans un mur. Autre motivation encore de passer au craft, on peut chercher à améliorer la satisfaction client. Pour ça c'est facile à imaginer, si on livre plus vite, en respectant les délais annoncés et sans qu'il y ait de bug, on peut imaginer que les clients vont être contents. En général ça se passe comme ça. Enfin, et non des moindres, on peut chercher à impliquer et fidéliser les développeurs. Je reviens là-dessus parce que c'est l'essence de mon engagement avec artisan-développeur.fr. Aider les développeurs à s'épanouir. Et le craft amène des choses très puissantes. J'ai ce mantra qui guide mon travail avec artisan-développeur.fr, le code durable rend heureux. Et en fait, mon client cherchait à progresser sur chacun de ces points. Alors venons-en maintenant à la mission en elle-même. La mission portait sur 4 équipes de 4 à 8 personnes. L'ambition était d'y aller par vagues pour arriver à terme à accompagner toutes les équipes, soit plus de 100 développeurs. Concrètement, comment on a fait?

12:48 Le cursus s'appuie sur 8 modules construits sur un arche pédagogique qui permet de graduellement augmenter le niveau de difficulté. L'idée était d'échanger avec l'équipe entre chaque module. On se rencontrait avec l'équipe. toutes les 2 à 4 semaines. Chaque rencontre était l'occasion de débriefer ensemble du module qu'ils avaient étudié. On voyait les points importants, c'était l'occasion de répondre aux questions qui avaient émergé, et puis on en profitait d'être ensemble pour faire des exercices d'entraînement. A la fin de la rencontre, je donnais accès au module suivant. On y allait comme ça, module par module, étape par étape. A mi-parcours, on a organisé un atelier d'une journée entière avec trois équipes sur les quatre pour mettre en pratique sur un format code retreat. On travaille toute la journée sur un même problème et on recommence toutes les 30 minutes à zéro en changeant de binôme. L'objectif central de la démarche était d'accompagner l'équipe à écrire des tests automatiques de manière systématique. En s'appuyant notamment sur le TDD comme outil, le Test Driven Development. C'est pour moi le cœur de la démarche craft. Le TDD, c'est cette pratique qui consiste à écrire le code en trois phases.

13:51 Phase 1, on écrit un test qui montre ce qu'on veut faire. En général, il échoue. Sinon, ça veut dire que ce qu'on veut faire est déjà implémenté. Phase 2, on écrit le code rapidement. Et phase 3, on refactorise le code pour qu'il soit tout propre. Voilà, vous connaissez le TDD. Mais avec le TDD, le souci est double. Il faut former les équipes et il faut un contexte propice. Je m'explique. Ce qui est terrible avec du code spaghetti, c'est que même si un jour vous décidez que c'est fini, ça y est, cette fois c'est bon, vous allez écrire du code propre et tester, c'est pas si simple. Un code spaghetti ne se laisse pas tester si facilement. Peut-être que vous avez essayé. On attaque l'idée d'écrire un test et on commence à tirer toute une pelote. d'objets en cascade et de dépendances qui rendent le test impossible à écrire. Il faudrait à ce moment sortir sa hache à dépendance, mais c'est super flippant et c'est d'ailleurs super dangereux. Sans une approche sécurisée, vous risquez bien de faire plus de mal que de bien et casser des choses qui marchaient très bien, parfois même sans vous en rendre compte. Donc en général, on a cette situation où il faut apprendre à faire des choses pas naturelles du tout, à savoir traduire son intention dans un test avant d'écrire le code de production, tout en le faisant.

15:00 dans un contexte pas propice du tout, voire carrément hostile. Il faut donc intégrer dans la démarche pédagogique le code existant non pas comme un frein, mais comme le point de départ. Et c'est pour ça que les premiers modules se concentrent sur des choses en apparence simples et basiques, pour permettre aux développeurs de gagner confiance tout en commençant à travailler le code pour le rendre testable. C'est pour ça qu'on commence avec quelques patterns de refactoring, des notions de base de conception objet, et on cherche à les mettre en œuvre le plus vite possible dans la vraie vie pour montrer que c'est possible de changer les choses. Enfin, quand on arrive au TDD, l'équipe est prête, du moins en théorie, pour passer à l'action sur du code de production. L'accompagnement se termine sur des sujets connexes qui viendront renforcer les pratiques déjà acquises. Bon alors quels sont les résultats que nous avons obtenus? Qu'est-ce que je referais pareil ou différemment? La question des résultats appelle forcément à réfléchir sur la mesure. Comment mesurer un changement de culture? Je ne crois pas trop à une mesure faite par un consultant externe.

16:01 Ça serait soit superficiel, soit extrêmement long à faire et donc extrêmement coûteux. Alors j'ai opté pour un autodiagnostic de pratique. L'idée est que chaque personne embarquée dans le cursus évalue ses pratiques au début et à la fin de l'accompagnement. Alors est-ce que cette mesure est biaisée? Oui, bien sûr. D'abord, il y a le biais de l'autoperception. Que ce soit volontaire ou non, on s'évalue rarement bien, surtout sur des sujets qu'on maîtrise mal. Ensuite, il peut y avoir une pression sociale. Ça fait mieux d'avoir un meilleur score. Et enfin, il est difficile, en une trentaine de questions, de saisir différentes subtilités. Donc l'idée n'était pas tant d'attribuer une note, mais de permettre à chacun de faire un point pour se donner une idée de sa progression. Et pour limiter les biais, les résultats n'étaient visibles que par le développeur lui-même et les données étaient agrégées au niveau de l'équipe. Est-ce que l'outil était parfait? Bien sûr que non, loin de là. Mais est-ce qu'il a rempli sa mission? Je dirais plutôt oui. Il a permis de dégager des tendances tout en montrant une évolution. Entre le début et la fin, on voit clairement une évolution positive d'ailleurs du niveau.

17:06 Ou plutôt, pour être exact, on voit clairement une évolution de la perception que chacun avait de son niveau. Vous pouvez voir ici en rouge le diagnostic initial et en vert le final sur une des équipes. On note clairement une progression. Alors oui, bien sûr, j'ai choisi le radar qui était le plus visuel et flatteur, mais la tendance reste la même pour toutes les équipes. Comment interpréter ce résultat? D'abord, c'est globalement positif. L'équipe progresse. Ça confirme d'ailleurs le ressenti plus qualitatif lors des échanges. Certes, le cursus n'est pas la seule source de cette amélioration, mais on peut dire qu'une nouvelle dynamique a été lancée. Clairement, il y a eu une prise de recul des développeurs qui se sont mis à se poser des questions différentes sur le code qu'ils produisaient. L'envie de creuser et de progresser est aussi venue. Est-ce que pour autant on a atteint tous les objectifs dont on rêvait? Concrètement, est-ce que le TDD est devenu une norme dans les équipes? Là, je dirais que c'est plus mitigé. L'idée de faire du TDD me semble avoir été acceptée comme quelque chose de positif et souhaitable, ce qui n'était pas déjà gagné en début de mission.

18:08 On a vu que les équipes s'y étaient essayées. Est-ce que c'est devenu systématique? Je ne pense pas. Et là, on arrive à une limite de l'accompagnement. À un moment, il faut aller sur le terrain avec l'équipe et manger du vrai code dans la vie courante. C'est là qu'arrivent les ateliers Vimavie qu'on avait prévus, mais Madame Covid est arrivée et a tout repoussé de quelques mois. Donc je n'ai pas encore de retour sur cette phase. Par contre, la pratique du code a clairement évolué. La relation au legacy est moins conflictuelle et les développeurs savent maintenant qu'ils peuvent faire bouger les choses et ils le font. Donc l'objectif que l'on s'était fixé de faire bouger les choses a plutôt bien été rempli. Toute la question est maintenant de savoir comment entretenir ce mouvement qui a été initié. C'est l'objet d'une nouvelle phase qui a pour but de former les futurs formateurs de l'entreprise pour transmettre la culture. Ça devrait se dérouler dans les mois à venir et je pourrais vous en dire plus l'année prochaine. Alors, qu'est-ce que je retiens de cette expérimentation? D'abord, l'ingrédient principal, le moteur de la démarche de changement, c'est vraiment l'équipe. Sa motivation impacte directement les résultats de la démarche, bien au-delà du processus d'accompagnement.

19:13 J'ai travaillé avec d'autres entreprises et avec des résultats très disparates. Certaines équipes sont arrivées à passer au TDD presque toutes seules, là où d'autres ont mis deux ans à appliquer les contenus juste des premiers modules. Je sais, c'est bateau dit comme ça, mais vraiment, si vous êtes CTO d'une boîte et que vous voulez... faire bouger la culture d'entreprise, la première chose à faire est de leur en donner envie. Sinon, vous allez dépenser beaucoup d'euros pour un retour sur investissement assez maigre. Ensuite, je note que ce type de changement aussi profond est vraiment long. On ne redresse pas la barre d'un code legacy vieux de plusieurs années en quelques semaines. Et le retour sur investissement va se faire sentir après plusieurs mois. Pour complètement assainir la situation, il faudra probablement quelques années. Donc c'est vraiment long. tellement que ça peut sembler désespérant. À quoi bon s'engager là-dedans si ça va être aussi long? Tout simplement parce que sinon les choses ne feront qu'empirer. Ce qui rend les choses encore plus difficiles à faire, c'est que sans KPI clair à court terme, c'est rarement motivant pour le management.

20:16 Donc si vous êtes CTO, je vous encourage à réfléchir à l'évolution de la culture technique sur plusieurs années. C'est quelque chose qui s'anticipe à l'avance parce que c'est vraiment lent à faire bouger. Voilà pour ce que j'avais à partager avec vous. J'espère que cette présentation vous a plu. Merci pour votre attention et à tout de suite pour la session de questions réponses.