Семь ролей: кто что проверяет — конвейер производства постановок

Навигатор

Что делает: Собирает use case: кто действующее лицо, что он хочет получить, при каких условиях начинает и чем заканчивает.
Что проверяет: Что задача сформулирована как задача, а не как решение. Что известны границы: где сценарий начинается, где заканчивается, что остаётся снаружи. Что есть основной поток и названы альтернативные.
Что заворачивает: Формулировки вида «сделать кнопку», в которых зашито готовое решение и не виден исходный сценарий. Сценарии без явного окончания — их невозможно ни разложить на шаги, ни проверить.

Вход — бизнес-требования, заметки со встречи, существующая документация. Выход — use case и концепт для согласования с заказчиком.

Детализатор

Что делает: Определяет, какие аспекты решения задеты сценарием, и разворачивает use case в соответствующие спецификации. Требования к компоненту — всегда. Требования к UI, к контрактам интеграций, к структуре БД и описание алгоритма — по признаку применимости.
Что проверяет: Что признак применимости оценён по каждому аспекту явно, а не пропущен по невнимательности. Что каждый шаг сценария нашёл отражение хотя бы в одном документе и не осталось шагов, описанных словами «и далее система обрабатывает».
Что заворачивает: Обратно Навигатору — сценарии, которые при детализации распадаются, потому что за одним use case прячутся два разных. И постановки, где аспект задет, а спецификации по нему нет: отсутствие документа заметить труднее, чем ошибку в нём, поэтому это самая частая дыра.

Вход — use case. Выход — комплект спецификаций под фактический состав решения.

Страж

Что делает: Архитектурное ревью постановки до того, как её увидит архитектор.
Что проверяет: Согласованность с принятыми на проекте решениями и ограничениями. Что предлагаемое не противоречит существующим контрактам интеграций. Что у требования есть выполнимая реализация в текущей архитектуре, а не только в вакууме.
Что заворачивает: Постановки, которые требуют менять то, что менять не планировалось, и не говорят об этом прямо. Скрытая цена изменения — самое частое, что архитектор возвращает вручную.

Бизнес-линза

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

Прагматик

Что делает: Оценивает реализуемость в текущих условиях, а не в принципе.
Что проверяет: Соразмерность объёма работ ценности результата. Наличие зависимостей от смежных команд, которые в постановке не названы. Что требование можно реализовать в обозримом инкременте, а не только целиком.
Что заворачивает: Постановки, у которых нет способа выкатиться частями, когда ценность позволяет резать. И те, где скрытая зависимость обнаруживается только на планировании.

Стандарт

Что делает: Финальный гейт качества оформления.
Что проверяет: Единообразие формулировок критериев приёмки. Полноту обязательных разделов. Терминологию по глоссарию проекта — одно понятие называется одним словом во всех документах. Проставленные связи: требование — задача, спецификация — смежные спецификации.
Что заворачивает: Всё, что не пройдёт формальную проверку у ревьюера, — чтобы человек тратил внимание на смысл, а не на оформление.

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

Эволюция

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