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

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

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

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

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

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

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

• Короткие и понятные. Легко вникнуть каждому участнику процесса.

• Позволяют разбить проект на небольшие этапы и показывать видимые результаты на каждом спринте.

• Команда концентрируется на потребностях реальных людей, а не на абстрактных объектах.

• Позволяют разработчикам и клиентам обсуждать требования на протяжении всей жизни проекта.

• Подходят для проектов, где требования изменчивы или плохо поняты.

• Облегчают оценку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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