# 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/>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.system-analyst-base.ru/soft-skills/trebovaniya/klassifikaciya-trebovanii/uroven-polzovatel/user-story.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.