Определение готовности и критериев приемки в Scrum

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

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

Когда пользовательская история будет завершена?

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

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

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

Его можно резюмировать следующим образом:

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

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

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

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

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

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

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

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

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

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