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

Определение готовности (Definition of Done, DoD)  — это список требований, которым должна соответствовать пользовательская история, чтобы команда могла считать ее завершенной.  В то время как  критерии приемлемости  пользовательской истории состоят из набора тестовых сценариев, которые должны быть выполнены, чтобы подтвердить, что программное обеспечение работает должным образом.

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

Другими словами,  для завершения пользовательской истории должны быть соблюдены как критерии DoD, так и критерии приемлемости.  Инкремент Продукта не считается завершенным, если оба этих списка не выполнены. Таким образом, нам необходимо определить два аспекта определения готовности (DOD) — критерии завершения и критерии приемки:

Определение Готово

Определение Готово структурировано как список элементов, каждый из которых используется для проверки Истории или PBI, который существует для того, чтобы гарантировать, что  Группа Разработки  соглашается с качеством работы, которую они пытаются произвести. Он служит контрольным списком, который используется для проверки  каждого элемента невыполненной работы по  продукту  (также известного как PBI) или пользовательской истории на полноту. Элементы в определении «Готово» предназначены для применения ко всем элементам в Бэклоге Продукта, а не только к одной  Пользовательской Истории . Его можно резюмировать следующим образом:

• Этот термин больше относится к приращению продукта в целом.
• В большинстве случаев этот термин подразумевает, что приращение продукта  подлежит отгрузке.
• Термин определен в Руководстве по Scrum.
• Используется как способ общения между членами команды
• Общее качество программного обеспечения
• Является ли приращение доставляемым или нет

Цели определения готовности

• Создайте общее понимание в команде о качестве и полноте
• Используйте в качестве контрольного списка, по которому проверяются пользовательские истории (или PBI).
• Убедитесь, что инкремент, отправляемый в конце  спринта  , имеет высокое качество и что его качество хорошо понимают все участники.

Пример — определение «Готово»

Например, в индустрии программного обеспечения командам может потребоваться задать некоторые из следующих вопросов, чтобы придумать свой DoD:

• Код прошел рецензирование?
• Код завершен?
• Код проверен?
• Код зарегистрирован?
• Модульные тесты пройдены?
• Пройдены функциональные испытания?
• Приемочные испытания завершены?
• Владелец продукта  рассмотрел и принял?

Критерии приемки

Пользовательские истории являются одним из основных  артефактов разработки  для  Agile-разработки , но  Scrum  явно не требует использования ни пользовательских историй, ни критериев приемлемости. Если элемент невыполненной работы по продукту считается слишком большим для включения в спринт, он обычно разбивается на пользовательскую историю, а затем на набор задач, как показано на рисунке:

Пользовательские истории инкапсулируют критерии приемки, поэтому мы часто видим, что определение готовности и критерии приемки сосуществуют в нашем процессе разработки scrum. Пользовательская история обеспечивает контекст функциональности, которую должна предоставить команда. Критерии приемки дают представление о деталях указанной функциональности и о том, как заказчик их примет. Два из них вместе обеспечивают весь результат.

Некоторые из Критериев приемки будут обнаружены в ходе Текущего уточнения невыполненной работы до начала спринта, а другие будут обнаружены сразу после  планирования спринта  , когда мы сядем, чтобы поговорить о пользовательской истории в небольшой команде. Таким образом, критерии приемлемости — это атрибуты, уникальные для пользовательской истории или элемента невыполненной работы.

• Этот термин применяется к отдельной PBI/Истории.
• Критерии приемлемости различны для каждого PBI/Story.
• Термин не определен в Руководстве по Scrum.
• Используется как способ сообщить всем участникам, что требования для конкретной PBI/истории выполнены.
• Также известные как приемочные тесты, условия удовлетворения, в некоторых случаях «тестовые случаи» и т. д.

Цели критериев приемлемости

• Уточните, что команда должна создать, прежде чем приступить к работе
• Убедитесь, что у всех есть общее понимание проблемы
• Помогите членам команды узнать, когда История завершена
• Помогите проверить Историю с помощью автоматических тестов.

Пример — критерии приемлемости

• Пользователь не может отправить форму, не заполнив все обязательные поля
• Информация из формы хранится в базе данных регистраций
• Оплата может быть произведена с помощью кредитной карты
• Электронное письмо с подтверждением отправляется пользователю после отправки формы

Пример пользовательской истории с критериями приемлемости

На рисунке ниже показан пример критериев приемлемости пользовательской истории.

использованная литература

• Определение готовности и критериев приемки
• Что такое картирование пользовательских историй?
• История пользователя и вариант использования для гибкой разработки программного обеспечения