Что такое User Story: от простого определения к зрелой истории

Что такое User Story и зачем она нужна

User story — короткое описание функции программного обеспечения, написанное простым языком без деталей реализации. Каждая история укладывается в 2–3 предложения и отвечает на один вопрос: чего хочет пользователь и зачем это нужно бизнесу.

Три цели применения пользовательских историй:

• понять реального пользователя, а не абстрактного заказчика;
• расставить приоритеты через ценность, которую история приносит;
• упростить коммуникацию между бизнесом, разработчиками и тестировщиками.

В Scrum пользовательские истории хранятся в бэклоге и разбираются на планировании каждого спринта. В Kanban переходят в работу по мере освобождения команды. Обе методологии Agile используют короткие итерации (циклы разработки), что позволяет быстро адаптировать продукт к обратной связи.

Чем User Story отличается от технических спецификаций

Техническая спецификация — формальный документ с точными требованиями к поведению системы. User story намеренно оставляет детали реализации открытыми: N в INVEST расшифровывается как Negotiable (договорная). Авторы методологии называли US «обещанием разговора», а не инструкцией к исполнению.

Пользовательские истории не заменяют техническую документацию, а дополняют её: история отвечает на «зачем», спецификация — на «как именно».

Шаблон User Story: формула «Как — Я хочу — Чтобы»

Канонический шаблон:

«Как [роль], я хочу [действие], чтобы [ценность]»

Формула — каркас, а не ритуал. Без третьей части (ценности) история превращается в обычное функциональное требование: непонятно, зачем тратить ресурс команды именно на эту задачу.

Три обязательных компонента истории

Роль — кто использует функцию. Не «пользователь» в вакууме, а конкретный персонаж: читатель библиотеки, клиент банка, водитель такси. Точная роль помогает владельцу продукта (Product Owner) или бизнес-аналитику принять решение о приоритете задачи.

Действие — что пользователь хочет сделать, без указания «как» реализовать. Технический выбор решения остаётся за разработчиком.

Ценность — бизнес-результат для пользователя или компании. Без неё история не проходит критерий V (Valuable) из INVEST и не объясняет команде, зачем браться за эту задачу сейчас.

Примеры пользовательских историй по доменам

Три готовых примера с разными ролями:

• Онлайн-библиотека. «Как читатель, я хочу искать книгу по автору и названию, чтобы находить нужное издание без просмотра всего каталога.»
• Интернет-банк. «Как клиент банка, я хочу видеть текущий баланс на главном экране приложения, чтобы быстро оценивать доступные средства.»
• Такси-приложение. «Как пассажир, я хочу видеть геолокацию водителя в реальном времени, чтобы понимать, когда машина подъедет.»

Трансформация bad → good: сырая история «Как пользователь, я хочу видеть баланс» не содержит критериев приёмки и нефункциональных требований — какое время отклика приемлемо? Что показывать при ошибке сервера? Без ответов история без критериев приёмки порождает баги в продакшене до запуска фичи.

Критерии качества пользовательской истории: фреймворк INVEST

INVEST — мнемонический фреймворк оценки user story, созданный Биллом Вейком (Bill Wake) в 2003 году. Служит фильтром перед включением зрелой истории в спринт и предотвращает появление «гигантских» US, которые застревают в нескольких итерациях подряд.

Расшифровка INVEST: шесть критериев с примерами

Самый частый провал — V (Valuable): команды пишут технические задачи вроде «Как система, я хочу записать лог», забывая о конечном пользователе. Критерий T напрямую требует Acceptance Criteria: без них история не тестируема. Нарушение S — сигнал к декомпозиции, то есть разбивке на более мелкие атомарные истории.

Acceptance Criteria: как определить условия приемки

Критерии приёмки (Acceptance Criteria, AC) — набор условий, при выполнении которых user story считается завершённой. Без AC история нарушает критерий T из INVEST и не проходит DoR (Definition of Ready — чек-лист готовности к спринту). AC обеспечивают приёмочное тестирование и устраняют разночтения между разработчиком и QA.

Формат Given/When/Then и спецификация по примерам

Самый распространённый формат критериев приёмки — трёхчастная структура:

• Given (дано) — начальный контекст: состояние системы и пользователя до действия.
• When (когда) — действие пользователя.
• Then (тогда) — ожидаемый результат системы.

Спецификация по примерам (Specification by Example) конкретизирует AC реальными числами вместо общих слов. Пример: «Given клиент с суточным лимитом 100 000 ₽, When пытается перевести 101 000 ₽, Then система возвращает сообщение „Превышен суточный лимит» и блокирует операцию». Конкретные цифры устраняют споры об интерпретации до написания первой строчки кода.

Типичные ошибки при написании пользовательских историй

Пять ошибок, с которыми чаще всего сталкиваются команды:

1. История без контекста. Роль — «пользователь», ценность не указана. Команда не понимает приоритет задачи.
2. Гигантская US. Охватывает целый модуль вместо одного шага — нарушение S из INVEST. Решение — декомпозиция на атомарные истории.
3. Нет критериев приёмки. Разработчик и QA понимают «готово» по-разному — нарушение T.
4. Перегрузка одной истории. Три разные потребности в одной карточке нарушают I (Independent) и усложняют оценку.
5. Игнорирование нефункциональных требований. Время отклика, безопасность и масштабируемость не прописаны — всплывают уже после релиза.

Реальный антикейс: BBC Digital Media Initiative потерял около 100 млн фунтов стерлингов отчасти из-за размытых требований без проверяемых критериев приёмки. По данным отчёта Национального ревизионного ведомства Великобритании, 2014, проект был прекращён, не достигнув ни одной ключевой цели.

User Story Mapping: визуализация пути пользователя

Картирование пользовательских историй (User Story Map) — метод организации US на двумерной карте для приоритизации бэклога и планирования релизов. Структура трёхуровневая:

Активности: [Поиск товара] [Покупка] [Доставка]

↓ ↓ ↓

Задачи: [Фильтрация] [Корзина] [Оплата] [Отслеживание]

↓ ↓ ↓

Истории: [Фильтр по [Добавить [Оплата [Push о статусе

цене] в корзину] картой] заказа]

Верхний уровень — активности пользователя в продукте. Средний — задачи внутри каждой активности. Нижний — конкретные user story с критериями приёмки. Вертикальный срез карты образует MVP, горизонтальные срезы — последующие итерации развития. Карта наглядно связывает бэклог с реальным путём пользователя и помогает расставить приоритеты без потери контекста.

User Story, Use Case и Job Story: сравнение форматов

Job Story — формат из методологии «работы, которые нужно выполнить» (Jobs to be Done, JTBD): «Когда [ситуация], я хочу [мотивация], чтобы [результат]». Фокус — на контексте и триггере, а не на роли пользователя. Подходит для стратегического открытия продуктовых потребностей, а не для тактического планирования спринта.

Итог: user story — инструмент Agile-команд, Use Case — для Waterfall и UML-документации, Job Story — для исследований на старте продукта.

Кто работает с User Story: роли в команде

Кто пишет: Product Owner или бизнес-аналитик (BA) — формулируют историю с фокусом на ценность пользователя: «зачем», не «как».

Кто реализует: разработчик уточняет историю, оценивает объём в story points и при необходимости декомпозирует истории с нарушением критерия S.

Кто тестирует: QA-инженер создаёт тест-кейсы напрямую из Acceptance Criteria. Без AC тестировщик не знает, что именно проверять.

Three Amigos — синхронизация трёх ролей перед спринтом: BA/PM, разработчик и QA совместно уточняют историю на груминге (уточнении) бэклога. Встреча занимает 10–15 минут, но сокращает количество дефектов понимания требований на 40% — за счёт единого взгляда на историю до начала разработки.

Работа с пользовательскими историями — базовый инструмент профессии системного аналитика. В рамках федерального проекта «Активные меры содействия занятости» (нацпроект «Кадры») можно освоить профессию бесплатно, с нуля: программа «Системный аналитик: с нуля до проектирования систем» проходит онлайн с официальным документом об образовании.

Часто задаваемые вопросы

Чем User Story отличается от технического задания?

User story описывает потребность пользователя простым языком и оставляет детали реализации открытыми (N = Negotiable из INVEST) — это приглашение к диалогу, а не инструкция. ТЗ фиксирует точные системные требования. US дополняет документацию, не заменяя её.

Кто в команде пишет User Story?

Чаще всего Product Owner или бизнес-аналитик — они ближе к пользователю и понимают бизнес-ценность. В зрелых Agile-командах применяют Three Amigos: BA, разработчик и QA совместно уточняют историю за 10–15 минут перед включением в спринт.

Как понять, что User Story слишком большая?

Нарушены критерии S (Small) и E (Estimable) из INVEST: история не реализуется за 1–2 недели или не поддаётся оценке. Если переходит из спринта в спринт — это Epic. Решение — декомпозиция на атомарные истории.

Как QA-инженер использует User Story в тестировании?

QA создаёт тест-кейсы напрямую из Acceptance Criteria, особенно в формате Given/When/Then. Критерий T (Testable) из INVEST гарантирует проверяемость. Specification by Example устраняет споры об интерпретации до начала разработки.

Как User Story связана с бэклогом и спринтом?

Пользовательские истории хранятся в Product Backlog. Перед спринтом команда выбирает истории, прошедшие DoR-чек: шаблон заполнен, AC прописаны, история оценена, нет внешних блокировок.

Как выглядит User Story Map для онлайн-магазина?

Верхний уровень — активности: Поиск, Покупка, Доставка. Средний — задачи: фильтрация, корзина, оплата картой. Нижний — конкретные user story. Вертикальный срез карты образует MVP, горизонтальные срезы — итерации развития.

Обязательно ли писать User Story в Agile?

US — рекомендованный, но не единственный формат. Баги и инфраструктурные задачи оформляются без шаблона «Как, Я хочу, Чтобы». В Scrum US применяется для элементов бэклога, в Kanban — для карточек доски.

Что делать, если одна User Story зависит от другой?

Зависимость нарушает I (Independent) из INVEST — риск для спринта. Решения: переформулировать истории до независимости, зафиксировать блокировку и управлять порядком, декомпозировать обе до атомарного уровня.

Чем User Story отличается от Use Case?

Use Case — формальный документ Waterfall/UML с последовательностью действий системы. User story — 2–3 предложения о потребности пользователя без деталей реализации. US гибкая (Negotiable), Use Case подробная и фиксированная. Для Agile-команд предпочтительнее US.

Почему истории без критериев приёмки опасны?

Без AC разработчик и QA по-разному понимают «готово» — появляются баги в продакшене и бесконечные правки. Кейс BBC Digital Media Initiative: отсутствие проверяемых критериев привело к потере около 100 млн фунтов. Наличие AC — обязательный пункт DoR (Definition of Ready).