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

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

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

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

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

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

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

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

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

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

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

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

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

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

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