User Story Mapping
Планирование продукта с помощью карты историй
Источник: Jeff Patton, "User Story Mapping: Discover the Whole Story, Build the Right Product", 2014
История — часть контекстного сценария, его фрагмент, содержащий требование к отдельной функциональности.

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

Шаблон для истории на карточке:
Как [тип пользователя], я хочу [сделать то-то и то-то], таким образом я смогу [получить такую-то выгоду]

Но как быть, когда функционал большой и карточек очень много?
Я пару раз слышал шутку: «Мы перестали писать документацию, и поэтому у нас теперь Agile». Это называется: кто знает – тот поймет, потому что на самом деле процесс, управляемый историями, требует для работы множества документов. Но зачастую эти документы совсем не похожи на традиционные задокументированные требования /Jeff Patton/
Карты пользовательских историй
User Story Mapping
Карта — это техника, позволяющая увидеть весь функционал. Карта представляет собой листочки с историями, расклеенными на поверхности в порядке повествования. Каркас карты образуют персонажи (или роли), их цели и задачи, а истории —это основные элементы.
Карта историй помогает нам держать фокус на пользователях и их опыте, в результате чего взаимодействие улучшается и продукт становится несравнимо лучше /Jeff Patton/
Как составить карту
Каркас карты состоит из нескольких уровней, каждый из которых читается слева направо:
→ Персонажи или роли;
→ Цели для каждого из персонажей: может быть одна или несколько;
→ Основные действия, которые персонажу предстоит совершить для того, чтобы достичь целей;
→ Маршрут: шаги, из которых состоят действия.
Составлять карты до смешного просто. Работая вместе с другими, я озвучиваю историю работы с продуктом, записывая каждый шаг, предпринимаемый пользователем, на листочках-стикерах, наклеивая их слева направо. Затем мы возвращаемся к началу и обсуждаем каждый шаг в деталях, записывая подробности на листочках и наклеивая их сверху вниз под соответствующим шагом. В результате получается простая, напоминающая таблицу структура, излагающая историю слева направо и раскрывающая детали сверху вниз. Эти детали образуют бэклог (backlog): набор функциональностей, которые требуется внедрить в проект /Jeff Patton/
Кода каркас готов, можно идти вглубь, располагая детали под шагами.
↓ Истории располагаются сверху вниз и группируются по приоритету

Благодаря приоритетам, получается разбить функционал на релизы. Истории с высшим приоритетом переходят в спринт (небольшую по времени итерацию, обычно от недели до месяца)

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

Первый релиз определяет минимально жизнеспособный продукт или MVP (minimum viable product) — это продукт минимального объема, при выпуске которого успешно достигаются желаемые результаты.

Рассматривайте каждый релиз как эксперимент и помните о том, что хотите узнать. Минимально жизнеспособный продукт-эксперимент (МЖПэ) – самый маленький продукт, который можно создать, чтобы что-то изучить /Jeff Patton/
Итеративно мыслите, чтобы верно оценивать, и вносите изменения в то, что вы уже сделали. Исправления – всего лишь неизбежный результат увеличения знаний. Улучшения, внесенные после релиза, самые ценные /Jeff Patton/
Для планирования MVP и дальнейших релизов, Джефф Паттон предлагает выделять функциональность, которая соответствует категориям:

• Конкурентное преимущество — преимущество, которое отличает их от конкурентов;
• Спойлер — функциональность, которая стремится перекрыть чужое конкурентное преимущество;
• Фактор снижения затрат — функциональность, введенная для снижения затрат организации;
• Минимальный пакет — минимальный набор функций, необходимый для успешного конкурирования на рынке.
Самое главное в историях
Хорошая карта — это результат командой работы. Истории на такой карте — это не только требования, выявленные в ходе интервью с пользователями, но и требования участников команды разработки, заинтересованной в наилучшем решении, готовой подвергать решение сомнению и регулярно улучшать продукт.
Истории называются историями из-за способа их использования, а не потому, что их надо записывать. С самого начала предполагалось, что истории будут вызывать обсуждение. Истории — строительные блоки коммуникации между разработчиками и теми, кто использует результаты их труда. Карты историй организуют и структурируют эти строительные блоки и тем самым стимулируют процесс коммуникации /Jeff Patton/
Альтернативные истории
Техника меппинга подходит не только для наглядного представления функциональности продукта и плана релизов, но и позволяет рассмотреть альтернативный функционал: рискованные сценарии, проблемы, вопросы. Эти требования и идеи могут быть как встроены в основную карту, так и образовывать отдельные карты альтернативных историй и обсуждений.
Помните: времени и ресурсов всегда не хватает. Концентрируйтесь на том, чего хочет достичь ваш бизнес, а также на людях, для которых создаете продукт /Jeff Patton/
Полезные ссылки
User Story Mapping with Jeff Patton – видеолекция Джеффа Паттона

Realtime Board – инструмент для команд, работающих удаленно
Это было полезно?