В предыдущих сериях:
Общее описание сути Event Storming.
Big Picture в Event Storming — это визуальное представление бизнес-домена, отражающее поток событий, взаимосвязи между участниками процесса и возможные проблемные области. Этот артефакт создаётся в ходе совместной работы команды и фиксирует текущее состояние системы, помогая сформировать единое понимание её структуры, ограничений и точек для улучшения. Он служит отправной точкой для последующего проектирования архитектуры и принятия решений, обеспечивая прозрачность и согласованность между бизнесом и техническими специалистами.
Много слов, зачем нам нужен big-picture.
1. Общее понимание системы и процессов
Big-Picture Event Storming позволяет всем участникам (разработчикам, бизнес-аналитикам, стейкхолдерам) прийти к единому пониманию текущих процессов.
- Какие ключевые события происходят в системе.
- Как процессы связаны между собой.
- Какие действия инициируют события и как они влияют на другие части системы.
- В каких местах процесса существуют узкие места или избыточные этапы.
2. Выявление скрытых проблем и узких мест
Методология Event Storming помогает визуализировать проблемные области и потенциальные точки отказа.
- Какие части процесса вызывают задержки или сбои.
- Где происходят ошибки или дублирование работы.
- Какие участки процесса являются недостаточно прозрачными или плохо документированными.
- Какие внешние зависимости влияют на выполнение процессов (интеграции, третьи стороны, регуляторные требования).
3. Формирование границ ограниченных контекстов
Event Storming помогает определить Bounded Contexts (ограниченные контексты) — ключевой элемент доменного моделирования (DDD).
- Какие части системы могут быть выделены в отдельные контексты.
- Как взаимодействуют различные контексты и какие границы между ними.
- Где необходимо улучшить коммуникацию между контекстами.
4. Определение участников и их ролей
В процессе Big-Picture Event Storming выявляются основные роли и их влияние на систему.
- Какие пользователи и системы инициируют события.
- Как принимаются решения на каждом этапе процесса.
- Где автоматизация может заменить ручные процессы.
- Как взаимодействуют разные бизнес-подразделения.
5. Обнаружение бизнес-правил и политики управления
При работе с процессами можно выявить явные и неявные бизнес-правила.
- Какие условия влияют на выполнение событий.
- Где требуется явная проверка или одобрение (например, финальные согласования перед отправкой заказа).
- Какие ограничения или регуляторные нормы нужно учитывать.
- Где могут возникать конфликты между различными требованиями.
6. Возможности для улучшений и оптимизации
В ходе обсуждения участники находят возможности для оптимизации.
- Какие шаги можно автоматизировать.
- Где можно упростить процессы за счёт изменения логики работы.
- Как лучше организовать потоки данных между системами.
- Где можно сократить время выполнения операций.
7. Определение точек интеграции и обмена данными
Big-Picture Event Storming позволяет понять, как взаимодействуют различные системы и сервисы.
- Где происходят обмены данными между модулями системы.
- Какие внешние API и сервисы вовлечены в процессы.
- Какие точки интеграции могут стать узкими местами.
- Как можно улучшить синхронизацию между системами.
8. Формирование документации для будущих решений
Полученная в ходе Event Storming информация может использоваться для создания:
- Диаграмм бизнес-процессов.
- Документации для разработчиков и аналитиков.
- Основы для проектирования архитектуры ПО.
- Технических заданий для команд разработки.
Как big-picture формируется на практике?
Цель проведения.
Цель крупномасштабного исследования в том, чтобы оценить состояние существующего направления бизнеса или изучить жизнеспособность новой бизнес-модели, например, стартапа. Также этот вид Event Storming часто используется для проведения организационных ретроспектив, изучения организации с целью структурных изменений.
Доменное событие (Domain Event) – оранжевые стикеры
- Основная концепция Event Storming.
- Это событие из мира экспертов в предметной области и происходящее в изучаемой предметной области.
- Формулируется как глагол в прошедшем времени.
Самое главное о доменном событии:
Событие произошло в прошлом.
Достаточно важное, чтобы сохранить (persist) его.
Достаточно важное, чтобы быть интересным другим контекстам.
Неизменяемый объект.
Не содержит сущностей или других изменяемых объектов.
Может быть создано в сущности
Имена и свойства соответствуют единому языку в ограниченном контексте
Имя несет информацию о том, что произошло после завершения операции
Интерфейс события выражает его предназначение, а свойства отражают его причниу
Временная ось (Timeline)
- Порядок расположения событий слева направо по мере их наступления.
- Параллельные потоки событий могут располагаться друг над другом.
Упорядочивание по временной оси (Enforce the Timeline)
- Фаза, следующая за хаотическим исследованием.
- В рамках этой фазы все события упорядочиваются на единой временной оси.
- Удаляются дубликаты событий.
Возможность (Opportunity) – зеленые стикеры
- Противоположность неудовлетворенности (Hotspot).
- Обозначает потенциально выгодную или позитивную ситуацию.
- Используется после того, как события упорядочены на общей временной оси.
Действующее лицо (Actor) – желтые стикеры
- Человек или группа людей, департамент, команда,
- Конкретное лицо, влияющее на или на которое влияет доменное событие.
Система (System) – розовые стикеры
- IT-система, используемая как решение некоторой проблемы в домене.
- После того, как события упорядочены по единой временной оси, можно начать располагать системы вокруг доменных событий.
Дополнительные концепции
Неудовлетворенность (Hotspot) – 🟥 малиновые стикеры
- Используется для обозначения и визуализации конфликтов.
- Источниками конфликтов могут быть:
- рассогласованность используемого языка,
- недопонимание,
- несогласие,
- возражения,
- проблемы,
- желание изучить что-то глубже.
Начало, Хаотическое исследование (Chaotic Exploration).
Предполагается, что цели определены, участники мотивированны, доска и стикеры готовы, если он-лайн, то подготовлена достка в miro и мы знаем, что делаем. Ну тогда погнали, пока архитектурные баги не догнали.
Хаотическое исследование - второй, после фиксации целей, этап сессии. В рамках него участники самостоятельно размещают все события которые приходят им в голову, в том порядке, который они считают нужным.
При этом, в зависимости от уровня подготовки и желания фасилитатора сессии возможно раздельное внесение событий или совместное с параллельным обсуждением и подтверждением от всех участников группы.
Возможно нанесение события сразу по временной шкале, или сначала
Можно стараться сразу разместить события по временной шкале, можно сначала разместить события, потом их упорядочить.
Основные события .
Основные события выступают как главы в общем повествовании, предоставляя порядок и структуру общего нарратива. Эти «главы» - естественные границы для поддоменов и/или процессов.
Временные границы:
- Начало или окончание процесса
- Начало или окончание пути пользователя
Лингвистические границы:
- Изменение названия сущности (Заявка-> кредит)
Роли и ответственность:
- ·Передача сущности от одного человека другому
- Начало или окончание процесса с точки зрения роли
- Начало или окончания пути пользователя с точки зрения роли
Кластеры событий
- Сходство или родство событий
Точки принятия решений
Критические события
- Необходимы для функционирования системы.
Часть событий могут стать Pivotal Events, представляющие собой самые важные, опорные для бизнеса события.
При их нанесении на доску, обязательно будут споры между экспертами и это хорошо. В результате вы получите набор событий, наиболее важных для бизнеса, между которыми вы будете формировать уже более декомпозированную карту событий.
После нанесения событий как понять, что все сделано правильно?
- Видна логическая последовательность событий.
- Устранены дубликаты и противоречия.
Выявление неопределенностей и возможностей.
После нанесения на доску событий добавляется информация о неопределенностях и возможностях. При этом, право голоса есть у всех. Если неопределенность не удалось быстро разрешить, она фиксируется.
- Малиновые стикеры мы используем для обозначения проблем, например: не ясно как считается скидка.
- Зелеными стикерами отмечаем потенциальные улучшения, например: автоматизировать обработку отказов.
Все сделано правильно, если:
- Выявлены основные проблемные зоны
- Появились идеи для улучшения, если идей нет – значит все и так идеально и зачем это все?
Определение действующих лиц и систем.
Далее, на доску наносится информация о действующих лицах – кто выполняет события, например: клиент, менеджер, оператор КЦ. Для этого используем желтые стикеры.
В случае, если описывается ситуация AS-IS обогащаем информацией о информационных системах, используем розовые стикеры.
Все сделано правильно, если:
- Понятно, какие роли участвуют в процессах.
- Видно, какие системы задействованы.
Группировка событий в ограниченные контексты.
У вас на доске должны уже появится основные события и они должны быть выстроены по времени. На этом этапе визуально уже должно быть понятно, как можно разделить контексты. Например: оформление заказа, доставка и так далее.
Для этого мы используем черные рамки.
Как понять, что все сделано правильно?
- Контексты логично обособлены
- Нет сильной зависимости между контекстами.
Не обязательно все области доски должны быть помещены в контексты, но контексты, желательно, должны покрывать максимальную область интересующего нас домена.
Завершение сессии, как понять. Что все прошло удачно?
- Все события выстроены в последовательность
- Выявлены неопределенности и возможности
- Определены роли
- Сформированы ограниченные контексты.
В следующей статье дам ряд практических советов, но на этом, пожалуй, о ES все.