Как писать User Stories, чтобы было понятно всем

User Story — одна из составляющих процесса разработки практически любого IT-продукта по методологии Agile. Ее используют в качестве основы для проработки бизнес-логики додатку, функциональности и дизайна. Ошибки при составлении юзер стори могут привести к тому, что итоговый продукт не будет соответствовать запросам пользователей. Подробней о том, что такое User Stories и как их правильно составлять, расскажем в статье.

Что такое User Stories и зачем они на самом деле нужны

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

Обычно юзер стори пишут по таким двум шаблонам:

1. As a <user/user role> I want <capability> so that <benefits description>. Что я, как пользователь, хочу или должен получить от системы (имеется в виду функциональность), чтобы решить свои проблемы/закрыть собственные потребности.

1. In order to <receive benefit> as a <role>, I can <goal/desire>. Чтобы заполучить нужную ценность в качестве конкретной роли, что пользователь должен получить от продукта в плане функциональности.

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

Основные критерии качества юзер стори

Есть разные подходы для оценки качества User Story. На практике часто используют формулу INVEST из-за ее простоты и универсальности.

INVEST:

• Independent — User Story должна быть цельной и независимой от других компонентов, но с учетом возможных взаимодействий между различными составляющими системы. Например, новички BA часто делают ошибку, когда отделяют UI от Backend — надо помнить, что раздельно друг от друга они не имеют смысла для пользователей.
• Negotiable — юзер стори должна быть поводом для дискуссий и поиска решений, как лучше выполнить задачу и удовлетворить потребности пользователей.  
• Valuable — каждая User Story должна нести ценность.
• Estimable — качественную юзер стори всегда можно просчитать в story points, часах и т.д.
• Small — хорошо, если большую User Story можно разбить на меньшие (декомпозировать), чтобы лучше проработать каждую и иметь больше гибкости при планировании процесса разработки.
• Testable — при написании стори обязательно надо учитывать возможность ее тестирования.

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

Пример плохой user story

Представьте разработку медицинского проекта. BA после общения со стейкхолдерами предлагает такой пример user story: As a user I want to see patient data from system HC-1 in system CHC-12 so that I can use the data. 

Давайте вместе разбираться, что не так в данной юзер стори:

• нет уточнения, какой именно user: врач, пациент, администратор и т.д;
• patient data может быть разной по формату, объему;
• capabilities без четкой формулировки, потому что данные можно создавать, редактировать, удалять, поэтому мало указать to see patient data;
• benefits зависят от роли юзера, его действий, других факторов.

То есть в этом примере user story явно не хватает деталей для создания понятного технического задания девелоперам. Нужно декомпозировать на отдельные юзер стори с учетом ролей пользователей и прочего.

Пример хорошей user story

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

Декомпозиция User Stories

Декомпозиция User Story — это разделение большой стори на меньшие по размерам, так чтобы каждая имела свою ценность для пользователя и соответствовала другим критериям качества. Это делается для конкретизации ТЗ для разработчиков, упрощения планирования — маленькие по объему задачи значительно легче поместить в рамки одного спринта, чем объемное задание. В качестве примера рассмотрим страницу входа на сайт.

Есть одна большая задача — разработать Login Page. Для оптимизации процесса декомпозируем на шесть отдельных User Stories, как человек может залогиниться. Каждая стори независима от других и имеет свою ценность, при этом некоторые из них при необходимости дробятся еще — внедрить ту же самую валидацию для номера 5 или добавить несколько этапов для ситуации с напоминанием пароля.

Как сделать декомпозицию

По факту декомпозиция любого проекта включает в себя дробление System на Epics — большие куски функциональности, которые невозможно реализовать за один спринт. Поэтому далее проводится разделение на меньшие части — User Stories. Их в свою очередь разбивают на Tasks — именно их выполняют девелоперы и тестировщики. 

Конечно, схема может быть сложнее, например, между System и Epic будет еще Novel. Но нужно помнить, что в любом случае одна юзер стори всегда принадлежит только одному эпику. Когда же выполняют все Tasks конкретной User Story, ее закрывают. Так делается со всеми блоками вплоть до done всех Epics — тогда можно сказать, что System построена.

В Jira процесс декомпозиции выглядит так:

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

• Spike — задача, которую должна сделать команда до выполнения User Story. Например, для написания какого-то модуля нужно дополнительно изучить новую технологию.
• Enable / Tech Story — техническая задача, которая разблокирует возможность вообще приступить к User Story.

Эти модули нужны для упрощения планирования и менеджмента процесса разработки в целом.

Основные подходы к декомпозиции

User Story Mapping

Story Map — простая и популярная техника для создания Backlog с помощью визуализации подхода к декомпозиции под названием by workflow step.

1. Определяете основных юзеров User и их цели User Goal в аппликации: чтобы что-то купить, написать отзывы и т.д.
2. Расписываете основные активности пользователей отдельными блоками Activity.
3. Разбиваете действия пользователей на шаги Steps, которые они должны сделать для выполнения определенной активности, например, купить товар: залогиниться, выбрать, положить в корзину, приобрести.
4. Разделяете шаги на отдельные User Tasks по приоритету — более важные, то есть обязательная и основная функциональность, расположены выше.

Процесс User Story Mapping удобен тем, что Story Map можно сделать самому, вместе с клиентом или командой. При этом полученный результат нагляден, а все данные легко занести в любой таск-менеджер по типу Jira.

Вместо вывода

Правильно созданная User Story значительно упрощает планирование и разработку продукта. Она помогает понимать контекст задачи, а с помощью грамотной декомпозиции можно учесть максимум деталей и значительно снизить риски возникновения ошибок. Главное помнить, что хорошая юзер стори имеет понятную структуру и отвечает основным критериям качества: Independent, Negotiable, Valuable, Estimable, Small, Testable.