Пользовательские истории в разработке

Что такое пользовательские истории или User story

В разработке и управлении продуктами пользовательская история — это простое и понятное описание одной или нескольких функций программной системы. 

Пользовательская история (User story) описывает тип пользователей, чего они хотят и почему. Этот инструмент помогает создать упрощенное описание требований, но при этом таковым не является. Требования — это другой инструмент, с более сложной структурой и описанием. 

Обычно User story используют при разработке по методологии Agile. Ранее мы писали, как происходит работа при гибком подходе. На этапе дискавери-фазы обычно разбивают разработку продукта на пользовательские истории, а не на характеристики или требования.

Зачем нужны пользовательские истории 

Пользовательские истории — это инструмент планирования. С их помощью мы определяем приоритеты, оцениваем и принимаем решение на каком этапе  (спринте) будет реализована та или иная функциональность. 

User story полезным тем, что упрощают коммуникацию. Вместо того, чтобы обмениваться документацией - начинается диалог по каждой новой фиче. Таким образом, недопониманий становится меньше, работа ведется прозрачно, а результат получается точным.

Сила пользовательских историй в том, что они дают начало диалогу. Вместо того, чтобы просто взять и передать коллегам спецификацию, которая интерпретируется сначала разработчиками, потом тестировщиками — мы начинаем обсуждение. Мы включаем в коммуникацию сотрудников с различными навыками. И так — по каждой новой фиче.

Преимущества пользовательских историй 

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

Критерии хорошей user story: модель INVEST

Чтобы история была пригодна к работе, её проверяют по шести критериям:

Критерий	Что означает	Вопрос для проверки
Independent (Независимая)	История не зависит от других и может быть реализована в любом порядке	Можно ли взять её в спринт без завершения другой?
Negotiable (Обсуждаемая)	Детали реализации уточняются в диалоге, история — не жёсткий контракт	Есть ли поле для переговоров по объёму?
Valuable (Ценная)	Даёт реальную ценность пользователю или бизнесу	Кто выиграет, если мы реализуем это?
Estimable (Оцениваемая)	Команда может оценить трудозатраты в сторипоинтах	Можем ли мы назвать размер истории?
Small (Маленькая)	Выполняется за один спринт, обычно ≤ 8 сторипоинтов	Завершим ли мы её за одну итерацию?
Testable (Тестируемая)	Есть чёткие критерии приёмки (acceptance criteria)	Можем ли мы написать тест «история выполнена, когда X»?

Как выглядит пользовательская история

Большинство команд пользуются шаблоном пользовательской истории, обычно это всего лишь одно или два предложения, написанных по следующей формуле:

Как [описание пользователя ], я хочу [ функциональность ], чтобы [ выгода ].

Детально рассмотрим шаблон:

Описание пользователя. Кем является человек по ту сторону экрана? Личность пользовательской истории не обязательно должна ограничиваться должностью человека. Например, руководителем удаленной команды может быть как и менеджер отдела, так генеральный директор, или любое другое лицо в компании. При построении истории мы должны понимать как думает и работает этот человек, знать его намерения. В идеале у пользователей нужно провести интервью.

Функциональность. Здесь описывается не сама фича, а намерения людей, каких целей они хотят достичь.

Выгода. Для чего пользователи совершают все эти действия? Описываем конечную выгоду и проблемы, которые хочет решить выбранная личность.

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

На практике пользовательские истории могут выглядеть так:

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

Важно: Различные пользователи, описанные в историях могут быть одним и тем же человеком, которому для разных задач требуются разные функции.

Почему мы используем User story

Вместо того, чтобы писать планы с точки зрения продукта (какие функции нужно создать), User stories разворачивают нас к пользователям. Этот инструмент заставляет составлять каждую предложенную идею для новой функциональности с точки зрения реальных людей, которые будут использовать эту функциональность.Таким образом, мы создаем лучший интерфейс для пользователей будущего продукта.

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

User story, use case и задача: в чём разница

Параметр	User Story	Use Case	Задача (Task)
Фокус	Ценность для пользователя	Сценарий взаимодействия с системой	Конкретный шаг для разработчика
Объём	1–2 предложения	Формальный документ	Техническое описание
Автор	Product Owner, стейкхолдер	Бизнес-аналитик	Разработчик
Создаётся при	Планировании бэклога, спринта	Анализе требований	Декомпозиции story
Методология	Agile, Scrum, Kanban	Waterfall, RUP, Agile	Любая

Частые вопросы о пользовательских историях

Чем user story отличается от технического требования?

User story описывает потребность пользователя и ценность для него («чтобы...»). Техническое требование фиксирует конкретное поведение системы, нередко без привязки к пользователю. User story инициирует диалог, требование — договорённость.

Кто составляет пользовательские истории?

Обычно Product Owner в диалоге с командой разработки и стейкхолдерами. Для понимания реальных нужд рекомендуется проводить интервью с конечными пользователями.

Что такое критерии приёмки (Acceptance Criteria)?

Набор условий, при выполнении которых история считается готовой. Популярный формат — Given-When-Then: «Дано [контекст], когда [действие], тогда [ожидаемый результат]».

Можно ли использовать user story вне Agile?

Да. Метод применяют и при Kanban, и в классических проектах — везде, где важно сохранить фокус на потребностях пользователей, а не на технических деталях.

Как оценивают трудоёмкость user story?

Чаще всего с помощью Planning Poker: команда присваивает истории сторипоинты — относительные единицы сложности, а не часы. Истории размером более 8 сторипоинтов рекомендуется разбивать.

Нужна помощь с внедрением Agile-методологии в проекте? Обсудите разработку с командой YuSMP Group.