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

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

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

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

Один из основных артефактов гибких методологий разработки ПО — бэклог. В проекте может быть несколько видов бэклогов:

  1. Бэклог продукта — функции продукта, которые вы хотите реализовать, но ещё не определили приоритеты для выпуска.
  2. Бэклог релиза — функции продукта, которые должны быть реализованы для конкретного релиза.
  3. Бэклог спринта — User Stories, которые должны быть завершены в течение определённого периода времени.
Product Backlog Item (PBI)

Бэклог продукта состоит из элементов — Product Backlog Item (PBI). Обычно их классифицируют так:

  1. User Story — это облегчённый формат записи требований к системе, в котором больше внимания уделяется цели и меньше — деталям.
  2. User Story может содержать дочерние задачи (Task). Это основные этапы, которые нужно сделать для того, чтобы история была реализована.
  3. Эпик (Epic) — это высокоуровневое описание того, что хочет клиент. Его полное выполнение имеет максимальную ценность. Фактически это большая бизнес-задача, которую делят на несколько пользовательских историй.
  4. Группа эпиков, реализующих одну и ту же функцию, образует Тему (Theme). Темы часто называют Фичами (Features).

Классификация элементов бэклога: темы, эпики, пользовательские истории и задачи
Набор полностью готовых к передаче в эксплуатацию пользователям PBI называют Инкремент Продукта (Product Increment).
User Story
User Story (US, пользовательская история) — атомарная единица функциональности продукта, несущая ценность для пользователя. В классическом виде US пишется в формате:

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

Критерии неразрывно связаны с ключевыми этапами пользовательской истории.
Типовые этапы жизненного цикла User Story в Agile
Связь критериев готовности и критериев приёмки с этапами жизненного цикла US графически можно изобразить так:

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

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

Использование DoR позволяет уменьшить вероятность того, что взятая в спринт US проработана плохо.

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

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

Существует два мнения по поводу того, какое место здесь занимает оценка US:
  1. US должна быть оценена до взятия в работу, то есть. наличие оценки — один из критериев DoR.
  2. US может быть оценена только при соответствии критериям DoR.
Каждая команда решает сама, какой из двух вариантов ей удобнее применять.
DoR для спринта и релиза
В контексте спринта DoR — перечень условий, которые должны быть выполнены, чтобы команда могла начать планирование и выполнение спринта. Аналогично для релиза DoR — перечень условий, необходимых для выпуска новой версии продукта.

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

  • Все пользовательские истории, выбранные для спринта, оценены и имеют DoR
  • У команды определены цели и ожидаемые результаты для спринта
  • Вся необходимая документация и дизайн доступны
  • Команда имеет доступ к необходимым ресурсам, таким как серверы, тестовые данные и так далее
  • Команда имеет определённый бюджет и ресурсы для выполнения спринта
  • Команда имеет понимание требований проекта и его структуру
  • Команда имеет определённый план спринта и понимает, как он будет реализован
  • Команда имеет определённую методологию разработки, такую как Scrum или Kanban
  • Команда имеет общее понимание того, какие задачи будут выполнены в течение спринта и кто за них ответственен
  • Команда имеет определённую систему отслеживания прогресса и отчётности о выполнении задач в рамках спринта
Примеры DoR для релиза

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

DoD (Definition of Done) — критерии готовности PBI к передаче в эксплуатацию.

Для DoD актуальны те же особенности, что для DoR:

  • Могут применяться как к любому PBI, так и к релизам и спринтам
  • Одинаковы для всех US (спринтов, релизов) в проекте
  • Определяются командой до начала первого спринта
  • Могут видоизменяться в рамках работы команды (обычно в рамках ретроспективы)
DoD для US
В контексте US критерии DoD — перечень условий, которым должна соответствовать US для того, чтобы её можно было передать в эксплуатацию пользователям.

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

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

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

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

  • Все US в спринте соответствуют критериям DoD
  • Проектная документация актуализирована в соответствии с изменениями продукта
  • Тест-кейсы актуализированы в соответствии с изменениями продукта
  • Проведена ретроспектива по спринту
Примеры DoD для релиза

  • Весь код, связанный с релизом, успешно развернут в production-окружении
  • Релиз проходит все smoke-тесты с пользовательскими данными
  • Служба поддержки обучена особенностям новой функциональности
  • Release Notes написаны
  • Владелец продукта принял релиз
Acceptance Criteria
АС (Acceptance Criteria) — критерии приёмки результата реализации US. AC относится к требованиям, которым должен соответствовать продукт и представляет собой список условий, которые должны выполняться, чтобы US удовлетворяла требованиям пользователей. Для каждой US продукта AC будут уникальными.

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

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

Например, для US «Поиск товара на сайте в рамках заданного ценового диапазона» AC могут быть такими:

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

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

Критерии готовности (DoD, DoR) и критерии приёмки (AС) являются важными элементами гибких методологий.

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

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

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

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


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