Пользовательские истории (User Stories)

Я буду доволен, если вы вынесете из книги всего две мысли. Вот эти две мысли.
• Цель работы с историями не написание идеальных историй.
• Цель разработки продуктов не создание продуктов.
Сейчас я все объясню
—Джефф Паттон — «Пользовательские истории»

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

Про пользовательские истории слышали, наверное, все, кто занимается нынче программной разработкой. Но даже когда они используются в работе, это зачастую выглядит как «давайте просто использовать тип User Story» для тасок в Jira. Даже если кто и помнит, что история — это не просто таска, то имеет место набор убеждений и заблуждений. Например:

история — это задача, просто сформулированная по шаблону «Как персона, я хочу потребность, чтобы профит«;
причём формулированием профита можно пренебречь, он же очевиден;
а в качестве персоны везде писать «заказчик» или «пользователь». Или «владелец продукта» О_о;
дальше можно в свободной форме написать любые свои размышления на тему или вообще не писать ничего, формат же соблюдён, а кому надо — спросят;
acceptance criteria (критерии приёмки)? Что это?
истории пишет проджект/продакт/тимлид и передаёт в команду на реализацию. А то и назначает на исполнителя.

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

Предпосылки

Пользовательские истории появились как воплощение одного принципов Agile-подхода, предполагающих непрерывную коммуникацию с заказчиком в противовес тщательно зафиксированным в ТЗ или контракте требованиям. В современных реалиях программное обеспечение очень динамичная штука. Постоянно меняется даже на уровне идеи в процессе разработки, так что его нельзя единожды определить и описать.

Исходно их использование определено не в Скраме, как многие думают (в Скрам-гайде нет ни слова о пользовательских историях), а в Экстремальном программировании (XP). И понятно почему — наряду с целым рядом разных довольно жёстких ограничений и требований XP предполагает постоянное присутствие представителя бизнеса прямо в команде разработки, так что формат историй — короткая формулировка, влезающая на карточку — достаточен и удобен. Не надо заранее прописывать все детали, потому что когда настанет время взятия в работу — можно будет получить их все из первых рук.

Второй момент — почему именно «истории», а не «заметки на салфетке». Так уж устроен мозг человека, что истории мы воспринимаем лучше всего. Передать и воспринять набор информации в виде истории гораздо проще, чем в виде изолированных элементов и информационных единиц. То есть в сравнении с тем, как обычно выглядят требования в ТЗ или спецификации — даже если есть структура, зачастую трудно охватить и удержать в голове в виде целостной картины — представление в виде истории о пользовательском опыте («Я выбираю рейс, жму купить билет, ввожу свои данные, оплачиваю картой Visa или MasterCard») выглядят куда выигрышнее. Хоть и не являются исчерпывающими в плане деталей, обеспечивают главное — общую картину, потребность. А детали и ограничения выявляются уже в процессе в формате диалога.

Суть

Пользовательская история — минималистичный консистентный формат выражения требований, который легко писать, читать и оценивать.

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

Подход к выявлению потребностей с помощью пользовательских историй называют нарративной коллаборацией. Участники (заказчик, менеджеры, команда разработки) описывают предполагаемый опыт в виде повествования, выделяют ключевые элементы и фиксируют в виде атомарных сущностей. Получается линия карточек, обеспечивающих связный опыт. Возможно несколько линий — для разных персон.

Пример историй для создания механики рынка в игре

О формате. Считается, что 3R формат (Role — Requiremet — Reason) — это и есть определение User Story. На самом деле нет, у пользовательских историй нет жёсткого формата. Такой шаблон придумали и начали использовать ребята из малоизвестной телеком компании Connextra и представили его в 2001 году на конференции по XP в Лондоне. Вот как выглядит этот шаблон: Как [тип пользователя], я хочу [сделать то-то и то-то], таким образом я смогу [получить такую-то выгоду]. И он был настолько удобен, что прижился и распространился по всему миру.

Who — заинтересованное лицо (пользователь, заказчик, персона)
What — конкретная задача, которую надо решить или функция, которую надо обеспечить
Why — обеспечивает понимание ценности требование. Подсвечивает соответствие потребности общему видению и цели продукта

Критерии хорошей пользовательской истории

Для оценки качества истории есть удобный мнемонически акроним INVEST:

Independent (независимая) — может быть реализована отдельно от других пользовательских историй и при этом иметь смысл.
Negotiable (обсуждаемая) — не фокусируется на деталях и способах реализации («как»). Фокусируется на важных аспектах требований («что»).
Valuable (ценная) — несёт понятную ценность заказчику/пользователю. Даёт понимание, как провалидировать эту ценность.
Estimable (оцениваемая) — можно оценить время на реализацию.
Small (маленькая) — достаточно малая, чтобы оценить и реализовать за итерацию.
Testable (тестируемая) — верифицируема по набору критериев, которые позволяют однозначно определить, что работа выполнена.

К вопросу о верифицируемости. Как правило, эта часть обеспечивается критериями приёмки. Они же Acceptance Criteria, они же Conditions of Satisfaction.

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

Ещё один элемент, который очень часто игнорируется при попытке использования User Stories.

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

Формирование критериев приёмки — это поиск баланса между полной гибкостью, когда критериев просто нет (но тогда высокая неопределённость и риск уйти в бесконечные доработки) и ситуацией когда мы определили и описали вообще всё (и тогда история уже не Negotiable). Практика показывает, что оптимальная точка даже не в середине, а ближе к началу шкалы. То есть минимально необходимому набору критериев.

Также большое количество критериев может говорить о том, что история слишком большая и, возможно, её стоит разделить на меньшие.

Пример

User Story

Я, как покупатель, хочу иметь возможность платить картой VISA или MasterCard, чтобы оплачивать покупку удобным мне способом

Acceptance Criteria:

Оплата может быть сделана картой VISA
Оплата может быть сделана картой MasterCard
Тип карты определяется автоматически в процессе ввода
Присутствуют только релевантные поля для ввода

Резюме

Пользовательские истории — удобный формат управления требованиями к разрабатываемому продукту, если:

разработка динамичная и имеет место постоянная смена приоритетов и требований. Например, на основании проверки гипотез и экспериментов;
команда разработки вовлечена и компетентна. Либо хочется прийти к вовлечённости и компетентности. Работа с историями предполагает коллаборацию и обсуждения.

Преимущества

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

Ограничения

Налагает высокие требования к коллаборации, а это затраты на коммуникацию. Чаще подходит для областей с высокой неопределённостью и комплексностью, там это окупается.
Без грамотного использования критериев приёмки и выработанного понимания, когда история закончена, а все новые изменения — новая история, можно завязнуть в бесконечных доработках и накапливать ощущение фрустрации от недоделок.
На больших проектах будут трудности с масштабированием, особенно если не заниматься структурированием и управлением.