В прод идут не знания экспертов в предметной области, а предположения разработчиков (с) Альберто Брандолини

Как Асхат Уразбаев сформулировал для себя понимание Event Storming (в том числе применительно к LeanDS (https://t.iss.one/leands))

Основная задача и суперспосбность —быстро, за несколько часов, создать полную картинку того, как устроен бизнес компании (предметная модель бизнеса).

Предметная модель бизнеса позволяет, как пример:

* Создать бэклог для сложного трасформационного эпика
* Создать бизнес-глоссарий (центральное понятие в Data Governance)
* Спроектировать микросервисы внутри организации
* Моделировать потоки данных в организации
* И т.д.

Для подписчиков канала скидка 20% на конференцию ArchDays по промокоду microservices_arch

https://archconf.ru/welcome_from_sergey

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

Расскажу подробнее в следующих постах.

Разбирал старые доски Miro и наткнулся на старый вопрос от 15 ноября 2020 из какого-то чата (может автор и здесь) и там же разбор этой задачи в виде event storming.

Звучал вопрос так:

Задачка: есть покупатель, рейтинг(получает за каждую покупку либо + либо -), покупки(успешные и неуспешные), уровень покупателя, опрос.
Если у покупателя кол-во успешных покупок > 200 и рейтинг более 5 то мы должны ему дать опросник.
Опросник тоже может быть done / failed(неправильные ответы). После этого он только через день сможет ответить на вопросы заново.
Внимание вопрос: где и как это делать?  
Учитываем что кол-во успешных покупок не уменьшается. Но я не могу придумать хорошего варианта

Event Storming нашел для себя еще одну нишу. Сейчас идет очередной проект по исследованию business capability с целью стартовать разработку собственных систем взамен отдельных модулей ERP и прочих систем со сложнейжей предметной областью.

Вижу в этом и плюсы и минусы.
Плюсы:
- системы максимально адаптированы к предметной области компании
- системы могут максимально быстро изменяться вслед за изменением бизнеса компании
- отсутствие зависимостей от внешних вендоров («сделайте нам вот это»)
Минусы:
- обычно это действительно сложные системы, и если у каждой компании будет своя разработка, то сотрудникам при переходе из одной компании в другую придется обучаться использованию новой системы
- разработчикам при переходе из компании в компанию потребуется больше сил и времени на погружение (это уже не SAP/ABAP Developer, а Java Developer)
- сложности с внешним аудитом - большие и тяжелые ERP и иже сними выравниваю процессы компании и облегчают прохождение внешних аудитов, дают унификацию внутри компании по части отчетности (как пример)

И я напомню, что речь о системах, с кототрыми работают тысячи человек различной компетенции в сотнях (тысячах?) компаний.

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

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

Зачем?
Дело все в том, что для участника Event Storming выглядит очень простым, но от ведущего требуется четкое понимание целей сессий, как этих целей достигнуть, почему и как проявляются те или иные паттерны и как с ними работать.

Регистрация тут:
https://scrumtrek.ru/product/226/obuchenie-provedeniyu-event-storming-v-onlayn/

При этом для успеха сессии критически важно пригласить нужных людей, а это не всегда просто (но почти всегда возможно). Не стал включать в курс блок про управление ожиданиями стейкхолдеров (потому что это все-таки за скобками самого метода), но так как эта тема важна и несет ценность сама по себе, можно отдельно сходить на интенсив «управление ожиданиями стейкхолдеров»:
https://scrumtrek.ru/product/266/upravlenie-ozhidaniyami-steykholderov/

Кому интересно, приходите, в комментариях готов поотвечать на вопросы 🙂

В рамках управления ожиданиями стейкхолдеров, а в большей степени - практикам stakeholders alignment, разбирали и принципы работы с ними (на базе IASA bok):

Учитывать мнение стейкхолдеров
- Стейкхолдеры захотят повлиять на развитие ситуации в свою пользу
- Мнения различных стейкхолдеров могут конфликтовать между собой
- Важно знать, какие стейкхолдеры несут максимальную пользу в выполнении задачи

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

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

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

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

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

Есть такая важная, популярная практика: матрица интерес-власть

Она дает основу, с которой можно начать работу со стейкхолдерами.

План проведения
Предусловие
– Должен быть фокусный контекст: задача, аспект деятельности
– Все участники должны хорошо разобраться в контексте перед началом воркшопа
Шаг 1: Выявление стейкхолдеров
- Начинаем с 10 минут, если динамика работы сохраняется – увеличиваем время; здесь найти максимум важнее, чем выдержать тайминг
- Индивидуально
- Один стикер - один стейкхолдер
- Не советуясь друг с другом
Шаг 2: Распределение стейкхолдеров
- Распределить по матрице
- Договориться, если есть расхождения в распределении

В Event Storming практика полезна тем, что помогает собрать стейкхолдеров первой встречи, а именно:
- тех, кто знает, какие вопросы задавать (и которым любопытны ответы);
- тех, кто знает ответы

Разработчики и тестировщики, скорее всего, будут теми, кто задает вопросы о том, в чем заключается реальная проблема, и есть ли какие-либо правила или политики, которые необходимо реализовать. Бизнес (представители) должны быть в состоянии ответить на эти вопросы.

Многие привыкли к такому описанию нотации Event Storming. Если в планах нет идти в архитектуру, а максимум – провести Process Modelling, можно воспользоваться описанием попроще 👇

Нотация Event Storming без элементов модели Software Design.

Вот уже и инструменты, заточенные под Event Storming начинают появляться.
Досочка: https://prooph-board.com

Поймал себя на мысли, что вот этот принцип Рэя Далио очень гармоничен Event Storming’у 🙂

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

Отзыв 🧐👍

Пример процесса работы с требованиями и место Event Storming в этом процессе.

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/