Système de décision qui met fin au chaos du projet : enregistrement de décision d'architecture (ADR) (Systeme DE Decision Qui Met Fin Au Chaos Du Projet Enregistrement DE Decision Darchitecture Adr)

Système de décision qui met fin au chaos du projet : enregistrement de décision d'architecture (ADR)

Le plus gros problème des projets logiciels modernes n’est souvent pas la qualité du code. Le véritable danger vient d'un endroit bien plus insidieux : Décisions oubliées.

La grande majorité des équipes d'entreprise gèrent encore les décisions architecturales qui déterminent le sort du projet au niveau « Nous en avons parlé lors de la dernière réunion ». Cependant, à mesure que le projet grandit, que l’équipe change et que le temps passe, ces réunions s’estompent.

Ces questions ennuyeuses demeurent :

* « Pourquoi avons-nous fait de ce système un microservice, qui a décidé ? » * « Pourquoi avons-nous choisi cette base de données, avons-nous cherché des alternatives ? »

• " Avons-nous prévu ce problème que nous vivons actuellement ? "

Si vous n'avez pas de réponse claire à ces questions ni de document à présenter ; Cela signifie que votre projet dérive dans le chaos technique.

À ce stade, le système ADR (Architecture Decision Record) entre en jeu, ce qui évite au projet de dépendre des personnes.

Qu'est-ce que l'ADR ? (Pas un document, mémoire architecturale)

ADR est un système dans lequel les décisions critiques prises dans les projets logiciels sont enregistrées de manière courte, claire et permanente. Mais ne confondez pas cela avec une documentation technique ennuyeuse.

Chaque ADR est un enregistrement live qui répond à 4 questions fondamentales :

1. Quelle décision avons-nous prise ?
2. Pourquoi l'avons-nous acheté ? (Quel était le contexte ?)
3. Quelles étaient les alternatives ? (Qu'avons-nous éliminé ?)
4. Quels sont les compromis ? (Qu'est-ce que cette décision nous coûte ou nous risque ?)

L'ADR est la "mémoire" de votre projet. Le code peut changer, la technologie peut changer, même le CTO peut changer ; mais la logique des décisions reste dans le projet grâce à l'ADR.

Différence critique entre la tâche et l'ADR

De nombreuses équipes font l’erreur de penser que les tickets ou les tâches Jira sont des « décisions ». Il existe cependant une énorme différence entre eux.* Tâche : "Faites ceci", dit-il. Il est orienté vers l'action.

• ADR (Décision) : "Pourquoi faisons-nous cela ?" dit. Il est orienté stratégie.

Expliquons avec un exemple simple :

• Tâche : "Améliorer les points de terminaison du panier." (Cette tâche se termine et est archivée.)
• ADR : "La structure du panier doit-elle être un service distinct ou doit-elle rester au sein de l'application principale ?" (Cette décision affecte l'architecture du projet pendant des années.)

La tâche se termine, l'ADR est actif.

À quoi ressemble un ADR ?

La rédaction d'ADR n'est pas un travail qui prend des jours. Cela nécessite plutôt de la clarté. Voici un modèle ADR simple et efficace :

ADR-007 : Utilisation du cache Redis

Statut : Accepté

Contexte : Les temps de réponse des API ont augmenté et la charge sur la base de données a commencé à augmenter. Les opérations de lecture sont bien plus nombreuses que les opérations d’écriture.

Décision : Le cache Redis sera utilisé sur les points de terminaison fréquemment lus.

Alternatives : L'optimisation de l'index de base de données ou l'utilisation de CDN ont été envisagées mais éliminées en raison du besoin de données instantanées.

Conséquences :

• (+) Le temps de réponse (latence) diminuera.
• (+) La charge de la base de données diminuera.
• (-) La complexité de la suppression du cache (invalidation) sera ajoutée.

Comme vous pouvez le voir; Il révèle clairement non seulement la décision, mais aussi ses raisons et ses conséquences.

Pourquoi l'ADR n'est-il pas qu'un sujet « technique » ?

En tant que gestionnaire ou maître d'ouvrage, demander l'ADR, c'est protéger votre projet. Le système ADR fournit :

• Vitesse : Les mêmes discussions architecturales ne sont pas répétées à chaque sprint. La décision est prise, le voyage continue. * Facilité d'intégration : Un nouveau développeur entrant peut demander : "Pourquoi ?" Au lieu de demander "", il comprend tout l'historique du projet en lisant les journaux ADR.* Gestion technique de la dette : Vous avancez en acceptant des risques (compromis), pas inconsciemment.

Comment puis-je appliquer l'ADR à mes services ?

Dans mon travail de gestion de projet et de conseil technique, la rédaction d'ADR n'est pas une « corvée » mais une discipline de livraison.

Lorsque je m'implique dans un projet, je mets généralement en œuvre les éléments suivants au cours des 7 premiers jours :

1. Établissement de la structure du journal ADR : Nous déterminons où les décisions seront conservées (Jira, Git, Notion, etc.).
2. Enregistrement des décisions critiques : Nous prenons une radiographie de l'architecture actuelle et clarifions les décisions critiques prises rétrospectivement.
3. Façonner la feuille de route : Nous priorisons la feuille de route de livraison en fonction de ces décisions architecturales, et pas seulement des fonctionnalités.

Cela garantit une transparence totale entre la direction et l’équipe technique. La « dérive du périmètre » (expansion du périmètre) est évitée et le projet est confié au système lui-même, et non à la mémoire des individus.

Résultat

Le code change. Les réunions passent à toute allure. Mais les décisions constituent le fondement de votre projet.

Si vous sentez que les décisions flottent dans l'air dans votre projet et que les mêmes problèmes sont discutés encore et encore, vous avez besoin d'une « mémoire de décision ».

Le dossier « Technology Stack and Architecture » ​​est l'endroit le plus naturel pour prendre ces décisions.

---

Mettons en place ce système en 5 étapes en utilisant la structure Confluence :

Étape 1 : Créer la « Bibliothèque de décisions »

Ouvrons une nouvelle page d'accueil sous le dossier "Technology Stack and Architecture" dans la capture d'écran.

• Nom de la page : Journal de décision d'architecture (ADR)
• Objectif : Cette page n'est pas une décision autonome ; Il s'agit du tableau principal où sont répertoriées toutes les décisions (Index). Ainsi, lorsqu'un nouveau membre de l'équipe clique ici, il voit tout l'historique du projet dans une liste.#### Étape 2 : Préparer un modèle global Personne n’aime créer une page à partir de zéro à chaque fois. Dans Confluence, vous devez créer un « Modèle global » ou un modèle uniquement pour cet espace. Le contenu du modèle doit être celui dont nous avons parlé précédemment :
• Titre : ADR-XXX : [Titre court]
• Statut : (Nous détaillerons cela à l'étape 3)
• Contexte : Quel est le problème ?
• Décision : Que faisons-nous ?
• Conséquences : Coûts et gains.

Étape 3 : Utiliser la macro visuelle « Statut »

L'une des plus grandes forces de Confluence est la fonctionnalité Status Macro. Ajoutez cette macro en haut de votre modèle. Les couleurs permettent au cerveau de percevoir la situation en quelques secondes. Les codes couleurs standards peuvent être :

• 🟢 ACCEPTÉ (Vert) : La décision a été prise et est en cours de mise en œuvre.
• 🟡 PROPOSÉ (Jaune) : Ouvert à la discussion, pas encore approuvé.
• 🔴 REJETÉ (Rouge) : Cela a été suggéré mais non accepté (le cacher est aussi une leçon).
• ⚪ PÉRIMÉ (Gris) : Auparavant valide mais a maintenant été remplacé par une nouvelle décision (par exemple ADR-009).

Étape 4 : Modifier l'arborescence des pages (hiérarchie)

Positionnez chaque nouvelle page ADR que vous créez (par exemple ADR-001 : Cache Redis) en tant que page enfant de la page du journal de décision d'architecture que nous avons ouverte lors de la première étape. La vue sera comme ceci :``` 📂 Teknoloji Yığını ve Mimarisi └── 📂 Architecture Decision Log (ADR) ├── 📄 ADR-001: Redis Cache Kullanımı ├── 📄 ADR-002: Auth Provider Seçimi └── 📄 ADR-003: ...

C'est la partie "magique". 🪄 Au lieu de faire des listes manuellement une par une, utilisons l'automatisation de Confluence.
Ajoutez la macro « Propriétés de la page » à chaque page ADR (modèle) et placez des informations récapitulatives telles que le statut, la date de décision, les décideurs.
Accédez à la page principale (Architecture Decision Log) et ajoutez la macro "Page Properties Report".
Cette macro extrait ces informations récapitulatives des sous-pages et crée un tableau automatique et toujours à jour sur la page principale.