Как писать пользовательские истории (с примерами и критериями приёмки)

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

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

Формат

Пользовательская история состоит из трёх частей:

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

• Кто — конкретный тип пользователя: первый посетитель, платящий участник, администратор клиники. Не «пользователь».
• Что — то, что человек хочет сделать, своими словами. Не то, как устроен экран.
• Зачем — результат, который для него важен. Эту часть часто пропускают, а она не даёт построить не то, что нужно.

Пример:

Как участник спортзала, я хочу отменить запись на занятие с телефона, чтобы человек из листа ожидания мог занять моё место, и с меня не взяли штраф за неявку.

Слова «зачем» сообщают две вещи, которых нет в «что»: функция должна работать на телефоне, и в ней задействованы лист ожидания и правила штрафов.

Критерии приёмки

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

Часто их пишут в формате Дано / Когда / Тогда:

• Дано — исходная ситуация
• Когда — пользователь что-то делает
• Тогда — такой-то результат

Для истории о записи в спортзал:

1. Дано, что у меня есть запись более чем за 12 часов до занятия, когда я нажимаю «Отменить» и подтверждаю, тогда запись удаляется и я вижу «Запись отменена».
2. Дано, что я отменяю запись и на занятие есть лист ожидания, когда отмена сохранена, тогда первый человек из листа получает место и письмо.
3. Дано, что запись меньше чем за 12 часов до занятия, когда я нажимаю «Отменить», тогда я вижу, что применяется штраф за позднюю отмену, до подтверждения.
4. Дано, что экран имеет ширину телефона, тогда кнопка «Отменить» видна без горизонтальной прокрутки.

Простой чек-лист тоже подойдёт, если каждый пункт можно проверить. «Отменять легко» — не проверяемо. «Отмена занимает не больше двух нажатий из списка записей» — проверяемо.

Пошагово: как написать хорошую историю

Шаг 1. Начните с реального пользователя и реальной проблемы

Выберите один тип пользователя и то, с чем он сталкивается сегодня. Если вы беседовали с клиентами, используйте их слова. «Я всегда забываю отменить и мне списывают деньги» — лучшая отправная точка, чем «добавить функцию отмены».

Шаг 2. Напишите историю в одну строку

Заполните шаблон. Если не получается написать убедительное «чтобы», спросите себя, нужна ли вообще эта функция.

Шаг 3. Добавьте от трёх до шести критериев приёмки

Сначала охватите основной успешный сценарий, затем важные вариации: другая роль, пустое состояние, ограничение, ошибка. Если пишете больше шести, история, вероятно, слишком большая.

Шаг 4. Отметьте, что не входит в историю

Одна строка экономит много времени на переписке: «Не входит: возвраты за платные занятия; администраторы, отменяющие записи за участников». Это не даёт истории разрастаться во время работы.

Шаг 5. Проверьте по INVEST

INVEST — распространённый чек-лист для хороших историй. История должна быть:

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

Хорошие и плохие примеры

Как разбить слишком большую историю

Большие истории — то место, где проекты застревают. Частые способы разбить их:

• По роли пользователя. Участники отменяют свои записи; сотрудники отменяют любые.
• По шагу сценария. Просмотр занятий; запись на занятие; напоминание.
• Сначала простой случай. Отмена бесплатного занятия сейчас; штрафы и возвраты — в следующей истории.
• По вариациям данных. Сначала поддержка одной локации, позже нескольких.
• Сначала основной путь, потом ошибки. Сначала построить работающий вариант, затем добавить обработку ситуаций вроде заполненного занятия или истёкшего абонемента.

Каждая часть всё равно должна быть тем, чем пользователь может воспользоваться и что заметит.

Пользовательские истории как промпты

Пользовательская история с критериями приёмки очень близка к хорошему промпту для ИИ-конструктора приложений. Она даёт ИИ кто, что, зачем и определение готовности. Одна история в сообщении:

Как участник спортзала, я хочу отменить запись на занятие с телефона, чтобы человек из листа ожидания мог занять моё место. Критерии приёмки:

1. Кнопка «Отменить» есть у каждой записи в разделе «Мои записи», с шагом подтверждения.
2. Отмена за больше чем 12 часов до занятия просто удаляет запись.
3. Меньше чем за 12 часов показывать «Применяется штраф за позднюю отмену: 5 $» до подтверждения и сохранить штраф в записи.
4. Если на занятие есть лист ожидания, первый человек получает место и письмо.
5. Работает на экране шириной с телефон. Не входит: возвраты, отмена записей сотрудниками за участников. Построй это, затем проверь каждый критерий в превью и скажи, какие проходят.

Можно также попросить ИИ составить истории по черновой идее, а затем отредактировать их самостоятельно:

Вот идея моего приложения: [два-три предложения]. Напиши пользовательские истории для первой версии, сгруппированные по типам пользователей, каждая с 3–5 критериями в формате «Дано / Когда / Тогда». Отметь, какие необходимы для запуска, а какие могут подождать.

Всегда читайте и редактируйте результат. ИИ не знает ваших пользователей, а вы знаете.

Критерии приёмки также служат планом тестирования. Когда история построена, пройдите по каждому критерию самостоятельно. Наше руководство как протестировать приложение перед запуском развивает эту мысль.

Как пользовательские истории связаны с другими документами

• PRD описывает весь продукт: проблему, пользователей, объём. Пользовательские истории — подробные части внутри него. См. как написать PRD с помощью ИИ.
• Баг-репорт описывает поломку в сравнении с историей, которая уже была построена. См. как написать хороший баг-репорт.
• MVP — это минимальный набор историй, который даёт основную ценность. См. что такое MVP.

Типичные ошибки

• «Как пользователь…» Слишком расплывчато. Назовите конкретный тип пользователя.
• Пропуск «чтобы». Без причины вы не сможете разумно выбирать компромиссы.
• Описание решения вместо потребности. «Хочу выпадающий список» фиксирует дизайн, прежде чем кто-либо об этом задумался.
• Критерии, которые нельзя проверить. «Просто», «быстро» и «интуитивно» — это пожелания, а не критерии.
• Истории, которые на самом деле эпики. «Управлять аккаунтом» — это десять историй.
• Писать все истории заранее. Пишите подробно следующие несколько, а остальные держите одной строкой, пока до них не дошли.

Истории в Mythex

В Mythex режим Plan хорошо подходит, чтобы превратить идею в истории: агент обсуждает подход до того, как что-либо менять. Когда история готова, переключитесь в Build и вставьте её, по одной истории в сообщении. После каждой команда /test может пройтись по превью и проверить сценарий, а любой ответ можно откатить через Revert to this point, если пошло не так. См. эффективные промпты в документации и наше руководство как писать промпты для ИИ-конструкторов приложений.

Чек-лист пользовательской истории

• Называет конкретный тип пользователя
• Описывает потребность, а не дизайн
• Содержит реальную причину в «чтобы»
• Есть от трёх до шести проверяемых критериев приёмки
• Охватывает хотя бы один крайний случай или ошибку
• Указано, что не входит в историю
• Достаточно маленькая, чтобы построить и проверить за один раз
• Критерии проверены после сборки, по одному

Вопросы