Event Storming

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

Кто не в курсе, скажу, что Event Storming — это визуальная нотация для описания (бизнес- и не только) процессов. Описание делается на (онлайн) доске с помощью стикеров. Стикеры — разноцветные, каждый цвет имеет свой смысл. Стикеры выкладываются на доске слева направо, т.е. в направлении невидимой временной оси. Такая цепочка служит описанием последовательности действий какого-то процесса. За свою простоту, понятность и эффективность метод получил признание среди системных аналитиков и архитекторов и активно набирает популярность. Помимо этого, он очень хорошо сочетается с техниками DDD, что в том числе помогает визуально идентифицировать Bounded Contexts (и наглядно находить границы микросервисов).

Теперь важные моменты, на которые обратили внимание опытные пользователи Event Storming.

Этапы встреч

• Обсуждение проблематики (Big Picture). В составе участников: представители бизнеса, владелец продукта, бизнес- и системный аналитик, возможно, архитектор.

• Обсуждение бизнес-процессов (Processing Model). В составе участников уменьшается количество представителей бизнеса и добавляются технические специалисты.

• Проектирование решения (Software Design). Представители бизнеса исключаются из состава участников, но обязательно присутствуют архитекторы, разработчики и технические специалисты.

Перед каждой встречей

• Обозначить цель и ограничить время. Будет гораздо продуктивней, если до начала встречи каждый подумает на обозначенную тематику, а в идеале — подготовится; а также будет знать, сколько времени займет обсуждение.

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

Во время встречи

• Выбрать ведущего. Не принципиально, кто им будет, но он должен быть один. Чаще всего - это наиболее опытный пользователь Event Storming.

• Объяснить правила. Этот шаг необходим только в том случае, если имеется участник, который не знаком с Event Storming.

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

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

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

• Главное - добиться цели. Суть не в детализации, а в ответе на поставленный вопрос. По этой причине можно опускать детали (стикеры), которые очевидны или несущественны.

Техника проведения “Big Picture”

• Шаг 1: Неструктурированное исследование. Выписываем все события предметной области, которые приходят в голову. Фокус — на позитивных сценариях. Каждое событие формулируется в прошедшем времени (заказ оформлен, оценка получена и т.п.). Порядок и структура не важны, фиксируем всё без фильтрации.

• Шаг 2: Выстраивание событий в хронологическом порядке. Упорядочиваем все собранные события в хронологическом порядке. Проверяем логичность последовательности; читаем цепочку слева направо и наоборот. Ориентируемся только на то, что написано на стикерах.

• Шаг 3: Поиск ключевых событий. Выбираем ключевые события. Определяем наиболее важные события с точки зрения бизнеса. Эти события влияют на ход процесса, меняют состояние системы, разделяют модель на смысловые блоки. Их укрупняют или выделяют, как правило, они определяют Bounded Context.

---

Надеюсь, что этот конспект пригодится не только мне. :) Если кто-то использовал или использует Event Storming (или иную форму визуальной нотации), предлагаю поделиться своим опытом. ;)