User Story

User Story (пользовательская история) - это короткое описание функциональности или требования к системе, написанное с точки зрения конечного пользователя.

Основная цель пользовательских историй - описать конкретные потребности и цели пользователей, которые система должна удовлетворить. User Story представляется в формате короткого текстового предложения:

Как [кто], я хочу [что], чтобы [зачем]

User Story состоит из трех основных элементов:

1. «Кто» - указывается роль пользователя или актор, для которого предназначена функциональность
2. «Что» - описывается цель, функция или желание, которое пользователь хочет выполнить или получить
3. «Зачем» - указывается цель или польза (ЦЕННОСТЬ), которую пользователь получит, выполнив это действие

Примеры:

1. Как пользователь, я хочу зарегистрироваться на сайте, чтобы получить доступ к эксклюзивному контенту.
2. Как гость системы, я хочу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
3. Как пользователь, я хочу хранить свои фотографии в системе, чтобы иметь возможность показать их другим пользователям.
4. Как пассажир поезда, я хочу получить смс с местом и временем отправления состава, чтобы не пропустить свою поездку.
5. Я как пользователь сайта авиакомпании, хочу видеть расписание рейсов, чтобы выбрать удобное для меня время отбытия.
6. Я как сотрудник отдела поддержки банка, хочу видеть историю операций по карте клиента при его обращении, чтобы быстрее помогать клиентам.
7. Я как клиент банка, хочу иметь возможность открывать доп. карту в приложении, чтобы не тратить время на поход в отделение банка.

Преимущества использования User Story

1. US помогают сосредоточиться на реальных потребностях пользователей и их целях
2. Короткие текстовые формулировки легко читать и понимать, что упрощает коммуникацию
3. US ориентированы на предоставление ценности пользователям, что помогает приоритизировать разработку
4. US служат отправной точкой для обсуждения между заказчиками и разработчиками
5. US как инструмент agile-разработки способствует гибкому и пошаговому развитию функциональности, ориентированному на потребности пользователей

Почувствуем разницу между обычной US и US с ценностью:

	Обычная User Story	User Story с ценностью
Кто	Я как корпоративный клиент	Я как корпоративный клиент
Боль	-	Не понимаю в каком состоянии счет и из-за этого ухожу в минус
Что	Хочу скачивать отчет о движениях денежных средств	Хочу останавливать работу, если баланс стал критично низким
Зачем	Чтобы видеть, что баланс стал отрицательным	Чтобы не терять деньги

INVEST

Написанную User Story можно оценить по шести критериям INVEST, которые сформулировал директор по развитию продукта Билл Уэйк:

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

2. Negotiable (подлежащий обсуждению). User Story обязательно нужно обсудить в команде и внести изменения, если потребуется.
   История не должна содержать слишком много деталей и история может быть изменена и обновлена перед выполнением работ

3. Valuable (ценный). В функции, которую описывает User Story, должна быть реальная ценность для пользователя.
   История должна приносить пользу бизнесу и закрывать потребность заказчиков

4. Estimable (поддающийся оценке). Хорошую User Story можно оценить - понять, сколько времени, ресурсов и денег займёт разработка функции.
   История ясна и содержит достаточно деталей, чтобы историю можно было оценить

5. Small (маленький). История должна быть краткой и ёмкой.
   История может быть сделана за 1 итерацию и не более чем за 3 дня.
   История не содержит более 13 стори поинтов

6. Testable (поддающийся тестированию). С критериями приёмки команде разработки будет проще создать нужную функцию.
   Тестировать историю лучше за один раз - это ещё одна причина, почему в истории не должно быть много деталей.
   История должна иметь возможность быть протестированной или содержать критерии приемки

Критерии приемки (Acceptance Criteria)

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

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

Формат:

"С учетом [условия], когда я выполняю [действие], я ожидаю [результат]"

Примеры:

1. Перед отправкой фото в чате я должен иметь возможность добавить подпись к фото.
2. Если возникнут проблемы с запуском камеры моего телефона, должно появиться сообщение об ошибке типа "Камера не может быть запущена"

User Story определяет требования к функциональности или возможности, а критерии приемки определяют "Definition of done" для истории.