Что такое пользовательские истории: советы, шаблоны и примеры

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

Пользовательские истории — это объяснение функции программного обеспечения с точки зрения конечного пользователя. Это помогает Agile-командам понять, чего хотят пользователи, чтобы они могли предоставлять лучшие функции.

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

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

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

Пользовательскую историю обычно можно сформулировать одним предложением: «Как [персонаж], я хочу [цель программного обеспечения], чтобы [результат]».

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

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

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

4 ключевых компонента пользовательских историй

В Agile-проектах и Scrum-командах пользовательские истории структурируются так, чтобы обеспечить ясность и лучше соответствовать целям пользователей. История пользователя состоит из трех основных компонентов:

1. Роль

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

Например, пользователем может быть менеджер по продукту, постоянный клиент или заинтересованное лицо. Чётко определив роль, команда разработчиков создаёт функции для нужной аудитории.

Общая структура этой части пользовательской истории может быть следующей: «Как [роль]...»

2. Цель

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

Примером этого компонента может быть: «...Я хочу [действие]...», что дает аналитику рабочего процесса и потребностей пользователя.

3. Польза

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

Структура обычно заканчивается словами: «...чтобы я мог [преимущество]». Этот компонент необходим для создания тестируемой функции, которая соответствует как ожиданиям пользователей, так и критериям, определённым в приемочном тесте.

4. Очки истории

После определения роли, цели и пользы команда разработчиков часто присваивает пользовательской истории баллы. Стори поинты — это способ оценить сложность, трудозатраты и время, необходимое для завершения истории в рамках спринта или итерации. Agile-команды используют баллы, чтобы оценивать объём работы и обеспечивать надлежащий баланс историй в спринтах.

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

Как написать хорошую пользовательскую историю

Agile и Scrum команды часто пишут истории пользователей в три этапа, каждый из которых представляет точку зрения конечного пользователя. 

1. Персонаж: характер конечного пользователя или пользовательский персонаж

2. Потребность: цель, которую функция программного обеспечения преследует в пути конечного пользователя

3. Цель: цель взаимодействия конечного пользователя с функцией программного обеспечения

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

Шаг 1. Определите персонажа

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

Вот несколько вопросов, которые следует задать себе и своей команде при определении портрета пользователя:

• Для кого мы создаем эту функцию программного обеспечения?

• Какие функции продукта нужны конечному пользователю?

• Каковы демографические и психографические характеристики конечного пользователя?

В зависимости от размера целевой аудитории в одной пользовательской истории может быть несколько портретов. 

Пример персонажа: Кэт, менеджер проекта, возглавляющая команду из 10 человек

Шаг 2. Опишите потребность

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

При анализе намерений конечного пользователя учитывайте следующие вопросы:

• Чего пытается добиться конечный пользователь?

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

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

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

Шаг 3. Определите цель

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

Чтобы определить цель, задайте себе следующие вопросы:

• В чём преимущество этой функции?

• Какую проблему вы решаете?

• Как это вписывается в более глобальные цели?

Цель здесь — определить ценность вашей функции программного обеспечения по отношению к общим целям.

Пример цели: повышение эффективности за счёт создания чёткого плана действий.

Шаблон пользовательской истории

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

Ниже приведен часто используемый шаблон для написания пользовательских историй:

«Как [роль] я хочу [цель], чтобы [преимущество]».

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

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

Давайте разберем эту историю пользователя:

• Роль: конкретный тип пользователя (например, клиент, менеджер по продукту или заинтересованное лицо), который будет взаимодействовать с функцией.

  • Пример: «Как менеджер проекта...»

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

  • Пример: «...Я хочу отслеживать прогресс моей команды...»

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

  • Пример: «…чтобы задачи соответствовали целям бизнеса».

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

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

Чтобы вы лучше понимали, что такое гибкие пользовательские истории, мы собрали несколько примеров. Чем эффективнее ваши пользовательские истории, тем больше пользы вы сможете принести конечному пользователю. 

Ниже приведены три примера пользовательских историй для различных вариантов использования: 

Пример пользовательской истории 1: разработка продукта 

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

Пример пользовательской истории 2: качество обслуживания клиентов

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

Пример пользовательской истории 3: Приложение

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

Во всех трех примерах видно, насколько важно представлять обновления программного обеспечения с точки зрения конечного пользователя. Так ваша команда разработчиков будет вносить обновления с учетом интересов клиента.

Советы по написанию эффективной пользовательской истории

В дополнение к трем шагам, описанным выше, эффективная пользовательская история должна соответствовать принципам 3C и INVEST. Оба эти принципа помогают вывести пользовательские истории на новый уровень, что приводит к более эффективным обновлениям программного обеспечения. 

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

3 C в пользовательских историях

Эти три «К» — это Card (карточка), Conversation (беседа) и Confirmation (подтверждение). Эти три компонента позволяют разбить каждую пользовательскую историю на три отдельные оценки, что делает процесс более организованным. Давайте рассмотрим каждый из этих элементов, чтобы лучше понять их суть.

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

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

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

Эти три компонента помогают разбить пользовательскую историю на простые задачи. Это дает четкое направление для вовлеченных заинтересованных сторон.

Критерии INVEST

Аббревиатура INVEST расшифровывается как Independent (независимая), Negotiable (обсуждаемая), Valuable (ценная), Estimable (оцениваемая), Small (маленькая) и Testable (тестируемая). Давайте рассмотрим эти компоненты более подробно, чтобы лучше понять, как критерии INVEST могут помочь вам создавать более сильные истории:

• Независимая: история пользователя должна быть независимой, то есть не зависеть от других задач и быть самодостаточной. 

• Оговариваемая: история пользователя должна быть оговорена. Это означает, что она оставляет место для обсуждения. 

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

• Оцениваемая: история пользователя должна быть оценена, чтобы убедиться, что она вписывается в спринт и имеет правильный приоритет. 

• Small (маленький): пользовательская история должна быть небольшим объемом работы, который можно завершить за короткое время. 

• Проверяемая: история должна пройти приемочные тесты и соответствовать заранее определённым критериям приёмки для проверки качества. 

Следуйте аббревиатуре INVEST, чтобы писать пользовательские истории в конкретной и достижимой форме.

Лучшие практики для пользовательских историй

Написание пользовательских историй — ключ к успеху в гибких методологиях. Эти лучшие практики помогут вам создавать чёткие и эффективные истории, которые будут направлять вашу команду.

1. Взаимодействие с заинтересованными сторонами

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

Эксперт по Agile Майк Кон призывает команды поддерживать открытое общение, чтобы все понимали, как использовать функцию. Цель — чтобы истории были ориентированы на реальных пользователей.

2. Уточнение пользовательских историй во время планирования спринта

Во время планирования спринта найдите время, чтобы проанализировать и уточнить пользовательские истории. Разбивайте большие истории на более мелкие. Просмотрите критерии приёмки, чтобы устранить путаницу.

Назначьте баллы историям, чтобы они соответствовали способности команды к спринту. Как говорит Рон Джеффрис, один из создателей экстремального программирования, доработка историй помогает команде оставаться гибкой и сосредоточиться на самом важном.

3. Использование критериев приемлемости

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

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

Инструменты и методы управления пользовательскими историями

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

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

• Программные инструменты для управления пользовательскими историями: такие инструменты, как Jira и Asana, упрощают управление пользовательскими историями. С их помощью можно отслеживать ход выполнения, назначать задачи и расставлять приоритеты. Многие инструменты включают такие функции, как управление баллами истории, установка критериев приемлемости и планирование спринта. Они также помогают поддерживать документ с требованиями, который обеспечивает единое понимание ситуации.

• Приоритизация пользовательских историй с помощью метода MoSCoW: метод MoSCoW помогает командам ранжировать пользовательские истории по важности. Истории сортируются по четырем группам: «Должно быть», «Следует иметь», «Могло бы быть» и «Не будет». Эта методология гарантирует, что самые важные истории будут выполнены в первую очередь.

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

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

Затем команда разработчиков расставляет приоритеты и решает, какие пользовательские истории следует рассмотреть на совещании по планированию спринта. 

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

Пользовательские истории используются в фреймворках Scrum и Kanban. 

• В Scrum пользовательские истории помогают команде лучше понять задачи во время планирования спринта. 

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

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

Важность точной пользовательской истории

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

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

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

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

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

Позиционирование обновлений с точки зрения пользователя помогает создать надёжный пользовательский опыт, который повышает ценность Business и общий процесс сбора требований.

Повышение ценности за счет пользовательского опыта

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

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