Школа
системного анализа
и проектирования
системного анализа
и проектирования
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-подхода и хорошо владеющих его терминологией и практиками. Прочитав статью, вы поймете, как использовать все типы критериев готовности и приёмки для создания качественного продукта.
В статье мы рассмотрим особенности создания и применения каждого из критериев, разберём в чём разница и сходство DoR, DoD и AC, приведём примеры.
Статья полезна аналитикам, владельцам продуктов, менеджерам и тестировщикам, работающим с User Story в рамках Agile-подхода и хорошо владеющих его терминологией и практиками. Прочитав статью, вы поймете, как использовать все типы критериев готовности и приёмки для создания качественного продукта.
Время на чтение статьи: 10 минут
Воркшоп Сергея Медведева
«Основы бизнес-анализа и
разработки требований в Agile»
Научитесь описывать постановку задачи на разработку продукта в наглядной форме, не залезая в детали реализации
«Основы бизнес-анализа и
разработки требований в Agile»
Научитесь описывать постановку задачи на разработку продукта в наглядной форме, не залезая в детали реализации
Agile-контекст
Для того, чтобы лучше понять специфику критериев, стоит вспомнить некоторые из понятий гибких фреймворков разработки ПО.
Бэклог
Один из основных артефактов в гибких подходах к разработке ПО — бэклог. В проекте может быть несколько видов бэклогов:
Некоторые команды выделяют также бэклог релиза — перечень функций продукта, которые должны быть реализованы для конкретного релиза. В команде, которая достигла определенного уровня agile-зрелости, бэклог спринта будет совпадать с бэклогом релиза. Поэтому бэклог релиза — необязательный артефакт продукта и не фигурирует в Scrum Guide, но может использоваться в рамках командной договоренности.
- Бэклог продукта — это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта. Это все функции продукта, которые вы хотите реализовать, расположенные в порядке их важности.
- Бэклог спринта — это наглядная и доступная в режиме реального времени картина работы, которую команда разработки планирует выполнить в течение спринта. В бэклог спринта попадают наиболее приоритетные функции продукта.
Некоторые команды выделяют также бэклог релиза — перечень функций продукта, которые должны быть реализованы для конкретного релиза. В команде, которая достигла определенного уровня 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 графически можно изобразить так:
Связь критериев готовности и критериев приёмки с этапами ЖЦ 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 (Планирование итераций), подробнее об этом этапе в таблице выше.
В контексте 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 должны быть определены командой перед тем, как начнется первый спринт, но могут дополняться в процессе работы над продуктом. Пересмотр DoR обычно проводится в процессе ретроспектив.
Примеры DoR для спринта
- Все пользовательские истории, выбранные для спринта, оценены и имеют DoR
- У команды определены цели и ожидаемые результаты для спринта
- Вся необходимая документация и дизайн доступны
- Команда имеет доступ к необходимым ресурсам, таким как серверы, тестовые данные и так далее
- Команда имеет определённый бюджет и ресурсы для выполнения спринта
- Команда имеет понимание требований продукта и его структуру
- Команда имеет определённый план спринта и понимает, как он будет реализован
- Команда имеет определённую методологию разработки, такую как Scrum или Kanban
- Команда имеет общее понимание того, какие задачи будут выполнены в течение спринта и кто за них ответственен
- Команда имеет определённую систему отслеживания прогресса и отчётности о выполнении задач в рамках спринта
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), подробнее об этом этапе в таблице выше.
Если не вся команда однозначно понимает понятие «готовности», может произойти такое, что US объявлена готовой к выпуску в рамках релиза, но на самом деле не все необходимые работы были выполнены. Это может увеличить Time To Market продукта. Использование DoD позволяет уменьшить вероятность возникновения таких ситуаций.
В рамках жизненного цикла US DoD нужны на этапе 5 (Проверка и приёмка User Story), подробнее об этом этапе в таблице выше.
Примеры DoD для US
- Реализация US соответствует Acceptance Criteria
- Код, связанный с историей протестирован и отлажен
- Документация истории создана или обновлена
- Все необходимые одобрения истории получены
- Код, связанный с историей выложен в систему контроля версий
- Все возможные риски оценены и предусмотрены
DoD для спринта и релиза
В контексте спринта DoD — список условий, которые должны выполняться для завершения спринта.
Примеры DoD для спринта
Также как и DoR для релиза, в некоторых командах могут быть установлены 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 Acceptance Criteria позволяет упростить процессы разработки и тестирования через однозначное понимание командой требований, которым должен удовлетворять продукт.
В рамках жизненного цикла US AC нужны на этапе 5 (Проверка и приёмка User Story). С помощью AC US проверяется на соответствие требованиям пользователей и заказчика.
Предположим, что команда работает над такой US:
Как пользователь
Я хочу искать товар в пределах установленного диапазона стоимости
Чтобы найти подходящие мне товары в моей ценовой категории
Для этой US критерии приёмки могут быть следующими:
Подробнее об AC говорим в этой статье.
- Пользователь может установить диапазон цены с клавиатуры
- Пользователь может установить диапазон цены поиска при помощи бегунка
- Для активации поиска пользователь нажимает кнопку «Найти»
- Если пользователь вводит некорректный диапазон цен, система должна выдавать сообщение об ошибке и не показывать пустой список товаров
- Результаты поиска должны быть точными и соответствовать установленному диапазону цен, по умолчанию отображаются в порядке возрастания цены
- Результаты поиска разбиваются по 10 штук на странице, обеспечивается переход на предыдущие или следующие страницы при помощи ссылок
Подробнее об AC говорим в этой статье.
Сравнительная таблица: DoR, DoD, AC
В таблице ниже собрана основная информация про DoR, DoD и AC (в контексте US): определения, особенности создания и использования, примеры. Также вы можете скачать эту таблицу в pdf формате.
Резюме
Критерии готовности (DoD, DoR) и критерии приёмки (AС) являются важными элементами в гибких подходах к разработке.
Несмотря на то, что критерии часто путают при поверхностном рассмотрении, они значимо различаются и используются на разных этапах жизненного цикла US.
Безусловно, одно лишь применение критериев готовности и приёмки не гарантирует того, что создаваемый вами продукт будет качественным. Для того, чтобы продукт приносил максимальную пользу, необходимо комплексно использовать различные техники и принципы. Например, для формулирования полных US с понятной бизнес-ценностью, рекомендуем вам вспомнить о принципе INVEST. Также полезно будет вспомнить о техниках Impact Mapping (техника раскрытия целей продукта) и User Story Mapping (планирование реализации пользовательских историй).
Несмотря на то, что критерии часто путают при поверхностном рассмотрении, они значимо различаются и используются на разных этапах жизненного цикла US.
- DoR — общие критерии готовности (подготовленности) US (или спринта, релиза) к передаче в работу команде разработки.
- DoD — критерии готовности US (или спринта, релиза) к передаче в эксплуатацию конечным пользователям.
- АС — критерии приёмки результата реализации US.
Безусловно, одно лишь применение критериев готовности и приёмки не гарантирует того, что создаваемый вами продукт будет качественным. Для того, чтобы продукт приносил максимальную пользу, необходимо комплексно использовать различные техники и принципы. Например, для формулирования полных US с понятной бизнес-ценностью, рекомендуем вам вспомнить о принципе INVEST. Также полезно будет вспомнить о техниках Impact Mapping (техника раскрытия целей продукта) и User Story Mapping (планирование реализации пользовательских историй).
Воркшоп Сергея Медведева
«Основы бизнес-анализа и
разработки требований в Agile»
Научитесь описывать постановку задачи на разработку продукта в наглядной форме, не залезая в детали реализации
«Основы бизнес-анализа и
разработки требований в Agile»
Научитесь описывать постановку задачи на разработку продукта в наглядной форме, не залезая в детали реализации
Автор
Татьяна Арсланова
Системный аналитик
- 15 лет в ИТ
- Старший системный аналитик расчëтного центра (банк)
- Ex-ведущий BA/SA, лид группы аналитиков, проекты группы компаний «Татнефть» в областях: инновационная и новаторская деятельность, НИОКР, тиражирование лучших практик, расчëт эффективности инновационных проектов
- Соавтор патента «Система для управления интеллектуальными ресурсами предприятия» (RU 2 602 972 C2)
- Scrum.org, Professional Scrum Master™