Задача и границы
Для темы «как принимать архитектурные решения в продуктовой команде» предлагается прикладной артефакт «журнал архитектурных решений». Назначение «журнал архитектурных решений» — соединить продуктовые цели, технические ограничения, альтернативы и последствия в воспроизводимом процессе выбора. Проверку проводят в реальной работе команды.
В артефакте «журнал архитектурных решений» сначала связывают блоки «Контекст» и «Критерии». Неизвестность по условию «малые локальные изменения не требуют полного ADR» помечают отдельно. Причинные объяснения для темы «как принимать архитектурные решения в продуктовой команде» остаются редакционными гипотезами до самостоятельной проверки.
Практическую пользу артефакта «журнал архитектурных решений» проверяют действием «описать проблему до обсуждения технологии». В артефакте «журнал архитектурных решений» ошибку «начинать ADR с названия любимой технологии» используют как негативный сценарий. Для темы «как принимать архитектурные решения в продуктовой команде» бесполезную запись удаляют при пересмотре.
Проверенные основания
AWS рекомендует ADR для фиксации важных технических решений, их контекста и последствий, а совокупность записей образует журнал решений. основание
Процесс AWS предусматривает статусы ADR и жизненный цикл записи после появления новых обстоятельств. основание
Google SRE подчёркивает ценность раннего участия эксплуатационной экспертизы на стадиях архитектуры и проектирования. основание
Scrum Guide требует, чтобы каждый инкремент соответствовал Definition of Done и оставался пригодным для использования. основание
Проверенные источники задают внешние ориентиры. Редакционная схема «журнал архитектурных решений» соединяет их с компонентом «Альтернативы» и ограничением «часть сведений может быть ограничена требованиями безопасности». Прямое копирование без адаптации не предлагается.
Рабочая модель
Контекст. Компонент «Контекст» в артефакте «журнал архитектурных решений»: проблема, ограничения и ожидаемое изменение продукта. Формулировку делают наблюдаемой.
Критерии. Раздел «Критерии» для артефакта «журнал архитектурных решений»: надёжность, стоимость, скорость, безопасность и обратимость. Добавляют продуктовый пример.
Альтернативы. Элемент «Альтернативы» в модели «журнал архитектурных решений»: реальные варианты, включая сохранение текущего состояния. Расхождение запускает пересмотр.
Решение. Артефакт «журнал архитектурных решений», блок «Решение»: выбранный вариант и область действия. Проверку проводят на завершённой работе.
Последствия. Компонент «Последствия» в артефакте «журнал архитектурных решений»: новые возможности, долги и операционные обязанности. Формулировку делают наблюдаемой.
Статус. Раздел «Статус» для артефакта «журнал архитектурных решений»: предложено, принято, заменено или отменено. Добавляют продуктовый пример.
В артефакте «журнал архитектурных решений» изменение блока «Контекст» сопоставляют с блоком «Решение». Связь проверяют критерием «последствия включают стоимость сопровождения». Остальные поля заполняют только при влиянии на решение.
Связка «Альтернативы → Статус» получает отдельную строку в артефакте «журнал архитектурных решений». Блок «Альтернативы»: реальные варианты, включая сохранение текущего состояния. Блок «Статус»: предложено, принято, заменено или отменено. Переход проверяют критерием «альтернативы сравниваются одинаковым способом». Ошибка «скрывать вариант оставить систему без изменений» служит отрицательным тестом для темы «как принимать архитектурные решения в продуктовой команде». Если связь не объясняет эту ошибку, модель «журнал архитектурных решений» упрощают или дополняют.
Порядок внедрения
1. Описать проблему до обсуждения технологии. Шаг «описать проблему до обсуждения технологии» проверяют реальными примерами. Результат вносят в артефакт «журнал архитектурных решений».
2. Согласовать критерии с продуктовым владельцем. Операцию «согласовать критерии с продуктовым владельцем» проводят с затронутыми участниками. В артефакте «журнал архитектурных решений» фиксируют итог.
3. Собрать ограниченный набор реализуемых вариантов. Шаг «собрать ограниченный набор реализуемых вариантов» выполняют на ограниченной выборке. В артефакте «журнал архитектурных решений» сохраняют решение и риск.
4. Провести проверку наиболее рискованного допущения. Действие «провести проверку наиболее рискованного допущения» обновляет артефакт «журнал архитектурных решений». Недостающие сведения помечают отдельно.
5. Принять решение на назначенном уровне полномочий. Шаг «принять решение на назначенном уровне полномочий» проверяют реальными примерами. Результат вносят в артефакт «журнал архитектурных решений».
6. Связать реализацию и последующий пересмотр с adr. Операцию «связать реализацию и последующий пересмотр с ADR» проводят с затронутыми участниками. В артефакте «журнал архитектурных решений» фиксируют итог.
После действия «связать реализацию и последующий пересмотр с ADR» артефакт «журнал архитектурных решений» получает срок проверки. Подтверждением считают критерий «решение проверяется после реализации». Ограничение «документ не компенсирует отсутствие технической экспертизы» служит сигналом пересборки.
Цикл «журнал архитектурных решений» начинается действием «описать проблему до обсуждения технологии». Завершение подтверждает критерий «критерии отражают продуктовые и операционные цели». Ошибка «перечислять преимущества без новых обязанностей» прерывает обычный ход темы «как принимать архитектурные решения в продуктовой команде». Ограничение «часть сведений может быть ограничена требованиями безопасности» определяет допустимое исключение. Новый факт по блоку «Последствия» вносят в артефакт «журнал архитектурных решений» до следующего решения. Такой ритм удерживает артефакт «журнал архитектурных решений» непосредственно в delivery-процесса, а — в разборе «Как принимать архитектурные решения в продуктовой команде» — не в самостоятельной отчётной практике.
Рабочий сценарий
Редакционный пример для темы «как принимать архитектурные решения в продуктовой команде»: Команда выбирала между собственной очередью и управляемым брокером сообщений. Вместо сравнения списков функций она зафиксировала требования к восстановлению, ожидаемую нагрузку и допустимое время сопровождения. Прототип проверил риск повторной доставки, после чего ADR выбрал управляемый сервис и добавил обязанность регулярно тестировать переносимость данных.
В примере «журнал архитектурных решений» связывает компонент «Последствия» с шагом «принять решение на назначенном уровне полномочий». При переносе заново проверяют ограничение «экспериментальная архитектура нуждается в сроке действия» и критерий «статус и заменяющий документ прослеживаются».
Контрольный разбор «журнал архитектурных решений» сопоставляет «Критерии», действие «собрать ограниченный набор реализуемых вариантов» и критерий «альтернативы сравниваются одинаковым способом». Ограничение «аварийное решение можно документировать постфактум» записывают рядом. Для темы «как принимать архитектурные решения в продуктовой команде» эта регламент действий обеспечивает проверку — для сценария «Как принимать архитектурные решения в продуктовой команде» —, но не устанавливает причинную связь.
Перед применением команда проверяет артефакт «журнал архитектурных решений» на одном завершённом элементе темы «как принимать архитектурные решения в продуктовой команде». Она восстанавливает блок «Контекст» и повторяет действие «согласовать критерии с продуктовым владельцем». Для темы «как принимать архитектурные решения в продуктовой команде» отдельно проверяют ошибку «требовать вечной неизменности принятого решения». Если критерий «статус и заменяющий документ прослеживаются» нельзя подтвердить имеющимися данными, решение остаётся пробным. Ограничение «экспериментальная архитектура нуждается в сроке действия» записывают до начала следующего рабочего случая.
Типовые ошибки
- Начинать adr с названия любимой технологии. В артефакте «журнал архитектурных решений» последствие относится к блоку «Альтернативы». Исправление меняет рабочее правило.
- Скрывать вариант оставить систему без изменений. В артефакте «журнал архитектурных решений» последствие относится к блоку «Решение». Исправление меняет рабочее правило.
- Перечислять преимущества без новых обязанностей. В артефакте «журнал архитектурных решений» последствие относится к блоку «Последствия». Исправление меняет рабочее правило.
- Требовать вечной неизменности принятого решения. В артефакте «журнал архитектурных решений» последствие относится к блоку «Статус». Исправление меняет рабочее правило.
- Вести журнал отдельно от рабочего репозитория. В артефакте «журнал архитектурных решений» последствие относится к блоку «Контекст». Исправление меняет рабочее правило.
Критерии качества
- Контекст понятен без устного объяснения автора. После шага «описать проблему до обсуждения технологии» результат вносят в артефакт «журнал архитектурных решений».
- Критерии отражают продуктовые и операционные цели. После шага «согласовать критерии с продуктовым владельцем» результат вносят в артефакт «журнал архитектурных решений».
- Альтернативы сравниваются одинаковым способом. После шага «собрать ограниченный набор реализуемых вариантов» результат вносят в артефакт «журнал архитектурных решений».
- Последствия включают стоимость сопровождения. После шага «провести проверку наиболее рискованного допущения» результат вносят в артефакт «журнал архитектурных решений».
- Статус и заменяющий документ прослеживаются. После шага «принять решение на назначенном уровне полномочий» результат вносят в артефакт «журнал архитектурных решений».
- Решение проверяется после реализации. После шага «связать реализацию и последующий пересмотр с ADR» результат вносят в артефакт «журнал архитектурных решений».
В артефакте «журнал архитектурных решений» критерий «контекст понятен без устного объяснения автора» рассматривают вместе с условием «статус и заменяющий документ прослеживаются». Итоговая оценка называет остаточный риск темы «как принимать архитектурные решения в продуктовой команде».
Ограничения применимости
- Малые локальные изменения не требуют полного adr. Для блока «Контекст» в артефакте «журнал архитектурных решений» требуется новая проверка. Перенос остаётся гипотезой.
- Аварийное решение можно документировать постфактум. Для блока «Критерии» в артефакте «журнал архитектурных решений» требуется новая проверка. Перенос остаётся гипотезой.
- Часть сведений может быть ограничена требованиями безопасности. Для блока «Альтернативы» в артефакте «журнал архитектурных решений» требуется новая проверка. Перенос остаётся гипотезой.
- Экспериментальная архитектура нуждается в сроке действия. Для блока «Решение» в артефакте «журнал архитектурных решений» требуется новая проверка. Перенос остаётся гипотезой.
- Документ не компенсирует отсутствие технической экспертизы. Для блока «Последствия» в артефакте «журнал архитектурных решений» требуется новая проверка. Перенос остаётся гипотезой.
Если ограничения затрагивают «Контекст», «Альтернативы» и «Последствия», артефакт «журнал архитектурных решений» пересобирают. Дополнительные исключения не — с учётом темы «Как принимать архитектурные решения в продуктовой команде» — должны маскировать смену рабочего условий.
Вывод
Тема «как принимать архитектурные решения в продуктовой команде» становится управляемой через артефакт «журнал архитектурных решений». Начать следует с действия «описать проблему до обсуждения технологии», затем проверить компонент «Контекст» и критерий «контекст понятен без устного объяснения автора». Ограничение «малые локальные изменения не требуют полного ADR» оставляют видимым, поэтому артефакт не создаёт ложной уверенности.
