User story: как писать пользовательские истории

User story (пользовательская история) — это короткое, простое описание функции продукта с точки зрения того, кому она нужна. Классическая формула user story: «Как [роль], я хочу [действие], чтобы [ценность/результат]». Например: «Как новый пользователь, я хочу войти через Google, чтобы не заводить отдельный пароль». Смысл user story не в том, чтобы детально описать, что программировать, а в том, чтобы зафиксировать потребность пользователя и договориться о ней в команде. Детали решения рождаются позже, в разговоре, а сама история лишь напоминает, ради кого и зачем делается работа.

Что такое user story и зачем она нужна

User story пришла из гибких методологий как противоядие от толстых технических заданий, которые описывают, что делать, но забывают, зачем. История переворачивает фокус: сначала — пользователь и его потребность, потом — реализация.

Ключевая идея — user story это не документ, а обещание разговора. Короткая формулировка не пытается ответить на все вопросы, она лишь фиксирует суть, чтобы команда обсудила детали, когда возьмёт историю в работу. Поэтому пользовательские истории намеренно компактны: одна карточка, одна потребность.

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

Формат «как… я хочу… чтобы…»

Канонический шаблон состоит из трёх частей, и каждая отвечает на свой вопрос:

• •Как [роль] — кто пользователь. Не «пользователь» вообще, а конкретная роль: новый клиент, администратор, менеджер, гость. Роль подсказывает контекст.
• •Я хочу [действие] — что человек хочет сделать. Действие с точки зрения пользователя, а не системы.
• •Чтобы [ценность] — зачем ему это, какую пользу он получит. Самая важная и самая часто забываемая часть.

Сравните две формулировки. Плохо: «Добавить кнопку экспорта в CSV». Хорошо: «Как бухгалтер, я хочу выгрузить операции в CSV, чтобы свести отчёт в своей таблице». Вторая объясняет, кто и зачем — и сразу видно, что важна не кнопка, а возможность продолжить работу в привычном инструменте.

Часть «чтобы» — не украшение. Именно она позволяет команде предложить лучшее решение, а иногда и понять, что задачу можно закрыть проще, чем задумывал автор.

Критерии качества по INVEST

INVEST — это чек-лист из шести свойств хорошей user story. Аббревиатура складывается из первых букв:

• •Independent (независимая). Историю можно сделать отдельно от других, она не завязана жёстко на соседние.
• •Negotiable (обсуждаемая). Это не контракт, а предмет разговора. Детали уточняются с командой, а не спускаются сверху.
• •Valuable (ценная). Приносит понятную пользу пользователю или бизнесу. Если ценность не сформулировать — история под вопросом.
• •Estimable (оценимая). Команда понимает историю достаточно, чтобы прикинуть трудозатраты. Если оценить невозможно — история слишком расплывчата.
• •Small (небольшая). Помещается в один спринт. Слишком крупную историю (эпик) дробят на части.
• •Testable (проверяемая). Есть способ понять, что история сделана. Отсюда растут acceptance criteria.

INVEST — не бюрократический фильтр, а быстрая проверка на здравый смысл. Если история проваливает два-три пункта, её стоит переписать до того, как команда возьмёт её в работу.

Acceptance criteria: когда история готова

Acceptance criteria (критерии приёмки) — это условия, при которых история считается выполненной. Сама формула «как… я хочу… чтобы…» слишком общая, чтобы по ней принять работу, поэтому к ней добавляют конкретные критерии.

Для истории «Как пользователь, я хочу восстановить пароль, чтобы вернуть доступ к аккаунту» критерии могут быть такими:

• •На странице входа есть ссылка «Забыли пароль».
• •После ввода почты приходит письмо со ссылкой на сброс.
• •Ссылка действует ограниченное время и одноразова.
• •После смены пароля пользователь может войти с новым.

Хорошие критерии приёмки конкретны и проверяемы: по каждому можно однозначно сказать «выполнено» или «нет». Они снимают споры «а мы это имели в виду?» и служат основой для тестирования. Часто их пишут в формате «Дано — Когда — Тогда», описывая условие, действие и ожидаемый результат.

User story отвечает на вопрос «зачем и для кого», acceptance criteria — на вопрос «как понять, что готово». Первое без второго нельзя принять, второе без первого превращается в бездушное ТЗ.

Как писать user story: пошагово

Частые ошибки

• •Техзадание под видом истории. «Как система, я хочу отправить POST-запрос…» — это не user story. За ролью должен стоять человек, а не сервер.
• •Пропущенная ценность. Часть «чтобы» отбрасывают, и история превращается в список задач без объяснения смысла.
• •Слишком крупная история. Эпик размером в месяц выдают за одну историю. Её нельзя оценить и нельзя сделать в спринт — надо дробить.
• •Решение вместо потребности. В историю зашивают конкретную реализацию, лишая команду возможности найти вариант проще.
• •Нет критериев приёмки. Историю берут в работу без понимания, что считать готовым, — и спорят об этом уже на демо.
• •История ради истории. Формат соблюдён, но за ним нет реальной потребности пользователя — просто переписанный пункт из хотелок.

Итог

User story — это способ держать в фокусе пользователя, а не только код: короткая формула «как… я хочу… чтобы…» напоминает, для кого и зачем делается работа. Пишите от лица роли, всегда указывайте ценность, проверяйте историю по INVEST и подкрепляйте критериями приёмки. Тогда бэклог перестаёт быть списком задач и становится списком решённых проблем. Как продуктовые команды выстраивают работу с историями и требованиями, разбирают на профильных деловых мероприятиях, где практики делятся рабочими шаблонами и честными разборами ошибок.