User story это простыми словами
Коротко
User story (пользовательская история) — короткое описание нужной функции или результата простым языком с точки зрения того, кто будет этим пользоваться. В истории называют роль, действие и выгоду: кто, что хочет и зачем. Это не техническое задание и не список требований, а повод для разговора команды о том, что и для кого делаем.
Что такое пользовательская история
Пользовательская история отвечает на три вопроса: для кого делаем, что человек хочет получить и какую выгоду это ему даст. Пишут её от лица пользователя, а не системы: не «добавить кнопку экспорта», а «как бухгалтер, я хочу выгружать счёт в Excel, чтобы не переносить цифры вручную».
В agile-разработке история — наименьшая единица работы. Она описывает результат, а не способ его достичь: команда сама решает, как сделать функцию. Подробности обсуждают, когда берут историю в работу, а не заранее в документе.
Шаблон истории
Самый распространённый шаблон: «Как [роль], я хочу [действие], чтобы [выгода]». Роль — конкретный человек: клиент, менеджер, бухгалтер. Действие — что он хочет сделать. Выгода — зачем ему это, какую задачу он решает.
Пример: «Как постоянный клиент, я хочу, чтобы сайт запоминал мои данные, чтобы не заполнять форму заново при каждом заказе». Здесь видно, для кого делаем, что именно и зачем. Из такой записи команда понимает ценность, а не только набор экранов.
Чем история отличается от требований и задач
Требование описывает, что должна делать система: «поле обязательно для заполнения». Задача — что нужно сделать команде: «сверстать страницу». История описывает, чего хочет пользователь и зачем. Это разный уровень разговора.
История — не контракт с подробной спецификацией. Это приглашение к обсуждению: когда команда берёт историю в работу, она уточняет детали с заказчиком или продуктологом. Ошибка — превращать историю в мини-ТЗ и терять главное: для кого и зачем.
Из чего складывается хорошая история
- Роль — конкретный пользователь, а не абстрактный «пользователь». Чем точнее роль, тем яснее потребность.
- Действие — что человек хочет сделать. Одно действие на одну историю.
- Выгода — зачем ему это. Без выгоды история превращается в задачу.
- Критерии приёмки — как проверить, что история сделана. Их обсуждают вместе с историей, но записывают отдельно.
- Размер — история должна помещаться в одну итерацию. Если не помещается, её делят на части.
Критерии приёмки
Критерии приёмки — короткий список условий, при которых историю считают выполненной. Они помогают команде и заказчику одинаково понимать результат. Например, для истории о сохранении данных клиента критерии могут быть такими: данные сохраняются после закрытия браузера, клиент может их изменить, при первом заказе форма пустая.
Критерии пишут простым языком и проверяют на реальных примерах. Если критериев нет, историю нельзя принять: каждый будет понимать готовность по-своему.
Как разбить большую историю на маленькие
Большую историю делят на части, каждая из которых сама по себе даёт пользователю пользу. Например, историю «хочу оплачивать заказ картой» можно разделить на оплату одной картой, сохранение карты для следующих заказов и оплату несколькими способами. Каждая часть — отдельная история со своей выгодой и критериями.
Другой способ — разделить по шагам сценария: сначала человек выбирает товар, потом вводит адрес, потом оплачивает. Каждый шаг — отдельная история. Главное, чтобы после каждой части можно было показать работающий результат, а не половину экрана.
Частые вопросы
Кто пишет пользовательские истории?
Чаще всего продуктолог или менеджер продукта, но не только он. Инженеры тоже пишут истории, когда речь о технических улучшениях или внутренних инструментах. Важно, чтобы историю обсуждали с теми, кто будет её делать, и с теми, для кого она предназначена.
Обязательно ли использовать шаблон «как …, я хочу …, чтобы …»?
Шаблон помогает не забыть про роль и выгоду, но это не догма. Главное — чтобы из истории было понятно, для кого делаем, что человек хочет и зачем. Если шаблон мешает, пишите свободно, но проверьте, что все три элемента на месте.
Чем история отличается от задачи в трекере?
Задача — это работа команды: «сверстать страницу». История — это потребность пользователя: «как клиент, я хочу видеть статус заказа, чтобы понимать, когда придёт доставка». Одна история может породить несколько задач.
Что такое INVEST?
Это набор признаков хорошей истории: независимая, обсуждаемая, ценная, оцениваемая, маленькая, проверяемая. По-английски: Independent, Negotiable, Valuable, Estimable, Small, Testable. Проверка по этим признакам помогает понять, готова ли история к работе.
Что такое «три C» в пользовательских историях?
Card, Conversation, Confirmation — карточка, разговор, подтверждение. История записывается на карточке, обсуждается командой и заказчиком, а результат подтверждается критериями приёмки. Так история остаётся короткой, а детали уточняются в разговоре.
Можно ли использовать истории не в разработке ПО?
Да. Подход работает везде, где нужно понять, для кого и зачем делается функция или услуга. Например, при запуске нового продукта или улучшении клиентского сервиса. Главное — описывать с точки зрения пользователя и не забывать про выгоду.
Посмотреть рядом
Когда команда делает функции, которые никто не просил
Собрать требования из разговоров с клиентами
Пользовательские истории помогают услышать клиента, но их ещё нужно собрать и превратить в понятный план. Если продукт делается наугад, даже правильные истории не спасут.
Я провожу исследование рынка и конкурентов: собираю сотни высказываний покупателей, нахожу, за что они платят и чего им не хватает. Из этого получаются истории, которые действительно отражают потребности.