Пользовательская история (user story) ясна команде? Критерии и нарезка

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

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

Дальше в статье — три практических шага:

• прояснить исходный запрос и зафиксировать критерии приёмки;
• вовремя разделить крупную задачу на части;
• убедиться в общем понимании требований перед стартом разработки.

Шаблон user story: почему одной строки недостаточно

Пользовательская история — краткое описание функции с точки зрения того, кому она нужна. Такое определение дает руководство Mountain Goat Software.

Как [роль], я хочу [действие], чтобы [ценность].

В руководстве подчеркивают: строка «Как…, я хочу…, чтобы…» помогает начать разговор о задаче, но не описывает требование целиком. Консультант по гибким методам разработки Рон Джеффрис выделил три составляющие пользовательской истории. Разработчик и тренер команд Билл Уэйк приводит их в статье об INVEST:

• Карточка. Краткая запись истории — например, строка «Как…, я хочу…, чтобы…»;
• Разговор. Обсуждение цели, деталей и возможных решений;
• Подтверждение. Тесты, по которым принимают результат.

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

Шаблон и пример пользовательской истории

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

Без указания цели остаётся формальный запрос на уведомление без понимания решаемой проблемы. Полная формулировка сразу даёт задачу: менеджеру нужно вовремя заказать поставку. Дополнительно команде предстоит выяснить две детали:

• допустимую скорость доставки сигнала;
• точный порог минимального остатка.

При этом фиксация пользы не гарантирует рыночный спрос на продукт. По данным опроса Atlassian среди продуктовых специалистов в США, Франции и Германии, 84% команд опасаются рыночного провала текущих разработок.

Пользовательские истории позволяют учесть запросы аудитории до начала отрисовки макетов. Например, при перезапуске сервиса LekVapteke для поиска лекарств в аптеках Сибири студия Digital Clouds сначала составила пул историй. С их помощью команда провела аудит существующих функций, наметила точки роста и перешла к проектированию интерфейса. На момент публикации кейса оценки приложения достигли 4,9 балла в App Store и 4,8 балла в Google Play.

Что выяснить до написания пользовательской истории

Работа над историей часто начинается с неопределенного запроса: «Нужно улучшить уведомления» или «Пользователи где-то отваливаются, надо исправить». В таком запросе не указаны границы задачи, сценарий и признаки успеха. Если сразу перенести его в шаблон «Как…, я хочу…, чтобы…», недостающие сведения не появятся.

В «СВОЙ Тех» уточнение таких запросов частично поручили внутреннему ИИ-ассистенту. По данным компании, ассистент задает инициатору вопросы и собирает структурированный черновик. В него входят контекст, цель, сценарий, ограничения, критерии приемки, риски и пробелы. Аналитик проверяет и дорабатывает документ — на эту задачу у него уходит до тридцати минут. Теперь за двухнедельный спринт на прояснение запросов уходит 7–8 часов, а прежде требовалось около двадцати. Окончательная работа с требованиями по-прежнему остается за аналитиком.

До написания истории продакт выясняет:

• Цель. Какую потребность пользователя и бизнеса нужно удовлетворить;
• Сценарий. Кто, в какой ситуации и какие действия выполняет в продукте;
• Границы. Что входит в задачу и что остается за ее пределами;
• Ограничения. Какие сроки, регламенты и связанные системы нельзя изменить;
• Признак успеха. Как команда поймет, что цель достигнута;
• Риски и пробелы. Что пока неизвестно и у кого это уточнить.

12 ноября 15:00 МСК Онлайн Бесплатно Открытый разбор: КП отправили, а дальше тишина Для руководителей продаж: как узнать, что происходит со сделкой, пока клиент молчит, и как вернуть разговор. Зарегистрироваться

Пользовательская история и техническое задание: в чем разница

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

При этом подробный документ может отвлечь заказчика от главного. Вениамин Мустафин из fuse8 приводит пример: стороны спорят о виде и поведении кнопки, а неточность в бизнес-логике остается незамеченной:

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

Вениамин Мустафин, директор по развитию бизнеса fuse8.

Обсуждение истории с опорой на цель пользователя помогает проверить логику до разработки. Но сама по себе краткая запись не гарантирует, что команда заметит ошибку.

Преимущества и ограничения user story

Формат полезен на этапе обсуждения решения:

• Понятна польза. История объясняет, зачем нужна функция;
• Решение можно менять. Карточка не фиксирует все детали заранее, поэтому их можно уточнять без переписывания подробной спецификации;
• Текст понятен бизнесу. История написана словами пользователя, и заказчику не требуется перевод с технического языка.

Есть и ограничения:

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

Когда обсуждать историю с разработкой

Разработчиков стоит подключать до фиксации цели и границ задачи. Первое обсуждение требований прямо на планировании спринта затягивает выбор задач и оценку объёма работ. Планирование оставляет возможность скорректировать решение. Но поздний старт диалога перегружает встречу.

Позднее участие инженеров остаётся системной проблемой. По данным опроса Atlassian, 80% продуктовых команд не привлекают разработчиков на ранних этапах. Авторы исследования связывают такую изоляцию с двумя прямыми последствиями:

• упущенными возможностями в продукте;
• неожиданными техническими проблемами перед релизом.

Чтобы обсудить задачу до спринта, проводят встречу с продактом, разработчиками и тестировщиками. Каждый отвечает за свою часть:

• Продакт объясняет цель, сценарий и границы;
• Разработчики называют технические ограничения и предлагают варианты решения;
• Тестировщики уточняют, как проверить результат.

Договоренности записывают в черновик критериев приемки. Так критерии учитывают вопросы всей команды, а не только представление продакта о задаче.

Критерии приемки: как связать историю с проверкой результата

Критерии приемки описывают условия, которым должна соответствовать готовая функция. Каждый участник команды использует их в своей работе. Например, в X5 Tech тестировщик составляет тест-кейсы по истории и ее критериям, а разработчик на той же основе пишет код и проверяет результат. По размытому условию нельзя составить однозначный тест.

Критерии конкретной истории следует отличать от Definition of Done — общих требований к качеству готового результата. Эти два набора условий не заменяют друг друга.

Хорошие критерии приемки обладают пятью свойствами:

• Бинарные. Можно однозначно установить, выполнено условие или нет;
• Полные. Охватывают согласованные сценарии, включая ошибки и пустые значения;
• Подтверждаемые. Выполнение видно на экране, в данных или журнале событий;
• Однозначные. Разработчик и тестировщик понимают условие одинаково;
• Непротиворечивые. Ни одно условие не отменяет другое.

Разницу видно на примере складских уведомлений. Формулировка «уведомление приходит быстро» допускает разные трактовки. Условие «уведомление приходит не позже чем через минуту после того, как остаток упал ниже минимума» задает конкретный срок, который можно проверить.

Важно и то, как записаны условия. Их располагают в порядке сценария, чтобы каждое было проще связать с тест-кейсом. Валентина Ляликова из X5 Tech объясняет, к каким проблемам может привести отсутствие такой структуры:

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

Валентина Ляликова, ведущий бизнес-аналитик X5 Tech.

Критерии хорошей user story: проверка по INVEST

Готовую историю проверяют по шести требованиям INVEST. Их сформулировал Билл Уэйк. Для каждого требования есть вопрос, который помогает обнаружить проблему:

Если историю нельзя закончить за один спринт, она не проходит проверку по S — Small. Тогда ее делят на несколько меньших историй.

Как нарезать большую пользовательскую историю: пять приемов SPIDR

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

Майк Кон, основатель Mountain Goat Software, разобрал больше тысячи историй, собранных за 15 лет. По его наблюдению, почти любую большую историю можно разделить с помощью пяти приемов. Их названия образуют сокращение SPIDR. Рассмотрим эти приемы на примере складских уведомлений:

• Spike, исследование. Если для оценки и деления истории не хватает знаний, создают короткую исследовательскую задачу. Например, выясняют, передает ли учетная система остатки в реальном времени. Такая задача помогает подготовиться к дальнейшей работе, но сама еще не дает пользователю новую функцию;
• Path, путь. Разделяют историю по сценариям: уведомление в приложении становится одной историей, письмо на почту — другой;
• Interface, интерфейс. Начинают с простой версии экрана: показывают общий список товаров с низким остатком. Настройку порогов для отдельных позиций выделяют в следующую историю;
• Data, данные. Ограничивают набор обрабатываемых данных: сначала подключают один склад, потом остальные;
• Rules, правила. Откладывают сложную бизнес-логику: первая версия использует общий порог для всех товаров, сезонные пороги добавляют позже.

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

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

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

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

ИИ и пользовательские истории: что проверить в черновике

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

Качество историй изучили исследователи из Salem State University и Endicott College. В работе для конференции SIGCSE они сравнили студенческие задания, выполненные с помощью ИИ и без него. С ИИ студенты лучше формулировали пользу для пользователя и критерии приемки. Без ИИ им лучше удавалось ограничивать объем истории. Исследование проводили на учебных заданиях, поэтому его результаты нельзя автоматически переносить на работу продуктовых команд.

Если продакт поручает нейросети подготовить черновик истории, в запросе стоит задать:

• Формат: строку «Как…, я хочу…, чтобы…» и пример однозначного критерия приемки;
• Роль и цель пользователя: кому нужна функция и какую потребность она закрывает;
• Одну цель для истории: не объединять в ней разные потребности;
• Границы: что входит в историю и что остается за ее пределами.

Затем продакт сверяет черновик с исходной целью, проверяет критерии приемки и объем истории по требованию S из INVEST. Если история охватывает слишком много, ее делят с помощью приемов SPIDR.

Типичные ошибки в пользовательских историях

При подготовке карточек проверьте, нет ли в них пяти распространенных ошибок:

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

«Для протокола: свалить кучу историй в трекер — это не совместная работа».

Билл Уэйк, Agile-консультант, автор модели INVEST, статья 2021 года (перевод).

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

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

Шаблон и критерии INVEST помогают проверить формулировку пользовательской истории. До планирования спринта команда убеждается в едином понимании задачи.

На встрече продакт-менеджер, разработчик и тестировщик своими словами формулируют два момента:

• что конкретно сделает команда;
• как специалисты проверят и примут результат.

Для быстрой сверки достаточно разобрать саму историю и один из критериев приёмки. Если ответы расходятся, спорные требования уточняют до включения задачи в спринт.