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

[Ares_ekb]

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

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

Я в итоге пришел к более простой схеме для постановок (это просто набросок, который может меняться по необходимости):

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

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

# Сценарий использования

№ | Действия пользователя           | Ожидаемый результат
-------------------------------------------------------------------
1 | Активировать смену пароля,      | Появилась форма смены пароля
  | кликнув в верхнем правом углу   |
  | по значку пользователя и выбрав |
  | в появившемся всплывающем меню  |
  | соответствующий пункт           |
-------------------------------------------------------------------
2 | Ввести логин, старый пароль,    | В случае успешной смены пароля
  | новый пароль с подтверждением,  | показано уведомление "Пароль
  | нажать кнопку "Сменить пароль"  | успешно изменен". В случае
  |                                 | ошибки - сообщение "Не удалось
  |                                 | сменить пароль"
  
# Правила валидации

№ | Правило
-------------------------------------------------------------------
1 | Пароль должен быть не короче 8 символов
2 | Пароль должен содержать хотя бы одну заглавную букву и одну цифру
...

# Требования к пользовательскому интерфейсу

Пароль не должен отображаться на экране при вводе. Вместо символов
должны отображаться кружочки.

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

# Детали реализации

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

Плюсы следующие:

1) Такой сценарий проще читается обычными людьми. Нет дурацких повторов "Пользователь делает то-то ... Система делает то-то ..." - на мой взгляд это какая-то калька с диаграмм последовательностей, к которой все привыкли и даже не осознают её корявости.

2) Сценарии практически один в одни идут в ПМИ. Ещё их могут использовать тестировщики при ручном тестировании или при разработке автоматических тестов. Технические писатели - при написании руководства пользователя. Во всех этих местах сценарии описываются именно в терминах действий пользователей и ожидаемых результатов. Потом просто меньше работы по приведению сценариев к нужному виду.

3) Альтернативные сценарии - это тоже калька с диаграмм последовательностей или с диаграмм сценариев использования. Кто-то когда-то давно придумал описывать их в таком виде. Но, блин, для нормальных людей это настолько сложно для восприятия. Соотносить нумерацию в основном сценарии и в альтернативном. Зачем эти мучения? Если там прямо реально полноценный альтернативный сценарий, то лучше сделать его полностью самостоятельным сценарием. А если простое ветвление в конце, то проще это сразу описать и не мучить людей. По моему опыту большинство сценариев простые и линейные. Совсем детали типа правил валидации или UI можно вынести отдельно. Представьте, что вы пишите ПМИ или руководство пользователя. Зачем там все эти сложности?

Это примерная схема, можно добавить по необходимости пред- и постусловия и остальное. Хотя в вашем примере постусловие "Новый пароль пользователя сохранен в БД" избыточно - это детали реализации. Может пароли вообще не в БД хранятся, а просто в файлах. И может быть там хранится не сам пароль, а его хэш.

[webhamster]

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

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

Что есть эпик?

[AkBarsDigital]

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

Например, проект «Курьерская доставка банковских карт». Эпик: «Доставка неименных банковских карт». История 1: «Я как клиент банка могу получить неименную карту в срок, который я указал в Заявке, чтобы сократить срок получения банковской карты»

[anitspam]

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

Вроде бы надо выбрать Соню, так как она

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

Но с другой стороны Степан ознакомился со статьёй и знает, что

> не используйте схему работы, в которой просто написали пользовательскую историю и передаете её разработке. Так не работает.

[iozjik]

Отличная статья, спасибо!