User Stories & Use Cases & Acceptance Criteria
User Story (US)
Краткая формулировка ожидания пользователя от системы. US самих по себе, как правило, недостаточно для описания ФТ. Они носят верхнеуровненый характер и полезны для определения и согласования скопа проекта с заказчиком и внутри команды, планирования и приемки.
Классический формат US:
Например,
Я как пользователь, хочу сортировать товары в каталоге, чтобы мне было удобнее выбирать товары по определенным признакам.
Критерии хорошей US:
- Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке;
- Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации;
- Valuable — ценная для клиентов, бизнеса и стейкхолдеров;
- Estimable — оцениваемая по сложности и трудозатратам;
- Small — компактная, может быть сделана командой за одну итерацию;
- Testable — тестируемая, имеет критерии приемки.
Задание 1: составить User Stories для процесса оформления заказа на сайте используя шаблон (от выбора товаров на витрине и добавления их в корзину до оплаты заказа и перенаправления пользователя на thank you page).
Use Case (UC)
Cценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний.
Пример: UC ADD_DOC Добавление нового документа
Задание 2: составить список UCs для USs, определенных в задании 1. Описать один из UC.
Критерии готовности и приемки: DoR, DoD и Acceptance Criteria
Definition of Ready (DoR) – критерий готовности задачи к тому, чтобы взять ее в работу. Как правило, Definition of Ready будет одинаковым для всех задач в проекте. Для этого на старте надо договориться, что именно должно быть в задаче, чтобы ее можно было реализовать. Например, задачу берем только при четко обозначенном измеримом результате, задача не должна превышать 16 часов (иначе надо бить на отдельные задачи), постановка/фз должны быть согласована старшим аналитиком и владельцем процесса и т.п.
Пример DoR:
- Создана задача в JIRA, проставлены корректные теги;
- Для задачи подготовлено и согласовано BRD;
- Для задачи подготовлено и согласовано ФЗ;
- Для задачи определены критерии приемки (Acceptance Criteria);
- Задача оценена и ее оценка не превышает 40 стори поинтов;
- Определены зависимости от других задач.
Definition of Done (DoD) – критерий полной готовности задачи. Так же как и Definition of Ready, обычно одинаков для всех задач в проекте. Для этого на старте нужно сесть и договориться, в каком случае считается, что задача закрыта. Например, выполнена разработка, код залит в репозиторий, проведено тестирование, выполнена установка на прод, функционал описан в документации.
Пример DoD:
| Разработка | Тестирование | Документация |
|---|---|---|
| Код написан и проведено ревью | Проведено QA тестирование | Функционал задокументирован |
| Юнит тесты покрывают 75% кода | Пройдены UI тесты | Подготовлены пользовательские инструкции |
| Функционал смержен с главной веткой | Функционал принят Владельцем продукта | Подготовлен план выкатки на прод |
Acceptance Criteria (AC) – критерий того, что задача не просто готова, а еще и работает так, как надо заказчику. В отличие от Definition of Done и Definition of Ready, Acceptance Criteria для каждой задачи будут уникальными, написанными специально для нее.
Пример AC:
User Story: Как клиент, я хочу зарегистрироваться, чтобы начать совершать покупки онлайн.
Acceptance Criteria:
- Пользователь может отправить форму регистрации только после того, как заполнены все обязательные поля;
- Email должен быть уникальным;
- Отправка формы с одного IP в течении 30 минут возможна только 3 раза;
- Пользователь получает уведомление по email после успешной регистрации.