Привет Хабр! Меня зовут Татьяна Ошуркова, я разработчик и аналитик. Использование пользовательских историй или user stories является распространенным подходом в работе с требованиями.

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

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

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

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

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

7 ноября я проведу бесплатный вебинар: «User stories. Теория, практика, инструменты», где я подробно разберу, что такое пользовательские истории и как с ними работать. Также я расскажу про методологию BDD, PlantUML и многое другое. Запись на вебинар доступна по ссылке.

Проблематика

Техники Example Mapping и Scenario Mapping решают несколько ключевых проблем, возникающих при работе с пользовательскими историями:

• Нечеткие или неполные требования.

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

• Недостаточная конкретизация бизнес-правил

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

• Сложности в коммуникации между бизнесом и разработчиками

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

• Пробелы в критериях приемки

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

Example Mapping

Example Mapping – это техника уточнения пользовательских историй, предложенная в рамках методологии BDD (разработка через поведение). Ее цель – помочь команде лучше понять требования, задать правильные вопросы и создать достаточное количество примеров для описания функций системы. В Example Mapping работа с пользовательскими историями ведется совместно с участием разработчиков, тестировщиков и бизнес-аналитиков (или других представителей бизнеса).

Основные элементы Example Mapping:

1. История (Story) – первым шагом определяется и формулируется пользовательская история. Она служит контекстом для последующих примеров и правил.

2. Правила (Rules) – правила, в контексте определенной истории. Они помогает выделить основные бизнес-правила и ожидания.

3. Примеры (Examples) – участники добавляют примеры, иллюстрирующие, как должно работать каждое правило. Примеры помогают уточнить правила и делают их более конкретными.

4. Вопросы (Questions) – если что-то остается непонятным или требует дополнительного разъяснения, это записывается как вопрос. Позже можно найти ответы на эти вопросы и уточнить историю.

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

1. Правило: Пользователь должен быть авторизован для изменения лимитов.

   Пример: Неавторизованный клиент не видит опцию «Установить лимит» и видит экран авторизации.

   Вопрос: Нужно ли дополнительное подтверждение личности при установке лимита?

2. Правило: Пользователь может устанавливать лимиты по типам транзакций (например, снятие наличных, покупки в интернете, покупки в магазинах).

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

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

   Вопрос: Есть ли ограничения на минимальные и максимальные лимиты по типам транзакций?

3. Правило: Лимит должен быть установлен на определенный период (например, на день, неделю или месяц).

   Пример: Клиент устанавливает дневной лимит на покупки в магазинах.

   Пример: Клиент устанавливает месячный лимит на онлайн-покупки.

   Вопрос: Можно ли установить лимит на несколько типов транзакций одновременно, и какой приоритет у этих лимитов?

Если использовать графическое отображение Example Mapping, получится следующий результат:

Scenario Mapping

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

Основные элементы Scenario Mapping:

1. Шаги действия (Actions) – последовательные действия, которые пользователь выполняет для достижения своей цели. Определение шагов помогает выявить, какие конкретные действия ожидаются от пользователя на каждом этапе.

2. Что думает пользователь (Thinking) – мысли пользователя. Этот компонент помогает команде понять, как пользователь воспринимает и интерпретирует действия, а также какие вопросы могут возникнуть у него по ходу процесса.

3. Что чувствует пользователь (Feeling) – эмоции и чувства, которые возникают у пользователя. Понимание эмоциональной реакции помогает выявить моменты, которые могут подтолкнуть пользователя к завершению или прерыванию процесса.

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

Также хочу отметить, что вопрос «Что думает пользователь?» может быть полезен сам по себе, так как очень часто такой взгляд на функционал уходит на второй план после бизнес-задач и технических аспектов.

Scenario Mapping можно рассматривать и вне контекста пользовательской истории для проработки сценария поведения пользователя или сценария использования (Use case). Но данная техника используется преимущественно для историй, так как они включают в себя более подробную детализацию, цель, контекст, а также меньше ориентированы на технические аспекты, как сценарии использования.

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

1. Шаг: Открыть мобильное приложения банка

   Вопрос: В каком разделе находится изменение лимита?

   Вопрос: Могу ли я изменить лимит?

2. Шаг: Перейти в раздел управления картами

   Вопрос: Лимит устанавливается для каждой карты отдельно?

3. Шаг: Выбрать нужную карту для установки лимита

   Вопрос: Есть ли данный функционал в настройках по карте?

4. Шаг: Ввести новый лимит по карте

   Вопрос: Какие ограничения у меня есть для установки лимита?

   Вопрос: Видно ли, сколько сейчас доступно по лимиту?

5. Шаг: Подтвердить лимит

   Вопрос: Есть ли необходимость в дополнительных подтверждениях?

Если использовать графическое отображение Scenario Mapping, получится следующий результат:

Какую технику выбрать?

Данные техники решают ряд проблем, которые возникают при работе с требованиями. Но каждая из техник решает их с разных сторон. Example Mapping поможет в уточнении требований и их глубокой проработке. Ей можно воспользоваться в следующих случаях:

• Для уточнения требований и лучшего понимания пользовательских историй на раннем этапе.

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

• Подходит для совместной проработки с бизнес-аналитиками и разработчиками для нахождения потенциальной проблематики

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

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

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

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

Подведем итоги

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

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

Делюсь шаблонами в Unidraw:

• Example Mapping

• Scenario Mapping

Подписывайтесь на мой канал в Telegram, где можно найти больше полезных материалов и вебинаров.

Удачи в работе с требованиями и пользовательскими историями!