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

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

Давайте начнем…

Что такое сопоставление пользовательских историй?

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

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

Карта истории пользователя отображает три типа действий:

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

Подробности: Небольшие взаимодействия, которые пользователь будет испытывать для выполнения шагов.

Вот пример карты истории пользователя:

мобильное приложение-история пользователя-карта

Почему вы должны сопоставлять истории пользователей в гибкой разработке?

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

I. Улучшение сотрудничества между вашей командой

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

II. Лучшее управление бэклогом продукта

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

III. Обоснованная расстановка приоритетов

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

IV. Выявление рискованных допущений

Креативность иногда может взять верх над нами. Мы можем делать рискованные предположения, то есть добавлять элементы, которые не подкреплены пользовательскими данными, технически невыполнимы или отклоняют бюджет или сроки нашего проекта от курса.

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

Когда сопоставлять истории пользователей в гибкой разработке

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

С помощью сопоставления пользовательских историй вы можете проиллюстрировать решения проблем, и как только пользовательские карты будут готовы, команды могут вернуться к ним.

Однако перед началом создания карты пользовательских историй установите следующий контекст, чтобы убедиться, что все идет в соответствии с планом:

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

Область действия вашей карты истории: будете ли вы отображать весь продукт, только одну функцию или часть пользовательского интерфейса.
Результаты: Что будет результатом запуска продукта или функции, описанной на карте? Это помогло бы вам установить реалистичные начальные и конечные точки для карты.

Как создавать карты пользовательских историй в гибкой разработке?

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

Шаг 1: Сформулируйте проблему

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

Как [тип пользователя], я хочу [действовать], что [выгодно].

Это поможет вам поставить себя на место пользователей и доработать продукт таким образом, чтобы он принес им наибольшую пользу.

Шаг 2. Поймите пользователей вашего продукта

Следующий шаг - понять пользователей вашего продукта. Это важно, потому что разные аудитории имеют разные цели и могут по-разному взаимодействовать с вашим продуктом.

Лучший подход к созданию пользовательских персонажей - помочь командам понять целевую аудиторию и создавать истории пользователей с их точки зрения. Это позволит избежать напрасных усилий по созданию пользовательских историй, неподходящих для целевой аудитории.

Шаг 3: сопоставьте действия пользователей

Пользователи будут взаимодействовать с продуктом посредством повседневных действий, называемых темами или функциями. Следующий шаг - сопоставить их, поскольку это основа вашей карты истории пользователя.

Шаг 4. Сопоставьте истории пользователей в разделе Действия

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

Шаг 5: определите и расставьте приоритеты в потоке

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

Шаг 6: Определите пробелы, зависимости, технические требования и альтернативы.

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

Шаг 7: планирование спринтов и релизов

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

Проблемы с отображением пользовательских историй, с которыми вы можете столкнуться

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

Невозможно создать правильные истории пользователей, не зная клиента.
Сопоставление пользовательских историй может иметь неприятные последствия, если вы не знаете, какую проблему пытаетесь решить для своих клиентов.
Создание пользовательских историй излишне, поскольку карту пользовательских историй обычно необходимо воссоздавать в плоском бэклоге, чтобы команды разработчиков могли начать над ними работать.

В заключение

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

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