Пользовательские истории, или User Story, — это короткие, простые описания функций программы, которые записываются с точки зрения пользователя, клиента системы. Они состоят из нескольких предложений, которые часто строятся по такой структуре:
Как «кто-то», я хочу «выполнить что-то», чтобы «прийти к такой-то цели».
Анализируя историю, команда отвечает на вопросы:
«Как кто-то»: для кого мы это делаем? Нужно не только название персонажа, а понимание того, как он работает в системе, для чего использует ее. «Выполнить что-то»: здесь описываются намерения, а не конкретные функции. «Чтобы получить что-то»: как желание выполнить действие вписывается в общую картину? Какова польза, которую можно достичь, или какую проблему этим можно решить?
Как и все в Agile, такая структура не жесткое правило. Целевую часть иногда могут опускать, хотя именно она описывает ценность.
Где будут записаны истории, не так важно. Это могут быть стикеры, бумага или цифровой документе. Место User Story — в бэклоге продукта.
Подход к описанию задачи с точки зрения пользователя смещает фокус на него. Это соответствует принципам Agile: с историями команда лучше понимает, как поставить ценное ПО.
Задача из описания особенностей системы превращается в метод достижения цели через программу. К тому же истории удобно обсуждать: их понимает не только технический специалист.
Примеры пользовательских историй
Истории могут иметь разный размер: отражать один шаг пользователя или описывать большую функцию. Крупные User Story, которые можно разделить на части, называются эпики. В них могут объединяться десятки и сотни историй.
Я, как покупатель интернет-магазина, хочу оплатить покупку онлайн.
И вот несколько пользовательских историй, которые могут быть частью эпика выше:
Я, как покупатель, хочу оплатить покупку через банковскую карту Visa (MasterCard, МИР и т. д.)
Я, как покупатель, хочу оплатить покупку через банковский перевод
Я, как покупатель, хочу оплатить покупку через BTC
Большинство историй короткие, не более 3 предложений: так их удобно записывать и легче однозначно понять.
У оформленной истории также появляется порядковый номер, приоритет и оценка работы. Последний показатель присваивается истории на планировании работ, каждая команда может использовать свою систему оценок. Число показывает, сколько сил уйдет на выполнение User Story.
Для порядка в бэклоге может добавляться тема истории (если разработка идет по нескольким направлениям).
Детализироваться истории могут двумя способами:
- одна история делится на более мелкие и конкретные,
- добавляются «критерии удовлетворенности» — это условия, которые должны выполняться, когда история готова.
Глагол в структуре истории и критерии, по которым можно проверить, иногда бросают вызов: как записать нефункциональные требования, например, общие характеристики системы (масштабируемость, надежность, удобство и прочее)?
Такие требования нужно переосмыслять. Что значит масштабируемость для этой системы? — Чтобы платежная сеть обрабатывала минимум 2 млн транзакций в секунду. Это уже можно оценить, реализовать и проверить.
Кто и когда пишет истории?
Пользовательскую историю может написать любой, кто причастен к проекту. Но принимает историю в бэклог владелец продукта. Он ее оценивает и решает, стоит ли вообще добавлять.
В разработке по Agile важно не кто написал историю, а кто ее обсуждал.
Первые истории пишутся до начала первого спринта: они определяют, с чего начать разработку. Некоторые понятны сразу, какие-то откладываются на потом, когда у системы будет больше деталей.
Кроме того, новые истории могут быть написаны в любое время. Владелец не ограничен моментом, когда именно их добавлять.
Чем еще хороши истории?
Нам нравится работать через истории, потому что:
- их можно по-разному детализировать: ограничиться взглядом в будущее или подробно проработать действия пользователя здесь и сейчас;
- указание роли пользователя и конечной цели помогает выбрать лучшее решение, но не ограничивает в технической реализации;
- выполненную историю можно проверить в ПО и продемонстрировать другим;
- требования легче фиксировать, а бэклог пополнить, очистить или переструктурировать.
10 приемов, чтобы написать хорошую историю
Роман Пихлер, эксперт по Scrum, выделил 10 положений, которые помогут создать работающую историю.
- Пользователь впереди — не знаешь своего пользователя, сначала изучи его. История должна отражать действительность и реальную потребность, а не догадку.
- Используйте персонажей — вымышленных людей, которые отражают портрет одной целевой аудитории. Снабдите его картинкой и личными целями.
- Создавайте истории вместе, владелец продукта и команда. Хорошо, когда история рождается из обсуждения, а материал для нее дают фидбеки, запросы и данные.
- Оставляйте истории краткими. Лаконичность помогает уйти от путаницы и оставить главное.
- Не бойтесь начать с эпиков. В начале у продукта будут только они. Это как заготовка для более подробных историй и общая функциональность продукта.
- Уточняйте истории до победного. Эпик должен делиться на ясные, проверяемые части. Все должны понимать их смысл, а размер быть комфортным, чтобы взять задачу в работу.
- Не забывайте критерии удовлетворенности. Они гарантируют, что историю можно продемонстрировать. Роман говорит, что на его практике наиболее удобны 3-5 пунктов для проверки User Story.
- Используйте бумажные карточки. Это дешево, помогает сотрудничеству, визуализирует работу и хорошо группируется.
- Держите их на видном месте. Например, истории на стене виды всем. Когда их становится слишком много, сразу заметно.
- Не полагайтесь только на User Story. Для описания дизайна или маршрута пользователя лучше выбрать другие методы: эскизы, макеты, сценарии, UML.
