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

Описание

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

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

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

Процесс

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

1. Определить ключевые виды деятельности, которые должен поддерживать продукт, каждый вид деятельности записать на отдельной карточке. Для карточек видов деятельности используется один цвет.
2. Расположить их по порядку использования слева направо. Хотя последовательность выполнения активностей пользователями будет меняться, как правило существует общая ежедневная последовательность, которая может быть использована. Эти активности, как правило, слишком велики, чтобы реализовать в одной итерации разработки.
3. После расположения пользовательских активностей в логическом порядке, необходимо определить отдельные задачи, которые составляют каждую активность. Эти задачи должны быть отдельными частями работы для тех пользователей, кто использует продукт. Необходимо записать каждую задачу на отдельной карточке, используя различные цвета в зависимости от деятельности.
4. Расположить задачи в одной строке в логическом, последовательном порядке под соответствующим видом деятельности. Опять же, часто не будет строгой последовательности, которой необходимо следовать каждый раз, но будет общий логический порядок выполнения задач. Это отражается последовательностью карточек-задач на карте.
5. Проверить активности и задачи с помощью экспертов в данной области и других заинтересованных сторон. Задать им вопрос: составили ли они полную картину того, что должен обеспечить продукт? Обновить и изменить активности и задачи по мере необходимости.
6. Добавить подзадачи ниже задач, еще раз, используя карточки различных цветов. Часто они должны охватывать альтернативные пути постановки задач или должны иметь дело с исключениями или потенциальными проблемами при выполнении задачи. Добавить эти нижние задачи сверху вниз в логическом порядке, основываясь на приоритете пользователя. Эти подзадачи находятся на уровне истории пользователя и их будет много. Просмотр верхнего ряда подзадач по всей карте обеспечит обзор минимально возможного жизнеспособного продукта, набор функций, которые должны быть присущи продукту, чтобы имелось какое-либо значение для бизнеса вообще. Этот горизонтальный обзор историй пользователя обеспечивает логическую отправную точку для выпуска и итерационного планирования, в то время как вертикальное положение истории пользователя показывает ее относительный приоритет в общей картине.
7. Проверить карту историй с помощью заинтересованных сторон и обновить ее при необходимости.
8. Хранить карту историй, чтобы обеспечить обзор большой картины всего продукта. Указать, когда истории завершены на карте истории таким образом, чтобы был виден общий прогресс.

Использование

Попробуйте применить практику сбора требований при помощи карт историй с использованием демонстрационного проекта:

Создать проект

Особенности использования

Преимущества

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

Недостатки

• Story mapping может стать громоздкой практикой, если продукт очень большой и может потребоваться строительство ряда карт историй, которые охватывают большую программу работ. Хотя карты историй иллюстрируют поток, они не анализируют или не иллюстрируют зависимости между требованиями (хотя они могут быть использованы, чтобы помочь облегчить этот анализ).

--

Усилиями членов IIBA и экспертами сообщества Agile был разработан черновик The Agile Extension of the BABOK, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.

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

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

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile