#2 Les Retours d'EXpérience
C'est quoi un REX ? Je crois que c'est un chien. Ou un dinosaure.
⚠️ Lisez cette lettre dans votre navigateur pour profiter des corrections de dernière minute
Les liens marqués avec 🔒 sont accessibles seulement aux membres de M33Le pôle de formation Craft
Peu après mon arrivée chez Sipios, nous nous sommes demandé par quel chantier lancer le pôle de formation Craft.
La catégorisation des bugs sur un gros projet montre que 29% d’entre eux peuvent être attribués à une mauvaise conception du domaine métier. Autrement dit les développeurs ne maîtrisent pas les règles métier qu’ils formalisent.
It’s not stakeholder knowledge but developers' ignorance that gets deployed into production
— Alberto Brandolini
Nous avons donc estimé que sensibiliser les équipes aux notions du DDD (Domain Driven Design) apporterait une grande valeur.
J’ai accompagné quelques projets dans des ateliers d’event-storming afin de mettre en contact les experts métier et les experts techniques, poser les bases du langage ubiquitaire, le premier jet du workflow métier et délimiter clairement le scope du projet.
En parallèle nous avons formé les tech-leads aux patterns tactiques et à mettre en place des indicateurs sur leurs projets.
Nous allons y revenir…
Les gembas
J’ai eu l’occasion de faire un gemba sur l’un des projets que j’avais accompagné à un atelier d’event-storming.
Un quoi ?
Le gemba est une pratique du Lean qui consiste à ce que le management aille observer les équipes travailler. Les objectifs sont multiples : détecter les problèmes dont les équipes peuvent ne pas être conscientes (l’effet “grenouille dans la marmite”), renforcer la culture, questionner les standards… C’est une façon d’améliorer la qualité des produits par le respect des personnes.
Quel était le sujet ?
L’objet du gemba était d’observer comment l’équipe analysait un bug. Nous avons pu constater que l’analyse est allé très vite car chaque membre de l’équipe apportait son bout de connaissance sur le produit. La cause technique du bug a été identifiée sans ambiguïté en quelques minutes.
En temps normal les développeurs sont seuls sur un bug et l’analyse prend plus de temps. Les équipes ont encore des freins à passer en pair ou en mob.
Le gemba a également fourni un apprentissage sérendipitaire : le produit de l’atelier d’event-storming (le langage ubiquitaire et le workflow métier) n’ont pas été maintenus vivants. La connaissance métier est essentiellement dans la tête du Product Owner et fragmentée dans les tickets d’Epics et de User-story. Lorsqu’on se pose une question sur l’implémentation d’une règle métier on ne dispose pas de référentiel. Il faut avoir un sachant sous la main et avoir foi en sa mémoire.
… Voici donc un REX important pour moi : l’indicateur DDD mis en place n’est pas suffisant. Il faut aider les équipes à maintenir le workflow métier à mesure qu’on le découvre et qu’on ajoute des fonctionnalités et à enrichir le langage ubiquitaire.
Second REX : Aider les équipes à mieux travailler en équipe 😃. Pour cela je pense à utiliser mes créneaux hebdomadaires de pair programming.
TDD
Le TDD fait partie des premiers gestes à apprendre lorsqu’on ambitionne d’être un artisan du code. Par conséquent nous mettons l’accent sur ce geste lors des entretiens techniques.
Sur nos projets la couverture de test est généralement très bonne car nous outillons les projets pour cela. En revanche les résultats des tests de mutation laissent un peu plus à désirer.
REX : les équipes ne pratiquent pas suffisamment le TDD. Les nouveaux arrivants sont friands d’apprendre mais n’arrivent pas à acquérir les bons réflexes.
Notre move sera de mettre à jour la “Formation Commando” par laquelle passent les nouveaux arrivants.
Mes créneaux de pair programming vont également servir à évangéliser ce geste.
Enfin nous allons proposer la pratique du “1 commit par cycle de TDD”
Auto-apprentissage
LéoM & MahdiL ont produit un admirable système d’auto-apprentissage d’Angular avec un système d’auto-évaluation qui encourage l’entre-aide.
J’ai pu vivre une expérience particulièrement satisfaisante quand une équipe m’a sollicité au sujet des Observables et que j’ai pu la diriger vers ce système.
REX : Outre la satisfaction de relier des personnes qui ont un besoin aux personnes qui ont la solution j’ai pu gagner du temps (puisque je n’ai pas eu à former mes collègues) mais surtout les devs s’auto-évaluent et rendent visible leur expertise, permettant aux autres de savoir vers qui se tourner !
J’encourage fortement ce modèle 😉
Améliorer sa pratique
Dans la méthodologie Lean on parle de méthode 5S. Cette méthode s’applique aussi bien à la documentation, au code, aux emails, au poste de travail… Comme toujours le but est d’améliorer la qualité.
Ne se poser que les questions qui comptent
Avec des linters 😃
Les linters sont des outils d’analyse statique du code. Il permettent de renforcer les bonnes pratiques, de prévenir certains bugs, de formater le code…
Ces petits outils permettent de laisser le développeur se concentrer sur les questions importantes, les questions métier, qui apportent de la valeur au client.
Finis les interminables débats stériles sur comment faire l’indentation, où placer les accolades, import étoile ou pas…
La très intéressante présentation de YannN sur ce sujet :
Dans la méthode 5S les linters participent un peu à toutes les étapes :
Ils éliminent le besoin de formater manuellement le code. Les revues de code ne sont plus bruitées par les différences d’espacement, de saut de ligne etc.
Tout le monde s’habitue au même format de code et les yeux trouvent plus rapidement les éléments structurants (où sont les paramètres, où commence et se termine un bloc de code…)
La configuration du linter est de facto un standard et peut être facilement partagé entre les équipes et est facile à faire évoluer.
Bien ranger la documentation
You should name a variable using the same care with which you name a first-born child
Ce conseil de Robert Martin s’applique tout aussi bien au titres de votre documentation surtout si votre base documentaire est munie d’une fonction de recherche (comme Notion, Confluence, Obsidian…).
De plus il faut savoir où placer la documentation dans une hiérarchie. De multiples systèmes de classification existent.
S’ajoutent à ça des métadonnées (tags dans les favoris par exemple).
Ainsi quand on écrit une documentation il faut soigneusement étudier l’organisation de la documentation existante et exploiter tous les outils du système documentaire.
Un bon test est d’ouvrir la barre de recherche, tapez le sujet principal de votre doc et voyez si elle arrive en première page.
La méthode 5S nous encourage à maintenir et bien ranger la documentation. Malheureusement nous n’avons pas encore la technique qui nous permet de le faire de façon standardisée et automatisée.
Veille
JaCoCo est un outil formidable mais il a aussi d’attendrissantes faiblesses. Ce bug en particulier m’a contrarié en m’empêchant de transformer un bête switch en “switch expression” en réduisant par erreur la couverture de test :
Sur le thème de la Qualité Radicale, comment gérer les bugs ? (JaCoCo 😉😉)
IntelliJ 2022.3 vient de sortir ! Une pléthore de nouveautés à découvrir !
Et puis je ne peux m’empêcher de vous partager la verve de José Paumard au sujet du pattern matching en Java (dans les boucles for 🤩 et pourquoi pas partout où on déclare une variable ?)
Puzzler du jour
La réponse au puzzler précédent
Il fallait répondre :
2022-10-30T00:30:00Z
Pourquoi ? Comme souvent la réponse est dans la Javadoc !
For Overlaps, the general strategy is that if the local date-time falls in the middle of an Overlap, then the previous offset will be retained. If there is no previous offset, or the previous offset is invalid, then the earlier offset is used, typically "summer" time.
Comme on pouvait s’en douter le choix est arbitraire mais bien documenté.
25, 24, 23…
Décembre frappe à la porte. Qui fera le meilleur score à l’Advent Of Code ?
