Введение
User Story (пользовательская история) — это короткое описание функциональности или требования к системе, написанное с точки зрения конечного пользователя. Основная цель пользовательских историй — описать конкретные потребности и цели пользователей, которые система должна удовлетворить.
US как инструмент agile-разработки способствует гибкому и пошаговому развитию функциональности, ориентированному на потребности пользователей.
Основные концепции
Что такое User Story?
User Story представляется в формате короткого текстового предложения:
Как [кто], я хочу [что], чтобы [зачем]
Основные элементы пользовательской истории:
«Кто» — роль пользователя или актер, для которого предназначена функциональность.
«Что» — действие или функция, которую пользователь получит, выполнив это действие.
«Зачем» — цель или польза (ценность), которую пользователь получит, выполнив это действие.
User Story с ценностью vs Обычная User Story
Важно понимать разницу между формальным написанием истории и историей, которая несет реальную бизнес-ценность.
| Элемент | Обычная User Story | User Story с конечной ценностью |
|---|---|---|
| Кто | Я как корпоративный клиент | Я как корпоративный клиент |
| Ситуация | (Контекст часто опущен) | «Не понимаю в каком состоянии счет и из-за этого ухожу в минус» – боль клиента |
| Что | Хочу скачивать отчет о движениях денежных средств | Хочу останавливать работу, если баланс стал критично низким |
| Зачем | Чтобы видеть, что баланс стал отрицательным | Чтобы не терять деньги |
В первом случае пользователь просто получает отчет (инструмент), во втором — решает конкретную бизнес-проблему (предотвращает убытки).
Что такое Acceptance Criteria?
Критерии приемки (Acceptance Criteria) — это набор предопределенных требований, которым должна соответствовать функциональность, чтобы пользовательская история была принята командой. Они определяют границы User Story и помогают команде понять, когда история завершена.
Критерии приемки должны быть конкретными, измеримыми, достижимыми, релевантными и ограниченными по времени (SMART).
Практические примеры
Пример 1: E-commerce
User Story:
Как покупатель, я хочу добавлять товары в корзину, чтобы купить их позже.
Acceptance Criteria:
- Я могу добавить товар в корзину с карточки товара.
- Я могу добавить товар в корзину со страницы каталога.
- Когда я добавляю товар в корзину, я вижу уведомление, что товар добавлен.
- Количество товаров в иконке корзины обновляется после добавления нового товара.
- Я могу добавить в корзину не более 10 единиц одного товара.
Пример 2: Система бронирования
User Story:
Как путешественник, я хочу фильтровать отели по цене, чтобы найти вариант, соответствующий моему бюджету.
Acceptance Criteria:
- Я могу видеть фильтр по цене на странице с результатами поиска отелей.
- Фильтр представляет собой ползунок с минимальной и максимальной ценой.
- При изменении положения ползунка список отелей автоматически обновляется.
- Если отелей в заданном ценовом диапазоне не найдено, я вижу сообщение «Отели не найдены».
Пример 3: Социальная сеть
User Story:
Как пользователь, я хочу загружать фотографии в свой профиль, чтобы поделиться ими с друзьями.
Acceptance Criteria:
- Я могу загрузить до 5 фотографий одновременно.
- Поддерживаемые форматы: JPG, PNG.
- Максимальный размер каждой фотографии — 10 МБ.
- Во время загрузки я вижу индикатор прогресса.
- После успешной загрузки фотографии появляются в моем профиле.
- Если загрузка не удалась, я вижу сообщение об ошибке с указанием причины.
Типичные ошибки и как их избежать
| Ошибка | Как избежать |
|---|---|
| Слишком общие User Story | Декомпозируйте большие истории на более мелкие и конкретные. |
| Отсутствие или нечеткие Acceptance Criteria | Всегда определяйте четкие и измеримые критерии приемки до начала разработки. |
| User Story описывает техническую реализацию | Фокусируйтесь на потребностях пользователя, а не на том, как это будет реализовано. |
| Acceptance Criteria слишком сложные | Критерии должны быть простыми и понятными для всей команды. |
Связь с другими темами
User Story и Acceptance Criteria тесно связаны с другими практиками гибкой разработки, такими как:
Agile и Scrum: User Story являются ключевым элементом бэклога продукта в Scrum.
BDD (Behavior-Driven Development): Acceptance Criteria часто пишутся в формате Gherkin (Given-When-Then), что позволяет автоматизировать их тестирование.
Use Cases: User Story можно рассматривать как упрощенную версию Use Case.
Заключение
User Story и Acceptance Criteria — мощные инструменты, которые помогают командам создавать продукты, действительно нужные пользователям. Они способствуют лучшему пониманию требований, улучшают коммуникацию в команде и повышают качество конечного продукта. Правильное использование этих практик позволяет сфокусироваться на ценности для пользователя и избежать многих распространенных проблем в разработке.