2024 06 08 универсальность adrs
(005/100) Универсальность ADRs
Меня тут пожурили, что после 4 постов про ADRs, так и непонятно что это. Поэтому я решил заняться экстраполяцией и сказать, что выбранный шаблон подходит под большинство ситуаций и не сводится только к описанию решений по архитектуре сервиса.
В центре написания ADR лежит “Y-предложение”, хотя проще назвать это зафиксированным решением с обоснованием и последствиями. В оригинале шаблон выглядит так:
In the context of
<use case/user story u>
, facing<concern c>
we decided for<option o>
and neglected<other options>
, to achieve<system qualities/desired consequences>
, accepting<downside d/undesired consequences>
, because<additional rationale>
.
Данный шаблон прекрасно переиспользуется для итерации процессов внутри команды. Это работает лучше ретро, когда вы сидите с карточками, потому что позволяет любому в любой момент времени внести своё предложение. А другим участникам команды асинхронно его обсудить и внести свои корректировки. Подробнее про это рассказывать Шароватов на TeamLeadConf в 2022: https://www.youtube.com/watch?v=1gKdzgjRirk
Если пойти почитать последние посты у Дорофеева, то там можно увидеть ровно такой же шаблон при принятии решений, только урезанный до оценки рисков:
В результате причины может наступить следствие, что приведёт к определённым последствиям.
Получается, что в рамках личный решений - это тоже работает. Дальше больше, в рамках управления проектами - это проектный журнал. В рамках инженерных работ - это толстые доки по ГОСТу, где описаны расчёты для принятия какой-то конструкции.
Вот такой вот универсальный инструмент. Больше примеров есть тут - https://ozimmer.ch/practices/2021/04/23/AnyDecisionRecords.html (:
✍️ Напоминаю, что буду рад обратной связи и вашим вопросам по ссылке: https://forms.gle/7RsYTrkBBWcAbVhC9
#марафон #design @chernov_sharit