Чем критерии приёмки пользовательской истории отличаются от Definition of Done?
Критерии приёмки описывают, какое поведение и какой результат должны быть выполнены именно для данной пользовательской истории. Definition of Done — это общий для команды набор условий, при котором любая работа считается завершённой и готовой к поставке. История может удовлетворять своим критериям приёмки, но оставаться незавершённой, если не выполнены общие условия Definition of Done.
Эти два уровня контроля появились из разных потребностей гибкой разработки. Критерии приёмки сделали ожидания конкретного заказчика проверяемыми для отдельной функции, а Definition of Done помогло командам одинаково понимать слово «готово».
Без общего определения готовности команда могла считать задачу завершённой сразу после написания функциональности, тогда как тестирование, документация или интеграционная проверка оставались на потом. Без критериев приёмки, напротив, команда могла формально выполнить общий процесс, но реализовать не тот пользовательский результат.
Рассмотрим историю: «Как оператор, я хочу выгружать отчёт за выбранный период, чтобы анализировать продажи». Критерии приёмки могут определить допустимый период, состав данных, формат файла и поведение при отсутствии результатов.
Definition of Done может требовать, чтобы код прошёл ревью, автоматические и регрессионные проверки были успешны, требования были отражены в документации, а результат был проверен в целевой среде. Если смешать эти уровни, критерии конкретной истории станут перегруженными общими процессными правилами либо команда начнёт считать историю готовой слишком рано.
Критерии приёмки отвечают на вопрос: «Как убедиться, что эта история решает нужную пользовательскую задачу?» Они должны быть специфичны для истории и описывать наблюдаемый результат. Их проверяет заказчик, аналитик, тестировщик или другой согласованный участник приёмки.
Definition of Done отвечает на вопрос: «Каким общим условиям должна соответствовать любая завершённая работа?» В него могут входить обязательные проверки качества, ревью, обновление документации, соблюдение требований безопасности и готовность к развёртыванию — состав зависит от договорённостей команды и проекта.
Критерии приёмки влияют на функциональную корректность конкретной истории. Definition of Done задаёт минимальный уровень качества и полноты поставки. Поэтому критерии приёмки обычно хранят рядом с историей, а Definition of Done действует как общая политика команды или продукта.
Эти понятия не заменяют друг друга. Прохождение критериев приёмки не компенсирует невыполненное ревью или проваленные проверки качества, а соблюдение Definition of Done не доказывает, что реализован правильный бизнес-сценарий.
Есть и важное ограничение: Definition of Done не должно превращаться в чрезмерно подробный список шагов реализации. Оно фиксирует обязательный результат и качество, но не навязывает команде единственный способ его достигнуть. Критерии приёмки также не должны описывать внутреннюю архитектуру, если это не является частью проверяемого требования.
Для истории о выгрузке отчёта команда рассмотрела два варианта. Первый — включить в критерии приёмки пункты «код прошёл ревью» и «выполнен регрессионный тест». Плюс варианта — всё находится в одном месте, но минус — критерии становятся зависимыми от процесса и повторяются в каждой истории.
Второй вариант — оставить в критериях только поведение отчёта: период задаётся пользователем, выгрузка содержит согласованный набор полей, при пустом результате показывается понятное уведомление. Общие проверки вынести в Definition of Done.
Выбрали второй вариант. В результате заказчик получил прозрачный способ принять именно отчёт, а команда — единый контроль качества для всех историй. Если конкретная история требует дополнительного условия, например проверки производительности выгрузки большого периода, его добавляют в критерии этой истории или в отдельное требование, не изменяя общее Definition of Done без необходимости.
Да. Она может удовлетворять всем своим критериям приёмки, но не соответствовать Definition of Done, например из-за непройденного регрессионного тестирования или отсутствия обязательного ревью. В таком случае функциональный результат подтверждён, однако команда не должна считать работу завершённой для поставки.
Да, если они относятся к конкретной истории и имеют проверяемый результат. Например, ограничение времени формирования именно этого отчёта может быть критерием приёмки. Общие требования, одинаковые для всех функций, целесообразнее закрепить в Definition of Done или в общих нефункциональных требованиях продукта.
Нужно проверить, корректно ли сформулирована сама история и отражает ли она потребность пользователя. Критерии приёмки доказывают соответствие согласованному поведению, но не гарантируют ценность решения, если исходная потребность была понята неверно. В таком случае аналитик должен пересмотреть формулировку истории, ожидаемый результат и, при необходимости, согласовать новые критерии с заказчиком.