Паттерны декомпозиции User Story / задач

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

Есть две основных причины, почему так делать не стоит:

1. Слишком большие элементы бэклога таят в себе “сюрпризы”. Неприятные “сюрпризы”. Чем выше оценка в story points, тем выше вероятность, что вы не все учитываете
2. Чем крупнее ваши истории, тем дольше будет реализовываться поставка, и тем дольше фича не будет приносить ценность клиенту, следовательно, дольше не будет приносить пользу компании

При делении историй нужно не забывать про критерии хорошей истории — критерии INVEST.

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

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

Паттерн №1. Разделение на «проще-сложнее»

Выделение наиболее простого способа реализации достижения цели пользователя и реализация его в первую очередь.

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

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

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

Тогда результат декомпозиции может выглядеть так:

Паттерн №2. Разделение по бизнес-правилам

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

Сервис: Заправка авто онлайн

История: Я как водитель, хочу иметь возможность оплатить топливо со смартфона, чтобы не стоять в очереди на кассе

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

В реализации это выглядит так:

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

Паттерн №3. Разделение по способу ввода/вывода данных

Паттерн основывается на разных способах реализации интерфейса.

Сервис: Поиск жилья для поездки

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

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

Результат декомпозиции:

Паттерн №4. Вариантивность данных

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

Сервис: Агрегатор автосервисов.

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

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

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

Результат декомпозиции:

Паттерн №5. Разделение по операциям

Выделение различный действий с одной и той же сущностью.

Вернемся к сервису поиска жилья для поездок.

Сервис: Поиск жилья в поездке

История: Как путешественник я хочу управлять своими бронированиями отелей в приложении, чтобы сэкономить на этом время

Что в данном случае понимается под словом “управлять” ? Мы можем разложить это на несколько действий, например: отменить бронь, поделиться поездкой с кем-то, кто едет с вами, добавить в wallet. Вот как это реализовал у себя всем известный сервис.

Результат декомпозиции:

Паттерн №6. По шагам workflow

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

Сервис: Доставка продуктов

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

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

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

Паттерн №7. Выделение основного усилия

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

Сервис: Интернет магазин

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

Если в прошлом примере мы смогли пожертвовать онлайн оплатой в первой версии, то сейчас уже не отвертимся. Придется что-то придумывать.

Вы наверняка встречали множество способов оплаты онлайн.

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

Результат декомпозиции:

Паттерн №8. Отсрочка производительности

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

Сервис: История подержанных авто

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

Для проверки истории автомобиля требуется “опросить” несколько баз данных. При этом первое время, вероятно, это придется делать через посредников, а не запросами напрямую в первоисточники.

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

Результат декомпозиции может выглядеть так:

Паттерн №9. Исследование-разработка

Еще этот паттерн называют “выделение спайка”.

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

Знание о паттернах декомпозиции не должно парализовать вашу мысль в попытке вспомнить их. Если вам пришла в голову идея как декомпозировать — используйте ее. Все равно она будет соответствовать какому-то из паттернов :) . Но вот если во время разбора продуктового бэклога у вас ступор, тогда можете обратиться к описанным паттернам и решить как нарезать истории помельче.

Источник