Je travaille avec un client américain ayant une politique 100% remote, j’aide à la mise en place d’une équipe de QA pour des services backends.
Jusqu’ici toutes les décisions architecturales/techniques importantes étaient prises en réunions.
Résultat pas de traçabilité de l’information, tout doit être ré-expliqué aux nouveaux arrivants et bien entendu il y à une perte d’information importante impliquant des incompréhensions et de nouvelles réunions pour en rediscuter.
J’ai proposé la mise en place d’ADRs (Architecture Design Records) pour pallier ce problème, d’autant plus que le remote nécessite une certaine organisation pour l’accès à l’information; tout le monde n’est pas sur la même timezone!
On gère les documents en markdown directement dans un dossier à la racine du projet concerné, comme ça pas besoin de chercher dans les milliers de pages Confluence!
Résultat : un premier draft est versionné sous GIT via merge request, le document est discuté, revu et validé. Ces ADRs s’inscrivent dans le cycle de vie du projet et apportent tout le contexte nécessaire!
Pas de manière structurée de consigner et de partager des décisions d'architectures, de choix de stack, de design produit.
Mise en place d'Architecture Design Record, dont voici quelques outils:
Voici une liste de template alternatifs à ceux proposés dans le livre:
Exemple d'ADRs:
Exemple de documentation du rationnel dans le code source de Redis, son auteur applique ce principe de diverses manières au niveau du code:
Et vous, quelles sont vos retours d'expérience concernant l'application de ce principe ?