Это пять техник для нарезки больших пользовательских историй на маленькие.

С большими User Story сложнее работать, не всегда команда успеваю закончить их за спринт и показать результат. С маленькими проще работать, за спринт можно успеть 6-8 пользовательских историй и сразу дать ценность клиенту и пользователям.

SPIDR — это аббревиатура по первым буквам техник: Spikes, Paths, Interfaces, Data, Rules. Техники используют начинающие команды–разработчиков. Потому что это простой способ начать нарезку пользовательских историй. Со временем они пробуют другие техники и выбирают самые удобные для себя.

Когда команда работает над продуктом, то делит работу над ним на User Story — пользовательские истории. Это короткие и простые описания действий пользователя в продукте. Например, перевод денег со своей карты другому человеку. Чтобы быстрее увидеть результаты работы, пользовательские истории делят на маленькие подзадачи.

В Agile–командах принято делить большие пользовательские истории на несколько маленьких. Чтобы за недельный спринт сделать 6-8 историй. Есть много методик, как делить пользовательские истории. В тексте мы расскажем про SPIDR. Это аббревиатура по первым буквам техник: Spikes, Paths, Interfaces, Data, Rules.

В SPIDR пользовательские истории разделяют по архитектурным слоям: одна история для бизнеса, другая — для пользовательского интерфейса, третья — для базы данных и так далее. Этот подход помогает разделить большие пользовательские истории. Им часто пользуются начинающие команды.

До паука SPIDR не хватает одной буквы. Но для запоминания названия техник картинка подходящая

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

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

Для бизнеса здесь и сейчас метод Spikes не принесет ценности. Но он делает умнее и опытнее команду разработчиков.

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

Пример нарезки User Story на мелкие задачи

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

Возьмем пользовательскую историю: пользователь хочет оплачивать покупки в интернет–магазине. У него есть два возможных пути: оплата с помощью кредитной карты или оплата с помощью Paypal. Теоретически оплату кредитной картой можно разделить по типам кредиток: Visa, Mastercard, American express и так далее.

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

Под интерфейсами здесь понимают различные устройства: смартфоны на базе iOS или Android. Пользовательские истории делятся с учетом платформы, под которую их разрабатывают. Поэтому для начала стоит выбрать что–то одно, чтобы не распыляться.

Например, вы можете разделить User  Story на поддержку различных типов устройств: одна история для  веб–приложения,  другая —  для настольных браузеров, третья —  для устройств Android, четвертая — для iOS.

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

Пользовательская история экспорта данных может изначально включать две разные цели, например, Word или Excel. Одна история —  экспорт в Word, другая —  экспорт в Excel. Обратите внимание, что в этом сценарии первая история будет больше, чем вторая. Потому что сначала разрабатывают сложную User Story — экспорт в любом формате. Добавление вывода в другой формат файла потребует меньших усилий.

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

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

По технике Rules  пользовательские истории разделяют по правилам ведения бизнеса или технологическим стандартам.

Возьмем пример с онлайн–покупкой билетов в кино. Многие кинотеатры вводят  ограничения: не более пяти билетов на один адрес электронной почты.

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

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

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

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

В некоторых командах принято совместно решать, как разделять User Story. Есть команды, где эту функцию выполняет Product owner.

Кто и когда разделяет пользовательские истории, зависит от опыта команды и проекта.

Главное правило: разделять пользовательские истории на небольшие части. Команде будет гораздо проще работать с ними и постоянно давать ценность для бизнеса.

Большие пользовательские истории мешают команде. Их могут не успеть  завершить к концу спринта. Это деморализует команду разработчиков.