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

В IT есть, например, паттерны проектирования или алгоритмы — математические шаблоны. Шаблоны — полезная «вещь»: позволяют меньше писать, подставляя что-то в уже сформированные рамки. 

Мы в Ak Bars Digital тоже используем много собственных наработок, методологий и шаблонов, чтобы делать все быстро и качественно. В этой статье поделюсь прикладным шаблоном, который создали опытным путем для удобной работы с пользовательскими историями.

Автор: Дарья Плоскодняк — опытный продуктовый аналитик в Ak Bars Digital. Занимается развитием сквозных процессов Ак Барс Банка, связанных с банковскими картами. Один из лидеров внутреннего комьюнити аналитиков компании и участник многочисленных митапов и конференций. Статья подготовлена по мотивам выступления Дарьи на одном из таких мероприятий – митапе Three Amigos Talk.

Пользовательские истории

Сначала кратко о пользовательских историях.

Пользовательская история (или User Story, US) — это:

• понятное описание функций системы от лица пользователя, набор пользовательских сценариев;

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

С точки зрения agile-разработки, пользовательская история — это задача, которая должна помещаться в спринт.

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

Я как 1_ хочу 2, чтобы 3__.

1 – тип пользователя, персонаж

2 – действие или цель

3 – результат или ценность

Разберем некоторые кейсы с реальными пользовательскими историями:

#1. «Я, как клиент банка, хочу получать сообщение об изменении статуса заявки на кредит, чтобы скорее получить деньги».

Вопрос, который возникает, глядя на эту user story, какой статус ожидает клиент? 

Как улучшить: «Я, как клиент банка, хочу получать смс об одобрении заявки на кредит, чтобы как можно скорее получить деньги»

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

#2. «Я как сотрудник магазина хочу проще заходить в складскую программу».

Первое, что бросается в глаза — не сформулирована ценность данной истории. Буквально, нет ответа на вопрос «Зачем?».

Также обратите внимание на формулировку «проще». Подобные слова в описании пользовательской истории не уместны, так как «проще» у каждого свое. Такая формулировка не позволяет этой истории отвечать одному из критериев качества пользовательских историй — недвусмысленности. Подробнее про критерии качества читайте в статье на Википедии.

Как улучшить: «Я как сотрудник магазина хочу иметь возможность авторизоваться в складской программе по коду из 4-х цифр, чтобы обслуживать больше клиентов за смену»

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

Пример детального и максимально наполненного описания пользовательской истории.

Разберем пример подробнее.

Описание

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

Пример нашей нумерации: ABOL-04-113.

• ABOL — название команды Ak Bars Online;

• 04 — номер эпика;

• 113 — номер истории.

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

Примечание. Эпик — это сущность (крупная часть функционала или этап проекта), ценность которой для пользователя мы не можем выразить в одной истории текущего спринта. Эпик разбивается на истории и задачи. Например, в проекте «Курьерская доставка банковских карт», эпик — это «Доставка неименных банковских карт». Пример истории : «Я как клиент банка могу получить неименную карту в срок, который я указал в Заявке, чтобы сократить срок получения банковской карты»

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

Пример: ABOL-04-113. »Я как действующий клиент банка, уже зарегистрированный в личном кабинете, хочу иметь возможность сменить пароль, чтобы иметь доступ к личному кабинету, если забыл пароль»

Сценарии использования, или Use case

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

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

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

Пример нашего юзкейса.

Не стоит тратить ресурсы на описание юзкейсов, если у вас небольшие проекты — интеграционные сервисы, мало интерфейсов и пользователей, или вообще нет пользователей.

Правила бизнеса

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

Запоминаем главное — правила бизнеса могут и будут меняться!

Ограничения бизнеса

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

Ограничения бизнеса тоже могут меняться, но не так часто, как правила. 

Интеграция с внешними системами

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

Сюда отлично подойдет описание инфраструктуры, ER-диаграмма, примеры в формате JSON или XML, и все прочие детали интеграции с внешними системами. В общем, всё, что может пригодиться разработчикам.

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

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

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

Критерии приемки прописываются отдельно для каждой истории. Пример критериев приемки для нашей истории:

1. Пользователю доступна функция смены пароля на всех устройствах.

2. Функция смены пароля доступна на странице авторизации.

3. Новый пароль не может дублировать старый пароль.

4. Новый пароль имеет не меньше 8 символов.

5. Пароль не может начинаться и заканчиваться пробелом.

Есть еще один вариант описания критериев приемки, который очень любят тестировщики — модель Given-When-Then. 

• Given (дано) — состояние ситуации до начала действий пользователя.

• When (когда) — пользователь совершает какие-то действия.

• Then (тогда) — ситуация меняется и система реагирует на действия пользователя.

Подробнее про это можно почитать в статье «Как описать User stories, используя язык Gherkin».

В критериях приемки есть только два варианта — да и нет.

Критерий не может быть выполнен, например, на 90%.

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

Важно не путать критерии приемки и DOD (definition of done). DOD — это общий чек-лист критериев – он может быть один на все пользовательские истории в рамках процесса. 

Как отличить DOD и критериев приёмки? Очень просто. Представим доставку пиццы. DOD — пицца приготовлена, упакована, отправлена, вручена. Критерии приемки — пицца приготовлена из тех ингредиентов, которые заказал клиент.

На этом всё. Вы можете пользоваться шаблоном как есть или модернизировать его. Главное — формулировать понятно для всех участников и понимать ценность пользовательской истории для бизнеса.

Практика «три С» — card, conversation, confirmation

Ещё одна практика, которой можно пользоваться при работе с user story.

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

Conversation — обсуждения требований с командой. Если вы аналитик, то не используйте схему работы, в которой просто написали пользовательскую историю и передаете её разработке. Так не работает. Нужно обсудить требования с командой, в идеале выделить на это отдельную встречу.

Confirmation — прописать четкие критерии приемки.

А как на практике?

Давайте пофантазируем и представим заказчика, который передал требования на разработку и сказал «Хочу ракету». У нас есть две команды, в каждой — по одному аналитику: Соня и Степан. Они одновременно начали работать с требованиями. 

• Степан решил сэкономить время и побыстрее сделать ракету. Для этого передал свои требования в виде незрелой пользовательской истории в команду разработки. 

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

Чья команда быстрее выполнит проект? Чей проект будет более качественным? Оставляйте свои мнения в опросе и пишите комментарии — давайте обсуждать.