freeCodeCamp/guide/russian/agile/acceptance-criteria/index.md

---
title: Acceptance Criteria
localeTitle: Критерии приема
---
## Критерии приема

Пользовательская история, как элемент в вашем отставании, является заполнителем для разговора. В этом разговоре, владелец продукта и команда разработчиков достигнут понимания желаемого результата.

Критерии приема сообщают команде разработчитов, как должен вести себя код. Избегайте написания **«Как»** в пользовательской истории; придерживайтесь **«Что»** . Если команда следит за развитием тестирования (TDD), она может служить основой для автоматических тестов. Критерии принятия будут началом плана тестирования для команды QA.

Самое главное, если история не соответствует каждому из критериев приема, то владелец продукта не должен принимать историю в конце итерации.

Критерии приёмки - это не то же самое, что приёмочные тесты. 

Критерии приемлемости можно рассматривать как инструмент защиты Команды доставки. Когда Группа доставки обязуется фиксировать множество историй в планировании Спринта, они фиксируют также набор критериев приемлемости. Это помогает избежать ползучести.

Рассмотрим следующую ситуацию: при принятии пользовательской истории владелец продукта предлагает добавить то, что не входит в сферу истории пользователя. В этом случае команда доставки может отклонить этот запрос (как бы мала она ни была) и попросить владельца продукта создать новую историю пользователя, о которой можно позаботиться в другом Sprint.

#### Дополнительная информация:

Nomad8 предоставляет [FAQ по критериям приема](https://nomad8.com/acceptance_criteria/)

Продвинутый переход на [критерии приема](https://www.leadingagile.com/2014/09/acceptance-criteria/)