Привет! Меня зовут Павел Лукьянов, я deputy CTO в AGIMA. Каждую пятницу с 3 до 4 пополудни я занят. Не звоните мне и не ищите меня. В это время у нас еженедельная встреча архитектурного комитета, где я и другие умные люди обсуждаем важные вопросы. Как правило, в центре внимания новые проекты или капитальные перемены на старых. Меняется стек? Это к нам. Обновляем архитектуру? Окей, давайте подумаем. Запускаем проект с нуля? Подберем оптимальные решения.

Все важнейшие технические вопросы у нас проходят через такой вот консилиум архитекторов и руководителей департаментов. Поэтому мы можем гарантировать и самим себе, и заказчику, что техническая часть проекта точно будет на высоте. Но архитектурный комитет, как и любая другая структура, живет по своим правилам и законам. Что это за правила и законы, я расскажу в этой статье. Если вам предстоит настраивать работу архкомитета в вашей компании — велком. 

Но прежде чем начну, дисклеймер. Эта статья — в двух частях. В первой рассказываю про Definition of Ready (DoR) и Definition of Done (DoD), а также про статусную модель. Во второй — про приемку архитектурных документов и ADR (Architectural Decision Record).

Чтобы архитектурный комитет приносил реальную пользу компании, его работу нужно регламентировать и организовать. Да, всегда страшно перестараться и превратить хорошее начинание в набор бюрократических правил, но без четко описанных процессов мы, к сожалению, рискуем увязнуть в долгих спорах и рассуждениях.

Поэтому мы внимательнейшим образом изучили статьи зарубежных коллег, усвоили ключевые практики, некоторые адаптировали под себя. И теперь уже почти не вспоминаем о бюрократической стороне дела — все правила усвоены и приняты в команде. Однако уверен, начать именно с описания процессов было правильно.

И первым делом мы обозначили принципы нашей работы. Главный из них звучит так:

Мы тут все люди страстные и увлеченные, любим поразгонять на технические темы и поискать какие-то классные, нетривиальные варианты. Но главный принцип должен нас отрезвлять: мы собираемся не чтобы бесконечно обсуждать классные идеи и делиться знаниями, а чтобы найти оптимальное решение для конкретного проекта. Отсюда вытекают следующие установки:

• Повторное использование важнее изобретений.

• Документы — для команды, а не для галочки.

• Комитет — совет, а не диктатор. Решение — всегда коллективное.

• Ответственность за реализацию несет проектная команда.

Лично мне нравится в этих правилах всё. Они напоминают, что архитектурный комитет — орган скорее совещательный, но при этом его работа не должна превращаться в формальность. Так мы сохраняем пользу этих собраний для команд разработки и в то же время имеем возможность одним глазом присматривать за технической стороной почти всех проектов компании.

Definition of Ready

Definition of Ready (DoR) — это чек-лист критериев, подтверждающих, что документ готов к рассмотрению архитектурным комитетом. По сути, с помощью этого чек-листа команда готовит задачу к нашему рассмотрению. Выработка DoR экономит всем время. Мы заранее знаем, что на встрече, которая проходит всего раз в неделю, не увидим сырой документ и не будем тратить время на выяснение деталей проекта.

✔️ Собраны все исходные материалы:

• Для архитектурного документа: документ оформлен по утвержденному шаблону, содержит все требуемые разделы (архитектурные представления, диаграммы, описание решений) и заполненные чек-листы (по безопасности, производительности, эксплуатационным требованиям и др.). Нет пустых или черновых разделов.

• Для ADR: запись решения содержит описание контекста, рассматриваемую проблему, варианты (минимум два альтернативных решения) и предложенное решение с обоснованием. Статус ADR предварительно помечен как «Proposed» (то есть предложен).

• Для запроса на консультацию: вопрос четко сформулирован, описан контекст (какая система, проблема или решение рассматривается), предоставлены необходимые исходные данные (например, ссылки на пользовательские истории или требования).

✔️ Определены участники и стейкхолдеры. Мы знаем, кто будет защищать архитектурное решение и кого позвать на встречу. Всех заинтересованных поставили в известность, они готовы участвовать в ревью. При необходимости составлен список RACI (Responsible, Accountable, Consulted, Informed) для архитектурной задачи.

✔️ Задача соответствует стратегии и требованиям. Решаемая проблема значима и актуальна к рассмотрению, причем именно сейчас. В терминологии архитектуры можно сказать так: выбран «самый ответственный момент» для принятия решения — откладывать дальше нельзя, но и преждевременным его не назовешь. Все факторы и условия известны: понятно, какие качества (безопасность, масштабируемость, производительность, удобство сопровождения и т. д.) критически важны и как решение должно им удовлетворять. Для архитектурного документа это выражается в наличии раздела с нефункциональными требованиями и их приоритизацией; для ADR — в описании решаемой архитектурной проблемы и критериев выбора.

✔️ Альтернативы проработаны. В архитектурный комитет лучше принести несколько вариантов решения проблемы. В архитектурном документе спорные решения, как правило, сопровождаются анализом нескольких альтернатив с указанием их плюсов и минусов. В ADR мы перечисляем все рассмотренные варианты и объясняем, почему они отвергнуты или приняты. Если представлен только один вариант, это должно быть обосновано.

✔️ Подготовлен ADR-шаблон или протокол. Участники заранее договариваются о способе фиксации будущего решения. Если по итогам ревью потребуется ADR, то шаблон ADR заранее выбирают и готовят. Если решение оформляют протоколом, мы назначаем ответственного за ведение протокола встречи. Так мы быстрее переходим к документированию решения.

Когда все перечисленные критерии выполнены, задача считается готовой для проработки в комитете. Если каждый пункт отмечен галочкой, можно начинать обсуждение.

Definition of Done

Definition of Done (DoD) — набор критериев, показывающих, что работа по задаче комитета полностью завершена. Так мы понимаем, что реально вынесли решение, которое поможет команде и проекту. Ну и следим, чтобы оно было оформлено должным образом или чтобы его правильно поняли все заинтересованные люди. Иначе зачем нам вообще собираться?

✔️ Принято и задокументировано решение. По итогам обсуждения мы утверждаем или не утверждаем предложенное архитектурное решение. Если утверждаем — фиксируем статус Accepted (в случае ADR) или ставим пометку «Одобрено» в протоколе. Если требуются доработки, решение помечается как условно одобренное с поправками либо отклоняется. В этом случае указываем причины и рекомендации. Все выводы фиксируем письменно: либо в виде ADR, либо в протоколе заседания. Мы не считаем задачу завершенной, пока нет документа с обоснованием.

✔️ Обратная связь и действия по результатам. Если комитет выдал замечания, они должны быть обработаны. Задача не закрывается, пока команда не внесла требуемые исправления в архитектурный документ или ADR. Например, если решение условно одобрено при выполнении ряда доработок, эти доработки должны быть внесены на всех уровнях: архитектурный документ нужно скорректировать, еще раз показать ответственным членам комитета, а те должны подтвердить, что теперь всё в порядке. Если решение отклонено, команда получает рекомендации и четкие инструкции. DoD полностью завершает цикл обратной связи: либо документ принят, либо новые задачи на доработку архитектуры запланированы.

✔️ Соответствие требованиям проверено. В конце должно быть подтверждено, что решение соответствует исходным критериям и корпоративным стандартам. Например, если одним из требований была безопасность, после доработок специалист по ИБ повторно проверяет документ и дает заключение. Все критичные требования изначального чек-листа DoR должны быть закрыты. Также комитет должен убедиться, что архитектурное решение не противоречит стандартам предприятия. Например, не вводит несанкционированных технологий.

✔️ Информацию запротоколировали и распространили. После заседания нужно оформить протокол встречи или обновить существующий документ. В нашей практике это подробный отчет в корпоративной Wiki. Ответственный архитектор сначала утверждает протокол, а затем и рассылает всем заинтересованным. Если принимаем ADR, сохраняем его в утвержденном хранилище с указанием даты, статуса и ссылок на контекст. Нумерацию ADR обновляем, ссылку на новый ADR добавляем в индекс. Таким образом, любой в компании может найти и посмотреть информацию о решении. Этот шаг важен для коллективной корпоративной памяти.

✔️ Задача в таск-трекере закрыта. Наконец, соответствующая задача на доске архитектурного комитета переводится в финальный статус. Все связанные активности (дочерние задачи, связанные тикеты разработки) должны быть обновлены. Закрывая задачу, комитет сигнализирует, что по данному вопросу на текущий момент больше нет незавершенных действий.

Таким образом, Definition of Done подтверждает, что архитектурная задача прошла полный цикл: от подготовки и обсуждения до документирования и исполнения решений. Явные DoD-критерии делают работу комитета прозрачной.

Статусная модель канбан-доски и типы задач комитета

Архитектурный комитет использует отдельную канбан-доску в таск-трекере. На ней мы можем увидеть типы задач (issue types), с которыми работает комитет, и их статусы в столбцах. Сначала посмотрим на типы задач.

Для управления этими задачами определяется статусная модель, то есть набор статусов на канбан-доске. Так выглядит жизненный цикл задачи на архитектурном комитете от создания до завершения:

Рассмотрим на примере. Задача типа «Рассмотрение архитектурного документа» создается как новая. После выполнения DoR переводится в «Готова к рассмотрению». Когда назначено заседание, задача переходит в «На рассмотрении». По итогам обсуждения возможны исходы: «Одобрено» либо «Требуются доработки». Если идем по второму сценарию, задача переходит в статус «На доработке», а когда правки внесены, возвращается в «Готова к рассмотрению» для повторного круга ревью. Если решение сразу одобрено, задача переводится в «Утверждено». Если комитет отклоняет предложение, задача получает статус «Отклонено». Финальный шаг — «Закрыто», когда оформлены протокол и/или ADR.

Эту модель можно адаптировать под потребности. Например, запросы на консультацию будут идти по доске быстрее — там вряд ли будет этап «На доработке». Протокол встречи тоже может идти по упрощенному воркфлоу. Тем не менее, единая доска с общими статусами удобна для обзора: видно, какие вопросы только собираются к ревью, что сейчас рассматривается, а что уже решено или требует доработок.

Канбан-доска комитета должна быть прозрачной для заинтересованных команд. Это достигается через корректное именование задач и информативные комментарии при переходах статусов. Кроме того, поскольку мы data-driven компания, мы собираем метрики со всех этапов движения задачи и вообще со всех досок в единую базу данных — DWH. Это позволяет нам следить за всеми процессами в компании через единые дашборды. Подобные системы, кстати, мы делаем и для других компаний.

Также полезно связать задачи этой доски с задачами разработки: одобренная архитектура может ссылаться на эпики реализации, ADR — на соответствующие user story. Таким образом, экосистема таск-трекера отражает связь стратегии (архитектуры) и тактики (разработка).

Во второй части статьи расскажу чуть больше про приемку архитектурного документа и ADR. Она выйдет завтра. Как и в этой статье, сконцентрируемся больше на процессах и регламентах. Если внедряете что-то подобное у себя — смело забирайте и применяйте. Если есть вопросы — готов ответить в комментариях. Также подписывайтесь на мой телеграм-канал.

Что еще почитать

• Почему мы построили монолит на чистой архитектуре. И почему это взбесило системных аналитиков

• Базовый набор тимлида: от каких убеждений стоит отказаться, чтобы команда тебя не возненавидела

• Код-ревью под микроскопом: как нетоксично давать обратную связь и проверять код без нервов