Как писать User Stories и зачем они нужны

В этой статье мы расскажем насколько важны User Stories при разработке мобильных приложений и насколько они нужны в веб-разработке, нюансы работы с ними, а также как правильно писать пользовательские истории наравне с CJM, про которую мы писали в недавней статье.

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

User Stories были придуманы Роном Джеффризом и Кеном Швабером в 1990-х годах в рамках создания методологии Extreme Programming (XP). Эта методология была разработана для повышения эффективности разработки программного обеспечения путем ускорения процесса разработки и повышения качества продукта.

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

User Stories обычно записываются от первого лица и следуют простому шаблону: "Я, как [роль], хочу иметь [возможность] для того, чтобы [цель]"

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

2. Определение целей пользователей – команда должна понимать, что пользователи хотят достичь, используя продукт.

3. Создание списка User Stories – команда должна создать список User Stories, которые описывают функциональность продукта, которую нужно реализовать.

4. Приоритизация User Stories – команда должна определить, какие истории наиболее важны для пользователей и бизнеса.

5. Разработка детальных описаний – для каждой User Story необходимо написать более подробное описание, которое включает в себя шаги, необходимые для ее выполнения.

6. Оценка пользовательских историй.

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

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

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

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

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

1. Создать страницу товара.

2. Добавить функциональность поиска.

3. Как пользователь, я хочу, чтобы продукт был лучше

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

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

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

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

Критерии хорошей User Story можно описать с помощью акронима INVEST. Эти критерии помогают команде создавать эффективные и понятные пользовательские истории.

I - Independent (независимость)

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

N - Negotiable (договоренность)

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

V - Valuable (ценность)

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

E - Estimable (оцениваемость)

Каждая User Story должна быть оцениваемой. Команда должна иметь возможность оценить сложность и объем работы, необходимых для реализации каждой истории. Это помогает команде планировать и управлять процессом разработки.

S - Small (маленькие)

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

T - Testable (тестируемость)

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

Использование подхода INVEST при разработке User Stories помогает команде создавать более эффективные и понятные пользовательские истории, помогает упростить процесс разработки, позволяя команде достигать быстрых результатов и избегать ошибок на ранних этапах работы.

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

Использование INVEST может быть особенно полезным в Agile-подходах к разработке, где упор делается на гибкость и быстрое достижение результатов. Однако, использование INVEST может быть полезным в любом виде разработки, где требуется создание понятных и эффективных пользовательских историй.

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

L-TECH прорабатывает User Stories для каждого проекта, благодаря проработанным сценариям, пользователи высоко оценивают юзабилити наших интерфейсов сайтов и приложений. Если вашему проекту нужна предпроектная аналитика и составление User Stories или вы хотите заказать разработку приложения под ключ, расскажите нам о своем проекте. Мы с удовольствием проконсультируем вас, ответим на любые вопросы, подберем нужный технологический стек для вашей идеи, оценим сроки и стоимость реализации проекта.