Критерии приемки задачи: как понять, что результат можно принять

Критерии приемки задачи описывают, по каким наблюдаемым признакам результат можно принять. Они отвечают не на вопрос «что разработчик делал внутри», а на вопрос «что должно работать, отображаться, сохраняться, проверяться или подтверждаться после выполнения задачи».

Acceptance Criteria дополняют постановку задачи, но не заменяют ТЗ, Definition of Ready или Definition of Done. ТЗ задает рамку проекта или этапа, DoR показывает, что задачу можно начинать, DoD задает общий стандарт завершенности работы команды, а критерии приемки фиксируют проверяемый результат конкретной задачи.

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

• перед оценкой задачи, чтобы команда понимала объем проверки;
• перед передачей задачи в разработку или подрядчику;
• при декомпозиции требований, roadmap или ТЗ в backlog задач;
• перед демо, приемкой этапа или закрытием change request;
• при работе с Jira, YouTrack, Trello, Codex или AI coding agents, когда задача должна быть принята по явным условиям.

Definition of Ready, Acceptance Criteria и Definition of Done часто оказываются рядом, но отвечают на разные вопросы. Если их смешать, команда начинает спорить, задача уже готова к старту, готова к приемке или просто соответствует внутреннему стандарту качества.

Если нужно описать всю задачу целиком, используйте страницу как ставить задачи разработчикам. Здесь фокус уже: как написать критерии приемки результата.

Критерии не обязаны быть длинными, но должны помогать проверить результат без догадок.

• Observable outcome. Что видно пользователю, системе, интеграции, администратору или приемочной стороне.
• Основной сценарий. Как должен работать нормальный путь.
• Negative cases. Что происходит при неверных данных, запрете, отсутствии настройки, недоступности сервиса или неподдерживаемом сценарии.
• Способ проверки. Где подтвердить результат: интерфейс, API, лог, тест, отчет, документ, демо или акт.
• Границы. Что не проверяется и не входит в эту задачу.
• Данные, роли и состояния. На каких ролях, тестовых данных, контурах и ограничениях проверяется результат.

Пишите критерии через результат, а не через реализацию. Формулировка должна позволять другому человеку открыть задачу, выполнить проверку и понять, закрыт критерий или нет.

• начинайте с поведения или результата: пользователь видит, система сохраняет, API возвращает, отчет содержит;
• разделяйте основной сценарий и negative cases;
• указывайте способ проверки, если он не очевиден;
• не добавляйте в критерии новые требования, которые не входят в scope задачи;
• не превращайте критерии в список внутренних подзадач разработки.

Формулировка «обработать ошибку» почти всегда слишком общая. Разные негативные состояния требуют разных реакций интерфейса, backend, логирования, повторов и приемки.

• authRequired: пользователь не вошел в систему и должен авторизоваться.
• invalidCredentials: учетные данные неверны, сессия не создается.
• policyDenied: пользователь авторизован, но действие запрещено политикой или ролью.
• notConfigured: сценарий невозможен, потому что не задана настройка, провайдер или параметр.
• temporaryUnavailable: внешний сервис временно недоступен, нужен повтор или понятное ограничение.
• unsupported: сценарий не поддерживается в текущем scope и не должен выглядеть как поломка.

Когда эти состояния разведены заранее, приемка проверяет реальное поведение, а не общее обещание «ошибки обработаны».

Jira, YouTrack, Trello или другой backlog только фиксируют договоренность. Главный вопрос не в инструменте, а в том, есть ли в задаче проверяемый результат.

Короткий шаблон блока:

Acceptance Criteria
1. Основной результат: ...
2. Основной сценарий проверки: ...
3. Negative cases: ...
4. Способ проверки: ...
5. Out of scope: ...
6. Owner / reviewer: ...

Если критерии зависят от среды, данных или ролей, это лучше указать сразу. Не храните в задаче секреты, токены, production endpoints и значения, которые относятся только к одному окружению.

Если критерии приемки пишутся для большого списка работ, полезно отдельно договориться, как вести backlog задач: где хранить дефекты, change request, spikes, статусы, приоритеты и связи с требованиями.

• результат задачи можно проверить наблюдаемым способом;
• описан основной сценарий;
• есть negative cases для важных ошибок и ограничений;
• понятно, где и как проверяется результат;
• зафиксировано, что не входит в эту задачу;
• нет секретов, токенов, production endpoints и environment-only значений;
• понятно, кто принимает результат и кто может ответить на вопросы.

• Писать пожелания вместо проверок. «Должно быть удобно» не помогает принять результат.
• Описывать реализацию вместо результата. В критерии можно вынести техническое ограничение, но не стоит диктовать каждую внутреннюю операцию.
• Не фиксировать negative cases. Тогда ошибки всплывают только на демо или после релиза.
• Подменять acceptance criteria Definition of Done. Review, тесты и отсутствие блокирующих дефектов важны, но они не описывают конкретный результат задачи.
• Делать критерии слишком общими. Чем шире формулировка, тем больше спор на приемке.
• Добавлять новые требования во время приемки. Если меняется scope, это лучше оформлять как уточнение или change request.

Чем критерии приемки отличаются от Definition of Done?

Критерии приемки описывают, что принять в конкретной задаче. Definition of Done задает общий стандарт завершенности работы: review, проверки, отсутствие блокирующих дефектов, обновление документации при необходимости.

Нужно ли писать критерии приемки для каждой задачи?

Для мелкой технической задачи критерии могут быть короткими. Но если результат влияет на пользователя, интеграцию, данные, приемку или оценку, критерии лучше записать явно.

Можно ли писать acceptance criteria на английском?

Можно, если команда так работает и все участники одинаково понимают формулировки. Для внешней приемки и заказчика часто лучше использовать русский текст и при первом упоминании пояснить термин Acceptance Criteria.

Кто должен писать критерии приемки?

Обычно их готовит аналитик, PM, product owner, тимлид или ответственный за постановку задачи. Разработчик может уточнять формулировки, но критерии должны быть понятны принимающей стороне.

Что делать, если критерии изменились после разработки?

Сначала отделите дефект от нового требования. Если меняется ожидаемый результат или scope, зафиксируйте уточнение, change request или новую задачу, а не меняйте правила приемки задним числом.

Если нужно описать не только критерии, но и всю задачу целиком, начните со страницы как ставить задачи разработчикам. Если результат уже передан на проверку этапа, используйте приемку итерационного проекта.

Если критерии относятся к крупному объему работ, свяжите их с техническим заданием на разработку ПО и roadmap проекта из требований. Если задачу выполняет AI-агент в репозитории, проверьте также как работать с Codex в репозитории: там важны контекст, границы, проверки и финальный отчет.