Источник: https://systems.education/dor_dod_ac Сравнительная таблица: DoR, DoD, AC В таблице ниже собрана основная информация про DoR, DoD и AC (в контексте US): определения, особенности создания и использования, примеры. Definition of Ready (DoR) Definition of Done (DoD) Acceptance Criteria (АС) Готовность (подготовленность) User Story к передаче в работу Готовность User Story к передаче в эксплуатацию. Критерии приёмки результата реализации US DoR — контрольный список команды, позволяющий убедиться, что у вас есть всё необходимое для начала работы над User Story. DoD — контрольный список команды, обеспечивающий ясность и однородность в определении всеми членами команды того, что работа над User Story полностью завершена. AC — список условий, которые должны выполняться для US, чтобы она удовлетворяла потребностям пользователя и соответствовала ожиданиям заказчика. Какие Одинаковые для всех User Stories продукта. Уникальные для каждой User Story. Кто формирует Команда разработки Если DOR и DoD являются частью единых стандартов организации, все команды должны использовать их в качестве необходимого минимума, но могут дополнять своими критериями. Если эти критерии не определены стандартами организации, то команда должна создать свои DoR и DoD, подходящие разрабатываемому продукту. Команда разработки, владелец продукта Для написания AC используются практики: Product Backlog Refinement (PBR) и Three amigos. Когда формируется Первоначальное формирование перечня критериев должно быть проведено до первого спринта, уточнения и изменения в критерии вносятся на основании решения команды (например, во время ретроспективы). Критерии приёмки составляются до передачи User Story в разработку. Что дальше Когда User Story стала соответствовать DoR, она передаётся в разработку. Когда User Story стала соответствовать DoD, появляется инкремент продукта. Если US соответствует AC, она считается выполненной. Работу над US можно завершить. Если US не соответствует критериям Если User Story не соответствует критериям подготовленности, её нельзя включать в бэклог спринта. Если в рамках планирования спринта US не соответствует DoR, она возвращается на доработку. Если User Story не соответствует критериям готовности, её нельзя выпускать или даже демонстрировать на обзоре спринта. Если на момент формирования состава релиза US не соответствует DoD, она возвращается в бэклог продукта. Если по завершении спринта US не соответствует AC, US не может считаться выполненной. Такая US переносится в следующий спринт, или возвращается в бэклог продукта, или вообще удаляется, если потеряла актуальность. Примеры ● US имеет описание, понятное всей команде. ● Реализация US соответствует Acceptance Criteria. ● Все необходимые для реализации ресурсы, технические спецификации и прототипы доступны. ● Код, связанный с историей протестирован и отлажен. Я хочу искать товар в пределах установленного диапазона стоимости ● Документация истории создана или обновлена. Чтобы найти подходящие мне товары в моей ценовой категории ● Все зависимости от других US зафиксированы. ● US приоритезирована и оценена командой. ● Команда договорилась об Acceptance Criteria. ● Все необходимые одобрения истории получены. ● Код, связанный с историей выложен в систему контроля версий. ● Все возможные риски оценены и предусмотрены. Для US Как пользователь ● Пользователь может установить диапазон цены с клавиатуры. ● Пользователь может установить диапазон цены поиска при помощи бегунка. ● Для активации поиска пользователь нажимает кнопку «Найти». ● Если пользователь вводит некорректный диапазон цен, система должна выдавать сообщение об ошибке и не показывать пустой список товаров. и т.д.
