Критерии приемки для агильных пользовательских историй

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

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

Давайте погрузимся в критерии приемки.

Что такое критерии приемки?

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

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

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

Критерии приемки могут включать детали, такие как

  • Опыт пользователя
  • Влияние текущей пользовательской истории на существующие функции
  • Ключевые показатели производительности, такие как скорость
  • Что пользовательская история должна делать

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

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

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

1. Критерии приемки должны быть написаны с точки зрения пользователя

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

2. Критерии должны быть четкими и краткими

Критерии приемки не должны путать с тестовыми случаями или документацией. Важно, чтобы ваши критерии были как можно проще и понятнее.

3. Все должны понимать ваши критерии приемки

Если ваши разработчики не могут их понять, ваши критерии бесполезны. Если вы не уверены в ясности, потратьте время на вопросы и внесите корректировки, пока все не станет понятным.

4. Критерии приемки не касаются того, как (Как?), а касаются того, что (Зачем?)

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

5. Критерии приемки должны быть конкретными, но не должны быть еще одним уровнем детализации

Рассмотрим программное обеспечение для подачи налоговой декларации. Самое важное требование — правильно рассчитать сумму налога, подлежащего уплате, на основе доходов и расходов. Ясно, верно? И вы знаете, что нельзя протестировать каждую возможную комбинацию — потому что возможностей почти бесконечно много.

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

6. Критерии приемки могут быть переформулировкой пользовательской истории с точки зрения пользователя

Это относится только к тому случаю, когда пользовательская история не является чрезмерно сложной. Вот пример, о котором я говорю.

Для пользовательской истории, такой как «Я, финансовый сотрудник, хочу принимать счета, чтобы отслеживать все финансовые отчеты”

Его критерии приемки могут быть «Когда я выполняю действие «принять», счет принимается (подтверждается проверкой записи счета)”

Дано/Когда/То Шаблон критериев приемки

Чтобы облегчить жизнь, вот простой шаблон, который вы можете использовать для написания критериев приемки:

Дано [контекст] когда [выполняется конкретное действие] то [должны произойти определенные последствия]

Примеры критериев приемки

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

“Я, писатель, хочу получать уведомления, когда другие добавляют комментарии, чтобы быть в курсе событий.”

Вот три примера критериев приемки для приведенной выше пользовательской истории:

  1. Дано мой телефон заблокирован когда приложение не открыто, то я должен получить уведомление в виде баннера.
  2. Дано я пишу документ когда приложение открыто, то значок колокольчика должен обновиться, чтобы показать непрочитанные уведомления с количеством.

Пример – отправка обратной связи на веб-сайте

Мы определяем пользовательскую историю и критерии приемки для функции комментариев в блоге. Войдя в систему, пользователи могут добавлять комментарии. Пользовательская история для функции «Добавить комментарий» будет следующей:

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

Критерии приемки для этой функции:

Сценарий: Зарегистрированный пользователь оставляет комментарий к посту в блоге
Учитывая, что я зарегистрированный пользователь,
Когда я открываю страницу, содержащую конкретный пост в блоге,
Тогда система отображает раздел «Комментарии» под постом блога, показывая список комментариев, добавленных другими пользователями.
Система отображает поле «Добавить комментарий» в верхней части раздела «Комментарии».
Когда я заполняю поле «Добавить комментарий» своим комментарием и нажимаю кнопку «Отправить»,
Тогда система сохраняет мой комментарий.
Система отображает мой комментарий в верхней части раздела «Комментарии».
Система отображает мое имя пользователя и аватар слева от моего комментария.
Система отображает значки «Удалить» и «Редактировать» с противоположной стороны моего комментария.

 

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

 

Leave a Reply