От практики к теории: как перейти от Event Storming к User Stories?

Content

В этой статье мы описываем, как вы можете использовать Event Storming (событийный штурм) для вашего нового проекта разработки, а затем применить концепцию User Story Mapping (составление карт пользовательских историй) для добавления User Stories (пользовательских историй) и планирования их в спринтах или релизах. Event Storming - это очень мощный инструмент для организации воркшопов, который улучшает сотрудничество между ИТ-специалистами и клиентами.

Что такое Event Storming?

Event Storming часто используется в качестве отправной точки для изучения бизнес-домена. Event Storming может быть применен на 3 уровнях:

1. Big Picture Modeling (исследование на большом масштабе)

2. Process Modeling (моделирование процессов)

3. Software Design (дизайн программного обеспечения)

В большинстве случаев, вы начинаете с Big Picture Modeling. Цель данного исследования - оценить состояние целого направления бизнеса в рамках корпоративной разрозненности или изучить жизнеспособность новой бизнес-модели стартапа. Это помогает группе создать общее состояние видения определенной области компании. В ходе процесса участники определяют и согласовывают основные бизнес-события (называемые Domain Events) в бизнес-потоке и их порядок во времени. После того, как бизнес-события были отображены на временной шкале, вы можете продолжить и добавить в модель дополнительные концепции по мере необходимости, такие как

• Hot spots (горячие точки). Они позволяют визуализировать болевые точки и вопросы без ответов.
• Возможности.
• Actors (фигурки человека).
• Внутренние или внешние системы.
• Аспекты, которые требуют большего внимания.
• Основные события. Наиболее важные события в бизнес-домене, которые являются отличным источником информации.
• Swimlanes (плавательные дорожки), которые группируют действия по ролям, ресурсам, элементам организации и т.д.
• Bounded Contexts (ограниченные контексты) - система, которая инкапсулирует кооперативные компоненты с четкими границами, определяющими, что может входить в систему или выходить из нее. Внутри границ можно свободно использовать повсеместный язык. Вне этого языковые термины могут иметь разные значения.

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

• Policies (политика) - правила, регулирующие то, какая команда будет запущена в зависимости от события, например, всякий раз, когда происходит X, мы делаем Y.
• Команды/действия - элементы, которые запускают события, представляют решения, действия или намерения. Они могут быть инициированы субъектом или автоматическим процессом/политикой.
• Модель запроса/модель чтения/информация - информация, необходимая субъекту для принятия решения или отправки команды.
• Мокапы UX.

Вы достигнете точки, когда ни Big Picture, ни Process Modeling не будут достаточно подробными для разработки программного обеспечения. Именно тогда вы переходите на третий уровень, Software Design. Это способ погрузиться в сложный субдомен и сотрудничать в соответствии с требованиями к программному обеспечению. Цель Software Design - разработать чистое и удобное в обслуживании программное обеспечение, управляемое событиями. Это помогает командам разработчиков совместно проектировать внутреннюю часть ограниченного контекста. Во время этого воркшопа вы можете добавить концепции, упомянутые выше для Process Modeling, а также следующие концепции по мере необходимости:

• Aggregates (агрегаты) - это основанный на домене шаблон проектирования; кластер или инкапсуляция объектов домена, которые концептуально принадлежат друг другу и могут рассматриваться как единое целое, например, заказ, список воспроизведения, автомобиль. Это уменьшает интерфейс сегмента приложения и ограничивает доступ к внутренним объектам.
• Бизнес-правила.
• Ограничения.

Бизнес-события и временная шкала являются основой Event Storming. Другие концепции, упомянутые выше, применяются по мере необходимости.

Добавление User Stories

Event Storming - отличная отправная точка, но большинство Agile-команд работают с User Stories в Product Backlog (бэклоге продукта). Как перейти от бизнес-процесса, задокументированного с помощью Event Storming, к действенным User Stories, которые можно оценить, расставить по приоритетам и спланировать в спринте? Некоторые команды могут начать кодирование после нескольких сессий Software Design, но многим владельцам продуктов и разработчикам нравится структура Product Backlog или User Story Map (карта пользовательских историй), поскольку она, помимо многих других преимуществ, обеспечивает плавное планирование итераций на основе ценности. Владелец продукта также заинтересован в предсказуемости и хочет иметь возможность контролировать и предсказывать контент в предстоящих спринтах.

Один из способов взглянуть на это - начать с ключевых событий и команд в рамках домена, определенных во время воркшопов Event Storming. Многие из этих событий/команд связаны с действиями пользователя и могут рассматриваться как основа в User Story Map, т. е. могут быть этапами пути пользователя. Затем команда может продолжить работу в соответствии со Scrum и User Story Map, добавляя User Stories для каждого шага. Далее команда оценивает объем работы, проделанной для каждой пользовательской истории, и выявляет, какие истории она может завершить для предстоящих спринтов или релизов. Команда и владелец продукта, как обычно, определяют приоритеты User Stories, чтобы достичь больших результатов в кратчайшие сроки и визуализировать содержание каждого релиза/спринта.

Улучшение коммуникации при удаленной работе

Многие команды сегодня работают удаленно, и заказчики и члены команды не всегда могут собраться перед огромной белой доской и разместить на ней стикеры. Поэтому для удаленной совместной работы им необходим онлайн-инструмент. Qlerify устраняет разрыв между Event Storming и инструментом планирования разработчиков. Qlerify - это удобное рабочее пространство для совместного редактирования с поддержкой Event Storming, User Story Mapping, Product Backlogs, Agile Data Modeling, социального сотрудничества и интеграции API с инструментами ALM, такими как Jira.

Максимальная скорость и простота

Одним из преимуществ использования Qlerify является то, что этот инструмент позволяет создавать и документировать контент в режиме реального времени во время воркшопов Event Storming, а также мгновенно синхронизировать контент c Jira одним нажатием кнопки. Agile-команды могут приступить к планированию спринтов сразу после сеансов составления карт!

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

Заключение

Qlerify позволяет удаленным командам перейти от воркшопа к актуальному Product Backlog в Jira в рекордно короткие сроки - ваши разработчики могут начать писать код сразу после воркшопа!

Если вы хотите узнать больше об Event Storming и User Story Mapping, следующие ресурсы отлично описывают данные концепции:

• Пользовательские истории. Искусство гибкой разработки ПО, Джефф Паттон (книга на Amazon)
• User Story Mapping, Джефф Паттон (оригинал статьи)
• Знакомство с Event Storming, Альберто Брандолини (оригинал статьи)
• Знакомство с Event Storming, Альберто Брандолини (книга Leanpub)
• Предметно-ориентированное проектирование, Вон Вернон (глава 7 представляет Event Storming как инструмент ускорения и управления для DDD)
• Введение в Event Storming, Вольфганг Вернер (хорошая шпаргалка для быстрого введения в тему)