Как нарезать пользовательские истории в Agile-проектах

В Agile-проектах цель обычно разбивается на отдельные единицы работы, каждая из которых описывает функциональность или возможность действия с точки зрения конечного пользователя. Эти блоки работы называются user stories (пользовательские истории).

Это подводит нас к очевидному вопросу: как лучше всего разбивать работу на пользовательские истории? Как и во многих других сферах, ответ — зависит от ситуации.

Обычно это типичный ответ консультанта. Но реальность такова, что не существует «серебряной пули» для создания идеальных пользовательских историй.

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

Хорошая новость

Существуют техники, которые повышают шансы на создание хороших и рабочих пользовательских историй.

Многослойный торт как метафора системы

Одна из популярных методик создания историй основывается на подходе «Я в роли.... хотел бы.... таким образом чтобы....». Это хорошее начало, но оно не объясняет, как именно разделить работу на маленькие, функциональные блоки, которые:

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

Идея «многослойного торта» была предложена Биллом Уэйком в 2003 году. Суть концепции:

Представьте систему как торт с несколькими слоями: сеть, база данных, логика, интерфейс. При разбиении истории мы как бы отрезаем кусок этого торта. Лучше резать торт вертикально, чтобы пользователь сразу получал «вкус» всей системы. Работа только над одним слоем (например, только над БД) не имеет ценности для клиента, если нет интерфейса.
   

Почему горизонтальные разрезы — плохая идея

1. Нельзя попробовать торт, пока он не испечен целиком

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

2. Торт может не понравиться

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

3. Нельзя выбрать кусочек

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

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

Как выглядит правильный «кусочек торта»

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

• Independent (Независимая)
• Negotiable (Обсуждаемая)
• Valuable (Ценная)
• Estimable (Оцениваемая)
• Small (Небольшая)
• Testable (Тестируемая)

Но не всегда каждая история должна нести отдельную ценность.

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

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

Пример: сложность системы

Пользовательская история:

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

Задача кажется простой, но за этим стоит:

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

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

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

Когда история становится слишком объемной, возникает естественное желание разделить ее по горизонтали — но этого мы хотим избежать. Мы по-прежнему стремимся сохранять вертикальное разбиение историй. Но как это сделать, не создавая при этом громоздкие истории?

Как резать торт (варианты разбиения)

Вот стратегии, которые помогут:

1. Этапы бизнес-процесса
2. Бизнес-правила
3. Сценарии: happy / unhappy 
4. Типы данных и параметры
5. Платформы и каналы
6. Размытия и склейки

1. Этапы бизнес-процесса

Делите процесс на шаги, если каждый шаг приносит пользу. Если шаг сам по себе не ценен — объедините его с другими.

Можно начать с базового потока, а затем добавлять сложность постепенно, получая обратную связь.

2. Бизнес-правила

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

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

3. Сценарии: Happy / Unhappy 

Иногда стоит разделить сценарии на:

• Удачный (happy)
• Неудачный (unhappy)

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

4. Виды данных

Полезно при создании форм или поиска.

Пример:

• сначала — фильтрация по цене,
• потом — по бренду,
• потом — по цвету.

5. Платформы и каналы

Проще сфокусироваться на одной платформе, особенно в начале. Например, сначала — мобильная версия, потом — десктоп.

6. Размытия и склейки

Избегайте размытых формулировок и склеек. Делайте истории конкретными.

Пример:

«Сохранять и использовать карту»  

Разделите на:

1. Сохранить карту
2. Использовать сохраненную карту

Вывод

User stories — это не теория, а практический навык. Используйте метафору «многослойного торта», избегайте горизонтальных разрезов, и применяйте стратегии вроде бизнес-сценариев, бизнес-правил, типов данных и платформ. Главное — обратная связь, тестируемость и ценность.