User Story и INVEST

В прошлых статьях мы выявляли требования. Теперь нужно их записать, и один из самых распространённых способов называется пользовательской историей. User Story - это короткая запись одного требования с точки зрения того, кто будет им пользоваться. Она не заменяет разговор: она фиксирует, о чём нужно поговорить.

Кейс: отмена заказа в виде истории

Владелец «Узелка» хочет, чтобы покупатели сами отменяли заказы. Для команды это одна большая идея, в которой смешано многое: кнопка, правила, возврат денег, письмо покупателю. Чтобы не потеряться, мы выделяем одну историю и проверяем её.

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

Из чего состоит история

У истории три части. Роль - это тот, кто хочет что-то сделать, в нашем кейсе покупатель. Действие - это то, что он делает. Ценность - это польза, ради которой он это делает.

Роль выбирают из списка заинтересованных сторон из 02-02, а ценность связывают с бизнес-целью. Если ценность не удаётся сформулировать, часто оказывается, что история не нужна или роль выбрана неверно.

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

INVEST - это набор из шести проверок, который помогает оценивать пользовательские истории. Каждая буква - одна проверка.

Буква	Что проверяем	Как нарушается в кейсе
I, Independent	История независима от других	«Отменить заказ» нельзя сделать, пока нет «Посмотреть статус», и обе ждут друг друга
N, Negotiable	Детали можно обсуждать	В истории уже написано, какого цвета будет кнопка и где она стоит
V, Valuable	Есть польза для того, кто заботится о продукте	«Добавить таблицу отмен» даёт пользу только команде, не покупателю
E, Estimable	Объём работы можно оценить	Неясно, как вернуть деньги, и команда не может оценить работу
S, Small	История мала и выполняется за часы или дни	«Сделать личный кабинет» займёт месяцы
T, Testable	Есть примеры поведения, по которым можно проверить	«Отмена должна работать удобно» нельзя проверить

Размер «часы или дни» взят как ориентир самой модели INVEST. В конкретной команде границу определяют сами: обычно это то, что влезает в одну итерацию. Итерация - это короткий отрезок работы команды, в конце которого есть результат.

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

Большую историю, которую нельзя проверить целиком, называют эпиком. Эпик - это крупная задача, которую делят на несколько историй. Делят по пользе для пользователя, а не по таблицам и экранам: каждая новая история должна давать пользователю одно заметное действие.

В кейсе «личный кабинет» распадается на «посмотреть статус», «отменить заказ» и «изменить адрес». Каждую можно проверить отдельно и выпустить независимо.

Чего история не даёт

История не описывает правила, исключения и критерии готовности. В нашем примере не сказано, до какого статуса можно отменить и кто возвращает деньги. Это нужно записать отдельно: критерии приёмки разбираются в статье 02-09, а сценарии с шагами в 02-10.

Историю часто удобно читать как приглашение к разговору. Команда приходит с вопросами к продуктовому владельцу, и вопросы из 02-04 помогают этот разговор подготовить.

Где это встречается в работе

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

Итог

• User Story - короткая запись одного требования: кто, что делает и зачем.
• История без ценности не объясняет, зачем её делать.
• INVEST задаёт шесть проверок: независима, обсуждаема, ценна, оцениваема, мала, проверяема.
• Слишком большую историю делят по пользе для пользователя.
• Правила и критерии готовности записывают отдельно.

Что дальше

• 02-09 Acceptance Criteria: как дополнить историю критериями приёмки.
• 02-10 Use Case и пользовательские сценарии: как описать шаги действия.
• 02-23 Декомпозиция и оценка задач: как превратить историю в задачи для разработки.