Меня зовут Александр Донсков и я архитектор в компании REG.RU. Сегодня я расскажу о том, что такое Event Storming и что будет, если запереть 10 человек в одной комнате (в том числе виртуальной). 

Цель статьи не столько в том, чтобы рассказать, как это работает, сколько показать действенность подхода на реальных кейсах. Я проводил Event Storming 4 раза с разными командами. Чтобы объяснить участникам смысл происходящего, для каждой команды перед началом мероприятия я делал презентацию. Но оказалось, что пока не начнешь таскать карточки, выстраивать бизнес-процессы и накидывать акторы ― объяснить процесс практически невозможно. 

Что такое Event Storming

Альберто Брандолини, который придумал Event Storming, описывает его так: это способ собрать вместе разработчиков и представителей бизнеса для совместного исследования предметной области и потратить на это «часы вместо дней и недель». По факту, это возможность спроектировать систему в виде бизнес-процессов и разделить ее на ограниченные контекстные модули, из которых впоследствии можно построить архитектуру. 

Вот пример того, как выглядят бизнес-процессы, которые протекают внутри наших сервисов:  

На схеме результат Event Storming’а c командой, которая эти сервисы поддерживает. Понимаю, что ничего не видно и не понятно. Позже я подробно расскажу об этой работе и ещё двух других. Но сначала поговорим о том, кто нужен для проведения Event Storming-сессии. 

Кого позвать на Event Storming

Нам нужны: 

  • представители бизнеса ― ПМ, аналитик, техподдержка, отдел продаж и др.;

  • представители разработки ― backend, frontend, архитектор и др.;

  • фасилитатор процесса.

Во всех примерах из статьи я выступал в роли фасилитатора. Так как я еще и архитектор, сначала получалось не очень: фасилитатор не должен высказывать своё мнение, а мне не всегда удавалось сдержаться. В такие моменты главное вовремя себя остановить, чтобы дискуссия не перешла в полемику. 

Теперь немного о том, из чего состоит Event Storming и через какие нужно будет пройти.

Из чего состоит Event Storming

Вот базовые блоки: 

  • события;

  • агрегаты ― сущности в ограниченном контексте. Например, корзина или товар на витрине;

  • акторы ― те, кто пользуются событием или являются его заказчиком. Например, пользователь, менеджер, разработчик, скрипт или внешний вызов API;

  • действия ― то, что мы рассматриваем как бизнес-процесс. Например, покупка продукта клиентом на сайте. В случае этого бизнес-процесса действия ― это всё, что происходит с того момента, как клиент зашел на сайт, и до того момента, когда он положил товар в корзину.

Сама сессия Event Storming’а проходит в несколько этапов.

Этап 1. Шторминг событий 

На этом этапе генерируются все возможные события: клиент зашел на сайт, клиент нажал на кнопку «Положить в корзину», клиент нажал на кнопку «Перезапустить сервер». В общем, генерим всё, что приходит в голову. Для каждого события клеим/добавляем на доску стикеры:

Исходя из собственного опыта, хочу сказать, что людям, которых мы собрали на шторминг, тяжело сфокусироваться на чем-то конкретном из-за большого количества всевозможных событий. Каждый только и думает, за что взяться и с чего начать. Это происходит, даже если вы провели предварительную мини-презентацию с рассказом о том, что и как делать. Чтобы избежать расфокусировки, советую направлять участников при помощи связанных между собой событий или определенных направлений. Например: 

  • что происходит в корзине и какие там есть события, 

  • какие события могут быть в личном кабинете у услуги домена, 

  • какие события могут быть при оплате и т. д. 

Это позволит сразу сконцентрироваться на чём-то конкретном, вместо того, чтобы пытаться охватить и вспомнить всё, что есть.

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

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

Этап 2. Разбор событий в хронологическом порядке 

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

Этап 3. Добавление акторов, действий и агрегатов

Достаточно сложный этап из-за понимания такой сущности, как агрегат. Это понятие может оказаться достаточно сложным в понимании и для бизнеса, и для разработки. 

Пример:

Где:

  • «Выбрал товар», «Добавил в корзину» и «etc» ― это события;

  • «User» ― актор, который инициирует событие;

  • «Покупка» ― действие;

  • «Витрина», «Корзина» и «Агрегат» ― агрегаты. На их основе в дальнейшем будем строить ограниченные контексты, группировки и т. д. 

Этап 4. Работа с результатами 

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

Это, в принципе, и есть вся основа Event Storming.

Чем полезен Event Storming

Самая главная польза Event Storming ― это синхронизация между бизнесом и разработкой. Когда вы проговариваете все бизнес-процессы, которые у вас есть, вы:

  1. Формируете общий для бизнеса и разработки словарь.

  2. Даете разработке понять, что хочет бизнес, а бизнесу понять разработку и ограничения системы. 

  3. Формируете определение и структурное разделение сущностей системы на модули:


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

  4. Дизайните бизнес-процессы. Все понимают, что и как происходит, и обо всём договариваются:

  5. Быстро оцениваете сущность, ее важность, зависимости и сложности. Например, бизнес хочет, чтобы разработчики сделали ракету. Но тесный контакт с разработчиками даёт понять, что ракету не построить, а бизнесу вполне подойдет бумажный самолётик. 

  6. На основе готовой карты легко смоделируете будущие изменения архитектуры и бизнес-процессов. У вас будет карта, которая содержит цепочки событий, и по ним можно увидеть, какие у событий есть зависимости:

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

  7. Визуально поймете, какие узкие горлышки есть у архитектуры и бизнес-процессов:

    Бизнес поймет и решит, что есть какие-то лишние манипуляции, а разработка сразу объяснит, лишние они или без них, наоборот, никак, так как от этих событий зависят другие события в будущем. В архитектуре тоже будет видно, если система построена не очень хорошо. Может быть, слишком много связанности и зависимостей у модулей, или они отвечают за слишком большое количество действий и нет разграничения по контексту. Как, например, какая-нибудь ручка, которая отвечает и за клиентскую работу, и за админскую, и за менеджерскую. 

А теперь к реальным примерам. 

Event Storming системы заказа серверов с нуля

Это наша самая большая работа:

Делали мы ее составом из 10 человек на протяжении примерно 3 месяцев. Собрать всех хотя бы на 3 часа было достаточно проблематично из-за плотного графика каждого участника. 

Тут еще раз стоит уточнить, что мы собирались в онлайне. Конечно, эту систему придумали для проведения офлайн-мероприятий и в любой методичке по Event Storming'у вам посоветуют именно такой формат. И да, подтверждаю, лучше собраться вживую. Но из-за удалёнки и географической распределенности участников мы делали, что могли и как могли.

Вернемся к карте. Эту систему мы проектировали с нуля. У нас есть базовые блоки: система 1C, система Битрикса и наша кастомная логика, которой не существовало и которую нужно было реализовать на уровне Python-сервисов. Плюс ко всему у нас есть бизнес-процессы.

Мы видели, что есть пользователь со своим набором полей, который имеет свои договоры с нами как с поставщиком. Вроде всё понятно: есть пользователь и его, наверное, стоит засунуть в Битрикс, потому что там пользователи тоже есть. Мы разобрали бизнес-процессы и поняли, что в Битрикс это вообще не влезает и это отдельная сущность, за которую должны отвечать отдельные люди и должны это делать вне Битрикса через отдельный модуль.

Также мы разграничили зоны ответственности команд и выяснили, за что отвечает команда Битрикса, команда 1С и команда, которая пишет на Python. После чего мы смогли построить зависимости и связи. Стало понятно, как выгружать товары, как проводить платёжки по заказам, где брать договоры и т. д. 

Перед началом мероприятия у нас не было ничего, кроме 100 страниц бизнес-требований, трех команд с разными сферами ответственности и маленьким пониманием того, за какую конкретно часть какая команда отвечает. Никто не понимал общий объем работ и схему взаимодействия. 

Когда мы завершили Event Storming, каждая команда получила представление о том, что должна делать, где нужно договариваться, и вообще жизнь у ребят стала лучше. Всё было сделано с нуля, у нас не было каких-то готовых решений. За это время разработка поняла, что хочет бизнес, а бизнес понял, какие есть технические ограничения в этой системе. Я думаю, что все остались в выигрыше. 

Event Storming существующей системы

Второй пример нашей работы: 

Если первый пример мы создавали с нуля, то в этот раз условия были другие. Это уже существующая, рабочая и вообще замечательная система облачных серверов. Так зачем же её прогонять через Event Storming? Цель заключалась в том, чтобы составить карту продукта, на её основе спроектировать техническое развитие продукта и получить возможность внесения каких-то глобальных изменений на фоне меняющейся конъюнктуры и требований к системе. 

Мы провели шторминг и закончили за 5 созвонов по 3 часа. И вот какие результаты мы получили, помимо карты продукта:

  • появилось понимание по агрегатам, 

  • синхронизировались по терминам (была путаница во время шторминга),

  • нашли узкие горлышки (например API-ресурсы, которые умеют всё на свете). 

Выводы сделаны, работа над картой продолжается. 

Event Storming системы без документации

И третий пример, который сейчас в работе:

Это Domain service, который представляет собой легаси-код. Он определяет доменную услугу, что она делает, какие у неё внутри бизнес-процессы и всё такое. Давным-давно за этот сервис отвечала только одна команда. Сейчас им занимаются ребята из новой команды. Единственная корректная всеобъемлющая документация ― это код. Разработчики не могли в полной мере ответить на все вопросы. Бизнес тоже не мог. Было тяжело вытаскивать требования и формировать общую картину того, что мы будем делать. Мы еще не закончили и продолжаем работу. 

Цель ― понять основные бизнес-процессы, определить связи и зависимости, определить акторов, разделить по ним бизнес-процессы и спроектировать архитектуру. Домены ― это сложно и много нюансов. Все нюансы мы не могли и не стали разбирать. Мы прорабатываем процессы над сущностями, чтобы понять, что же нам делать. К участникам приходит понимание, и пока всё нравится. С одной стороны, всем становится легче, но с другой – мы понимаем весь объем работы и он немного пугает. 

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

Теперь поговорим о том, что Event Storming не может заменить. 

Что не заменяет Event Storming

  • БТ, ТЗ и другую документацию. Конечно, если вы работаете над небольшой фичей, то наверняка сообразите, куда шлепнуть код, где соединить, и пойдёте дальше. А если это уже что-то более-менее серьезное, то без бизнес-требований, техзадания, контрактов и другой документации вы, скорее всего, попадете в производственный ад;

  • аналитику процессов. Вы можете накинуть что-то на шторминге, но в итоге какие-то события нужно будет убрать: что-то слишком сложно, что-то слишком дорого, а что-то не соответствует вашей маркетинговой стратегии. Поэтому без аналитики никак;

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

Комментарии (0)