+7 (499) 322 88 70
ok@systems.education
Татьяна Арсланова | ИННА АЛЕКСАНДРОВА
DoR, DoD, AC: критерии готовности и критерии приёмки
Введение
При разработке продуктов с использованием User Story (US) часто используются такие критерии готовности и приёмки как DoR (Definition of Ready), DoD (Definition of Done) и AC (Acceptance Criteria). На практике чаще ограничиваются использованием AC для US, недооценивая пользу применения DoR и DoD в процессе разработки. Между тем использование этих критериев может существенно повлиять на качество реализации продукта.

В статье мы рассмотрим особенности создания и применения каждого из критериев, разберём в чём разница и сходство DoR, DoD и AC, приведём примеры.

Статья полезна аналитикам, владельцам продуктов, менеджерам и тестировщикам, работающим с User Story в рамках Agile-подхода и хорошо владеющих его терминологией и практиками. Прочитав статью, вы поймете, как использовать все типы критериев готовности и приёмки для создания качественного продукта.
Время на чтение статьи: 10 минут
Основы бизнес-анализа и разработки
требований в Agile

Научитесь описывать постановку задачи на разработку продукта в наглядной форме, не залезая в детали реализации
Посмотреть программу курса
Agile-контекст
Для того, чтобы лучше понять специфику критериев, стоит вспомнить некоторые из понятий гибких фреймворков разработки ПО.
Бэклог
Один из основных артефактов в гибких подходах к разработке ПО — бэклог. В проекте может быть несколько видов бэклогов:

  1. Бэклог продукта — это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта. Это все функции продукта, которые вы хотите реализовать, расположенные в порядке их важности.
  2. Бэклог спринта — это наглядная и доступная в режиме реального времени картина работы, которую команда разработки планирует выполнить в течение спринта. В бэклог спринта попадают наиболее приоритетные функции продукта.

Некоторые команды выделяют также бэклог релиза — перечень функций продукта, которые должны быть реализованы для конкретного релиза. В команде, которая достигла определенного уровня agile-зрелости, бэклог спринта будет совпадать с бэклогом релиза. Поэтому бэклог релиза — необязательный артефакт продукта и не фигурирует в Scrum Guide, но может использоваться в рамках командной договоренности.
User Story
User Story (US, пользовательская история) — короткая формулировка потребности пользователя, в которой больше внимания уделяется цели пользователя и меньше — деталям реализации. В классическом виде US пишется в формате:

Как [РОЛЬ]
Я хочу [ДЕЙСТВИЕ]
Чтобы [ЦЕННОСТЬ]
И хотя такой формат может показаться вполне самодостаточным, на практике качественная реализация US невозможна, если требования сформулированы только в виде US: каждый участник команды разработки, включая заказчика, может иметь разное понимание US и степень ее готовности. В решении этой проблемы помогает практика совместной командной выработки:
  • дополнительных артефактов, описывающих реализацию (макеты интерфейсов, диаграммы процессов, модели данных, спецификации и т.д.);
  • критериев приемки US (Acceptance Criteria);
  • артефактов процесса разработки — критериев готовности (DoD и DоR).
Жизненный цикл US: DоR, DoD, AС
При поверхностном рассмотрении DoR, DoD и AC легко спутать. Термины действительно близки: это набор правил и командных соглашений, дополняющих бэклог продукта. Применение всех трёх наборов правил служит общей цели — обеспечению прозрачности процесса разработки — одной из важнейших ценностей в гибкой разработке.

Критерии неразрывно связаны с ключевыми этапами пользовательской истории.
Типовые этапы жизненного цикла User Story в Agile
Стоит заметить, что User Story не появляется из ниоткуда. Этапу 1 (запись User Story) всегда предшествует Discovery — деятельность команды, направленная на выработку идей по улучшению и развитию продукта. Discovery включает в себя анализ трендов, рынка и конкурентов, изучение клиентов и технологий, а также генерацию гипотез и проведение экспериментов. В рамках Discovery идея превращается в гипотезу о проблеме, затем гипотеза валидируется о реальных пользователей. После под проблему формируется решение, которое записывается в виде User Story.

Связь критериев готовности и критериев приёмки с этапами жизненного цикла US графически можно изобразить так:

Связь критериев готовности и критериев приёмки с этапами ЖЦ US
Definition of Ready
Критерии DoR (Definition of Ready) могут применяться как к US, так и к спринтам (и к релизам в некоторых командах).
DoR для US
DoR (Definition of Ready) — общие критерии готовности (подготовленности) US к передаче в работу команде разработки.

В контексте US DoR представляет собой некий контрольный список условий, которым должна удовлетворять US перед тем, как она может быть передана в разработку. US, которая не соответствует критериям готовности, не может попасть в бэклог спринта.

Критерий DoR не относится напрямую к US как к формулировке требования, а является артефактом процесса разработки. DoR одинаковы для всех US продукта.

Использование DoR позволяет исключить взятие в спринт недостаточно проработанной US.

В рамках жизненного цикла US DoR нужны на этапе 3 (Планирование итераций), подробнее об этом этапе в таблице выше.
Примеры DoR для US

  • US имеет ясное и краткое описание
  • DоD определены и утверждены командой
  • Все необходимые ресурсы, технические спецификации и прототипы доступны
  • Все зависимости от других US зафиксированы
  • US приоритезирована и оценена командой
  • Команда договорилась об Acceptance Criteria
DoR для спринта и релиза
В контексте спринта DoR — перечень условий, которые должны быть выполнены, чтобы команда могла начать планирование и выполнение спринта.

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

  • Все пользовательские истории, выбранные для спринта, оценены и имеют DoR
  • У команды определены цели и ожидаемые результаты для спринта
  • Вся необходимая документация и дизайн доступны
  • Команда имеет доступ к необходимым ресурсам, таким как серверы, тестовые данные и так далее
  • Команда имеет определённый бюджет и ресурсы для выполнения спринта
  • Команда имеет понимание требований продукта и его структуру
  • Команда имеет определённый план спринта и понимает, как он будет реализован
  • Команда имеет определённую методологию разработки, такую как Scrum или Kanban
  • Команда имеет общее понимание того, какие задачи будут выполнены в течение спринта и кто за них ответственен
  • Команда имеет определённую систему отслеживания прогресса и отчётности о выполнении задач в рамках спринта
В некоторых командах могут быть установлены DoR для релиза — перечень условий, необходимых для выпуска новой версии продукта. Но как и в случае с бэклогом релиза, команды, работающие с гибкими подходами к разработке, должны стремиться к тому, чтобы в конце каждого спринта был готовый к поставке релиз. Тогда DoR будут нужны только для спринта.
Definition of Done
Для DoD актуальны те же особенности, что для DoR:

  • Могут применяться как к US, так и к спринтам (и релизам в некоторых командах)
  • Одинаковы для всех US (спринтов, релизов) в разработке продукта
  • Определяются командой до начала первого спринта
  • Могут видоизменяться в процессе работы команды (обычно в рамках ретроспективы)
DoD для US
DoD (Definition of Done) — это формальное описание состояния инкремента, при котором он соответствует требованиям качества, предъявляемым продукту (согласно Scrum Guide). Другими словами, в контексте US критерии DoD — перечень условий, которым должна соответствовать US для того, чтобы её можно было передать в эксплуатацию пользователям.

Если не вся команда однозначно понимает понятие «готовности», может произойти такое, что US объявлена готовой к выпуску в рамках релиза, но на самом деле не все необходимые работы были выполнены. Это может увеличить Time To Market продукта. Использование DoD позволяет уменьшить вероятность возникновения таких ситуаций.

В рамках жизненного цикла US DoD нужны на этапе 5 (Проверка и приёмка User Story), подробнее об этом этапе в таблице выше.
Примеры DoD для US

  • Реализация US соответствует Acceptance Criteria
  • Код, связанный с историей протестирован и отлажен
  • Документация истории создана или обновлена
  • Все необходимые одобрения истории получены
  • Код, связанный с историей выложен в систему контроля версий
  • Все возможные риски оценены и предусмотрены
DoD для спринта и релиза
В контексте спринта DoD — список условий, которые должны выполняться для завершения спринта.

Примеры DoD для спринта

  • Все пользовательские истории, выбранные для релиза, завершены и протестированы
  • Качество продукта оценено и проверено командой QA
  • Документация обновлена и актуальна
  • Продукт совместим с целевой производственной средой
  • Производственное окружение настроено и готово к использованию
  • Продукт интегрирован с другими необходимыми системами и приложениями
  • Все задачи, связанные с релизом, закрыты
  • Команда имеет понимание процесса релиза и план выпуска
  • Ресурсы, такие как серверы, базы данных и т.д., готовы к использованию
  • Продукт протестирован и утверждён заказчиком

Также как и DoR для релиза, в некоторых командах могут быть установлены DoD для релиза. DoD для релиза — необязательный артефакт. Команды должны стремиться к тому, чтобы по итогам каждого спринта был готовый к поставке релиз.
Acceptance Criteria
АС (Acceptance Criteria) — критерии приёмки результата реализации US. AC относится к требованиям, которым должен соответствовать продукт и представляет собой список условий, которые должны выполняться, чтобы US удовлетворяла требованиям пользователей. Для каждой US продукта AC будут уникальными.

Дополнение US Acceptance Criteria позволяет упростить процессы разработки и тестирования через однозначное понимание командой требований, которым должен удовлетворять продукт.

В рамках жизненного цикла US AC нужны на этапе 5 (Проверка и приёмка User Story). С помощью AC US проверяется на соответствие требованиям пользователей и заказчика.

Предположим, что команда работает над такой US:

Как пользователь
Я хочу искать товар в пределах установленного диапазона стоимости
Чтобы найти подходящие мне товары в моей ценовой категории
Для этой US критерии приёмки могут быть следующими:

  • Пользователь может установить диапазон цены с клавиатуры
  • Пользователь может установить диапазон цены поиска при помощи бегунка
  • Для активации поиска пользователь нажимает кнопку «Найти»
  • Если пользователь вводит некорректный диапазон цен, система должна выдавать сообщение об ошибке и не показывать пустой список товаров
  • Результаты поиска должны быть точными и соответствовать установленному диапазону цен, по умолчанию отображаются в порядке возрастания цены
  • Результаты поиска разбиваются по 10 штук на странице, обеспечивается переход на предыдущие или следующие страницы при помощи ссылок

Подробнее об AC говорим в этой статье.
Сравнительная таблица: DoR, DoD, AC
В таблице ниже собрана основная информация про DoR, DoD и AC (в контексте US): определения, особенности создания и использования, примеры. Также вы можете скачать эту таблицу в pdf формате.
Резюме
Критерии готовности (DoD, DoR) и критерии приёмки (AС) являются важными элементами в гибких подходах к разработке.

Несмотря на то, что критерии часто путают при поверхностном рассмотрении, они значимо различаются и используются на разных этапах жизненного цикла US.

  1. DoR — общие критерии готовности (подготовленности) US (или спринта, релиза) к передаче в работу команде разработки.
  2. DoD — критерии готовности US (или спринта, релиза) к передаче в эксплуатацию конечным пользователям.
  3. АС — критерии приёмки результата реализации US.
Использование критериев позволяет добиться большей управляемости процесса разработки за счёт одинакового понимания уровня готовности всех US продукта.

Безусловно, одно лишь применение критериев готовности и приёмки не гарантирует того, что создаваемый вами продукт будет качественным. Для того, чтобы продукт приносил максимальную пользу, необходимо комплексно использовать различные техники и принципы. Например, для формулирования полных US с понятной бизнес-ценностью, рекомендуем вам вспомнить о принципе INVEST. Также полезно будет вспомнить о техниках Impact Mapping (техника раскрытия целей продукта) и User Story Mapping (планирование реализации пользовательских историй).

Концептуальное проектирование и трансформация идеи в цифровой продукт


Для менеджеров и ИТ-специалистов, кто отвечает за коммерческий успех продукта, глубоко погружаясь в проблемы клиентов, максимизирует ценность продукта.
Этот курс для тех, кто хочет научиться проектировать успешные цифровые продукты.
Посмотреть программу курса
Татьяна Арсланова
Системный аналитик
  • 15 лет в ИТ
  • Старший системный аналитик расчëтного центра (банк)
  • Ex-ведущий BA/SA, лид группы аналитиков, проекты группы компаний «Татнефть» в областях: инновационная и новаторская деятельность, НИОКР, тиражирование лучших практик, расчëт эффективности инновационных проектов
  • Соавтор патента «Система для управления интеллектуальными ресурсами предприятия» (RU 2 602 972 C2)
  • Scrum.org, Professional Scrum Master™