kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Карта пользовательских историй
В этом уроке вам предстоит объединить знания, которые вы получили в предыдущих уроках, в единую систему — карту пользовательских историй. Вы узнаете, зачем эта карта нужна, из чего состоит и как организовать её создание.
Что такое карта пользовательских историй
Когда команда работает над проектом в каскадной или гибкой модели, у неё накапливается информация, где многое связано друг с другом. Например:
- На этапе проектирования интерфейса появляются персоны.
- У этих персон появляются цели, которых они хотят достичь с помощью ПО. Так формируются пользовательские истории.
- Эти истории пользователи затем воплощают в жизнь с помощью интерфейса, и история превращается в сценарий использования.
Чтобы увидеть картину целиком (как будет использоваться ПО), всю информацию о проекте можно собрать в одном месте — на карте пользовательских историй.
Карта пользовательских историй (User Story Map) — это техника, которая позволяет расположить пользовательские истории согласно последовательности использования функций продукта.
User Story Map позволяет команде разработки:
- Увидеть масштаб продукта, чтобы в дальнейшем сформировать его бэклог.
- Определиться с приоритетами при разработке продукта с нуля — решить, какие функции ПО нужно реализовать в первую очередь, чтобы проверить его в действии.
- Заранее определить проблемы, с которыми столкнётся пользователь и команда разработки при работе с уже существующим ПО и регулярном добавлении новых функций.Если при внедрении новой функциональности у команды перед глазами есть User Story Map, меньше вероятность того, что «поломаются» уже имеющиеся сценарии использования. Ещё карта может дать команде пищу для размышлений, когда та ищет способы решения пользовательских задач.
Составить карту пользовательских историй можно с помощью разных инструментов: начиная с аналоговых (стикеров на стене или большой маркерной доски) и заканчивая специальным ПО (Miro, FigJam, Jira, Visual Paradigm и прочие).
Как составлять карту пользовательских историй
User Story Map создают коллективно. Желательно, чтобы в этом участвовала вся команда разработки и пользователи. Эта встреча похожа на мозговой штурм, где фасилитатором может быть системный аналитик.
Процесс создания User Story Map состоит из пяти крупных шагов:
- Подготовка.
- Определение пользовательских активностей.
- Определение пользовательских задач.
- Проработка деталей пользовательских историй.
- Разделение User Story Map на релизы или итерации.
В этом уроке разберём каждый шаг на примере сервиса с интерактивной картой метро.
1. Подготовка
На этом этапе закладывается основа карты. Команде разработки нужно ответить на вопросы из трёх блоков:
- Над каким ПО мы работаем? Какова его основная задача? Какую глобальную проблему пользователей оно решает? Карточку с ответом на этот вопрос нужно разместить в левой части карты.
- Кто наши пользователи? Какие персоны мы можем выделить? Кто может стать нашим потенциальным пользователем? От карточки с описанием ПО в левой части карты проведите горизонтальную линию. Вдоль этой линии разместите карточки с описанием персон.
- Зачем пользователям наше ПО? Какую пользу от него они могут получить?Затем следует выделить персоны с похожими целями и сгруппировать их по общим признакам и проблемам, с которыми они сталкиваются. Например, Ангелина и Виталий регулярно пользуются метро, и в назначенном месте им нужно быть вовремя. Их цели похожи, а значит, и пользовательские истории у них могут быть общими. На следующих этапах создания карты их нужно расположить под сложившейся группой пользователей (Ангелина и Виталий).Цели и проблемы Кости отличаются от целей и проблем Ангелины и Виталия. У Кости будут другие пользовательские истории, поэтому его выделяют в отдельную группу. Группы персон с разными целями нужно распределять над горизонтальной линией на расстоянии друг от друга. Это поможет визуально разграничить их. Под каждой группой персон записывают пользовательские истории, которые подходят именно этой группе.
2. Определение пользовательских активностей
У каждой группы персон, выделенной на предыдущем этапе, есть общие глобальные цели. Задача команды разработки на этом этапе — определить их и верхнеуровнево обозначить действия, которые пользователь может совершить, чтобы достичь этих целей.
Активности (User Activities) — это последовательные действия, которые пользователю нужно совершить, чтобы достичь своих целей.
Для примера рассмотрим группу пользователей — Ангелина и Виталий. Каждому из них нужно рассчитывать время и маршрут поездки. Ангелине важно всегда вовремя быть на работе, а Виталий часто опаздывает на занятия, так как плохо рассчитывает маршрут. Если бы они воспользовались приложением для решения своей проблемы, им нужно было бы совершить две активности:
- Проложить маршрут.
- Узнать детали этого маршрута.
Чтобы определить активности пользователей, можно пообщаться с ними напрямую или выдвинуть свои предположения о том, как пользователи могут достичь своей цели с помощью ПО.
На карте пользовательских историй все активности нужно расположить под персонами, согласно последовательности, в которой они будут выполняться.
Пользовательские активности — это каркас (backbone) карты, который формирует представление об основных функциях ПО.
Составляя активности, команда разработки может обнаружить, что у персон появляются общие цели. Например, Костя постоянно забывает маршрут и хотел бы иметь доступ к часто используемым маршрутам. Но и Виталию эта активность поможет лучше рассчитывать маршрут. Поэтому стоит объединить Костю и Виталия в ещё одну группу. Важно не забывать добавлять подобные изменения на карту.
3. Определение пользовательских задач
На следующем шаге нужно опуститься на уровень пользовательских задач.
Пользовательская задача (User Task) — это более конкретное описание действий, которые пользователь должен выполнить в рамках активности. Каждую активность можно поделить на несколько мелких задач.
Например, активность «Проложить маршрут» можно разделить на три задачи, которые пользователь должен будет выполнить в приложении:
- Открыть карту метро.
- Найти нужные станции.
- Построить маршрут между ними.
Все эти задачи располагаются под карточкой активности слева направо в хронологической последовательности, то есть том порядке, в котором пользователь будет их выполнять.
4. Проработка деталей пользовательских историй
Процесс использования ПО можно описать с помощью пользовательских активностей. Задачи описывают тот же процесс, но более подробно. А детали пользовательских историй описывают этот же процесс на максимальном уровне детализации.
Если активности и задачи описывают функции ПО верхнеуровнево, то добавление пользовательских историй позволяет детализировать функции ПО. Это помогает увидеть «пробелы» в карте, добавить неучтённые задачи и увидеть альтернативные варианты решения пользовательских задач.
Под каждой задачей необходимо расположить пользовательские истории, написанные по шаблону, с которым вы познакомились в предыдущих уроках: «Как (пользователь), я хочу (задача), чтобы (цель)».
И Ангелина, и Виталий должны выполнить задачу «Построить маршрут». Что им нужно для этого сделать? Выбрать начало и конец маршрута. Теперь нужно описать это действие в виде пользовательской истории по шаблону:
«Как пользователь, я хочу ввести названия станций начала и конца маршрута, чтобы узнать его детали».
В процессе обсуждения с командой разработки и пользователями можно обнаружить ещё один вариант выполнения той же самой задачи:
«Как пользователь, я хочу прямо на карте выбрать начало и конец маршрута, чтобы увидеть протяжённость маршрута».
В отличие от активностей и задач, детали пользовательских историй располагают на карте вертикально, друг под другом. Для одной задачи может быть написано много пользовательских историй, они будут появляться и изменяться в процессе составления карты, поэтому вертикальное расположение будет более компактным.
В процессе составления карты можно добавлять новые идеи, которые появляются в результате обсуждений с командой. Например, во время проработки деталей историй по выбору станций можно заметить, что выбирать станции метро можно не только в списке и на карте, но и с помощью поиска по названию.
Необходимость показывать станции пересадки может натолкнуть на ещё одну задачу — «Посмотреть альтернативный маршрут». Это даст пользователям возможность выбрать более комфортный маршрут. Так на карте может появиться новая задача и пользовательская история для её детализации.
Чтобы сделать карту более точной и полезной, можно добавить дополнительную информацию на карточку в виде пометки. Например, в процессе обсуждения команда пришла к выводу, что пользовательская история ввода начальной и конечной точки маршрута должна включать в себя возможность поменять эти точки местами. Соответствующий комментарий был помещён на карту.
Основная часть User Story Map считается готовой, когда к каждой задаче добавлена одна или несколько пользовательских историй. Теперь можно увидеть все пользовательские истории в одном месте.
При составлении User Story Map нужно уметь вовремя остановиться. Задача этого инструмента — составить представление о том, как пользователь может работать с ПО и, как итог, какие функции должно выполнять ПО. Не стоит сильно углубляться в детали функциональности, подробно описывать элементы интерфейса и используемые данные.
На этом этапе думайте «на милю в ширину, на дюйм в глубину». Доберитесь до конца пользовательской истории прежде, чем успеете потеряться в её деталях.Джефф Паттон, User Story Mapping
5. Разделение User Story Map на релизы или итерации
Важная часть работы с картой пользовательских историй — разделение карты на части. Есть несколько принципов деления:
- По итерациямВсю карту можно разделить на наборы пользовательских историй, которые команда разработки сможет реализовать за одну итерацию. В течение каждой итерации будет реализовываться набор историй. Он в итоге даст инкремент, то есть набор функций, который приносит пользу заинтересованным лицам.Предположим, что ваша команда использует гибкий подход. Одна итерация в команде занимает четыре недели. Для реализации ПО потребуется выполнить три итерации. Поэтому распределим пользовательские истории на три группы таким образом, чтобы в каждую итерацию выдавать набор функций, который даёт пользу всем заинтересованным лицам.
- По возможным релизамПомимо разделения карты по итерациям, все пользовательские истории можно разбить по функциям , которые необходимо выполнить в первую очередь.Один из вариантов такого разделения — определение MVP (Minimal Viable Product — минимально жизнеспособный продукт). О том, что это и как определять MVP на карте пользовательских историй, вы узнаете в следующем уроке.
Расположите описание этапов создания карты в том порядке, в котором они выполняются.
Определить цели пользователей и сделать каркас карты.
Этап 2
У пользователей есть цели, и для их достижения они совершают активности. Выделение основных активностей происходит на втором этапе создания карты. Пользовательские активности составляют каркас карты.
Выделить набор задач, которые нужно взять в работу в первую очередь.
Этап 5
Выделять задачи, над которыми вы будете работать в первую очередь, нужно на самом последнем этапе, когда готова карта пользовательских историй. Только после этого её можно делить на итерации или релизы.
Обозначить задачи, которые пользователи выполняют для достижения небольших целей.
Этап 3
После того как определены пользовательские активности, нужно описать задачи, которые выполняются в рамках этой активности. Выделение пользовательских задач — это третий этап составления карты.
Добавить описания персон, а также целей и задач ПО
Этап 1
Общее описание ПО и список его потенциальных пользователей появляются на карте пользовательских историй в первую очередь.
Добавить описание задач в виде пользовательских историй.
Этап 4
Детали пользовательских историй появляются на предпоследнем этапе создания карты.
Подведём итоги
В этом уроке вы познакомились с популярным подходом к работе с пользовательскими историями — составление карты пользовательских историй.
Карта пользовательских историй (User Story Map) — это техника, которая позволяет расположить пользовательские истории, согласно последовательности использования функций продукта.
Карту пользовательских историй составляет вся команда разработки на встрече в формате мозгового штурма.
Основные этапы создания карты пользовательских историй:
- Подготовка.
- Выделение основных активностей.
- Выделение пользовательских задач.
- Проработка деталей пользовательских историй.
- Разделение карты пользовательских историй на релизы или итерации.
Карту пользовательских историй можно разделить на итерации и выделить на ней MVP.
Чат поддержки