Это перевод статьи Story Mapping: Painting The Big Picture Of Your Product’s User Stories. Оригинал вы можете найти по этой ссылке. Украинскую версию статьи можно прочесть тут.
Вы пристально смотрите в свой ноутбук. Оттуда на вас смотрит длинный список User Stories (пользовательские истории). Вы перетасовываете некоторые из них, пытаясь расположить их в рациональном порядке.
Вы постоянно пересортировуете список. То для просмотра всех Stories, связанных с функцией A, то для просмотра наиболее важных Stories по всем функциям сразу. Если это вообще возможно.
Вы повторяете это снова и снова — и теряетесь.
Вам нужна Story Map. Давайте посмотрим, как вы можете создать карту с помощью Story Mapping, но сначала давайте разберемся, что это вообще такое.
Давайте поглубже разберемся:
Story Mapping или User Story Mapping — это метод, используемый при product discovery: описание нового продукта или новой функции для существующего продукта.
В результате получается Story Map: все User Stories, объединенные в функциональные группы. Это помогает вам следить за общей картиной, а также предоставляет все детали приложения в целом.
Основная цель Story Mapping — облегчить product discovery и приоритизацию задач в разработке. Вы достигаете этого, помещая пользовательские действия и задачи на карту, которая помогает держать их в контексте.
Story Map всегда показывает, как каждая отдельная история вписывается в приложение в целом. И это позволяет легко выявлять пробелы и решать, насколько какая-то из них важнее других.
Story Mapping поддерживает две ценности Agile Manifesto. «Сотрудничество с заказчиком важнее согласования условий контракта» и «Готовность к изменениям важнее следования первоначальному плану».
Вы получаете наилучшие результаты, когда сотрудничаете с (будущим) пользователем или экспертом в предметной области. Кто-то, кто близко знаком с работой, которую должно поддерживать ваше приложение, и проблемами, которые оно должно решать.
Используя Story Mapping, легко реагировать на изменения. Потому что, когда вы добавляете новую User Stories, или изменяете/удаляете существующую, легко определить, что еще нужно добавить, изменить или удалить.
Джефф Паттон впервые описал Story Mapping в своей статье «Все дело в том, как вы его нарезаете» (It’s All in How You Slice it) в 2005 году, на то время он уже использовал его в течение нескольких лет. Но тогда он не называл это Story Mapping. Он придумал этот термин в своей статье «Бэклог новой User Stories — карта» (The New User Story Backlog Is a Map) в 2008 году. Он также написал об этом книгу: «User Story Mapping: искусство гибкой разработки ПО».
Когда вы закончите знакомство с продуктом, вы, скорее всего, поместите User Stories в список невыполненных работ на Scrum или Kanban-доске.
Так правильно поступать с усилиями, потраченными на разработку, если вы определились с порядком постройки продукта.
Однако возможности управления невыполненными работами этих инструментов недостаточны для управления продуктами и их выпуском. Просто потому, что отставание отображается в виде длинного плоского списка. Фильтрация, маркировка и раскрашивание, которые вы можете сделать, немного помогают, но вы никогда не увидите полной картины.
Story Mapping решает эту проблему, упорядочив User Stories в простом удобном макете.
Story Mapping дает вам ряд прямых и косвенных преимуществ.
Полная картина на руках
Когда вы создаете физическую Story Mapping, вы получаете еще несколько преимуществ.
Наиболее важные подводные камни и ошибки при использовании Story Mapping:
Вам необходимо сотрудничать с кем-то, кто использует или будет использовать ваш продукт для поддержки их работы.
Без их вклада и точки зрения вы будете гадать: что важно, а что принесет реальную пользу. Вы будете играть в игру «попал или не попал» и, вероятно, напрасно потратите свои усилия на разработку.
Работая без проблемы, которую нужно решить и без цели, которую нужно достичь, вам нечем руководствоваться в своих решениях. Вы не будете понимать, когда закончите. Это приводит к напрасным усилиям или, по крайней мере, к трате усилий на то, что не вовремя.
С глаз долой, из сердца вон. Без Story Map, которая служит видимым напоминанием об общей картине вашего приложения, слишком легко отклониться от курса. От этого появляется опасность заблудиться в сорняках: увязнуть в деталях одной Stories, не имеющих отношения к целому. Это бъет еще больнее, когда эти детали требуют больше усилий, чем нужно для ценности Stories.
Хотя физическая Story Map предпочтительнее из-за дополнительных преимуществ, которые она предоставляет, в настоящее время так много команд работают удаленно, что у вас не всегда будет такая роскошь. Но вы все еще можете визуализировать карту. Например, у вас может быть специальный большой монитор, показывающий карту везде, где находятся члены вашей команды.
1.Начните с больших валунов
Определите большие Stories, широкие действия пользователя, которые должно поддерживать ваше приложение. Это большие Stories, потому что в них много шагов. Эти шаги необязательно должны иметь определенный порядок или рабочий процесс. На самом деле, многие действия пользователя включают шаги, которые пользователь будет выполнять в разное время и по разным графикам.
Напишите каждое действие на карточке. Расположите их в порядке, удобном для пользователя. Если кто-то говорит о выполнении одного действия, а затем другого, расположите их в таком порядке. Если действия не выполняются одно за другим, просто используйте такой порядок, в котором пользователь говорит о них. Это поможет рассказать историю приложения другим людям.
Допустим, вы создаете сайт Fun Events Club. Посетители могут искать интересные мероприятия, к которым можно присоединиться. Участники могут присоединяться и проводить мероприятия. А команда сайта выступает в качестве модераторов и проверяет, соответствуют ли новые мероприятия правилам.
Тогда большие валуны этого сайта, действия пользователей, могли бы выглядеть так.
2.Разбейте свои валуны
Разбейте историю каждой пользовательской активности на более мелкие Stories – пользовательские задачи. Поместите пользовательские задачи под действия, к которым они относятся, а потом расположите их в том же порядке, что и сами действия, или в таком порядке, который будет понятен для пользователя.
Для Fun Events Club это выглядит так.
Теперь у вас есть то, что называется основой вашей Story Map.
Большинство пользовательских задач имеют собственные шаги или независимые подзадачи. Поместите эти подзадачи под (если вы шли горизонтально) пользовательскую задачу, которой они принадлежат.
Это выглядит таким образом.
И пользовательские задачи, и подзадачи становятся User Stories, которые вы реализуете. В конце концов, пользователю по-прежнему нужно выбрать мероприятие из списка, чтобы просмотреть его детали или сразу присоединиться к нему.
3.Найдите камешки, которые улетели
Пройдите карту от начала до конца с кем-то еще с вашей стороны. Это может быть пользователь, разработчик, тестировщик или кто-то другой, заинтересованный в приложении.
Расскажите о (типах) пользователей вашего приложения и о том, как они используют ваше приложение. Это своего рода настраивание резиновой уточки для вашей Story Map. И это вполне естественно выявит то, что вы пропустили. Либо потому, что вы подумаете о них сами, либо потому, что ваш собеседник указывает на них.
Оказывается, для Fun Events Club мы тоже пропустили парочку.
Когда вы идете по карте с кем-то, воспользуйтесь возможностью, чтобы дополнить Story Map с другой информацией, которую вы услышите. Болевые точки в текущей системе, возможности, которых ждал пользователь. Крайние случаи и ограничения, которые необходимо учитывать. Напишите их на стикере и приклейте на соответствующую карточку.
4.Расставьте свои камешки в ряд
Нет смысла расставлять приоритеты по действиям пользователей. Помимо действий, которые не будут использоваться ежедневно, весьма вероятно, что что-то из каждого действия необходимо для создания работающего целого.
Поэтому сосредоточьтесь на приоритизации пользовательских задач и подзадач в рамках каждого действия. Дополнительным преимуществом является то, что вам не нужно думать об относительной важности задач, относящихся к разным видам деятельности.
В нашем примере с Fun Events Club подзадачи уже расположены в порядке важности. Немного преждевременной оптимизации от вашего авторства.
5.Слепите ценный первый валун из кучи гальки
Выберите задачи из каждого действия, которые необходимы для создания первой версии, которая работает от начала до конца, даже если она все еще находится в зачаточном состоянии. Это ваш MVP, ваш минимально жизнеспособный продукт.
6.Продолжайте лепить
Планируйте последующие выпуски, расставляя приоритеты для оставшихся задач. То, как вы хотите двигаться вперед, полностью зависит от вас.
Вы можете отдать приоритет самым ценным Stories из нескольких или даже всех пользовательских действий. Вы также можете сосредоточиться на одном действии и отдать приоритет всем Stories, кроме наименее ценных. И, возможно, деловые люди в вашей компании захотят принять во внимание другие аспекты. Они находятся в лучшем положении, чтобы решить, какие особенности и Stories сделают хороший выпуск.
Вместо того чтобы рисовать линии между Stories, чтобы отметить, какие из них входят в последующие выпуски, вы также можете перестроить карту, чтобы показать выпуски в виде горизонтальных отрезков Stories.
Story Mapping подходит не только для новых приложений. Вы также можете использовать его для существующих приложений.
Чтобы помочь вам понять, что делает приложение, и воссоздать его общую картину, чтобы вы могли воспользоваться этим преимуществом при продвижении вперед.
И, конечно же, наметить новые функции и поместить их в контекст существующего приложения.
Если вы не можете (не имеете права) сначала создать полную Story Map существующего приложения, по крайней мере разместите все существующие действия пользователя.
Это даст вам контекст для новых функций.
И это также даст вам место для размещения задач, которые вам нужно добавить или изменить в существующих действиях пользователя. Например, когда вы создаете новую функцию для рассылки целевых электронных писем. Вам нужно будет добавить выбор нескольких контактов в существующий список контактов. И вам, вероятно, потребуется добавить некоторые дополнительные возможности фильтрации.
Помните боль от необходимости расставлять приоритеты Stories в длинном, плоском бэклоге?
И насколько сложно было объяснить приложение другим людям?
Теперь вы знаете, как Story Mapping может вам помочь. Чтобы расставлять приоритеты в Stories и собирать выпуски, которые приносят значимую ценность. И рассказать историю вашего приложения, ведь пользователи будут его использовать. Просто пройдитесь по Story Map.
Итак, сделайте свое будущее счастливым и воспользуйтесь преимуществами Story Mapping. На стене или с помощью цифрового инструмента.
Что входит в User Storу?
Agile User Storу состоят из одного - двух письменных предложений, а также списка идей, которые вы хотите иметь по желаемой функциональности.
Что такое epics?
Epics — это большие коллекции User Stories, которые могут охватывать несколько команд и проектов. Кроме того, они обычно доставляются через серию спринтов.
Что такое story mapping?
Story mapping — это процесс, используемый либо для описания нового продукта, либо для предоставления новой функции существующего продукта.
Какие инструменты вам нужны для story mapping?
Для story mapping требуется инструмент визуализации, такой как белая доска и стикеры, или их цифровой эквивалент.
Сколько времени занимает story mapping?
User story map необязательно создавать за один сеанс. Иногда это может занять несколько сеансов в течение нескольких дней в зависимости от размера, сложности и масштаба продукта.
Story mapping — це процес, який використовується для опису нового продукту або для надання нової функції продукту, що існує. Приклад створення User Story Mapping
Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …
Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.
