Понятие
User Story описывает функции продукта, нужные пользователю.
Форма подачи: повседневный или деловой язык пользователя.
Суть: описание требований к разрабатываемой системе.
Подход: BDD (Behavior-driven development - "разработка через поведение").
Применимо: гибкие методологии разработки на начальных этапах выявления и уточнения потребностей.
Ответственный за формулировки: клиент/заказчик/стейкхолдер.
Похожий инструмент: сценарии, варианты использования (Use Case) (более подробны, цельны, формализованы, описание агентов и взаимодействий). User story vs Use Case
Графическое представление: прецеденты (use case) UML.
Метод представления: карточки (короткие записи/истории, кусочки бизнес-ценности);
Использование: пользовательские истории приоритизируется клиентом, разбиваются на задачи и оцениваются разработчиком, приемочное тестирование по каждой истории.
Плюсы и минусы User Story
Плюсы
- фокус на пользователях;
- понятны всей команде, заставляют думать как пользователь;
- декомпозиция по историям, подходит для гибких методов разработки.
Минусы
- не заменит требований (могут не затрагивать важных нефункциональных требований);
- часто можно по-разному интерпретировать (при недостаточности деталей).
Критерии INVEST для User Story
Оценка по шести критериям, которые сформулировал Билл Уэйк:
кратко (S) формулировать независимые (I) истории при обсуждении (N), выражать ценность (V) для пользователя, создавать истории, которые можно оценить (E) и протестировать (T)
Как формулировать User Story
Классический шаблон:
- КАК <категория пользователей>
- ХОЧУ <иметь возможность действовать>
- ЧТОБЫ <получить результат или ценность>
Как пользователь, который часто пользуется приложением, я хочу, чтобы при зависании системы несохраненные файлы не терялись.
Шаблоны возможности или ограничения:
- <Роль> должен иметь <возможность> в <показатель производительности> c < момента отсчета> в <условия эксплуатации>, чтобы <ценность>.
Администратор клиники должен иметь возможность просмотреть данные о прошлых и запланированных посещениях пациента в течение 3 секунд после определения личности клиента по номеру телефона входящего звонка, чтобы добавить новое или изменить запланированное посещение.
- <Система> должна <выполняемая функция> <объект> каждые <производительность> <единица измерения>, чтобы <ценность>.
CRM-система должна отправлять СМС-напоминание клиенту о предстоящем посещении за сутки перед посещением, чтобы он помнил о приеме и пришел вовремя.
Критерии приёмки и ограничения:
Критерии приёмки - условия, которые должны быть выполнены, чтобы история считалась завершённой. Глубина и подробности критериев приёмки зависят от потребностей команды.
Ограничения определяют, что невозможно, не разрешено или не может быть сделано в рамках конкретной истории. Ограничивают возможности или функции.
Советы по написанию
- Фокусироваться на преимуществах для пользователя;
- Создавать небольшие и выполнимые истории;
- Добавлять детали в критерии приёмки.