Design Review et Atelier de conception.
L’architecture d’un logiciel c’est primordial.
La durée de vie votre logiciel dépend de votre architecture et des choix techniques.
La “scalabilité” et la stabilité de votre logiciel dépendent de l’architecture de votre infrastructure, mais également de l’architecture de votre code applicatif.
À la question, “Qu’est-ce qu’une bonne architecture ?”
Martin Fowler répond: “Une bonne architecture est une architecture qui supporte sa propre évolution”.
⏳ Seul le temps vous dira si vous avez une bonne architecture et si vous avez fait les bons choix techniques.
En général, les équipes techniques savent répondre assez facilement aux défis techniques qu’elles rencontrent puis il arrive qu’elles rencontrent une fonctionnalité complexe à développer, une fonctionnalité que l’on peux résoudre de différentes manières, chaque approche offrant des avantages et des inconvénients.
🧠 Le casse-tête commence et dans ces cas-là, j’aime dire que nous choisissons la moins pire des solutions 🙈, l’occasion pour moi de ressortir un de mes proverbes préféré : “la plus sucrée des 2 (“solutions”) est amère” 😅.
Au -delà de l’expérience et des compétences intrinsèques de vos équipes technique, bien souvent, ce qui aide à trouver la bonne solution, c’est le travail collaboratif.
📖 Les 3 petits cochons
Vous connaissez sûrement l’histoire des 3 petits cochons ?
Dans mon livre, les 2 premiers cochons n’ont pas assez réfléchis sur la solution technique, ils n’ont pas étaient assez challengés par le 3e cochon sur leur choix technique 😁.
💡 Dans l’histoire des 3 petits cochons leur mère leur dis bien de prendre garde au Loup, mais seul le 3ème cochon imagine que le loup sait souffler très fort ! 🙀
🏀 La Collaboration
La collaboration dans le monde du design est très fréquente. En effet, il est très fréquent que les designers organisent des ateliers pour réfléchir à l’implémentation et l’UX d’une nouvelle fonctionnalité.
La forme peut varier, mais le fond reste le même avec un concept simple. On organise une réunion au cours de laquelle on explique le besoin fonctionnel, on lance un chrono et chaque personne gribouille sa solution puis nous faisons un tour de table afin de confronter les idées, on réagit, on commente, on note les remarques… Ensuite, on affine pour conserver les idées qui ont le plus de succès auprès de l’assemblée.
🎯 L’objectif est de donner le maximum d’idée pour permettre le design de la fonctionnalité.
Personnellement, c’est un atelier auquel j’aime beaucoup participer et je vous encourage à l’essayer dans vos équipes, cela renforce la cohésion et augmente “l’ownership produit” particulièrement celui des équipes techniques.
🔬 Appliquons cet atelier aux équipes techniques
Côté “engineering” nous faisons très souvent des design review, concrètement un.e developpeur.se va prendre l’ownership d’une fonctionnalité et avant de développer quoi que ce soit, la personne va documenter les impacts techniques, les changements dans la codebase, ajouter des diagrammes…
📝 Elle va noter tout ce qui va aider à comprendre le développement et faciliter la code review. Ensuite cette design review est partagée et présentée aux différentes équipes puis place au développement 🚧 🛠️
Le workflow classique est le suivant :
Le principal inconvénient de cette approche est que la responsabilité de la solution technique repose sur les épaules d’une seule personne et ceci n’est pas infaillible, rappelez-vous des 2 premiers cochons qui n’ont pas consulté le 3ème.
Quand bien même plusieurs devs réfléchissent ensemble, les plus expérimentés ou ceux/celles qui ont le plus confiance en eux vont influencer les autres et vous n’aurez pas de réelle confrontation d’idée.
De plus, énormément de devs ont besoin de focus un bon moment pour cerner un problème. Relire une design review n’est pas suffisant pour se plonger dans la problématique et envisager différentes solutions.
Certains ont besoin de faire un POC pour valider et/ou écarter certaines hypothèses, d’autres ont besoin de faire des recherches...
J’ajoute que d’expérience, j’ai rarement vu une Design review complètement remise en question ou refusée.
🎨 L’atelier de conception technique
Pour l’implémentation d’une brique technique complexe nous avons fait un mélange entre un atelier de conception et une design review.
Chaque développeur a réfléchi à différentes solutions avec 2 contraintes :
- Un temps de réflexion restreint à 2,3 jours (évidemment à revoir selon la complexité de la feature).
- Ne pas regarder les travaux en cours des collègues pour ne pas être influencé et ne pas les influencer.
Par la suite, nous avons organisé une session de présentation, chaque personne décrit sa solution en détail avec des schémas, des exemples de code… Puis réponds aux questions qui lui sont posées.
Durant cette session, il est important de prendre une posture critique et de challenger au maximum les propositions.
L’objectif est de mettre en exergue les inconvénients et faiblesses de chaque solution et d’évaluer les trade-offs le cas échéant.
Pour fluidifier les discussions, il faut un animateur capable de cadrer la réunion, faire respecter le temps de parole, faire le scribe… Il faut que l’animateur soit capable de suivre les discussions techniques et dire franchement lorsque l’on tombe dans de l’over-engineering…
Personnellement, j’ai regardé et commenté les solutions avant le jour de la présentation histoire de gagner du temps et de poser certaines questions en amont.
Pour les participant.e.s, il est important d’accepter que ses idées soient critiquées et de savoir écouter les autres. J’ai le plaisir de travailler avec des devs qui, en plus d’être bons techniquement, savent que l’on dev pas pour se faire plaisir et tester des patterns, mais que l’on dev pour répondre à un besoin métier et/ou une problématique business 😚.
Lors de la réunion de restitution de nouvelles idées ont émergées 🎉 et au final, c’est un mix des solutions qui a été accepté.
Effet Kiss-cool, toutes les personnes qui ont réfléchis à l’implémentation technique se sont bien emparés du sujet, de plus tout le monde est sur le même niveau d’information et d’implication 🤝
À retenir :
- Différentes personnes réfléchissent de manière isolée à une solution technique durant un temps restreint.
- Les solutions sont présentées et “challenger” au maximum dans le but de mettre en exergue les avantages et inconvénients.
- L’animateur de la réunion veille à faire respecter le temps de parole et à établir un consensus autour d’une solution.
- La Design review est créée à partir de la solution retenue.
- C’est parti pour le Dev 🚀💻
Je suis très content des résultats et de l’émulation créée grâce à cet atelier, néanmoins il est bon de noté que cette approche est coûteuse, en terme de ressource et de temps.
Je pense qu’il convient de l’utiliser sur des features complexe, celles qui soulèvent beaucoup de question 🧐.
👋 Voilà pour ce retour d’experience, preneur de vos feedback et si vous voulez rentrer en contact c’est par ici 📬.
