Декомпозиция User Story: формируем общий контекст, чтобы создавать классный продукт
Обсудим, как написать хорошую User Story, какие существуют паттерны декомпозиции пользовательских историй, как их использовать и главное — зачем на самом деле декомпозиция нужна команде.
Декомпозировать, чтобы что
Пойду с козырей. Давайте сразу разберем очень важный вопрос: а зачем вообще нужна декомпозиция User Story?
Когда мы работаем в команде, важно иметь общее понимание того, что мы делаем и к чему стремимся, верно? Проблема в том, что все мы разные, а значит, по-разному воспринимаем и усваиваем информацию. Добавьте сюда же неизбежное искажение данных при передаче — знаменитое «точно тебе говорю, так и было», как же тогда команде получить общий контекст? И в этот момент на помощь нам приходит декомпозиция!
Декомпозиция пользовательских историй позволяет каждому участнику команды:
— лучше понимать требования пользователей и цели проекта,
— регулярно получать качественную обратную связь,
— яснее видеть куда и каким путем мы идем, а также осознавать личный вклад в общее дело,
— а значит, работать более слаженно, координируя действия и достигая лучших результатов.
Всё это вместе помогает создавать продукт, который лучше соответствует потребностям и ожиданиям пользователей.
С декомпозицией понятно, а как правильно сформулировать User Story?
Давайте вспомним, что User Story — это описание какого-то сценария, который пользователь хотел бы реализовывать с помощью нашего продукта.
Хорошая User Story должна отвечать на следующие три вопроса:
- Кто является пользователем или заинтересованной стороной, для которой предназначена данная функциональность или изменение системы.
- Что конкретно требуется сделать или какое поведение системы должно быть изменено.
- Зачем? Какая цель или потребность пользователя лежит в основе этого требования или изменения?
Кроме того, важно проверить User Story на соответствие 6 INVEST-критериям. Они должны быть небольшими, независимыми и понятными, что существенно облегчит процесс планирования и управления проектом.
Подробнее об этом мы уже говорили в статье «Что такое бэклог простыми словами?», где в том числе рассматривали типы элементов Бэклога. А ниже вы найдете удобную табличку с краткими характеристиками каждого критерия.
Кстати, еще больше деталей и примеров пользовательских историй доступны в нашем гайде User Story — инструкция по применению.
Как декомпозировать User Story?
Давайте внимательно посмотрим на изображение ниже — вы видите 2 способа, как можно декомпозировать User Story.
Первый вариант — горизонтальная декомпозиция по архитектурным слоям, когда для каждого компонента создается отдельная задача. И что важно: в этом случае задачи сильно зависят друг от друга. Другими словами, само по себе изменение в каком-то одном компоненте не несет ценности для пользователя. Ценность появляется только, когда изменения в одном компоненте или слое мы объединяем с другими.
Второй вариант — вертикальная декомпозиция, которая охватывает функциональность целиком и содержит требования ко всем компонентам. В контексте гибкого подхода упоминают именно второй способ. На это есть как минимум 3 причины.
- Быстрая обратная связь. Когда мы разбиваем user story на мелкие вертикальные кусочки, это значит, что каждая часть содержит в себе все необходимое для создания полезного функционала. Это позволяет нам быстрее получать обратную связь от пользователей, потому что они могут проверить и оценить часть нашего продукта, а не ждать, пока мы закончим все сразу.
- БОльшая гибкость. Мы можем легко переключаться между разными частями и сосредотачиваться на том, что действительно важно и приоритетно. Это помогает быстрее реагировать на изменения в требованиях и сохранять нашу продуктивность.
- Более управляемый и прогнозируемый рабочий процесс, ведь каждая часть user story может быть выполнена за один раз.
А теперь будем декомпозировать: пошаговый гайд и набор паттернов
Рекомендую сохранить этот компактный гайд, который поможет не запутаться в этапах и паттернах декомпозиции, а ниже мы подробнее разберем 3 основных шага.
1. Подготовить User Story.
Для начала убедитесь, что User Story соответствует INVEST за исключением критерия малого размера (Small). На этом этапе чаще всего проблемой становится критерий ценности (Valuable). Если пользовательская история не несет никакой ценности, вполне возможно, что это не User Story, а просто задача. В этом случае вам нужно объединить несколько не-историй вместе, чтобы они представляли ценность для продукта и пользователя.
2. Применить паттерны декомпозиции.
Паттернов декомпозиции очень много! Вы можете использовать разные шаблоны в зависимости от специфики задачи или требований проекта:
— Workflow Steps (последовательность действий);
— Operations (операции);
— Variations in Data (различные группы данных);
— Simple/Complex (простота/сложность) и многие-многие другие.
В пошаговом гайде по ссылке выше вы найдете варианты разных паттернов декомпозиции, а ниже мы рассмотрим несколько примеров.
Декомпозиция с использованием паттерна workflow
Исходная User Story:
«Как сотрудник отдела продаж, я хочу иметь возможность отслеживать статус заказа от момента размещения до доставки клиенту, чтобы обеспечить своевременное выполнение заказов и уведомлять клиентов о статусе их заказов».
User story 1: «Как сотрудник отдела продаж, я хочу иметь возможность просматривать список новых заказов, которые требуют обработки».
User story 2: «Как сотрудник отдела продаж, я хочу иметь возможность обрабатывать заказы, включая подтверждение, сборку и упаковку товаров».
User story 3: «Как сотрудник отдела продаж, я хочу иметь возможность отслеживать статус заказа (обработка, отправка, доставка) и обновлять его в системе».
User story 4: «Как сотрудник отдела продаж, я хочу иметь возможность отправлять уведомления клиентам о статусе их заказа (например, подтверждение заказа, информация о доставке)».
Каждая из описанных User Stories представляет отдельный этап в рабочем процессе от обработки заказа до его доставки.
Пример с использованием паттерна декомпозиции Simple/Complex
Исходная User Story: «Как покупатель, я хочу иметь возможность оформить заказ на сайте, чтобы купить нужные мне товары».
User story 1 (Simple): «Как покупатель, я хочу добавить товары в корзину перед оформлением заказа».
User story 2 (Complex): «Как покупатель, я хочу иметь возможность управлять содержимым корзины перед оформлением заказа (добавлять, удалять и изменять количество товаров)».
User story 3 (Simple): «Как покупатель, я хочу ввести свои контактные данные и адрес доставки для оформления заказа».
User story 4 (Simple): «Как покупатель, я хочу выбрать метод оплаты и получить подтверждение заказа на указанный электронный адрес».
В этом примере первая и последняя User Stories являются более простыми и описывают базовые шаги процесса оформления заказа. User story 2 является более сложной, так как она включает в себя множественные действия, связанные с управлением содержимым корзины.
Декомпозиция с использованием паттерна Operations
Исходная User Story: «Как администратор, я хочу иметь возможность управлять пользователями в системе, чтобы назначать им различные роли и права доступа».
User story 1: «Как администратор, я хочу иметь возможность добавлять новых пользователей в систему».
User story 2: «Как администратор, я хочу иметь возможность удалять пользователей из системы».
User story 3: «Как администратор, я хочу иметь возможность назначать роли пользователям, чтобы управлять их правами доступа».
User story 4: «Как администратор, я хочу иметь возможность изменять роли пользователей, чтобы обновлять их права доступа при необходимости».
Каждая из этих User Stories представляет отдельную операцию или действие, которое может быть выполнено администратором в системе. Такое деление позволяет легко оценить, планировать и реализовывать каждую часть независимо друг от друга.
Декомпозиция с использованием паттерна Variations in Data
Исходная User Story: «Как менеджер продукта, я хочу иметь возможность просматривать статистику продаж за определенный период времени, чтобы анализировать производительность товаров».
User story 1: «Как менеджер продукта, я хочу просматривать общую сумму продаж за выбранный период времени».
User story 2: «Как менеджер продукта, я хочу просматривать количество проданных товаров за выбранный период времени».
User story 3: «Как менеджер продукта, я хочу просматривать самые популярные товары за выбранный период времени».
User story 4: «Как менеджер продукта, я хочу сравнивать данные по продажам между различными категориями товаров за выбранный период времени».
В этом примере каждая User Story — это отдельная вариация данных, которые менеджер продукта может анализировать в рамках статистики продаж.
3. Оцените декомпозицию.
Пришло время оценить декомпозицию, для этого воспользуйтесь следующим списком вопросов:
- Все новые истории примерно одного размера?
- Соответствуют ли истории INVEST-критериям?
- Есть ли истории, которые можно отложить или удалить?
- Есть ли история, с которой сразу можно начать и получить ценный результат для продукта, пользователя, бизнеса и т.д.?
Если на какой-то из вопросов вы ответили «нет», попробуйте применить другой паттерн декомпозиции и улучшить результат. Кстати, а каким образом выбрать среди разных вариантов наиболее подходящий шаблон декомпозиции?
Рекомендую выбирать паттерн, который позволит делить User Story на более-менее равные истории меньшего размера, обязательно экспериментируйте с разными шаблонами и выбирайте подход к декомпозиции в зависимости от конкретной ситуации и потребностей проекта, это обеспечит максимальную эффективность и понятность для всей команды.
Таким образом, декомпозируя крупные User Stories на более мелкие кусочки, команда может легче управлять процессом разработки, лучше понимать, сколько времени и ресурсов потребуется на каждую часть проекта, понимать, что происходит и как их работа вписывается в общую картину. И в конечном итоге, это помогает делать нашу команду более эффективной и продукт более качественным.
Кстати, а какие паттерны декомпозиции входят в ваш персональный шорт-лист? Буду рад вашим комментариям или вопросам к этому материалу.
Хочу рассказать вам о методе Бережливого планирования продуктов и месте, которое он занимает в современной деятельности по созданию технически сложных и комплексных продуктов, таких как беспилотный автомобиль, аэротакси или современные космические ракеты. А заодно порассуждать, почему некоторые технологические стартапы превращаются в глобальные корпорации, как например Tesla, а некоторые входят в анналы истории как имена нарицательные для обозначения кринжовых концепций и безумных проектов, например как ё-Мобиль.
Что такое минимально жизнеспособный продукт (MVP)? Почему MVP так важен в процессе разработки и как его эффективно использовать? В этой статье ответим на все эти вопросы и посмотрим примеры самых узнаваемых брендов, история которых начиналась с MVP.
Разработка — это дорого и очень часто ее ресурсов не хватает, особенно в небольших компаниях. Именно поэтому в организации критично важно передавать команде разработки только действительно важные и актуальные задачи. Как понять, что бизнес-идея жизнеспособна? И какие быстрые и недорогие эксперименты помогут оценить потенциальные риски новой гипотезы?
В статье Иван Дубровин рассказывает, как выстроить стратегию тестирования бизнес-идеи до этапа разработки.