В рамках управления ожиданиями стейкхолдеров, а в большей степени - практикам 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/

Еще инструмент подъехал
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

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

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