> For the complete documentation index, see [llms.txt](https://docs.system-analyst-base.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.system-analyst-base.ru/soft-skills/trebovaniya/klassifikaciya-trebovanii/uroven-polzovatel/user-story.md).

# User story

{% hint style="info" %}
**User stories** представляют собой короткие, простые и понятные описания функциональности системы с точки зрения конечного пользователя или заинтересованной стороны. Они фокусируются на описании потребностей и целей пользователей, а не на технических деталях. Каждая user story содержит название, описание и критерии приемки. 
{% endhint %}

## Формат записи User story

Я, как \[Роль пользователя]\
Хочу \[решить задачу/выполнение какого-либо действия]\
Когда \[при каких условиях/обстоятельствах]\
Чтобы \[достичь цель]

### Пример

Я, как \[юзер кофе-машины] \
Xочу \[взбить молоко] \
Когда \[открываю кран подачи пара] \
Чтобы \[получилась густая молочная пенка]

Я, как \[юзер кофе-машины]\
хочу \[иметь возможность наливать воду в кофе-машину]\
Когда \[открываю крышку резервуара с водой]\
Чтобы \[кофе-машина могла функционировать]

## INVEST

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

* **Independent** (независимый). В пользовательской истории лучше описывать одну или несколько независимых функций. Они должны решить проблему пользователя без помощи других инструментов. 
* **Negotiable** (подлежащий обсуждению). User Story обязательно нужно обсудить в команде и внести изменения, если потребуется. Без обсуждения есть риск, что команда разработки получит неполное представление о задаче.
* **Valuable** (ценный). В функции, которую описывает User Story, должна быть реальная ценность для пользователя.
* **Estimable** (поддающийся оценке). Хорошую User Story можно оценить — понять, сколько времени, ресурсов и денег займёт разработка функции.
* **Small** (маленький). История должна быть краткой и ёмкой. Объёмные истории сложнее оценить, и они могут потребовать больше ресурсов на разработку.
* **Testable** (поддающийся тестированию). С критериями приёмки команде разработки будет проще создать нужную функцию. Тестировать историю лучше за один раз — это ещё одна причина, почему в истории не должно быть много деталей.

Источники: 

* <https://habr.com/ru/companies/deutschetelekomitsolutions/articles/598625/> (почитать)
* <https://practicum.yandex.ru/blog/chto-takoe-user-story-i-kak-napisat/>