При этом мы вполне можем использовать полученную модель внутри команд разработки, чтобы моделировать компонентную модель, но первичные данные мы получаем от 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) разработчиков.»

Сравнение Event Storming и Service

Кто хочет немного разобраться в Service Blueprint.

Service Blueprint – это техника проектирование точек контакта клиента с услугой, продуктом или компанией. Визуализация включает в себя сценарии использования, точки касания, видимые клиенту (интерфейсные решения) и точки касания, не видимые клиенту (внутренние системы). Может использоваться для оцифровки текущих процессов и опыта клиентов.

1. Основополагающая статья, с нее все началось: https://hbr.org/1984/01/designing-services-that-deliver

2. Более современное описание подхода к созданию Service Blueprint: https://divergentthinking.design/service-design-blueprint-workshop

3. Описание из Open Agile Architecture: https://pubs.opengroup.org/architecture/o-aa-standard/journey-mapping.html

4. Хорошая презентация с описанием: https://static1.squarespace.com/static/5697b3bea2bab855798833c2/t/5c5f828f15fcc09ae50ab741/1549763255171/Blueprint-Workshop+Final+Web.pdf

Финальные аккорды 🧐

Думаю, будет полезно опубликовать ответ здесь.

Привет, хочу провести сессию Event Storming, но не уверен что до конца понял его. Есть какие нибудь референсы, чтобы потренироваться, по типу: вот задание и ответ, сделай по заданию и сверь с ответом?

Боюсь, что такого не будет, это ведь исследовательская практика, а каждая предметная область – уникальна в своем представлении в голове каждого конкретного человека и цель – построить общую, непротиворечиваю, согласованную ментальную модель, а обозначения в event storming – удобный способ фиксации этой единой ментальной модели. Обсуждения, мысли, идеи, дополнительный контекст все равно остаются в головах, но теперь в синхронизированном состоянии.

У меня есть в тренинге по Event Storming несколько заданий, в которых дается уже готовая модель и в ней нужно найти антипаттерны, вроде «множественное толкование», «скрытый смысл», «нарушение симметрии» и прочие, в беклоге есть на правах идеи оформить это в статью, а может будет проще и удобнее в видео, но это будет точно не в этом и не в следующем месяце.

Для тренировки можно, например, загуглить уже готовые примеры результатов, скопировать хоть картинку к себе на лист миро и везде, где есть подозрение на скрытую сложность формулировать на стикерах вопросы и размещать их рядом с тем местом, где вопрос возник. Это немного подготовит к проведению сессии. Вопросы желательно формулировать полные, не просто «А что здесь написано?», а «Событие Документы Загружены может содержать скрытую сложность, какие именно документы загружены?». Для того, чтобы было проще нужно постараться поставить себя на место человека, которому нужно написать по этой модели код (если мы говорим про разработку). Код не терпит двусмысленностей, он выполняет определенный алгоритм и если из формулировки не ясно (не непонятно, а именно не одно не понятно), как это реализовать, то есть «можно так, а можно же и так», то модель должна быть уточнена для избавления от подобных предположений.

Ответ Альберто Брандолини, изобретателя Event Storming, на вопрос «What, in reference to DDD, is a bounded context?»

Bounded Contexts and Subdomains exist at different levels.

A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organisation. So logistics and operations might be separated from invoicing & billing. Eric differentiates core, supporting and generic subdomains according to their business relevance in the given scenario.

Contexts are portions of the solutions space. They're models. It would be a good thing to have them, reflect the domains-subdomains partitioning ...but life isn't always that easy. And you might have bloated legacy domain encompassing everything, or more context in the same subdomain (i.e. old legacy app the replacement app somebody is building).

To have a Bounded Context you need to have a model, and an explicit boundary around it. Exactly what's missing in many data-driven application that use databases to share data.

Another - orthogonal - way to see it may be the following. Ubiquitous Language, the special condition where every term has a single unambiguous definition, doesn't scale. The more you enlarge it, the more ambiguity creeps in. If you want to achieve precise, unambiguous models, you need to make their boundaries explicit, and speak many little Ubiquitous Languages, each one within a single Bounded Context, with a well defined purpose.

Почему разработчики не играют в “правда или действие" после сессии Event Storming?
Потому что правда уже на стикерах, а действия в плане 👌

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

Под гранулярностью будем понимать объем деталей и информации, передаваемой посредством событий.