Bonnes pratiques

Promouvoir la propriété. Chaque membre de l'équipe de projet doit être habilité à créer et à posséder un ADR. Cette pratique répartit le travail de recherche architecturale entre les membres de l'équipe et décharge le travail de l'architecte de solutions ou du chef d'équipe. Elle favorise également le sentiment d'appartenance dans le processus décisionnel. Cela permet à l'équipe d'adopter ces décisions plus rapidement au lieu de les traiter comme des décisions imposées par les niveaux supérieurs de l'organisation.

Préservez l'historique des ADR. ADRs doit avoir un historique des modifications, et chaque modification doit avoir un propriétaire. Lorsque le propriétaire de l'ADR le met à jour, il doit modifier l'état de l'ancien ADR en Remplacé, noter ses modifications dans l'historique des modifications du nouvel ADR et conserver l'ancien ADR dans le journal des décisions.

Planifier des réunions d'examen régulières. Si vous travaillez sur un nouveau projet (inédit), le processus ADR peut être assez intense au début. Nous vous recommandons d'établir une cadence de discussions régulières sur les ADR et de tenir des réunions d'examen avant ou après la présentation quotidienne. Avec cette approche, le résultat défini se ADRs stabilisera en deux ou trois sprints, et vous pourrez établir une base solide en réduisant le nombre de réunions.

Stockez ADRs dans un emplacement central. Chaque membre du projet doit avoir accès à la collection de ADRs. Nous vous recommandons de les stocker ADRs dans un emplacement central et de les référencer sur la page principale de la documentation de votre projet. Il existe deux options populaires pour le stockage ADRs :

• Un dépôt Git, qui facilite la création de versions ADRs

• Une page wiki, qui rend les informations ADRs accessibles à tous les membres de l'équipe

Traiter le code non conforme. Le processus ADR ne résout pas le problème de non-conformité du code existant. Si votre ancien code ne prend pas en charge le code établi ADRs, vous pouvez soit mettre à jour la base de code obsolète ou les artefacts progressivement, tout en introduisant de nouvelles modifications, soit votre équipe peut décider de refactoriser le code de manière explicite en créant des tâches de dette technique.