Expériences - Craftech

Voici une lise détaillée de mes expériences passées sur les 10 dernières années, qui me semblent plus significatives et représentatives que ce que j’ai pu faire avant.

2020-2024 : approche produit et utilisation concrète du Domain-Driven Design

Contexte : en changeant de domaine chez un client dans l’hôtellerie, dans l’équipe de Thomas Pierrain, j’ai pu améliorer et renforcer des connaissances autour des tests et comment mieux refléter le métier au coeur du code, pour ensuite prendre une dimension supplémentaire en impactant durablement les process de notre équipe mais aussi ceux du département.

Concrètement : malgré un contexte sanitaire compliqué pour le secteur hôtelier et grâce à un client solide, j’ai pu travailler efficacement au contact des experts métier afin de maximiser la livraison de valeur ajoutée pour nos produits (dont notamment le backend des sites web publics) :

sur 2 projets différents en 2023, j’ai mis en place un mode de fonctionnement basé sur le partenariat, la discussion, la pédagogie, la confiance et la transparence. Les relations avec les équipes métier et le management s’en sont trouvées grandement améliorées durablement, avec 2 livrables solides livrés en production de façon fluide avec peu voire pas de bug. Étant conscient des dégâts pouvant être occasionnés par la complexité accidentelle, j’ai limité au maximum le code et les dépendances inutiles ou trop techniques. Mes compétences de communication et de vulgarisation ainsi que la solidité et adaptabilité de notre code ont été saluées par les équipes produit.
Au sein de l’équipe, j’étais partisan d’adopter un état d’esprit orienté produit en utilisant des méthodologies de type flux (avec des bases de Kanban) afin de réduire le TTM (Time to Market) et d’améliorer la valeur métier de nos livrables. Certaines cérémonies issues de Scrum ont été conservées (rétro, stand up meeting) mais d’autres comme le sprint planning ou le grooming ont été remplacées par des réunions au fil de l’eau avec les experts produit où ceux-ci nous présentaient les user stories à venir accompagnées d’exemples et du contexte métier global. Nous étions alors en capacité de discuter de chaque point pour mieux comprendre ce qui était attendu et réduire voire supprimer les incompréhensions. J’encourageais les discussions régulières avec les experts métier afin d’éliminer les ambigüités et éviter les bugs ou les corriger avant qu’ils n’arrivent en production. Le point essentiel ici a été de demander aux autres développeurs de passer plus de temps dans l’espace du problème que dans l’espace de la solution. Par cette approche, j’ai nettement contribué à améliorer la relation entre notre équipe et celles situées au niveau business grâce à ma transparence, ma communication et la qualité de mes livrables.
utilisation de l’architecture hexagonale afin de faire dépendre le code technique du code purement métier et non l’inverse.
mise en place de tests d’acceptance plutôt que de tests unitaires afin de tester toutes les briques du code concernées par un scénario métier particulier. Développement de builders au sein d’une architecture avec dépendances complexes ; puis passage à un système de scénarios utilisant une API fluent et un paradigme plus fonctionnel pour se débarrasser du code déclaratif inutile. Utilisation de fuzzers pour générer aléatoirement des données de test.
gros chantier d’amélioration des performances sur la brique “prix et disponibilités” du backend de nos sites web. Résultat après plusieurs semaines de travail : réduction de 30% du temps d’attente utilisateur, diminution d’un facteur 5 du nombre d’appels entre services.
organisation de séances d’Event Storming avec les experts métier et divers intervenants techniques (devs, tech lead, staff engineer…) afin d’aligner des modèles et partager le même vocabulaire pour supprimer les confusions récurrentes et les implicites.
mise en place de plusieurs pratiques issues de l’eXtreme Programming : pair/mob programming, collective ownership (pour casser les silos et éviter le “bus factor”), conventions de code…

Les points positifs : de nouvelles façons de fabriquer des tests plus compréhensibles par des personnes non techniques, une confirmation que l’approche produit est nettement supérieure à l’approche projet pour construire un produit de qualité générant de la valeur métier.

Ce que je corrigerais avec le recul : lors d’une migration technique imposée, le passage forcé en mode projet avec planning et grosse pression du management a eu un impact négatif sur le produit, l’ambiance de l’équipe et la productivité. J’aurais dû prendre les devants et mieux communiquer en amont plus tôt dans le projet afin de rassurer le management sur notre avancement.

2017-2019 : développement de compétences DevOps et force de proposition

Contexte : j’ai cherché à consolider les acquis des 2 années précédentes afin d’aider mes clients à optimiser la valeur apportée par les projets informatiques. J’ai pu participer à un grand projet de refonte du système d’information chez un grand compte de l’énergie.

Concrètement : pendant plus de 2 ans, j’ai pris plusieurs actions afin d’améliorer la façon de travailler et de s’approprier nos outils de développement :

tech lead de facto sur un projet critique : approche test driven, mono repo et trunk based avec livraison semi-continue (jusqu’aux environnements pré-production où nous n’avions pas la main). Le périmètre complet du projet a été développé en 2 mois à 4 personnes (ETP de 2 personnes environ), avec très peu de bugs grâce à la bonne couverture de tests ainsi qu’à la séniorité et la rigueur de l’équipe.
mise en place d’un serveur de build dédié à l’équipe. Auparavant, un autre serveur existait mais mutualisé pour tout le département et avait des limitations qui nous ralentissaient (pas assez de processeurs, espace disque limité). Il m’a paru important que l’équipe reprenne la main sur ce sujet crucial afin de se libérer des contraintes induites par l’ancien mode de fonctionnement.
automatisation de tâches régulières chronophages et sujettes à erreur de part l’intervention humaine. Notamment une tâche qui prenait auparavant plusieurs heures s’est transformée en un lancement de script de moins d’une minute et une pull request.
animations de katas autour du TDD sur le temps du midi, 1 fois par semaine pendant 6 mois.
référent sur Git et le modèle de branching proche de Gitflow.
migration de Team Foundation Server vers Azure DevOps. Référent Azure DevOps pour l’équipe.
remise en question permanente de la méthodologie, dans un but constant d’améliorer la qualité de fonctionnement de l’équipe et des livrables.

Les points positifs : belle montée en compétences “DevOps” dans un esprit de mieux maîtriser nos outils jusqu’à la livraison en production : Azure DevOps, serveur de build, livraison, archivage et versionnage des binaires.

Ce que je corrigerais avec le recul : savoir mieux reconnaître les batailles perdues d’avance.

2015-2016 : montée en compétences sur le software crafting : force de proposition chez le client

Contexte : dans une grande banque d’investissement, grâce à une prise de conscience au niveau du top management et une très bonne équipe, j’ai pu découvrir et développer des compétences craft pour ensuite devenir force de proposition sur des sujets impactants.

Concrètement : une excellente synergie dans l’équipe où je suis arrivé m’a permis de monter en compétence sur :

TDD via la pratique régulière de katas,
BDD et comment tirer le meilleur d’une discussion avec des experts métier,
DDD pour réduire les couplages forts qui handicapaient nos applications,
l’agilité pour éviter de se retrouver coincé dans une méthodologie en l’appliquant sans la remettre en question (notamment sur le sujet des planning pokers et autres techniques d’estimations coûteuses),
les valeurs du craft de manière générale, notamment l’amélioration continue et le partenariat avec les utilisateurs, dans la lignée de ce que j’avais vu lors de ma mission précédente.

Suite à cela, j’ai pu mener 2 actions concrètes :

sur le plan de l’agilité et de l’organisation de l’équipe en général, j’ai proposé de passer petit à petit vers un modèle plus basé sur le flux (ex : Kanban) plutôt que de rester sur du Scrum avec lequel certaines cérémonies ne me paraissaient pas adéquates. On a fini par alléger puis supprimer les points de sprint planning qui étaient à la fois ennuyeux pour les intervenants métier et peu utile pour les intervenants IT.
sur le plan technique, pour donner des pistes concrètes de solution au code legacy lourd auquel nous faisions face, nous avons démarré avec 2 collègues sur notre temps libre un prototype visant à mieux séparer les responsabilités de plusieurs composants. Cette initiative a rencontré un vif succès auprès du management mais n’a pas été continuée par la suite par manque de budget.

Les points positifs : ce fut pour moi une période charnière où j’ai pu réaliser l’étendue de l’existant en termes de bonnes pratiques (craft, agilité…). Ce sont des choses qui ont profondément changé ma façon de travailler et ma relation avec mes collègues, qu’ils soient utilisateurs, développeurs ou managers.

Ce que je corrigerais avec le recul : je modèrerais probablement mes envies et mes attentes. J’ai fourni vraiment beaucoup de travail à cette époque, surtout si l’on ajoute les à-côtés pour mon employeur (cf section suivante). J’ai fini par connaître une grosse fatigue et le changement de chef de projet en 2016 a porté un coup dur à ma motivation.

2015-2016 : montée en compétences sur le software crafting : force de proposition chez mon employeur

Contexte : découvrant les valeurs de l’agilité et du craft, je me suis demandé pourquoi personne n’avait essayé de promouvoir tout cela en interne à mon ESN alors que nous étions plus de 120 collaborateurs. J’ai donc monté diverses actions pour sensibiliser la plupart des corps de métier à ces sujets qui me semblaient être l’avenir voire le présent chez les acteurs IT.

Concrètement : en un peu plus d’un an et demi et avec l’aide de mon responsable, voici les actions qui ont été entreprises :

présentations sur le TDD, le software crafting, Clean Code. Ces présentations avaient lieu le midi dans les locaux de mon ESN ; une quinzaine de personnes assistaient à ces présentations en moyenne.
invitation d’intervenants externes reconnus sur divers sujets autour du craft. Live coding, refactoring de code legacy, etc…
présentation aux internes (commerciaux, direction générale, RH) de notre vision de l’évolution des métiers autour du développement logiciel. Craft, coach, DevOps… autant de mots-clés qui sont aujourd’hui monnaie courante mais ne l’étaient pas forcément en 2015.
présentation du craft puis atelier pratique chez d’autres clients, en partenariat avec eux. Nous avons repris divers éléments de nos présentations en interne pour les appliquer dans un atelier avec un kata.
création de supports visant à mettre en place un cursus de formation craft pour les nouveaux arrivants. 2 supports ont été créés mais la formation n’a finalement pas vu le jour.
organisation de code retreats lors du Global Day of Coderetreat en 2015 et 2016. À chacune des dates, une dizaine de personnes sont venues participer.
accord avec les RH pour mettre en place le système “une conférence par an”, dans lequel chaque collaborateur a le droit de participer à la conférence de son choix au titre de la formation.
officialisation du compagnonnage, une structure permettant d’accompagner chaque collaborateur dans sa progression et de le récompenser pour ses contributions en interne.

Les points positifs : j’ai beaucoup appris et j’ai vraiment eu l’impression d’aider d’autres personnes à s’épanouir dans leur vie professionnelle.

Ce que je corrigerais avec le recul : comme dans la section précédente, je m’emballerais moins et diminuerais probablement ma charge de travail.

2012-2014 : initiation à l’agilité et la livraison de valeur via le contact direct avec les équipes métier

Contexte : chez un client de l’asset management, je travaille sur plusieurs projets et suis notamment responsable technique d’un projet de suivi pour le Middle Office.

Concrètement : j’ai pu apprendre les vertus de travailler en direct avec les utilisateurs ou un de leurs représentants, sans intermédiaire et avec une approche respectueuse de chaque côté. On a ainsi pu piloter les changements rapidement, avec livraisons rapprochées sur des environnements de test afin de livrer de la valeur pour les utilisateurs. On retrouve ici plusieurs piliers de l’agilité et du software crafting : individus et interactions, collaboration avec le client, réponse au changement, partenariats productifs, ajout de valeur.

Les points positifs : j’ai pu appréhender sans le savoir une approche concrète de certains points prônés par les méthodes agiles. Je suis ressorti de là avec le sentiment d’avoir réellement pu aider les utilisateurs dans leur travail quotidien et développer une vraie relation entre le métier et l’IT.

Ce que je corrigerais avec le recul : je ferais probablement des points formels un peu plus rapprochés ; on avait une réunion hebdomadaire d’une heure alors que des points de 10-15 minutes 3 fois par semaine auraient été à mon sens plus appropriés. Du point de vue technique, je ne connaissais pas encore les pratiques comme TDD, le BDD et encore moins le DDD, qui m’auraient permis d’aller plus loin à la fois dans la fiabilité de l’application et son architecture.

Avant 2012 : prise de conscience

Contextes : de la startup aux grands groupes, en interne ou en prestation, j’ai pu voir des environnements très divers et me forger ma propre opinion sur la qualité des pratiques utilisées.

Concrètement :

une expérience de plus de 6 ans chez un grand éditeur français m’a permis à la fois de voir l’importance des tests automatisés et d’un process de livraison clair, malgré l’utilisation à l’époque d’une approche très waterfall. J’ai aussi pu constater que réinventer la roue était rarement très utile ou profitable…
ensuite, mon premier contact avec le monde de la finance m’a fait prendre conscience que toutes les équipes IT ne portaient pas la même attention à la qualité ! Heureusement, un management compréhensif a pu me donner les clés pour avancer sur plusieurs sujets de stabilisation applicative et assainir les relations avec les équipes Ops. J’ai là aussi pu découvrir les vertus du blue/green deployment, ce qui nous a permis de livrer en journée sans interruption de service ni pression dans un environnement international exigeant.
l’expérience suivante dans un cadre où le legacy était très présent m’a montré combien il pouvait être difficile de mettre la qualité en avant dans une organisation où l’urgence était la norme depuis des dizaines d’années. En fin de mission, j’ai pu émettre une liste de recommandations qui allaient dans le sens de l’intégration continue, de la philosophie aujourd’hui connue sous le nom de DevOps, utilisation des standards (pas besoin de développer tout en interne), investissement dans les tests automatisés, implication plus forte du métier dans le process pre-release (UAT, specs…), etc…

Les points positifs : je m’aperçois aujourd’hui que j’ai bien mûri à l’époque et pu apprendre au fur et à mesure de chacun de mes postes pour commencer à être force de proposition chez mes clients.

Ce que je corrigerais avec le recul : beaucoup de choses :) Probablement l’arrogance de mes débuts, commune à beaucoup de juniors dans notre métier. Et aussi avoir ignoré si longtemps d’investiguer la piste du TDD malgré plusieurs signaux tout au long des années ; je pensais que la séniorité demandait plus d’expertise technique et ne m’intéressait pas à la méthodologie ou aux pratiques de travail. J’avais tellement tort !