top of page

User Story: что это и как правильно декомпозировать с помощью SPIDR

Обновлено: 15 окт. 2024 г.

Сегодня техника «User Story» (пользовательская история, история пользователя, юзер стори) является самой популярной техникой для описания требований в ИТ-проектах. Что привело эту технику к первому месту? Краткость формулировки и ориентированность на ценность для стейкхолдера. Все это сделало User Story оптимальным вариантом для Agile.

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


Формат User Story

Самый распространенный формат истории пользователя включает в себе три блока: Как [роль], я хочу [функциональность или атрибут качества], чтобы [цель]

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

формат user story

Пример User Story:

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


Преимущества формата User Story:

  • Легко понять и использовать.

  • Ориентирован на конкретные потребности пользователей.

  • Помогает установить контекст и цель.


Критерии качества требований для User Story

Общепринятый набор критериев качества описывается акронимом INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.


Критерии качества для пользовательской истории

 

INVEST говорит, что пользовательская история должна:

  • не зависеть от других пользовательских историй,

  • ее границы должны быть предметом переговоров,

  • она должен приносить достаточную ценность для клиента,

  • команда разработки должна иметь возможность оценить сложность разработки,

  • она должна быть достаточно маленькой, чтобы ее можно было разработать за одну итерацию, и

  • ее можно протестировать, чтобы убедиться, что она соответствует потребностям клиента.

 

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

 

Что такое SMALL для пользовательской истории?

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

И все же большие истории – головная боль для product owner и команды разработки, в том числе бизнес-аналитика. Если история вообще не помещается в один спринт, то фундаментальное правило регулярной доставки ценности клиенту нарушается. Даже если разработка одной истории занимает целиком один спринт, то велик риск, что по результатам бизнес не получит ничего. Если что-то может пойти не так, оно пойдет не так. Поэтому стандартная рекомендация: в спринт должно входить 6-10 историй пользователя.


Несмотря на то, что все истории пользователей относительно уникальны, Майк Кон предложил 5 универсальных подходов к декомпозиции, которые описываются акронимом SPIDR (если хотите, можете добавить букву Е между D и R и получите паучка 😊)

 

SPIDR или 5 подходов к декомпозиции User Story

Работа с user story: 5 подходов к декомпозиции

SPIDR расшифровывается как Spike, Path, Interface, Data, Rules. Давайте рассмотрим каждую составляющую подробно.


Spike (Спайк)

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

Пример использования спайка:

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

Если раньше мы не работали с этими платежными системами, то по мнению команды пользовательская история слишком велика.

 

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


Скорее вам подойдет обычный формат задачи. Для нашего примера это: "Исследовать API разных платежных систем и выяснить, как их интегрировать."

 

Как понять, что вам нужен спайк

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

 

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

 

Path (Путь)

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

Пример пользовательской истории:

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

Пути:

  • Путь 1: "Как пользователь, я хочу восстановить пароль через электронную почту."

  • Путь 2: "Как пользователь, я хочу восстановить пароль через SMS."

 

Еще один популярный пример: в случае оформления заказа пользователь может совершить покупку с помощью кредитной карты или подарочной карты, купленной кем-то другим.

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

Может возникнуть вопрос: а стоит ли разбивать историю о покупке с помощью кредитной карты на отдельную историю для Visa и отдельную историю для MasterCard? Скорее нет, чем да. А вот вариант оплаты через PayPal, Stripe будет целесообразно выделить в отдельные истории.

 

Interface (Интерфейс)

Interface — это разделение истории пользователя по различным интерфейсам или взаимодействиям с пользователем. Это особенно полезно, когда история касается изменения или добавления функциональности в интерфейс приложения.

Разделение истории пользователя по интерфейсам

Пример юзер стори:

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

Интерфейсы:

  • Интерфейс 1: "Как пользователь, я хочу просматривать историю заказов на веб-сайте."

  • Интерфейс 2: "Как пользователь, я хочу просматривать историю заказов в мобильном приложении."

Другой пример — создание изначально простого пользовательского интерфейса, а затем отдельная история, которая делает пользовательский интерфейс более удобным. Например, добавление функции drag&drop.

Еще один пример – экспорт данных в разных форматах. Изначально пользовательская история может включать выгрузку в формате Word, Excel и PDF. Эту историю можно разделить на три – по одной на каждый формат.

 

Data (Данные)

Data — это декомпозиция истории по различным наборам данных или типам данных. Это может быть полезно, когда история касается работы с большими или сложными наборами данных.

Пример пользовательской истории:

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

Данные в пользовательской истории:

  • Данные 1: "Как администратор, я хочу анализировать отчеты о продажах по регионам."

  • Данные 2: "Как администратор, я хочу анализировать отчеты о продажах по категориям продуктов."

 

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

 

Rules (Правила)

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

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

Пример пользовательской истории:

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

Правила

Правило 1: Валидация электронной почты

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

Критерии приемки:

  • Пользователь вводит адрес электронной почты на странице регистрации.

  • Система проверяет, соответствует ли адрес электронной почты допустимому формату.

  • Если формат неверный, система выводит сообщение об ошибке.

Правило 2: Минимальная длина пароля

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

Критерии приемки:

  • Пользователь вводит пароль на странице регистрации.

  • Система проверяет, соответствует ли пароль минимальной длине (например, не менее 8 символов).

  • Если пароль слишком короткий, система выводит сообщение об ошибке.

 

Заключение

Чтобы правильно декомпозировать пользовательские истории вам потребуется практика. Прислушивайтесь к обратной связи от команды:

  • Устраивает ли их текущий размер историй?

  • Истории кажутся им слишком большими или слишком маленькими?

  • Какие аспекты из SPIDR вызывают у них сложности?

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


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


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

 

Если хотите попрактиковать в написании качественных историй – приходите на наш комплексный тренинг по бизнес-анализу. Если ощущаете, что вам мешает отсутствие технических знаний, то ждем вас на курсе «Technical skills for Business Analyst».


42 Comments


Ariska sarah
Ariska sarah
20 часов назад

Kabar4d Bocoran Pola Gacor Rtp 98.99% Pragmatic & PgSoft https://donnasellsnaplesproperties.com/

Like

Gwen Greta
Gwen Greta
2 дня назад

QIUQIU99 adalah situs agen qq atau qiu qiu online resmi terbaik yang menyajikan akses link daftar login situs qiuqiu99 uang asli terpercaya di Indonesia.

Like

Jesicca Christy
Jesicca Christy
3 дня назад

Dominoqq pkv games official online gambling real money game in Indonesia. 18 games from trusted pkv games bandarqq sites in 2025.

situs qiuqiu99

Like

PKV GAMES RESMI
PKV GAMES RESMI
4 дня назад

PKV Games adalah salah satu platform bermain judi qq online dalam permainan kartu domino dan remi poker uang asli terpercaya. Dimana menerapkan 18 permainan dari server pkv games online terbaik untuk dapat memainkan dengan deposit receh. Untuk permainan terdiri poker, domino99, bandarq, aduq, bandar poker, sakong, capsa susun, bandar66, perang baccarat, perang dadu, bd qq, adu sakong, gaple, live casino, slot, bd koprok, bandar remi, dan sportbook terbaru di tahun 2025

https://hasbihtc.com/

pkv games pkv games qq pkv games login pkv games resmi pkv games bandarqq dominoqq pkv games pkv games online pkv games apk situs pkv games agen pkv games daftar pkv games

Like

Live Draw Hongkong adalah situs resmi siaran undian togel hongkong yang menampilkan angka tercepat malam ini. LIVE DRAW HK

Like
bottom of page