User Story: что это и как правильно декомпозировать с помощью SPIDR
- Denis Gobov
- 21 мая 2024 г.
- 6 мин. чтения
Обновлено: 15 окт. 2024 г.
Сегодня техника «User Story» (пользовательская история, история пользователя, юзер стори) является самой популярной техникой для описания требований в ИТ-проектах. Что привело эту технику к первому месту? Краткость формулировки и ориентированность на ценность для стейкхолдера. Все это сделало User Story оптимальным вариантом для Agile.
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
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».