Skip to main content

User Stories & Use Cases & Acceptance Criteria

User Story (US)#

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

Классический формат US:

Например,

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

Критерии хорошей US:

  • Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке;
  • Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации;
  • Valuable — ценная для клиентов, бизнеса и стейкхолдеров;
  • Estimable — оцениваемая по сложности и трудозатратам;
  • Small — компактная, может быть сделана командой за одну итерацию;
  • Testable — тестируемая, имеет критерии приемки.

Шаблон документа по US

Задание 1: составить User Stories для процесса оформления заказа на сайте используя шаблон (от выбора товаров на витрине и добавления их в корзину до оплаты заказа и перенаправления пользователя на thank you page).

Use Case (UC)#

Cценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний.

Пример: UC ADD_DOC Добавление нового документа

Шаблон Use Case

Задание 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 после успешной регистрации.