Prácticas recomendadas

Promueva la propiedad. Cada miembro del equipo del proyecto debe estar facultado para crear y ser propietario de un ADR. En esta práctica, se distribuye el trabajo de investigación de arquitectura entre los miembros del equipo y se transfiere ese trabajo al arquitecto de soluciones o el líder del equipo. También se fomenta un sentido de propiedad en el proceso de toma de decisiones. Esto ayuda al equipo a adoptar esas decisiones con mayor rapidez, en lugar de tratarlas como decisiones impuestas desde niveles superiores de la organización.

Preserve el historial de ADR. ADRs debe tener un historial de cambios y cada cambio debe tener un propietario. Cuando el propietario del ADR lo actualice, deberá cambiar el estado del ADR anterior a Sustituido, anote sus cambios en el historial de cambios del ADR nuevo y mantenga el ADR anterior en el registro de decisiones.

Programe reuniones de revisión periódicas. Si está trabajando en un proyecto nuevo (completamente nuevo), el proceso de ADR puede ser bastante intenso al principio. Le recomendamos que establezca una frecuencia de reuniones periódicas de debate y revisión sobre el ADR antes o después de la reunión diaria. Con este enfoque, ADRs lo definido se estabilizará en dos o tres sprints, y podrás construir una base sólida con menos reuniones.

Almacene ADRs en una ubicación central. Cada miembro del proyecto debe tener acceso a la colección de ADRs. Te recomendamos que los guardes ADRs en una ubicación central y los consultes en la página principal de la documentación del proyecto. Existen dos opciones populares de almacenamiento ADRs:

• Un repositorio de Git, que facilita la creación de versiones ADRs

• Una página wiki, que hace que todos los miembros del equipo puedan ADRs acceder a ella

Aborde el código no compatible. El proceso de ADR no resuelve el problema del código heredado no compatible. Si tienes un código heredado que no es compatible con lo establecido ADRs, puedes actualizar la base de código obsoleta o los artefactos de forma gradual e introducir nuevos cambios, o tu equipo puede decidir refactorizar el código de forma explícita creando tareas técnicas obligatorias.