21 lines
2.7 KiB
Markdown
21 lines
2.7 KiB
Markdown
---
|
||
title: Acceptance Criteria
|
||
localeTitle: Критерии приема
|
||
---
|
||
## Критерии приема
|
||
|
||
Пользовательская история, как элемент в вашем отставании, является заполнителем для разговора. В этом разговоре, владелец продукта и команда доставки достигнут понимания желаемого результата.
|
||
|
||
Критерии приема сообщают команде доставки, как должен вести себя код. Избегайте написания **«Как»** пользовательской истории; придерживайтесь **«Что»** . Если команда следит за развитием тестирования (TDD), она может служить основой для автоматических тестов. Критерии принятия будут началом плана тестирования для команды QA.
|
||
|
||
Самое главное, если история не соответствует каждому из критериев приема, то владелец продукта не должен принимать историю в конце итерации.
|
||
|
||
Критерии приемлемости можно рассматривать как инструмент защиты Команды доставки. Когда Группа доставки обязуется фиксировать множество историй в планировании Спринта, они фиксируют также набор критериев приемлемости. Это помогает избежать ползучести.
|
||
|
||
Рассмотрим следующую ситуацию: при принятии пользовательской истории владелец продукта предлагает добавить то, что не входит в сферу истории пользователя. В этом случае команда доставки может отклонить этот запрос (как бы мала она ни была) и попросить владельца продукта создать новую историю пользователя, о которой можно позаботиться в другом Sprint.
|
||
|
||
#### Дополнительная информация:
|
||
|
||
Nomad8 предоставляет [FAQ по критериям приема](https://nomad8.com/acceptance_criteria/)
|
||
|
||
Продвинутый переход на [критерии приема](https://www.leadingagile.com/2014/09/acceptance-criteria/) |