Декомпозируем User Story: 21 паттерн, чтобы не резать вслепую

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

Напомню, что User Story формулируются коротко, без технических деталей по шаблону: «Я, как [роль], хочу [возможность], чтобы [цель]»

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

Но что делать если описанная User Story выглядит чересчур объемной? Пытаться декомпозировать, потому что:

1. User Story становится понятнее.
2. Может оказаться, что реализация каких-то частей не нужна (либо эти части не так важны).
3. Маленькие User Story сокращают сроки поставки и позволяют быстрее получить обратную связь.
4. Если вы оперируете понятием MVP разрабатываемой фичи, то набор маленьких User Story позволит собрать оптимальный MVP, безболезненно отрезав лишние части.

Выбранный способ декомпозиции должен:
• Помочь понизить приоритет части получившихся User Story.
• Обеспечить разбиение на равные по размеру User Story.
• Помочь избавиться от зависимостей или уменьшить зависимости от других историй.

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

Выглядит как большая и абстрактная User Story, но мы поделим её, используя один из способов:

1. «Я, как потребитель, хочу скачать меню ресторана с сайта в формате PDF, чтобы посмотреть его на своём устройстве».
2. «Я, как потребитель, хочу видеть меню ресторана в виде веб-страницы с поиском, чтобы быстро найти свои любимые блюда».

Этот небольшой пример не претендует на жизнь, но должен помочь натолкнуть на правильный путь при попытке декомпозиции :)

👍 Забираем способы декомпозиции User Story по ссылке и применяем в своей работе!

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