Решил разбить статью на n-частей, чтобы не плодить простыни. Здесь речь пойдет о том, что такое Event Storming и зачем он нужен.
Эрик Эванс, систематизировав и описав свои знания дал нам мощный инструмент, позволяющий через формализацию архитектуры крайне сложные информационные системы, с большой скоростью поддерживающие изменчивость бизнеса в его развитии.
Первая книга Эванса в 2004м году крайне сложна для понимания(как выяснилось?), плюс, при всей своей проработанности, весьма странна скомпонована и идет от стратегии к тактике. Выход книги Вон Вернона "Реализация методов предметно-ориентированного проектирования" понимание DDD малость упростила, но саму методику не упростило и разу. Заканчивая с книгами, книга Влада Кононова упростило понимание понятий максимально, но основной проблемы не решило.
Основных проблем DDD по моей версии две:
Первая. Применение методики на практике. Как видя перед собой огромный ком грязи, как подступиться к нему и начать отделять корректные слои системы или ландшафта?
Вторая. Как встроить практики DDD в процесс разработки. Ни раз уже в этом блоге упоминал, что архитектурные практики не встроенные в процесс разработки являются относительно мертвым накоплением знаний.
И тут как из пещеры на лыжах появились два персонажа: Джеральд Вассерман, который в 2014м году придумал Event Storming и Альберто Брандолини, который активно включился в продвижение ES, разработку шаблонов, организацию методик, обучения и стал развивать консалтинговые практики на базе ES.
Так, что же такое Event Storming?
ES - это методология, паттерн, если хотите. Нужен для анализа и моделирования сложных бизнес-процессов в организации. Этот метод позволяет быстро создать общее понимание системы среди различных заинтересованных сторон, улучшить коммуникацию между отделами, выявить скрытые проблемы и узкие места в процессах, а также стимулировать творческое мышление и генерацию новых идей.
Основные цели Event Storming:
- Быстрое создание общего понимания: Event Storming помогает участникам с различным опытом и знаниями достичь единого видения бизнес-процессов. Это особенно важно в командах с разнородным составом, где традиционные методы могут быть неэффективны.
- Выявление скрытых проблем: Визуализация процессов с помощью цветных стикеров позволяет обнаружить неочевидные проблемы и узкие места, которые могут быть упущены при использовании традиционных методов анализа.
- Стимулирование творческого мышления: Интерактивный формат мероприятия способствует генерации новых идей и инновационных решений. Это помогает участникам выходить за рамки привычных подходов и находить более эффективные способы выполнения задач.
- Улучшение коммуникации: Event Storming способствует улучшению коммуникации между различными отделами и заинтересованными сторонами. Совместная работа над моделью бизнес-процессов помогает устранить недопонимания и наладить более эффективное взаимодействие.
- Гибкость и масштабируемость: Метод может применяться как для анализа отдельных процессов, так и для моделирования целых систем. Это делает его универсальным инструментом для различных уровней детализации и сложности проектов.
Преимущества использования Event Storming:
- Повышение эффективности разработки: Благодаря быстрому созданию общего понимания и выявлению проблемных областей, Event Storming ускоряет процесс разработки и внедрения новых решений.
- Качество решений: Улучшенная коммуникация и более глубокое понимание процессов способствуют созданию более качественных и эффективных решений.
- Итеративный подход: Event Storming предполагает возможность итеративного подхода, что позволяет вносить изменения и улучшения на основе обратной связи и новых идей.
Из своего опыта могу сказать следующее: ES оказался невероятно полезен, не только в части майнинга информации о процессах и их составных частей, но и в построении надежных коммуникаций с бизнесом. Бизнес-заказчики очень активно включаются в процесс взаимодействия внутри ES и практически с первых сессий начинают жить в нем. Ещё раз - это основная ценность ES, по моей версии. Отсутствие единого языка и понимания предметной области плодит невероятное количество значимых рисков в разработке, особенно, если в разработки итерации поставки длятся значительное время.
Мне кажется, что ES создает уверенность у обоих сторон: продуктовой разработки и стейкхолдеров в том, что разработка точно понимает заказчиков, а заказчики точно знают, что их слышат.
Еще нюанс для апологетов Ajile. Гибкие методологии часто или почти всегда подразумевают, что разделения между бизнесом и ИТ нет, что это одна команда . В которой ИТ и бизнес равнозначно несут ответственность за результат. Так вот ES, через свои сессии позволяют размыть границу между заказчиком и исполнителем.
Немного академической нудятины.
Основные элементы Event Storming:
- Доменные события: Ключевые изменения состояния в системе, обозначаемые оранжевыми стикерами. Примеры: «Заказ размещен», «Платеж получен», «Товар отправлен».
- Команды: Действия, вызывающие доменные события, обозначаемые синими стикерами. Примеры: «Разместить заказ», «Подтвердить платеж», «Отправить товар».
- Агрегаты: Группы связанных объектов, обрабатываемые как единое целое, обозначаемые желтыми стикерами. Примеры: «Заказ», «Корзина», «Учетная запись пользователя».
- Модель чтения: Информация, необходимая для принятия решений в системе, обозначаемая зелеными стикерами. Примеры: «Список заказов», «История платежей», «Статус доставки».
- Ограниченный контекст: Логические границы в системе или решении, где определенные термины и концепции имеют специфическое значение, обозначаемые большими прямоугольниками.
- Бизнес-правила: Ограничения или условия, которые должны соблюдаться в системе, обозначаемые фиолетовыми стикерами.
При этом Event Storming может и должен делиться на уровни детализации.
- Уровень системы (big-picture):
Определение ключевых событий в системе или решении.
Расположение событий в хронологическом порядке.
Добавление команд, вызывающих события.
Определение агрегатов и моделей чтения.
Выявление ограниченных контекстов и бизнес-правил.
Обсуждение и уточнение модели с участниками. - Уровень процесса:
Сосредоточение на конкретном бизнес-процессе.
Детализация событий и команд в рамках этого процесса.
Выявление потенциальных проблем и узких мест.
Предложение улучшений и альтернативных решений. - Уровень дизайна:
Использование результатов предыдущих этапов для проектирования системы.
Определение ключевых сущностей и их взаимосвязей.
Проектирование интерфейсов и API.
Обсуждение технических решений и архитектуры.
Эти уровни детализации позволяют постепенно углубляться в анализ, начиная с общего понимания системы или решения и заканчивая конкретными проектными решениями, что делает Event Storming мощным и гибким инструментом в управлении бизнес-процессами и разработке программного обеспечения.
Как организовать Event Storming:
- Определение целей: Четко сформулируйте цели сессии Event Storming, будь то анализ существующего процесса, проектирование нового решения или выявление проблемных областей.
- Выбор участников: Пригласите представителей всех заинтересованных сторон, включая экспертов предметной области, разработчиков, аналитиков и представителей бизнеса.
- Сбор материалов: Подготовьте необходимые материалы: большой лист бумаги или доску, цветные стикеры, маркеры разных цветов.
- Создание комфортной среды: Обеспечьте просторное помещение с достаточным количеством места для передвижения участников и размещения материалов. Ну а в нашей жизни удаленной работы - подготовьте гарантированно рабочие инструменты коллективной работы, включая общедоступною борду.
- Брифинг перед Event Storming: Проведите краткий инструктаж для участников, объясняя цели сессии и основные принципы Event Storming.
Ну а дальше вы берете и клеите стикеры. либо: на физическую доску, либо на борду в Miro или любом другом инструменте.
Про эффективность сессий, на что стоит обратить внимание:
- Фокусироваться на событиях, а не на решении и тем более, не на технологиях.
- Как фассилитатор, поощряйте активное участие.
- Обязательно установите роль фассилитатора для соблюдения рамок сессий и оркестрирования процессов в них.
- Сессии обычно длятся от часа и более, имеет смысл делать короткие перерывы для сохранения внимания участников.
- Перед каждой сессией устанавливайте цели и образ результата. Формируйте план по сессиям и корректируйте его по результатам каждой итерации.
Про то, как на практике организовать сессии ES я опишу в следующей статье, в этой, подсвечу ряд нюансов методологии, которые надо осознать "на берегу".
Движение без цели - не имеет смысла.
Как и в любой активности, основной мотивирующей составляющей этой активности является её цель. При этом не только ваша, но и всех основных участников.
А цели у участников разные, если вы, как архитектор, решаете свои проблемы, то бизнес и продуктовая разработка свои и различные, при этом, цели. В связи с этим, перед запуском Event Storming'а стоит эти цели сформулировать и согласовать.
Для стейкхолдеров и run-команд основной бенефит- это прозрачность бизнес-процессов и прозрачность изменений, но эта цель не очевидна. Не буду углубляться, стоит просто поверить. Адекватной целью для бизнес-заказчика может являться выпрямление коммуникаций с ИТ, как следствие: сокращение ТТМ и управление ожиданиями.
Для команд продуктовой разработки основной ценностью для продуктовых команд, очевидно является ультимативная актуализация требований.
Повторюсь: без общей атмосферы безотлагательности и мотивированности всех участников, в силу трудоемкости первых итераций, есть шанс, что активность ES быстро сойдет на нет..
Не явное следствие этого пункта: ограничения, которые по моему мнение, есть у области применимости ES. ES однозначно подходит для практики продуктовой разработки, но слабо подходит, например, для исследования систем, решений. ландшафта в целях аудита.
Неактуальная документация вреднее, чем её отсутствие.
Нужно помнить, что любая архитектурная документация, как минимум, используется в двух процессах: поддержка принятия решения и тестирование - проверка требований. Последний пункт может выражаться не только в непосредственном тестировании, но и в проверке качества реализации или достижения бизнес-целей через метрики или синтетические фитнес-функции.
Тоже самое и с Event-Storming, если карты ES не обновляются с каждой итерацией или на постоянной основе, то двум выше обозначенным целям они удовлетворяют слабо.
ES может использоваться не только в итерациях бизнес-инкремента, когда каждая новая фича проходит через сессию event-stormig'а. Например, ES может применяться только в сложных или масштабных случаях, например, запуска новых или рефакторинга существующих бизнес-компетенций (business capability). но тогда ограничения полученных артефактов должны четко фиксироваться.
Выбор и установка масштаба.
Как было описано выше, ES может описывать решение или систему с разной детализацией. Кроме того ES может содержать не все базовые элементы. Как пример, big-map может содержать в себе только события, связь между ними и деление на контексты. Это позволит управлять событийной моделью предприятия, что уже само по себе несет невероятную ценность.
По этому, стоит сразу выбрать модель ограничений и использования, чтобы не перегружать модели излишней информацией.
Роли и подготовка.
Подразумевается, что каждый участник сессии будет непосредственно принимать участие в процессе построения моделей. К сожалению в 99.99% случаев это не возможно, будьте готовы к тому, что основным человеком, который будет лепить стикеры - будите вы. Задача организатора: зафиксировать ограничения и требования к стикерам и вовлечь участников в процесс, хотя бы с точки зрения валидации модели. Так же, организатор должен поддерживать и оркестровать дискуссию. Если дискуссии нет и все со всем согласны, значит, что-то пошло не по плану.. )
В следующей статье, приведу последовательный пример организации процесса Event-Storming-а при решении какой-то абстрактной масштабной задачи.