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

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

1. ПОСЛЕДОВАТЕЛЬНОСТЬ ДЕЙСТВИЙ

Можно ли выделить внутри стори базовый и дополнительный функционал?

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

Как пользователь (контент-менеджер), я могу опубликовать новость на сайте.

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

После декомпозиции:

… Я могу опубликовать новость сразу на сайте.

… Я могу опубликовать новость с рецензией редактора.

… Я могу опубликовать новость с юридическим обзором.

… Я могу опубликовать новость на промежуточном сайте.

… Я могу одобрить к публикации новость с промежуточного сайта на основной.

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

… Я могу опубликовать новость на промежуточном сайте.

… Я могу одобрить к публикации новость с промежуточного сайта на основной.

Редакционное и юридическое одобрение решили получать до публикации, еще в оффлайне. В будущем, конечно же, можно будет доработать этот флоу до желаемого.

2. РАЗДЕЛЕНИЕ ПО БИЗНЕС-ПРАВИЛАМ

Включает ли история различные бизнес-правила? (например, “поиск с гибкими датами”, который предусматривает несколько реализаций)

Если да, реализуйте сначала часть бизнес-правил и расширяйте функционал позже.

Как пользователь, я могу искать авиабилеты с гибкими датами.

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

После декомпозиции:

… Я могу искать билеты с указанием интервала для даты вылета и интервала для даты прилета.

… Я могу искать билеты с указанием N дней между датой вылета и прилета.

… Я могу искать билеты с указанием “только выходные дни в текущем месяце”.

… Я могу искать билеты с указанием +-N дней для даты вылета и прилета.

3. ОСНОВНОЙ ОБЪЕМ РАБОТ

Можно ли выделить внутри стори часть, которая будет сложнее в реализации, чем остальные?

Как пользователь, я могу искать авиабилеты с гибкими датами.

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

4. ПРОЩЕ / СЛОЖНЕЕ

Можно ли упростить историю, выделив базовый функционал? В идеале, представляющий наибольшую ценность.

Как пользователь, я могу искать авиабилеты из пункта А в пункт Б.

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

После декомпозиции:

… Я могу искать авиабилеты из пункта А в пункт Б с указанием даты вылета и прилета.

… Я могу искать авиабилеты из пункта А в пункт Б с указанием максимального количества остановок.

… Я могу искать авиабилеты из пункта А в пункт Б с указанием близлежащих аэропортов.

… Я могу искать авиабилеты из пункта А в пункт Б с указанием гибких дат вылета и прилета.

... Я могу искать авиабилеты из пункта А в пункт Б и обратно с указанием дат вылета и прилета.

5. РАЗНОВИДНОСТЬ ДАННЫХ

Используются ли в истории различные группы данных?

Если да, разделите историю, чтобы в первую очередь реализовать только часть бизнес-правил.

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

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

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

Получилось так:

... Я могу искать поставщиков транспортных услуг по странам отправления и назначения.

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

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

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

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

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

Как администратор, я могу опубликовать новость на русском.

Как администратор, я могу опубликовать новость на английском.

Как администратор, я могу опубликовать новость на испанском.

6. РАЗНОВИДНОСТЬ ИНТЕРФЕЙСА

Можно ли получить одни и те же данные через разные интерфейсы?

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

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

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

7. ОТСРОЧКА ПРОИЗВОДИТЕЛЬНОСТИ

Сложна ли реализация нефункциональных требований стори (например, производительность)?

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

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

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

Более медленная выдача результатов поиска - просто сделайте это, добавив прелоудер для «поиска».

Поработайте над производительностью выдачи - например, выдача результатов поиска «менее чем за 5 секунд».

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

8. РАЗДЕЛЕНИЕ ПО ОПЕРАЦИЯМ

Например, CRUD (сокр. от англ. create, read, update, delete — «создать, прочесть, обновить, удалить»).

Включает ли стори в себя различные операции? Если да, создайте стори для каждой.

Как пользователь, я могу управлять своей учетной записью.

«Управлять» охватывает несколько операций, разделите их:

... Я могу зарегистрировать новый аккаунт.

... Я могу редактировать настройки своей учетной записи.

... Я могу удалить мой аккаунт.

9. ВЫДЕЛЕНИЕ СВЯЗЕЙ

Можно ли выделить часть истории, с которой начнется работа пользователя?

Если да, опишите эту часть в виде отдельной истории, реализуйте ее, и начните процесс декомпозиции с самого начала.

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

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

Если вопросов нет, просто сделайте перерыв и попробуйте еще раз :-)

Как пользователь, я могу оплатить заказ с помощью кредитной карты.

Не очень понятно, с чего конкретно начать работу, поэтому выделяем исследовательскую историю по ключевому вопросу “как можно разработать онлайн оплату кредитными картами?”. Получаем:

Шаг 1. Исследовать оплату кредитными картами.

Шаг 2. Внедрить оплату кредитными картами.

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

Выводы

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

Не забывайте про принцип INVEST и паттерны выше каждый раз на старте формирования бэклога разработки.

И, конечно же, пишите в комментариях о вашем собственном опыте или методах декомпозиции. Удачных экспериментов!

Эта заметка является частью цикла заметок по разработке проектов
с высокой долей неопределенности в Molinos Studio.