User Stories на основе проектных требований

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

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

Пользовательская история (далее просто стори) — короткая формулировка намерения (несколько предложений), описывающая что-то, что система должна делать для пользователя.

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

Стори придумали последователи методологии eXtreme Programming (XP). В XP стори пишут сами заказчики, непосредственно интегрируясь в процесс разработки. А вот в Скраме за это отвечает отдельный менеджер (владелец продукта), агрегируя информацию от заказчика.

Стори:

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

Ценность декомпозиции стори

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

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

А значит качество декомпозиции напрямую влияет на качество продукта и приближает нас к тому, что нужно заказчикам
и пользователям.

Применение принципа INVEST

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

Билл Вейк (один из авторов XP), ввел в работу аббревиатуру INVEST, чтобы описать атрибуты хорошо декомпозированной пользовательской истории.

Независимость

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

Пример:

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

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

Обе стори связаны. Не очень понятно, как их тестировать и поставлять в продукт по отдельности.

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

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

Убрали зависимость и переформировали стори иначе.

Обсуждаемость

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

Ценность

Думаю, это самый важный атрибут. Отвечает за наличие в стори любого объема ценности за отведенное нам на работу время. Именно на основе этого атрибута приоритизируются все доступные пользовательские истории. Чем ценность для бизнеса выше, тем раньше стори уйдет в разработку.

Оценка трудозатрат

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

Компактность

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

Априори, значительно легче маневрировать компактными объектами при движении в нагруженной системе, а команда разработки обычно похожа на нагруженную систему :-) Поэтому компактность стори влияет на предсказуемость команды разработки, а значит и на доверие к команде.

Тестируемость

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

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

Представление стори через слои

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

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

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

https://agileforall.com/vertical-slices-and-scale/

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

Использование горизонтальных слоев замедляет поставку ценности
до тех пор, пока все слои не будут соединены воедино в результате серии итераций: UX слой, UI слой, backend с архитектурой БД и т.д. Такой подход не проходит проверку атрибутами на независимость
и ценность.

Запись пользовательских историй

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

Уметь переваривать потенциальные бизнес-цели, требования заказчика и правильно трассировать их в пользовательские истории — одна из ключевых задач команды разработки.

Так выглядит трассировка у нас в студии:

Цели → Эпики → Пользовательские истории → Задачи на разработку → Подзадачи

Сама формулировка:

Как <действующее лицо>, в случае <ситуация/обстоятельство>, я хочу <действие>, чтобы <ожидаемый результат>

• <действующее лицо> — роль пользователя в системе или его статус
• <ситуация/обстоятельство> — например, оплата заказа или регистрация нового пользователя
• <действие> — например, принять заказ. Тут скрывается коварнейшая ошибка. Важно записывать не конкретное действие в системе («Нажать кнопку принять»), а запрос на удовлетворение потребности (“Подтвердить оплаченный заказ”). Не загоняйте сами себя в рамки готового решения, вместо поиска наилучшего варианта под существующие требования.
• <ожидаемый результат> — например, отправить заказ на комплектацию. Не пропускайте эту часть, она поддерживает объективность мнений среди всех участников и здорово отсеивает pet features.

В завершении указываем:

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

Выводы

1. Формулируя стори, описывайте намерения, что система должна делать для пользователя.
2. Концентрируйтесь на ценности для пользователей от вашей стори, нежели на структурном или функциональном разбиении на задачи и технические компоненты.
3. Проверяйте получившиеся стори на соответствие INVEST.
4. Отдельно прорабатывайте с владельцем продукта критерии приемки каждой стори.
5. Продумывая реализацию и создавая задачи, мысленно «разрезайте» пользовательские истории насквозь, чтобы пользователи почувствовали ценность ваших результатов настолько рано, насколько это возможно.
6. Проверяйте формулировки стори, особое внимание <действию>
   и наличию потребности.

Эта заметка является частью цикла заметок по разработке проектов
с высокой долей неопределенности в Molinos Studio.