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/)
|