Event Storming помогает снизить эффект иллюзии прозрачности.

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

Перед нами, как архитекторами, во многих ситуациях стоит выбор: переписать или постепенно улучшать.

Например - устаревший код (тотальное легаси), желание уйти от вендора или хотя бы снизить зависимость от него, изменение классификации доменов (что раньше было supporting стало core), устаревание технологий (как-то с менфреймов выводили в java, так как ibm перестал их поддерживать).

Все эти кейсы объединяют две вещи:
- огромные объемы накопленной скрытой сложности
- отсутствие сколько-нибудь адекватного описания функционала, который реверс инжинирингом восстанавливать можно несколько лет

То есть, обращаю внимание, что иногда не стоит вопрос переписывать или нет, - стоит вопрос как снизить косты и риски при замене системы (когда идет замена на самописное, а не на новый cots).

И вот тут:
- event storming позволяет быстро, не оглядываясь на текущую систему, получить структуру, беклог, фичи, тесткейсы и так далее
- ddd помогает разложить по полочкам (по коду) получившуюся модель

К слову, финансы/инвестиции тоже часто ограничение. Но если этого ограничения нет (жизнь многогранна), то стоит порадоваться более широкому окну возможностей, потому что чаще бывает наоборот.

Если нужно не просто заменить систему, но взамен существующей легаси или cots написать свою, то EventStorming может, как точно выразился Борис Романов помочь как «методика, которая предсказуемым способом и в предсказуемые сроки позволяет получить довольно достоверную структуру предметной области, которая позволяет строить функциональную и модульную архитектуры не на "ощущениях", а не чем-то более обоснованном.»

Всем привет, есть новости 🙂

14 апреля в онлайн формате проведу на AgileDays воркшоп по Event Storming.
И спокойно 15 апреля пойду праздновать день рождения 🙂

А кто будет 21-го апреля очно, пишите в личку или в комментарии, соберемся/встретимся, можем и спонтанное обсуждение насущных вопросов устроить.

A Metrics Suite for Microservices, EventStorming and DDD 👍
Measuring Coupling and Cohesion of Bounded Contexts on an EventStorming Domain Model

https://phillipjohnson.co.uk/a-metrics-suite-for-microservices-eventstorming-and-ddd

На сессии Event Storming мы можем столкнуться с противоречием. Два SME утверждают разное об одном и том же факте.

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

Цель в том, чтобы найти различия в определении факта и разнести их по разным контекстам, где противоречий не будет, а не доказать правоту одного из SME.

В Event Storming противоречие – намек на то, что вы нашли несовместимые концепции в сущности, которую рассматривали до этого как целостную и согласованную.

В статье дается ответ на вопрос, что такое Event Storming, из каких строительных блоков он состоит и как эти строительные блоки увязываются в единый процесс.

https://agilemindset.ru/что-такое-event-storming/

Еще инструмент подъехал
https://www.msaez.io/

Описание
https://intro.msaez.io/tool/event-storming-tool/

Будем посмотреть.
Судя по описанию оно там как-то умеет сразу в код.

Пришло время вебинаров 🙂

Я заметил, что Event Storming набрал обороты и все в большем числе компаний начинают его применять.
Но нередко изначальная идея теряется.

Напомню, что основная идея – это исследование сложной предметной области и формирование общей ментальной модели между участникоами. Я много выступал сс темой того, что еще можно получить из Event Storming, как можно посотроить микросервисное решение используя эту технику и она стала восприниматься как механизм для построения микросервисов, хотя это в большей степени side effect.

Чтобы построить микросервисное решение не обязательно использовать Event Storming. Можно использовать и другие техники проектирования, Event Storming дает single source of truth в виде Domain Events, которые мы можем обогатить другими метаданными (команды,агрегаты,ограниченные контексты), чтобы получить целевую архитектуру в итоге.

Чтобы получить single source of truth нам нужны эксперты в предметной области, нужны в одном месте, чтобы в диалоге между собой они смогли увидеть различия между пониманием и поведением в рамках одних и тех же процессов и сущностей. То есть избавиться от множественного толкования одних и тех же терминов, поместив конкретные термины в собственные контексты. И вот тогда у нас начнут вырисовываться те самые границы контекстов.

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

Вот может об этом и стоит собрать встречу и пообщаться?

При этом мы вполне можем использовать полученную модель внутри команд разработки, чтобы моделировать компонентную модель, но первичные данные мы получаем от SME (subject matter experts). Альберто называет это «люди с вопросами и люди с ответами». Сверху имено цитата Альберто.

Собрал структурированную базу знаний по микросервисам на основе своих статей и переводов.

https://agilemindset.ru/микросервисы/

11 апреля в 19:00 здесь (telegram) проведу стрим по участникам Event Storming

- кто нужен
- где их искать
- что делать, если не могут
- что делать, если не хотят
- ответы на ваши вопросы

Вопросы можете писать заранее в тред к этому сообщению.

Все готово.

В 19:00 старт, постараемся уложиться в 30-45 минут.

Запись стрима о том, кого приглашать на сессии Event Storming
https://www.youtube.com/watch?v=PVH8RwG9EH4

Miro-доска из стрима
https://miro.com/app/board/uXjVMURLTB4=/?share_link_id=199133005609

В тему этой сессии, если кому-то интересно, то у меня есть практический однодневный курс по теме управления ожиданиями стейкхолдеров, пройдет 29 мая.

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

Многое из того, о чем говорю в стриме разбираем уже на практике в малых группах.

Для event storming эти знания особенно важны, так как мы помним, что «An Event Storming is only successful if the right people are involved» 🙂

Иногда есть такой этап - этап ревью требований.

На этом этапе задача ревьюеров (разработчиков, тестироващиков) в том числе проверить описанное в документе требований на полноту и непротиворечивость.

Тут есть загвоздка.

Анализ проводил не тот, кто ревьюит, для ревьюера обычно документ требований – это и есть вся информация о требованиях. То есть для него не существует иформации за пределами документа, а значит по-определению для его восприятия описанное в документе будет обладат полнотой.
Чтобы проверить документ требований на полноту, все ревьюеры должны принимать участие в сборе требований, чтобы обладать ровно тем же объемом информации (полнотой понимания), что и человек, подготавливающией документ.
Одна из таких практик, формирующих общий state of the mind, общее понимание предметной области, как раз event storming.

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

По модели, полученной с помощью Event Storming можно определить сложность предметной области. В общем случае – это число событий, Очевидно, если в какой-то модели 1500 событий, то она значительно сложнее модели с 50-ю событиями. Конечно, DDD позволяет нам этой сложностью управлять, мы находим границы поддоменом, формируем ограниченные контексты. И поддомены/ограниченные контексты так же можно оценить по уровню сложости по объему терминов, входящих в границу, событий, команд, сущностей.

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

И вот, обращается клиент, – все медленно, просто жуть, никто ничего не понимает, все по учебнику.

Проводим Event Storming, исследуем предметную область. Она простая, даже отчасти примитивная. Строим карту контекстов и проставляем связи так, как есть сейчас, а сверху накладываем текущую организационную структуру и там просто провал 🙂 Несмотря на простейшую предметку 80% времени уходит на коммуникацию, координацию, управление зависимостями. Фактически – очень простая реорганизация структуры команд должна привести к ускорению почти на порядок (мы пока этого не знаем, потому что все только начинается).

А все дело в том, что было 7 команд и 4 ограниченных контекста (ну так мы построили, не факт, что структура окончательная) и ни одна команда не могла самостоятельно закрыть собой развитие какого-то отельного контекста. То есть всегда требовалось от 2 до всех 7 команд, чтобы внести изменения в один контекст. Это при том, что в 1 команде были компетенции, чтобы полностью поддерживать один из контекстов, но логические границы (зоны ответсвенности/владения, если будет угодно) были установлены так, что они заводили на другую команду доработки.

К чему я это написал?
Предметная область может быть сложной, может быть простой, но нельзя забывать и про социальную/технологическую сложность. Простым проблемам - простые структуры и простые технологические решения. Конечно, без понимания предметной области никуда не дется, это база, фундамент, но не всегда необходимо проводить кардинальные изменения, иногда чтобы стать быстрее бывает достаточным сократить и перегруппировать количество людей/команд и может случится магия, а иногда можно упростить/заменить используемые технологии/библиотеки/решения на более простые и этим, убрав избыточную сложность, сократить время прохождения задач через весь цикл разработки.

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

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

Чем ниже актуальность документов, тем выше вариативность ментальных моделей среди сотрудников.

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

Та самая цитата еще с 2015-го года.

То, что Альберто «once said», – «в прод идут не знания экспертов в предметной области, в прод идут предположения (assumptions) разработчиков.»