Пользовательская история

Что это значит

Пользовательская история - это краткое описание требования с точки зрения пользователя в форме как роль я хочу функцию, чтобы получить пользу. Например: как предприниматель я хочу загрузить фото чека в приложение, чтобы не носить документы бухгалтеру лично. Это не техническая спецификация, а выражение потребности.

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

Каждую историю дополняют критерии приёмки, определяющие, когда требование выполнено. Например, приложение принимает фото в форматах JPG и PDF, показывает подтверждение, а документ появляется в списке на обработку. Критерии предотвращают недоразумения между заказчиком и разработчиками.

Как это работает на практике

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

Хорошая история достаточно мала, чтобы её можно было завершить за один спринт, независима от других, оцениваема и тестируема. Слишком крупные требования, так называемые эпики, делят на меньшие истории, которые приносят ценность постепенно и быстрее проверяются с пользователями.

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

На что обратить внимание

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

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