SPIDR: как из большой User Story сделать понятные задачи

Маленький эксперимент: как бы вы разбили эту историю?

Прежде всего предлагаю взять одну большую User Story в привычном формате и попробовать разрезать ее на части.

Исходная User Story:

«Как пользователь я хочу оформить заказ и оплатить его онлайн, чтобы получить товар»

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

Вопросы к User Story

1. Представьте, что вы смотрите на эту задачу на груминге. Как начнете рассуждать, что делать первым делом?

Варианты:

1. Сначала сделаем бэкенд отдельно, затем сделаем и прикрутим фронтенд
2. Стоп. А мы вообще понимаем, как это будет работать?
3. Mobile First! Давайте сразу вынесем mobile в отдельную задачу
4. Давайте просто сделаем всё сразу, чтобы потом не возвращаться

2. Хорошо, допустим, мы не бросаемся сразу ставить задачи и писать код. Прежде чем что-то декомпозировать, стоит понять: а в чём здесь вообще неопределенность? где мы сейчас гадаем, а не знаем?

Варианты:

1. Как ведет себя платежный провайдер при ошибке
2. Как обрабатывается повторная попытка оплаты
3. Есть ли какие-то ограничения у интеграции
4. Всё перечисленное выше

3. Допустим, с неизвестностью разобрались. Давайте решим: реализация чего дальше даст самый быстрый и ощутимый прогресс?

Варианты:

1. Поддержать все сценарии оплаты сразу
2. Взять только успешный сценарий оплаты
3. Сразу добавить скидки, промокоды и налоги
4. Сначала сделать API, UI потом

4. Что здесь на самом деле усложняет как саму User Story, так и разработку?

Варианты:

1. Добавление возможности применения скидок, промокодов, выяснение ограничений при доставке
2. Кнопка «Оплатить»
3. Название страницы
4. Сам факт наличия заказа

5. А интерфейсы обязательно делать все сразу?

Варианты:

1. Да, иначе получится «незаконченное решение»
2. Нет, можно начать с одного интерфейса
3. Лучше сначала сделать только бэкенд
4. Лучше сначала сделать только mobile

Резюмируем 

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

• Story 1: пользователь может успешно оплатить заказ онлайн.
• Story 2: система обрабатывает ошибку оплаты.
• Story 3: пользователь может повторить попытку оплаты.
• Story 4: добавить промокоды.
• Story 5: поддержать расширенные данные заказа.
• Story 6: вынести mobile-интерфейс отдельно. 

• Задача на ресерч: исследовать сценарии интеграции с платежным провайдером.

На самом деле на каждом шаге мы использовали одну и ту же логику декомпозиции, просто под разными углами:

1. Сначала убрали неизвестность, вынесли интересующие вопросы как задачи на исследования. 
2. Потом оставили только один (успешный) сценарий.
3. Далее отказались от лишних правил и фичей.
4. Ограничили данные.
5. Решили, что не будем делать все интерфейсы сразу.

Если в какой-то момент вам показалось, что большая и страшная User Story вдруг стала почти очевидной, — это неслучайно: вы только что «прогнали» ее через SPIDR. 

Что такое SPIDR

Автор книг «Пользовательские истории в Agile-разработке программного обеспечения», «Оценка и планирование в Agile» и «Успех в Agile» Майк Кон предложил способ быстро разбивать пользовательские истории на части с помощью одного из пяти приемов, которые образуют запоминающуюся аббревиатуру SPIDR — как «паук». 

Spikes: сначала убрать неопределенность

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

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

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

• Снижает неопределенность. Позволяет понять, как делать до начала разработки, а не в процессе.
• Улучшает оценку. После хорошего этапа discovery команда оценивает задачу не вслепую, а на основе реального понимания.

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

Минусы

• Не дает пользовательской ценности напрямую. В отличие от обычных stories, Spike не приносит фичу в продукт.
• Легко превратить в «бесконечное исследование», если не ограничить его по времени. 

Paths: разделить по пользовательским сценариям

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

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

В этом подходе могу выделить следующие плюсы:

• Реализация одного сценария (обычно happy path) позволяет быстро дать работающий инкремент и сразу получить ценность.
• Небольшой сценарий хорошо тестируется: каждый путь — отдельный проверяемый тест-кейс.

Минусы могут быть следующими: 

• Не всегда очевидно, где резать, так как сценариев может быть много — сложно выбрать «правильные».
• Сохраняется риск того, что остается скрытая сложность: даже один сценарий может быть перегружен правилами или данными.

Interfaces: не делать сразу все интерфейсы

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

Хороший пример — оплата телефоном в банковских приложениях. На Android такая функция давно реализована через NFC и работает как стандартный сценарий, а на iOS из-за ограничений системы банки не могут использовать тот же подход. В результате появляется альтернативное решение, например оплата через Bluetooth, и под него формируется отдельная пользовательская история с более высоким приоритетом именно для iOS.

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

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

Data: ограничить объем данных

Автор техники предлагает разделить историю на части в зависимости от данных, упростив или ограничив поддерживаемые данные. 

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

Например, если вы реализуете загрузку видео, не обязательно сразу поддерживать множество форматов: можно начать с одного (например, MP4), а остальные добавить позже. Или в банковском приложении сначала не учитывать отрицательный баланс, а добавить этот сценарий отдельной историей.

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

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

Rules: упростить бизнес-логику

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

User Story: пользователь может оформить заказ

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

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

SPIDR: практическая польза или очередной теоретический Agile-инструмент? 

SPIDR как способ декомпозиции удобно использовать в качестве отправной точки, особенно когда перед тобой большая и расплывчатая User Story и непонятно, с чего начать. Он помогает быстро «нащупать» структуру задачи: где неопределенность, что можно упростить, какие части можно вынести отдельно, — уже на этом этапе история становится более управляемой и обсуждаемой.

Но важно понимать, что сам по себе SPIDR не решает проблему, не заменяет ни продуктового мышления, ни качественной проработки требований. Если история изначально размыта или не несет четкой ценности, получится лишь разбить User Story на несколько таких же неочевидных частей. В какой-то момент можно даже скатиться в формальность: пройтись по всем «буквам», но так и не приблизиться к понятному результату.

Именно поэтому лучше воспринимать SPIDR как вспомогательный инструмент, а не как универсальный рецепт. Он хорошо работает вначале, когда нужно разложить задачу и задать правильные вопросы. А дальше подключаются другие подходы, например INVEST помогает проверить качество истории, Story Mapping — увидеть пользовательский путь и определить MVP.

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