Event Storming

Введение: Взрыв стикеров

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

Что делать? Можно месяц ходить по интервью, записывать, переспрашивать, путаться. А можно заказать большую комнату, купить несколько пачек разноцветных стикеров (либо на Miro/Holst доске), позвать всех экспертов и устроить Event Storming.

Event Storming – это метод быстрого исследования сложных предметных областей через совместное моделирование событий, которые происходят в бизнесе.

Придумал его Альберто Брандолини (Alberto Brandolini) как способ “разобрать на части” сложную систему, где никто не понимает, как все устроено целиком. Название происходит от “storm” (шторм) – вы как будто набрасываетесь на проблему ураганом стикеров, пока не останется белых пятен.

Что такое Event Storming

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

Главный герой Event Storming – это событие. Событие – это факт, который уже произошел и имеет значение для бизнеса.

“Заказ оформлен”, “Товар оплачен”, “Заказ передан в доставку”, “Клиент получил заказ” – это события. Они прошли, их нельзя отменить, они изменили состояние системы.

Почему события? Потому что эксперты легко вспоминают и рассказывают истории: “Сначала происходит это, потом это, а потом, если случилось то, то происходит это”. Истории проще рассказывать, чем описывать абстрактные “требования”.

Ключевые понятия Event Storming

В Event Storming используется несколько типов стикеров (обычно разных цветов). Давайте разберем основные.

Событие (Event) – оранжевый стикер

Событие – это сердце метода. Формулируется в прошедшем времени.

Примеры:

• “Заказ оформлен”
• “Платеж прошел”
• “Товар отгружен со склада”
• “Письмо с подтверждением отправлено”
• “Клиент получил уведомление”

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

Команда (Command) – синий стикер

Команда – это намерение, действие, которое кто-то предпринимает, чтобы вызвать событие. Формулируется в повелительном наклонении.

Примеры:

• “Оформить заказ”
• “Оплатить заказ”
• “Отгрузить товар”
• “Отправить письмо”

Связь: Команда вызывает Событие. Обычно они располагаются рядом: синий стикер слева, оранжевый справа.

Актор (Actor) – желтый стикер

Кто выполняет команду? Актор – это человек, роль или внешняя система.

Примеры:

• “Клиент”
• “Менеджер”
• “Курьер”
• “Платежная система”

Агрегат (Aggregate) – большой розовый стикер

Агрегат – это “вещь”, над которой происходят события. Группа связанных данных и логики, которая обеспечивает их целостность.

Примеры:

• “Заказ” (вокруг него события: заказ создан, оплачен, отгружен)
• “Пользователь” (зарегистрирован, подтвердил email, заблокирован)
• “Товар” (добавлен на склад, зарезервирован, продан)

Агрегат – это ответ на вопрос: “Что является главным объектом в этой части процесса?”.

Политика (Policy) – фиолетовый стикер

Политика – это правило или автоматическое действие, которое срабатывает в ответ на событие. “Если случилось это, то нужно сделать то”.

Примеры:

• “Если заказ оплачен → отправить письмо клиенту”
• “Если товара нет на складе → уведомить менеджера”
• “Если прошло 30 дней → отправить напоминание”

Внешняя система (External System) – розовый стикер с пометкой

Что-то, что находится за пределами нашей системы, но с чем мы взаимодействуем.

Примеры:

• “Платежный шлюз”
• “Служба доставки”
• “CRM заказчика”

Как проходит Event Storming (процесс)

Шаг 1. Готовимся

• Помещение: Большая стена (или онлайн-доска типа Miro/Holst).
• Материалы: Разноцветные стикеры, маркеры.
• Люди: Все, кто знает бизнес. Не обязательно IT-специалисты. Лучше пригласить бизнес-экспертов, менеджеров, операционистов – тех, кто реально работает.
• Фасилитатор: Ведущий, который задает вопросы и следит за динамикой.

Шаг 2. Начинаем с событий

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

Вопросы фасилитатора:

• “С чего начинается процесс?”
• “Что происходит дальше?”
• “А что может пойти не так?”
• “А если случится это, то что произойдет?”

На этом этапе не спорят о деталях, не критикуют. Просто набрасывают события. Важно – события в прошедшем времени.

Шаг 3. Добавляем команды и акторов

После того как события выстроились, начинаем думать: “А что вызвало это событие? Кто это сделал?”.

Для каждого события (или группы событий) добавляем:

• Синий стикер “Команда” (что сделали)
• Желтый стикер “Актер” (кто сделал)

Пример: Оранжевый “Заказ оформлен”. Слева от него синий “Оформить заказ” и желтый “Клиент”.

Шаг 4. Выделяем агрегаты

Теперь смотрим на поток событий и ищем “скопления” вокруг одного объекта. Берем большой розовый стикер, пишем на нем название агрегата и обводим им группу событий.

Пример: Все события вокруг заказа (создан, оплачен, отгружен, доставлен) обводим розовым “Заказ”.

Шаг 5. Добавляем политики

Смотрим, есть ли события, которые автоматически запускают другие действия. Для таких “если-то” добавляем фиолетовые стикеры.

Пример: На событии “Заказ оплачен” вешаем политику “Отправить уведомление менеджеру”. Из политики идет стрелка к команде “Уведомить менеджера”.

Шаг 6. Обозначаем внешние системы

Если событие вызвано внешней системой, или команда обращается к внешней системе - отмечаем это.

Что получается в итоге

После Event Storming у вас есть:

• Большая карта процессов на стене – визуальное представление того, как работает бизнес.
• Общее понимание среди всех участников (и бизнеса, и IT).
• Границы между разными частями системы (агрегаты).
• “Белые пятна” – места, где эксперты не смогли ответить на вопрос. Это зоны риска, которые нужно исследовать дальше.
• Исходный материал для дальнейшей работы: можно нарезать User Stories, выделить микросервисы (по агрегатам), описать API.

Разновидности Event Storming

Big Picture Event Storming (крупная картина)

Цель – понять весь бизнес целиком. Участвует много людей (10-30). Время – 1-2 дня. Результат – полная картина процессов, границы, проблемные зоны.

Когда использовать:

• В начале проекта, когда ничего не понятно.
• Когда нужно согласовать видение между бизнесом и IT.
• Когда компания запускает новое направление.

Process-Level Event Storming (уровень процесса)

Цель – детально разобрать конкретный процесс. Участвует 3-8 человек. Время – 2-4 часа. Результат – детальная схема одного сценария (например, “оформление заказа”).

Когда использовать:

• Когда нужно разобрать сложный сценарий перед разработкой.
• Когда есть спорные моменты в логике.

Design-Level Event Storming (уровень проектирования)

Цель – спроектировать архитектуру (например, границы микросервисов). Участвуют технические специалисты + аналитики. Результат – модель домена, агрегаты, bounded contexts.

Bounded Context (ограниченный контекст) — это чётко определённая область внутри системы, в которой применяется конкретная модель предметной области. Это понятие из методологии предметно-ориентированного проектирования (Domain-Driven Design, DDD).

Когда использовать:

• При переходе к микросервисной архитектуре.
• Когда нужно четко разделить ответственность между командами.

Типичные ошибки при проведении Event Storming

Ошибка 1: Путать события и команды

“Оформить заказ” – это команда. “Заказ оформлен” – это событие. Событие всегда в прошедшем времени.

Ошибка 2: Начинать с команд или акторов

Начинать нужно с событий. Именно вокруг событий выстраивается все остальное.

Ошибка 3: Слишком много технических деталей

“SQL-запрос выполнен” – это не бизнес-событие. События должны быть на языке бизнеса.

Ошибка 4: Спорить о деталях на этапе набрасывания

Сначала набросать все события. Спорить – потом. Иначе процесс застрянет.

Ошибка 5: Фасилитатор говорит больше экспертов

Фасилитатор задает вопросы, но не рассказывает, как работает бизнес. Говорить должны эксперты.

Ошибка 6: Не фиксировать результат

После воркшопа нужно сфотографировать стену (или экспортировать доску) и расшифровать. Иначе через неделю все забудут.

Что делать после Event Storming

Event Storming – это начало, а не конец работы. После того как стикеры наклеены:

1. Сфотографируйте или экспортируйте доску. Это ваш артефакт.

2. Расшифруйте в текст. Опишите ключевые сценарии, события, команды.

3. Нарежьте User Stories. На основе команд и сценариев можно сформировать бэклог.

4. Выделите агрегаты. Это кандидаты на микросервисы или модули.

5. Проверьте “белые пятна”. Там, где эксперты не смогли ответить, проведите дополнительные интервью.

6. Сделайте диаграммы. BPMN для процессов, C4 для архитектуры, Sequence для взаимодействий.

Пример: Event Storming для доставки еды

Резюме для системного аналитика

1. Event Storming – это метод исследования, а не только моделирования. Вы не просто рисуете схему, вы добываете знания из голов экспертов.

2. Главный герой – событие. Все начинается с оранжевых стикеров в прошедшем времени. События легко вспоминать и рассказывать.

3. Это командная работа. Ваша задача – фасилитировать, задавать вопросы, не давать застревать в деталях. Говорят эксперты.

4. Не бойтесь “белых пятен”. Если никто не знает ответ – это нормально. Вы нашли зону, которую нужно исследовать дальше.

5. Результат – не просто стикеры на стене. После воркшопа нужно расшифровать, структурировать и перевести в понятные артефакты (User Stories, диаграммы, требования).

6. Event Storming отлично сочетается с C4 и BPMN. Сначала проводите Event Storming, чтобы разобраться в домене. Потом на основе результатов рисуете C4 для архитектуры и BPMN для процессов.