Получите бесплатно — все материалы с наших курсов и тренингов
Тренинги, Курсы, Обучение — Agile, Scrum, OKR
Тренинги, Курсы, Обучение — Agile, Scrum, OKR
Тренинги, Курсы, Обучение — Agile, Scrum, OKR

Что такое SPIDR User story, примеры по пяти техникам деления пользовательских историй

17 сентября, 2023 г.
34 отзыва, в среднем 5 из 5
Что такое SPIDR User story, где и когда их применять + примеры
3
Редактировать описание
Дополнить публикацию

Что такое SPIDR User story?

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

8
0
Редактировать

Зачем делить User Story?

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

2
0
Редактировать

Почему метод деления назвали SPIDR и кто им пользуется?

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

8
0
Редактировать
Переквалификация в IT
Станьте руководителем Digital–продукта в Enterprise
Начать обучение →

SPIDR User Story

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

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

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

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

2
0
Редактировать

Техника Spikes

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

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

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

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

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

5
0
Редактировать

Техника Paths

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

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

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

2
0
Редактировать

Interfaces

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

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

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

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

3
0
Редактировать

Data

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

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

8
0
Редактировать

Rules

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

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

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

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

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

8
0
Редактировать

Кто разделяет User Story

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

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

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

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

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

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