Школа скрам-мастеров

Возможно, когда вам говорят, что было бы полезно составить «Карту пользовательских историй» (User Story Map), вы не до конца понимаете, в чём именно заключается эта польза и стоит ли инвестировать в это своё время. Эта подборка кейсов поможет вам найти ответ на этот вопрос – независимо от того, какими задачами вы занимаетесь в Agile-команде.

У Владельца продукта бэклог представлял собой горизонтальную нарезку задач. Ранее User Story Map не составлялась, и в результате Владелец продукта не видел целостной картины развития продукта – было неясно, закрываются ли все шаги, необходимые клиенту для достижения своей цели даже в рамках минимального функционала (MVP).

Решение: совместно с Владельцем продукта была составлена User Story Map на основе текущего бэклога. Сначала определили клиентский путь и процессные шаги со стороны компании, затем задачи из бэклога разместили в соответствующих зонах карты. В результате Владелец продукта не только увидел, как развивается продукт, но и выявил «белые пятна» – пробелы, которые в будущем могли бы стать препятствием для развития. Кроме того, карта позволила обнаружить задачи, которые находились в бэклоге, но не имели отношения к продукту и подлежали либо удалению, либо передаче другим командам.

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

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

Дополнительная статья по теме: Просто о тех. долге/костылях и рефакторинге для тех, кто не в ИТ

Решение: совместно с Agile-командой была проведена игра «Собирашка»©, наглядно демонстрирующая, как возникает технический долг и чем опасно его накопление. После игры команда провела анализ своего текущего техдолга – по степени влияния на дальнейшее развитие продукта и по уровню генерации ошибок (bugs).

Создание User Story Map помогает команде развивать продукт последовательно, обеспечивая клиенту реальную ценность, а не только идеальный один шаг его клиентского пути. И если кто-то скажет, что до релиза осталось всего несколько дней, обладая USM, Agile-команда будет понимать, где можно поставить «заглушки», чтобы функционал работал — пусть и не идеально, но работал. Эта история особенно ярко проявилась в данном кейсе.

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

Решение: вместе с командой была составлена User Story Map, в которую нанесли уже выполненные задачи и оставшиеся шаги. В процессе выяснилось, что команда работала по принципу: берём один шаг клиента — и доводим его до идеала, затем переходим ко второму, и так далее. Сквозная итеративность отсутствовала. В итоге в продукте уже было идеальное логирование, но не было самого функционала, ради которого клиент вообще приходил.
Был пересмотрен процесс планирования и подход к разработке. Команда успела выпустить продукт в срок, а доработками занималась уже после релиза — в первую очередь, «выпиливая» «костыли».

Бизнес-заказчики не понимали, над чем работает команда и почему функциональность реализуется именно в такой последовательности, а не в иной.

Решение: Agile-команда подготовила User Story Map, в которой отразила объём работы и ориентировочные сроки выпуска функциональности. На встрече с бизнес-заказчиками, проведённой на основе этой карты, удалось достичь взаимопонимания: команда объяснила, почему часть задач выполняется именно в таком порядке (в том числе по техническим причинам), и какие последствия были бы в случае иной последовательности.
После встречи приоритеты были частично пересмотрены самими бизнес-заказчиками — теперь, понимая, что появится через месяц, а что через два, они по-новому расставили акценты. Такой подход сделал работу команды более прозрачной и предсказуемой в глазах заказчика.

А ещё бывают ситуации, когда User Story Map (USM) показывает Agile-команде, что для выполнения поставленных задач она серьёзно зависит от других команд. Такая зависимость – сигнал: нужно пересмотреть границы продукта, провести перенарезку команд или, возможно, забрать необходимые компетенции внутрь команды.

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

Хотите так же? Ждём вас на нашем тренинге