Пользовательские истории · Конспекты по бизнес-анализу

Что это#

Руководство BABOK® описывает пользовательскую историю (user story) как краткое описание функциональности или качества, которые нужны пользователям от решения, чтобы достичь бизнес-цели. Команды используют истории, чтобы фиксировать потребности и расставлять приоритеты, оценивать и планировать работу, как основу приёмочных тестов и как единицу измерения работы.

Формулировка. Распространённый формат, который иногда называют формулировкой ценности:

Как <роль>, я хочу <возможность>, чтобы <бизнес-ценность>.

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

Критерии приёмки (acceptance criteria) раскрывают смысл истории и её границы. Учебные материалы по бизнес-анализу рекомендуют форму BDD (behavior-driven development, разработка через поведение): Дано (Given) контекст, Когда (When) происходит событие, Тогда (Then) наступает результат. Каждый критерий — один сценарий, который может стать тестом.

В лекции Маглинца об экстремальном программировании (XP) показана более ранняя форма той же идеи: приёмочные тесты пишут на обороте карточки истории тремя предложениями (установка, операция, подтверждение). Та же лекция описывает, как XP справляется с размером: историю, которая слишком велика, чтобы её оценить или уложить в итерацию, разбивают, а если команда вообще не может оценить историю, сначала проводят короткое исследование (spike).

INVEST — широко используемый чек-лист качества; он есть и в учебных материалах:

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

Когда применять#

В гибкой и другой итеративной работе с бэклогом и частой обратной связью.
Когда заинтересованным сторонам трудно читать формальные спецификации. Истории легко понять, и они могут появиться почти из любой техники выявления.
Чтобы через разговор бизнеса и команды выстроить общее понимание предметной области.

Руководство BABOK называет и ограничения. Истории не предназначены для долгосрочного хранения или детального анализа. Без трассировки к бизнес-целям команда теряет общую картину. В регулируемых отраслях может понадобиться дополнительная документация. Поэтому дополняйте истории:

сложные потоки с множеством ветвлений → варианты использования;
данные, правила и интерфейсы → модели и спецификации, связанные с историей;
цели → эпики или бизнес-цели, к которым трассируются истории.

Как это делать#

Начните с целей и пользователей. Кто пользуется решением (персоны или классы пользователей) и чего эти люди пытаются достичь?
Напишите формулировку с конкретной ролью, потребностью и выгодой. Не включайте в неё решение.
Обсудите её с командой и представителем пользователей. Карточка — напоминание о разговоре, а не договор.
Напишите критерии приёмки в форме «Дано / Когда / Тогда»: основной путь, ключевые правила, ошибки и граничные случаи.
Проверьте историю по INVEST и разбейте её, если проверка не пройдена.
Оцените историю, расставьте приоритет и свяжите её с эпиком или целью.
Уточните историю перед итерацией и подтвердите её на обзоре по критериям приёмки.

Распространённые способы разбить большую историю: по шагам процесса; по бизнес-правилам; по вариантам данных; сначала основной путь, потом пути с ошибками; сначала простая версия, потом улучшения; по одному каналу за раз. Каждый срез всё равно должен давать что-то, что видит пользователь.

Пример#

Учебные материалы описывают одну функцию — просмотр истории входов в систему — и как пользовательскую историю с четырьмя критериями «Дано / Когда / Тогда», и как классический вариант использования. Сравнить их рядом — хороший способ понять, когда какой формат подходит. Вот история для «Мастерской», вымышленной сети веломастерских:

Шаблон

WS-12 Уведомление о готовности
Как клиент, оставивший велосипед в ремонте,
я хочу получить сообщение, как только велосипед будет готов,
чтобы забрать его, не звоня в мастерскую.

AC1 Сообщение отправлено
  Дано заказ в статусе «В ремонте» у клиента, который согласен получать сообщения
  Когда механик отмечает заказ завершённым
  Тогда клиент получает сообщение с адресом мастерской и часами работы

AC2 Предпочтительный способ связи
  Дано клиент выбрал электронную почту как способ связи
  Когда заказ становится готовым
  Тогда сообщение отправляется по электронной почте, а не по SMS

AC3 Сбой доставки
  Дано сообщение не удаётся доставить
  Когда провайдер сообщает о сбое
  Тогда заказ появляется в списке звонков стойки приёма

AC4 Без дублей
  Дано сообщение о готовности по заказу уже отправлено
  Когда заказ снова переводят в статус готовности
  Тогда второе сообщение не отправляется

Проверка по INVEST: история работает и для заказов, принятых без предварительной записи, поэтому она не зависит от онлайн-записи (Independent). Если бы SMS и электронная почта оказались слишком большим объёмом для одной итерации, AC2 можно было бы выделить в отдельную историю (Small).

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

«Как пользователь…» → назовите реальную роль или персону; разным пользователям нужно разное.
Нет «чтобы» → без ценности нельзя расставить приоритеты или заметить решение получше.
Решение внутри истории («я хочу выпадающий список») → опишите потребность; проектное решение — потом.
Замаскированный эпик → разбейте его на срезы, каждый из которых даёт видимую ценность.
Технические задачи в виде историй («Как разработчик, я хочу базу данных») → оформляйте их как задачи внутри настоящей истории.
Критерии повторяют историю или описывают клики → формулируйте наблюдаемые результаты, по одному сценарию на критерий.
Нет связи с целями → трассируйте истории к эпикам и бизнес-целям.

Шаблон#