Что такое User Story Mapping?

User Story Mapping или Карты Пользовательских Историй - это способ визуального планирования и приоритизации задач. Способ хорош тем, что заставляет нас думать о своих software решениях с позиции Пользовательских Историй (User Story).

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

Что такое User Story?

Пользовательская История - это описание какой-либо фичи продукта, рассказанное с точки зрения её пользователя. Буквально рассказ о том, как именно фича используется конкретным пользователем. Пользовательские Истории при описании функционала software продукта, ставят во главу угла именно пользователя.

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

As a [type of user],
I want [some particular feature],
So that [some benefit] is received.

На русском, эта схема будет выглядеть следующим образом:

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

При составлении Пользовательских Историй важно понимать какой уровень детализации Вам необходим. Например, следующая история это плохой пример:

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

Почему это пример плох? Давайте закроем глаза на то, что пример взял из головы и описание цели странноватое. Главная проблема этого примера в том, что «хочу купить товар» это слишком большое действие, чтобы описывать его одной историей. «Купить товар» обычно подразумевает:

  • открыть сайт онлайн магазина

  • найти нужный товар

  • просмотреть его характеристики

  • прочитать отзывы на него

  • добавить его в корзину

  • залогиниться для сохранения истории покупок

  • ввести данные банковской карты

  • оплатить

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

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

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

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

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

Карта Пользовательских Историй, это метод визуального моделирования и планирования, поэтому для визуализации моей истории, я буду использовать сервис Miro (Online Whiteboard & Visual Collaboration Platform | Miro).

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

Каркас

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

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

То, что мы только что сделали, этот набор стикеров, из которых состоит наша история, называется Каркас (или Backbone, в зарубежной литературе). Именно он является основой Пользовательской Истории, и именно на него мы будем наслаивать остальные элементы, а именно генерировать мелкие истории в формате задач, а так же выделять части чего-то единого.

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

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

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

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

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

Задачи

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

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

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

В случае с моей картой, стикеры-задачи могут выглядеть так:

Есть один простой трюк, который поможет описывать задачи так, чтобы:

  • все они имели схожую смысловую структуру

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

Итак, трюк следующий - помните схему, по которой составляются Пользовательские Истории: As a [user], I want [something], So that [achieve some benefit] А теперь немного изменим её, заменив общие термины на элементы карты:

As a [user],
I want [task],
So that [backbone element]

Моя схема написана на русском, так что, давайте, следуя этой схеме, попробуем составить несколько историй для разработчика:

1) Как клиент онлайн магазина, Я хочу использовать строку поиска, Чтобы найти нужный товар
2) Как клиент онлайн магазина, Я хочу использовать номер телефона, Чтобы залогиниться в системе
3) Как клиент онлайн магазина, Я хочу просмотреть описание товара, Чтобы посмотреть информацию о товаре

Каждая из Задач, в подобном написании, представляет из себя Пользовательскую Историю. В таком случае, каждый из оранжевых стикеров - представляет из себя Epic (то есть, большую задачу, которая состоит из ряда историй). Если уж совсем точно, то - оранжевые тикеты, это Epic’и в JIRA, тикеты-задачи - это User Story в JIRA. Каждая из User Story в JIRA, затем может быть разбита на несколько тикетов, в рамках которых разработчик реализует те или иные части фичи.

Планирование

Пришло время поговорить о последнем элементе Карты Пользовательских Историй, а именно о планировании.

Если горизонтальная плоскость отображает шкалу времени, то вертикальная в данном методе, отображает приоритет. Чем выше Задача в колонке, тем выше и её приоритет и, соответсвенно, она быстрее будет выполнена разработчиком.

Есть два способа планирования в данном методе. Блок с Задачами может быть поделён, с помощью горизонтальных линий на:

  • важность или

  • релизы

В случае с важностью, обычно используют три уровня: Must, Should, Could. Первый означает первоочерёдную ценность задач и означает, что они обязаны быть выполнены. Второй - что задачи важны и хорошо бы их выполнить. Третий - необязательны и могут быть не выполнены. Пример деления по важности выглядит следующим образом:

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

Второй способ, вместо важности - разделение на релизы. Выглядит следующим образом:

Как можно заметить, выглядит это примерно так же, как и вариант выше, однако, насчёт привязки к номеру версии software решения, мы можем планировать Пользовательские Истории к выпуску в определённых версиях нашего софта.

Процесс моделирования

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

Прежде всего, подобные карты создаются не одним человеком, а группой людей, включающей себя бизнес-ориентированных людей (Product Owner’а например), заинтересованных в фиче людей и разработчиков. Моделирование карты происходит в формате воркшопа, то есть - живого общения с обсуждениями и разноцветными стикерами на флипчартах и стенах.

Основных шагов в ходе воркшопа пять:

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

  2. Создание большой картины. На этом этапе накидываются основные идеи о составе истории. Происходит первоначальное создание каркаса фичи.

  3. Детализация. На данном этапе через коллективное обсуждение элементы каркаса разбиваются на более мелкие задачи. Пересматриваются элементы каркаса, меняются местами, добавляются новые, удаляются ненужные, выделяются активности.

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

  5. Стратегия разработки и релизов. На этом этапе уже планируются задачи в разработку. Если нужно, карта актуализируется ещё. Цель этого этапа связать планирование на карте непосредственно с разработкой фичи.

Словарь терминов

  • Карта Пользовательских Историй - она же User Story Mapping; метод визуального описания и планирования задач.

  • Пользовательская История - она же User Story; это способ описания взаимодействия пользователя с software системой в формате нарративного повествования.

  • Каркас - он же Backbone; основной набор шагов Пользовательской Истории.

  • Активности - это группа задач, имеющих схожие цели.

Дополнительные материалы

Оригинал этой статьи, а также многие другие на разные темы об IT и разработке, можно найти на моём сайте #fullstackguy.

#fullstackguy в Telegram. Подписаться!