User Story
User Story (пользовательская история) - это краткое описание функциональности продукта, составленное с точки зрения пользователя и написанное простым, неформальным языком. Это не техническое задание в классическом понимании, а способ зафиксировать, какую ценность получит пользователь от новой функции и почему она ему нужна.
User Story - ключевой инструмент в гибких методологиях разработки (Agile, Scrum), позволяющий командам фокусироваться на реальных потребностях пользователей, а не на технических деталях реализации.
Суть и назначение User Story
[править]Основная цель User Story - сместить внимание команды с технических аспектов («как сделать») на пользовательскую ценность («зачем делать» и «что это даст»). Она помогает ответить на вопросы:
- Кто является целевым пользователем?
- Что именно он хочет сделать?
- Зачем ему это нужно, какую проблему это решит?
User Story служит отправной точкой для обсуждения задачи в команде. Она запускает диалог между продакт-менеджерами, разработчиками, дизайнерами и тестировщиками, позволяя совместно найти наилучшее решение.
Пример: Вместо формулировки задачи «Добавить кнопку фильтра по цвету» (описание интерфейса), User Story будет звучать так: «Как покупатель, я хочу фильтровать товары по цвету, чтобы быстрее находить то, что мне подходит». Вторая формулировка сразу раскрывает ценность для пользователя.
Структура User Story
[править]Классическая формула User Story выглядит следующим образом:
Как [роль / тип пользователя], я хочу [действие / цель], чтобы [ценность / выгода].
Разберём каждый компонент:
- Роль: Кто является пользователем? Важно определить конкретную роль или сегмент аудитории, для которого создаётся функция. Это может быть «новый пользователь», «зарегистрированный покупатель», «менеджер по продажам».
- Действие: Что именно пользователь хочет сделать? Опишите конкретную задачу, которую он пытается выполнить с помощью продукта.
- Ценность: Зачем ему это нужно? Какую проблему это решит или какую выгоду принесёт? Это самый важный пункт, который проверяет необходимость разработки.
Примеры хороших User Story:
- Как новый пользователь, я хочу посмотреть демо-версию без регистрации, чтобы понять, подходит ли мне сервис.
- Как покупатель, я хочу добавлять товар в корзину, чтобы оформить покупку.
- Как специалист отдела кадров, я хочу создать карточку кандидата, чтобы зафиксировать его данные и наполнить базу.
- Как геймер, я хочу переносить настройки чувствительности мыши между играми одним нажатием, чтобы не тратить время на подбор.
Критерии приемки (Acceptance Criteria)
[править]User Story сама по себе описывает лишь цель. Чтобы перейти к разработке, её необходимо дополнить критериями приемки (Acceptance Criteria). Это набор конкретных условий, при выполнении которых задача считается завершённой и работающей корректно.
Критерии приемки отвечают на вопрос: «Как мы поймём, что всё работает как надо?». Они пишутся простым языком и могут описывать как позитивные сценарии (что должно произойти), так и негативные (как система должна реагировать на ошибки).
Пример критериев приемки для User Story про изменение пароля:
- Если код введен верно, новый пароль сохраняется, пользователь видит подтверждение.
- Если код неверный - показываем ошибку, повторная отправка кода доступна через 60 секунд.
- Ссылка из письма действует 15 минут.
- Все действия записываются в журнал событий.
Критерии приемки «заземляют» абстрактные пожелания в измеримые требования и служат основой для тестирования.
INVEST: Как проверить качество User Story
[править]Для оценки качества пользовательских историй существует чек-лист INVEST, предложенный Биллом Уэйком. Хорошая User Story должна соответствовать следующим критериям:
- Independent (Независимая): Историю можно реализовать отдельно от других, она не зависит от них. Это позволяет гибко менять приоритеты.
- Negotiable (Обсуждаемая): История - это не жёсткая спецификация, а начало диалога. Детали реализации обсуждаются и уточняются командой.
- Valuable (Ценная): История должна приносить очевидную пользу пользователю или бизнесу.
- Estimable (Оцениваемая): Команда должна быть способна оценить объём работ и сложность реализации.
- Small (Небольшая): История должна быть достаточно маленькой, чтобы уложиться в один спринт (обычно 1-2 недели). Слишком объёмные истории (эпики) нужно дробить.
- Testable (Тестируемая): У истории должны быть чёткие критерии приемки, позволяющие однозначно проверить, что она работает корректно.
Место User Story в процессе разработки
[править]User Story не существует изолированно, она является частью более крупного процесса.
Все пользовательские истории собираются в бэклоге продукта - упорядоченном по приоритетам списке задач. Владелец продукта (Product Owner) отвечает за ведение бэклога и расстановку приоритетов на основе ценности историй для бизнеса и пользователей.
Спринт и планирование
[править]На встречах по планированию спринта команда выбирает из бэклога те User Story, которые сможет реализовать за следующую итерацию. Сложность историй часто оценивается в «стори-поинтах», например, с помощью «покера планирования».
Жизненный цикл User Story
[править]Путь истории от идеи до релиза включает несколько этапов:
- Создание: Продакт-менеджер формулирует историю.
- Обсуждение и проработка: Команда обсуждает детали и определяет критерии приемки.
- Оценка: Команда оценивает сложность реализации.
- Попадание в спринт: История выбирается для выполнения в текущей итерации.
- Реализация: Разработка, дизайн, настройка.
- Тестирование: Проверка соответствия критериям приемки.
- Завершение и релиз: Функция становится доступна пользователям.
Отличие от смежных понятий
[править]User Story часто путают с другими инструментами, поэтому важно понимать различия.
| Инструмент | Суть | Отличие от User Story |
|---|---|---|
| Use Case (Сценарий использования) | Подробное описание шагов взаимодействия пользователя с системой, включая альтернативные сценарии и исключения. | User Story краткая и фокусируется на цели (зачем), Use Case детальный и описывает процесс (как именно). US используется на этапе планирования, UC - на этапе проектирования. |
| Задача / Техническое задание (ТЗ) | Конкретное описание того, что и как нужно сделать разработчику. | User Story описывает проблему и ценность, а задача/ТЗ - решение. История может порождать несколько технических задач. |
| Jobs To Be Done (JTBD) | Фреймворк, изучающий глубинную мотивацию пользователя: зачем он «нанимает» продукт. | JTBD фокусируется на общей задаче («работе»), которую нужно выполнить. User Story фокусируется на конкретных функциях в рамках этой работы. Они дополняют друг друга. |
| CJM (Customer Journey Map) | Карта всего пути пользователя, от первого знакомства до лояльности, со всеми этапами и эмоциями. | CJM описывает весь маршрут. User Story описывает один конкретный шаг или задачу на этом маршруте. |
Применение User Story за пределами IT
[править]Хотя User Story чаще всего используется в разработке, этот подход полезен и в других сферах.
- В отделе продаж: для понимания потребностей клиентов и улучшения коммуникации.
- В PR и маркетинге: для создания контента, который откликается целевой аудитории, и для демонстрации ценности продукта.
- При создании контента: в брифах для авторов можно указать: «Как студент курса, прочитав эту статью, хочет понять концепцию User Story, чтобы применять её в своей работе».
