Руководство по скраму | 22. Критерии приемлемости пользовательской истории

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

Критерии приемлемости пользовательской истории — оглавление:

1. Введение
2. Как сформулировать критерии принятия пользовательских историй?
3. Критерии принятия пользовательской истории и определение готовности
4. Резюме

Введение

Мы рассмотрели User Story и проблемы, которые необходимо решить при ее создании, в предыдущих статьях. Однако сегодня мы сосредоточимся на критериях приемлемости User Story.

Критерии приемки должны соответствовать следующим рекомендациям:

• описывать новые и улучшенные функциональные возможности Продукта с точки зрения пользователя
• быть уникальным для каждой пользовательской истории

Официальное руководство по Scrum не определяет User Story и критерии ее приемлемости. Это необязательные, но очень распространенные элементы работы Scrum. Тем не менее, чтобы удовлетворить любопытство наших читателей, мы изобразим их как: Условия, которым должно соответствовать улучшение Продукта в течение данного Спринта, чтобы получить одобрение Пользователя.

Как сформулировать критерии принятия пользовательских историй?

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

Ясность и доступность критериев приемлемости

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

Запишите их вместе с критериями User Story перед планированием спринта. Каждый член Скрам-команды должен прочитать его и подтвердить, что он понимает и согласен с критериями приемлемости пользовательской истории. Обычно критерии приемки находятся на другой стороне карточки User Story.

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

Дело простое, если работа Продукта прозрачна для Пользователя. Однако чем сложнее продукт, тем сложнее его тестировать. Возьмите сложное программное обеспечение или масштабные услуги. Поэтому в большинстве случаев полезным инструментом для проверки User Story является подготовка приемочного теста.

Вступительный тест

Если вы решили разработать приемочный тест, запишите его на другой стороне карточки, содержащей User Story. Позже это может выполнить Скрам-команда или внешняя команда контроля качества.

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

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

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

Определение «Готово» — неотъемлемая часть работы в Scrum, которая является техническим эквивалентом критериев приемлемости. Однако не следует путать эти два понятия, поскольку они обозначают разные обязательства. Что такое определение «Готово» и как и когда его сформулировать — тема, которую мы рассмотрели в отдельном посте?

Здесь мы только упомянем, что Определение Готовности — это четкое и прозрачное описание ожидаемого состояния Продукта после завершения Инкремента в Бэклоге Продукта. В нем описываются улучшения, сделанные в рамках Инкремента. Это контрастирует с критерием приемлемости, соответствующим Пользовательской истории, которая описывает функциональность Продукта, созданную во время последнего Спринта, в том виде, в каком она воспринимается Заказчиком.

Например, возьмите эту пользовательскую историю с содержанием:

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

Определение завершения для приведенной выше пользовательской истории может включать следующее:

• создание панели входа для клиентов магазина
• интеграция платежной системы
• добавление кнопки моментальной оплаты в шаблон страницы товара

С другой стороны, критерии приемлемости для клиентов включают:

• возможность авторизоваться в магазине
• возможность определения метода оплаты по умолчанию
• работающая кнопка «Купить сейчас» для товара «волшебная палочка»

Резюме

Критерии приемлемости — это набор условий, которые служат способом оценки реализации пользовательской истории. Описывая новые и улучшенные характеристики Продукта с точки зрения пользователя, этот метод становится эффективным инструментом работы с Заказчиком. Он представляет производительность Скрам-команды с точки зрения пользователя.

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

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

Если вам нравится наш контент, присоединяйтесь к нашему сообществу занятых пчел в Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Автор: Кэролайн Беккер.

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

Просмотреть все сообщения

Руководство по скраму:

1. Глоссарий основных терминов, ролей и понятий
2. Что такое Скрам?
3. Скрам-ценности
4. Как внедрить Scrum в вашей компании?
5. Скрам-команда — что это такое и как она работает?
6. Кто такой владелец продукта?
7. Самые распространенные ошибки владельца продукта
8. Кто такой скрам-мастер?
9. Характеристики хорошего скрам-мастера
10. Самые распространенные ошибки скрам-мастера
11. Какую статистику и показатели должен отслеживать скрам-мастер?
12. Сотрудничество между владельцем продукта и скрам-мастером
13. Команда разработчиков в Scrum
14. Самые распространенные ошибки разработчиков
15. Скрам артефакты
16. Масштабирование Скрама
17. Бэклог спринта
18. Что такое бэклог продукта?
19. Что такое пользовательские истории?
20. Создание лучшей пользовательской истории с INVEST
21. Самые распространенные ошибки User Story
22. Критерии приемлемости пользовательской истории
23. Оценка и баллы в Scrum
24. Планирование покера
25. Игра на оценку команды
26. Определение приращения
27. Скрам-события
28. Что такое спринт в Scrum?
29. Обязательства команды Scrum — цель продукта, цель спринта и определение завершения
30. Что такое диаграмма выгорания?
31. Как создать и интерпретировать диаграмму выгорания?
32. Преимущества и недостатки диаграммы выгорания
33. Канбан-доски в Scrum и Scrumban
34. Скорость в Scrum — скорость команды разработчиков
35. Ежедневный Скрам
36. Планирование спринта
37. Обзор спринта
38. Что такое ретроспектива спринта?
39. Распространенные ошибки во время ретроспективы спринта
40. Развитие бэклога продукта