Ответ
User Story (Пользовательская история) — это краткое, простое описание одной функции программного обеспечения, сформулированное с точки зрения конечного пользователя и описывающее, какую ценность он хочет получить.
Стандартный формат (шаблон Коннора):
Как [<тип пользователя/роль>],
Я хочу [<выполнить некоторое действие>],
Чтобы [<получить определённую пользу/результат>].Примеры:
- Как зарегистрированный пользователь, Я хочу восстановить пароль по email, Чтобы получить доступ к аккаунту, если я его забыл.
- Как покупатель, Я хочу фильтровать товары по цене, Чтобы быстро найти варианты в рамках моего бюджета.
Ключевые компоненты хорошей User Story (INVEST-критерии):
- Independent (Независимая): Минимизирует зависимости от других историй.
- Negotiable (Обсуждаемая): Детали уточняются в диалоге, а не жёстко зафиксированы.
- Valuable (Ценная): Приносит пользу пользователю или бизнесу.
- Estimable (Оцениваемая): Команда может оценить её сложность.
- Small (Маленькая): Может быть выполнена за один спринт (идеально — за несколько дней).
- Testable (Тестируемая): Имеет чёткие критерии приемки.
Acceptance Criteria (Критерии приемки): Это условия, которые должны быть выполнены, чтобы история считалась завершённой и рабочей. Часто оформляются в виде сценариев.
Пример User Story с критериями приемки в формате Gherkin:
Feature: Восстановление пароля
Как зарегистрированный пользователь,
Я хочу восстановить пароль,
Чтобы вернуть доступ к своему аккаунту.
Scenario: Успешный запрос на восстановление пароля по email
Given Я нахожусь на странице входа в систему
When Я нажимаю ссылку "Забыли пароль?"
And Я ввожу свой зарегистрированный email "user@example.com" в появившуюся форму
And Я нажимаю кнопку "Отправить инструкции"
Then Мне показывается сообщение "Инструкции отправлены на ваш email"
And Письмо со ссылкой для сброса пароля отправляется на адрес "user@example.com"
Scenario: Запрос с незарегистрированным email
Given Я нахожусь на странице восстановления пароля
When Я ввожу email "unknown@example.com"
And Я нажимаю кнопку "Отправить инструкции"
Then Мне показывается сообщение "Пользователь с таким email не найден"
And Письмо не отправляетсяUser Story — это основной артефакт для планирования в Agile-методологиях (Scrum, Kanban), который связывает техническую реализацию с бизнес-ценностью.
Ответ 18+ 🔞
Давайте разберем эту вашу "пользовательскую историю", а то народ путается, как блядь, муму с чиполлино.
Вот смотрите, сидит такой чувак, не технарь, а нормальный человек, и думает: "Хочу, чтобы программа делала вот эту хуйню, потому что мне это выгодно". Вот это и есть user story, ёпта! Не какой-то там техзадание на трёхстах листах, а простое человеческое "хочу".
Как это выглядит, блядь (шаблон):
Как [<я, например, пользователь>],
Я хочу [<сделать что-то простое>],
Чтобы [<получить от этого какую-то пользу, а не просто потыкать кнопки>].Примеры, чтобы не быть мудаком:
- Как я, забывчивый кретин, Я хочу тыкнуть "забыл пароль", Чтобы мне на почту прислали волшебный пиздюль, а не регистрироваться заново.
- Как я, скупой барыга, Я хочу отсортировать все шмотки от дешёвых к дорогим, Чтобы сразу понять, на что у меня хватит бабла, а на что — нихуя.
А чтобы история была годной, она должна быть как хитрая жопа — соответствовать INVEST:
- Independent (Самостоятельная): Чтобы её можно было делать, не вписываясь в пять других историй, как последний мудак.
- Negotiable (Договорная): Не высечена в граните, а обсуждается. "А давайте вот так сделаем?" — "А хуле нет?"
- Valuable (Ценная): Должна приносить реальную пользу, а не быть хуйнёй для галочки.
- Estimable (Оцениваемая): Чтобы разработчики не говорили "ой, ёпта, хз", а могли прикинуть, насколько это пиздец сложно.
- Small (Маленькая): Должна влезать в один спринт. Не "сделать весь интернет", а "добавить одну кнопку".
- Testable (Тестируемая): Чтобы тестировщик мог проверить и сказать: "Да, работает, а не 'вроде норм'".
Критерии приемки (Acceptance Criteria) — это когда вы договариваетесь, что значит "сделано": Типа, "окей, кнопка есть, но если я введу левый email, ты мне не будешь говорить 'всё ок' и отправлять письмо в никуда, а скажешь 'иди нахуй, такого пользователя нет'".
Вот живой пример, как это всё вместе:
Feature: Восстановление пароля
Как зарегистрированный юзер, который всё забывает,
Я хочу сбросить пароль,
Чтобы не терять доступ к своему аккаунту из-за своей же ебанутости.
Scenario: Всё прошло хорошо
Given Я торчу на странице логина
When Я жму на "Забыл пароль, сука"
And Вбиваю свой настоящий email "myrealbox@example.com"
And Жму "Го!"
Then Я должен увидеть сообщение "Письмо летит к тебе, жди"
And На почту "myrealbox@example.com" должно прилететь письмо с ссылкой. Настоящее, а не в спам.
Scenario: Ввёл какую-то дичь
Given Я опять на этой странице восстановления
When Я ввожу email "petya@derevnya.global"
And Снова жму "Го!"
Then Мне должна выскочить ошибка "Бро, такого юзера нет. Очнись."
And Никаких писем никуда не улетает, чтоб не спамить.Вот и вся магия, блядь. User Story — это чтобы все, от менеджера до программиста, понимали, зачем они горбатятся, а не просто "ну надо же фичу запилить". Ценность, ёпта! Всё ради ценности.