Как писать Юзер Стори (пользовательские истории)?

Наверное, все, кто работает БА, сталкивались с написанием юзер стори (они же пользовательские истории).

Абсолютно на каждом интервью бизнес-аналитика, на котором я была в роли собеседуемого или собеседующего, были вопросы про юзер стори типа:

1. Пишешь ли ты юзер стори?
2. Приведи пример юзер стори.
3. Как разбивать юзер стори?
4. Какие признаки хорошей юзер стори?
5. Вот есть такая-то задача, напиши 3 пользовательские истории.
6. Какие приемочные критерии ты предложишь для такой-то юзер стори?

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

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

Давайте на высоком уровне разберемся, что это за зверь вообще такой, из чего состоит, и рассмотрим примеры юзер стори.

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

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

Что такое agile писала в статье Что такое Agile и какая роль бизнес-аналитика в Agile?

Компоненты Юзер Стори

Хорошо структурированная пользовательская история включает в себя три основных компонента: Роль, Цель и Польза.

Роль: В основе каждой пользовательской истории лежит пользователь или персона. Этот компонент проясняет, вокруг кого крутится пользовательская история, и придает контекст последующим элементам.
Действие: действие определяет, чего пользователь хочет. Это может быть действие, задача или цель, которую пользователь хочет достичь с помощью программного обеспечения.
Польза/ценность/цель: этот компонент описывает ценность или преимущество, которое получает пользователь, достигая поставленной цели. Он раскрывает "почему"/"чтобы что", что стоит за желаемым действием пользователя.

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

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

я хочу.... - это, собственно, наша цель - чего юзер хочет достичь.

Но! Это не конечная цель - у многих действий само действие - это не конечная цель (если ты не самурай).

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

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

Итого - конечная польза - это то, что дает нам больше контекста. Ведь, на самом деле, если юзеру нужен доступ к аккаунту, пароль можно и не сбрасывать, а можно, например, отправить "магическую ссылку" на почту, по которой юзер автоматически зайдет в аккаунт, не вводя пароль. Этот момент нужен для того, чтобы команда нашла лучшее решение из всех возможных, и чувствовала, что это не просто задача ради задачи, а что она приносит пользу кому-то конкретному. А это уже приятно!

Сохраняйте простоту и целенаправленность

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

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

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

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

Что еще нужно в пользовательской истории?

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

Но почему тогда требуют умения писать юзер стори, а про другое не говорят?

Потому, что пользовательские истории еще содержит в себе много всего)

Компонент, без которого юзер стори не возьмут в разработку - это приемочные критерии.

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

Acceptance Criteria, они же AC, они же приемочные критерии. Попробуем написать их все?

Пишем сначала все, что приходит в голову.

1. Пользователь имеет доступ к функции сброса пароля на странице входа в систему. (прим. - написано довольно абстрактно - но детали можно увидеть в дизайне)
2. При нажатии на ссылку "Забыли пароль?" пользователь перенаправлен на страницу сброса пароля.
3. На странице сброса пароля пользователю предложено ввести адрес электронной почты, к которой привязан аккаунт.
4. После заполнения поля адреса электронной почты адресом в валидном формате и отправки формы, пользователь видит сообщение (прим - что такой валидный формат - должно быть объяснено где-то, но в АС этой информации не место, т.к. АС тогда раздуются и будет сложно их проверять и держать все в голове. Кроме этого - сообщение - тоже может быть описано где-то в примечаниях к истории, или на отдельной странице, где вы храните все сообщения в системе, чтобы при написании нового не отклониться от формата остальных сообщений. Ссылка на этот документ должна быть прилинкована к пользовательской истории. Где и как показано сообщение - это вопрос дизайна, который тоже должен быть прилинкован. И да, сообщение типа "если по этому адресу зарегистрирован аккаунт, вам отправлено письмо" должно быть показано даже если по такому адресу нет аккаунта, т.к. иначе вы даете лазейку злоумышленникам получать "валидные" имейл адреса - зная адрес, зарегистрированный в системе, можно уже "ломать" аккаунт, пытаясь подставлять разные пароли)
5. Если введенный адрес электронной почты связан с зарегистрированной учетной записью, пользователю отправлено письмо о восстановлении пароля. (прим - разработка самого письма может быть в соседней пользовательской истории, и тогда история пользователя с письмом - блокирует разработку этой истории, а значит, должна быть разработана до завершения этой.)
6. Письмо должно содержать уникальную ссылку, при нажатии на которую пользователь переходит на защищенную страницу сброса пароля.
7. На странице сброса пароля пользователь имеет возможность ввести новый пароль и отправить его.
8. Поле для ввода пароля содержит правила проверки сложности пароля ). (прим. - например, минимальная длина, включение заглавных и строчных букв, цифр и специальных символов. Эти детали тоже или где-то описываются, или соответствуют общим правилам принятого на проекте требования к сложности пароля - они могут быть разные. В любом случае, в истории нужно дать ссылку на эти правила или описать их в примечаниях. Но на момент разработки истории команды уже точно должна завершить реализацию регистрации, где и должны были быть описаны требования к сложности пароля).
9. Если пользователь отправляет форму со "слабым" паролем, пользователь видит сообщение и пароль не заменяется.
10. После ввода правильного нового пароля нажатие кнопки "Сбросить пароль" приводит к обновлению пароля пользователя.
11. После успешного сброса пароля пользователь автоматически перенаправлен на страницу входа в систему. (прим. - это тоже правило безопасности - т.к. автоматический вход привносит уязвимости)
12. Пользователь может войти в систему, используя новый пароль.
13. Пользователь не может войти в систему, используя старый пароль (прим. - критерий для подстраховки)
14. При попытке использования ссылки для сброса пароля, по которой уже сбросили пароль, появляется сообщение об ошибке, указывающее на то, что срок действия ссылки истек или она уже была использована. (прим. - и тут мы вспоминаем, что время действия ссылки - конечно, поэтому добавляем следующий АС - приемочный критерий. И да, не забываем написать об этом в письме - пользователь должен понимать, на какой время можно рассчитывать.)
15. Ссылка для восстановления пароля действует в течение 1 часа после отправления (прим. - время действия ссылки может быть разным, например, для банковских систем это время может быть сокращено до 10 минут, к примеру. Есть правила безопасности, в частности, в вашей компании или компании клиента - лучше узнать, какие они, а не придумывать свои. Если их нет - нужно руководствоваться стандартами, например, https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md . OWASP - это онлайн сообщество, создающее свободно распространяемые статьи, методологии, документацию, инструменты и технологии в области безопасности веб-приложений.)
16. Никакая конфиденциальная информация не должна быть раскрыта или доступна неавторизованным лицам. (прим. - кажется, что это размытый критерий, но он проверяемый - только где-то укажите, какие данные хранит система, и QA проверит, не "утекли" ли они где-то в процессе - например, не попал ли электронный адрес, имя в ссылку, сообщения на страницах и пр).

Итого, при попытке написать критерии к одной пользовательской истории, их вышло аж 16. Руководствуясь критериями качества требований, проверяем - все ли хорошо написано? Ведь каждая юзер стори - это требование. Видим сразу, что мы уже не прошли 1й и 3й - Атомарность и Краткость.

По Атомарности - часть критериев может "переехать" в другую полноценную юзер стори.

Вернитесь наверх и попробуйте подумать, какие именно?

По Краткости - навскидку, "хорошая пользовательская история" содержит 2-8 критериев (это не обязательное правило, но ориентир). Да, почти в 2 раза перебрали. Нам поможет тут декомпозиция требований.

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

В итоге должна получиться пользовательская история, которая решает 1 проблему пользователи (да, история пользователя не может быть не окончена - то есть, если юзер стори содержит, к примеру, критерии 1-4, то она задачу с начала до конца не выполняет, соответственно, это уже никакая не юзер стори - вряд ли цель юзера - увидеть сообщение).

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

Не так и просто, но этому можно научиться)

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

Заключение

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

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

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

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