Пользовательская история (User Story) в разработке продуктов

Пользовательская история (User Story) – это небольшая автономная единица разработки, предназначенная для достижения определенной цели в продукте. Пользовательская история обычно пишется с точки зрения пользователя и следует формату: «Как [пользователь], я хочу [выполнить это действие], чтобы [я мог достичь этой цели]».

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

В Agile-разработке программного обеспечения User Story – это краткое объяснение функции простым языком, написанное с точки зрения пользователя. Многие эксперты по гибкой разработке также описывают User Story как наименьшую единицу работы по разработке продукта, которая может привести к полному элементу пользовательской функциональности.

Продуктовые группы предпочитают разбивать разработку на User Story, а не на характеристики продукта или требования к продукту по нескольким причинам:

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

Как выглядит User Story?

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

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

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

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

• Как администратор базы данных, я хочу автоматически объединять наборы данных из разных источников, чтобы мне было проще создавать отчеты для моих внутренних клиентов.

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

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

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

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

Кому следует писать User Story?

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

Фактически, одна из причин, по которой они написаны простым языком – без какого-либо жаргона разработчиков или технических подробностей – заключается в том, что это позволяет любому, кто работает в деловой или технической части команды, внести свой рассказ пользователя на рассмотрение. Этот член команды (менеджер по продукту, дизайнер UX и т. д.) Должен только понимать конкретную проблему пользователя и личности, которую он надеется решить. Им не нужно знать, как на самом деле команда разработчиков будет кодировать это решение.