Pourquoi avions-nous la même discussion architecturale encore et encore à chaque sprint ? (Pourquoi Avions Nous La Meme Discussion Architecturale Encore Et Encore A Chaque Sprint)

Pourquoi avions-nous la même discussion architecturale encore et encore à chaque sprint ?

Je travaillais dans une startup technologique à croissance rapide à Istanbul. Une pause déjeuner, je suis allé faire un tour dans le parc avec le Senior Developer de l'équipe. Il me parlait avec enthousiasme des fonctionnalités de la prochaine application mobile, des nouveaux modules à ajouter et des présentations aux investisseurs.

J'ai écouté et posé cette question simple : « Alors, où est le schéma architectural ? Où documentons-nous ces décisions ?

Il m'a regardé avec un sourire. Il n’y avait aucun plan. J'ai parcouru un "Manuel d'architecture logicielle" du système, il n'y avait même pas un simple papier brouillon. La façon dont le manager posait sa tête sur l'oreiller le soir et se réveillait le matin avec une nouvelle idée a déterminé notre architecture ce jour-là. Une erreur momentanée du client a jeté tout le sprint à la poubelle. Le projet n’avançait pas, il tournait simplement au gré du vent. (En fait, je n’ai pas été surpris d’apprendre plus tard qu’ils avaient intégré l’IA dans ce projet du jour au lendemain parce qu’il était populaire.)

En me promenant dans le parc ce jour-là, j'ai réalisé que ce n'est pas le « mauvais code » qui fait échouer les projets logiciels. Qu'est-ce qui coule les projets ; C’était la vaporisation des connaissances architecturales. Nous prenions une décision, oubliions pourquoi nous l'avions prise, et 3 mois plus tard, nous reparlions de la même décision. Ce fut le premier front sur lequel j'ai déclaré la guerre en tant que leader technique.

Entêtement du « savoir tribal » des entreprises traditionnelles

Après avoir vu ce chaos, ma première question lors de chaque entretien que j'ai eu était : « Quel est votre processus de gestion de projet et comment prenez-vous des décisions techniques ?

Quelques années plus tard, j'ai obtenu un entretien avec le service R&D d'une entreprise manufacturière traditionnelle. Le manager en face de moi a commencé par remettre en question mon professionnalisme car je ne portais pas de costume. (Cependant, j’avais déjà effectué un travail critique pour cette entreprise de l’extérieur, il n’en était même pas au courant.)Je lui ai demandé s'ils utilisaient Jira, les processus agiles et la documentation technique. La réponse que j’ai reçue était la dure réalité de l’industrie : "Nous les avons essayés, mais ils ne nous conviennent pas. Nous notons qui fera quoi dans un cahier lors de la réunion et procédons en conséquence."

Même si l’embauche était approuvée, j’ai rejeté cette offre à ce moment-là. Parce que l'architecture et le destin d'un projet ne peuvent être confiés aux encres pâles d'un carnet de réunion.

Théâtre de décision et chaos opérationnel

Plus tard, j’ai participé à un grand projet de transformation logistique. Lorsque je suis entré dans le système, il m’a fallu un mois complet pour comprendre qui faisait quoi. La gestion de projet était nulle, la mémoire technique était nulle.

J'ai immédiatement retroussé mes manches. J'ai présenté le business model Agile, établi des sprints de 2 semaines, intégré Jira et introduit des stand-ups quotidiens. Tout se passait bien. Mais il existe une réalité dans le secteur privé : lorsque vous apportez de la transparence et de la mémoire institutionnelle au système, ceux qui obtiennent le pouvoir grâce au « savoir tribal » (les secrets qu'eux seuls connaissent) se sentent menacés.

Le mobbing a commencé. Ils ont essayé de me retirer le contrôle. À cette époque, les impressions ADR (Architectural Decision Records) que j'avais créées n'étaient même pas examinées. Après un sprint, le manager est venu et a dit "Je ne sais pas pourquoi on a modifié cette base de données comme ça !" dit-il. Tout était écrit, mais ils ne l'ont pas lu. Notre documentation s'était transformée en un "Théâtre de Documentation Décisionnelle".

C'est alors que j'ai réalisé : utiliser un seul outil (Jira, ADR) ne suffit pas. Vous devez injecter cet outil dans les veines cibles (OKR) de l'entreprise.

Le système qui met fin au chaos du projet : ADR (Architecture Decision Record)Aujourd'hui, nous exploitons parfaitement ce système dans l'infrastructure mondiale de la plateforme de commerce électronique que je gère en tant que Lead Developer (avec une équipe de 6 à 7 personnes). Quand j’ai démarré le projet, la confusion régnait encore ; Des problèmes étaient ouverts dans GitLab, mais « Pourquoi faisons-nous cela ? » Il n'y avait pas de réponse à la question.

J'ai inculqué l'esprit Agile à l'équipe et, plus important encore, j'ai mappé les principes ADR (Architectural Decision Record) de Michael Nygard directement aux objectifs trimestriels annuels (T1, Q2, Q3, Q4).

Alors, qu’est-ce que l’ADR et pourquoi sauve-t-il la vie de chaque ingénieur ? Les ADR sont des enregistrements immuables qui stockent non seulement ce qu'était une décision architecturale, mais aussi pourquoi elle a été prise et quels compromis ont été acceptés, juste à côté du code.

Lorsque nous prenons une décision maintenant, nous l'enregistrons avec ce modèle simple mais mortellement efficace :

Contexte : à quel problème sommes-nous confrontés ? (Ex : les requêtes de panier fatiguent la base de données.)

Décision : Que faisons-nous ? (Ex : nous utiliserons Redis Cache.)

Alternatives (négligence) : Qu’avons-nous éliminé ? (Par exemple : nous avons éliminé la mise à l'échelle de la base de données en raison du coût.)

Conséquences/Conséquences : Que risque-t-on ? (Ex : la latence des données diminuera, mais la complexité de l'invalidation du cache sera ajoutée.)

Résultat : Plus de "Pourquoi ?" Nous ne demandons pas

Aujourd’hui, lors des réunions de sprint ou des présentations de direction, personne ne demande « Pourquoi avons-nous procédé de cette façon ? » Cela ne le dit pas. Parce que sous chaque objectif se cache un ADR comme une porte.

Si un nouveau développeur logiciel rejoint l’équipe (Onboarding), nous ne lui expliquons pas l’architecture pendant des jours. Nous fournissons uniquement des journaux ADR. Nous disons : « Lisez notre histoire, comprenez quelles guerres nous avons menées et pourquoi nous avons choisi ces armes. »Le secret pour mettre fin au chaos ; Il ne s’agit pas d’écrire des codes fantaisistes, mais plutôt de « Pourquoi ? » derrière ces codes. question dans un héritage d’entreprise. Chaque décision architecturale non documentée est une dette technique à taux d’intérêt élevé que vous devrez payer à l’avenir. Effectuez le paiement aujourd'hui en enregistrant votre justification.

Chers amis architectes logiciels et responsables techniques ; Dans vos projets, les décisions se perdent-elles dans un désert Wiki, ou vivent-elles au cœur du code ?

Série de manuels d'architecture

#1 : Pourquoi avions-nous la même discussion architecturale encore et encore à chaque sprint ? (Cet article que vous lisez)

2 : Principes d'ingénierie qu'un architecte logiciel a appris de son expérience (article suivant)