По модели, полученной с помощью Event Storming можно определить сложность предметной области. В общем случае – это число событий, Очевидно, если в какой-то модели 1500 событий, то она значительно сложнее модели с 50-ю событиями. Конечно, DDD позволяет нам этой сложностью управлять, мы находим границы поддоменом, формируем ограниченные контексты. И поддомены/ограниченные контексты так же можно оценить по уровню сложости по объему терминов, входящих в границу, событий, команд, сущностей.
Но что примечательно. Неоднократно в выступлениях я говорил о том, что сложность разработки складывается из трех основных факторов (разумеется, и в статике и в динамике): это сложность предметной области, социальная сложность и технологическая сложность.
И вот, обращается клиент, – все медленно, просто жуть, никто ничего не понимает, все по учебнику.
Проводим Event Storming, исследуем предметную область. Она простая, даже отчасти примитивная. Строим карту контекстов и проставляем связи так, как есть сейчас, а сверху накладываем текущую организационную структуру и там просто провал 🙂 Несмотря на простейшую предметку 80% времени уходит на коммуникацию, координацию, управление зависимостями. Фактически – очень простая реорганизация структуры команд должна привести к ускорению почти на порядок (мы пока этого не знаем, потому что все только начинается).
А все дело в том, что было 7 команд и 4 ограниченных контекста (ну так мы построили, не факт, что структура окончательная) и ни одна команда не могла самостоятельно закрыть собой развитие какого-то отельного контекста. То есть всегда требовалось от 2 до всех 7 команд, чтобы внести изменения в один контекст. Это при том, что в 1 команде были компетенции, чтобы полностью поддерживать один из контекстов, но логические границы (зоны ответсвенности/владения, если будет угодно) были установлены так, что они заводили на другую команду доработки.
К чему я это написал?
Предметная область может быть сложной, может быть простой, но нельзя забывать и про социальную/технологическую сложность. Простым проблемам - простые структуры и простые технологические решения. Конечно, без понимания предметной области никуда не дется, это база, фундамент, но не всегда необходимо проводить кардинальные изменения, иногда чтобы стать быстрее бывает достаточным сократить и перегруппировать количество людей/команд и может случится магия, а иногда можно упростить/заменить используемые технологии/библиотеки/решения на более простые и этим, убрав избыточную сложность, сократить время прохождения задач через весь цикл разработки.
Но что примечательно. Неоднократно в выступлениях я говорил о том, что сложность разработки складывается из трех основных факторов (разумеется, и в статике и в динамике): это сложность предметной области, социальная сложность и технологическая сложность.
И вот, обращается клиент, – все медленно, просто жуть, никто ничего не понимает, все по учебнику.
Проводим Event Storming, исследуем предметную область. Она простая, даже отчасти примитивная. Строим карту контекстов и проставляем связи так, как есть сейчас, а сверху накладываем текущую организационную структуру и там просто провал 🙂 Несмотря на простейшую предметку 80% времени уходит на коммуникацию, координацию, управление зависимостями. Фактически – очень простая реорганизация структуры команд должна привести к ускорению почти на порядок (мы пока этого не знаем, потому что все только начинается).
А все дело в том, что было 7 команд и 4 ограниченных контекста (ну так мы построили, не факт, что структура окончательная) и ни одна команда не могла самостоятельно закрыть собой развитие какого-то отельного контекста. То есть всегда требовалось от 2 до всех 7 команд, чтобы внести изменения в один контекст. Это при том, что в 1 команде были компетенции, чтобы полностью поддерживать один из контекстов, но логические границы (зоны ответсвенности/владения, если будет угодно) были установлены так, что они заводили на другую команду доработки.
К чему я это написал?
Предметная область может быть сложной, может быть простой, но нельзя забывать и про социальную/технологическую сложность. Простым проблемам - простые структуры и простые технологические решения. Конечно, без понимания предметной области никуда не дется, это база, фундамент, но не всегда необходимо проводить кардинальные изменения, иногда чтобы стать быстрее бывает достаточным сократить и перегруппировать количество людей/команд и может случится магия, а иногда можно упростить/заменить используемые технологии/библиотеки/решения на более простые и этим, убрав избыточную сложность, сократить время прохождения задач через весь цикл разработки.
👍8🔥1
Представьте. Вы - новый сотрудник в компании. Вы садитесь вместе с кем-то, кто в компании давно и он объясняет вам как устроены различные процессы. Вы задаете вопросы, получаете ответы, вопросов остается все меньше.Небольшая часть процессов описана в документах и с ними вы знакомитесь самостоятельно. И вот большую часть процессов вы выполняете не задумываясь.
И вот вы встречаетесь с кем-то еще из компании за чашкой кофе и сравниваете что вы делаете в рамках одних и тех же процессов. С удивлением вы понимаете, что в рамках одних и тех же процессов действуете по-разному. Это происходит от того, что ваши ментальные модели отличаются.
Чем ниже актуальность документов, тем выше вариативность ментальных моделей среди сотрудников.
Немалая часть знаний о процессах в компании хранится в головах сотрудников. EventStorming можно использовать для однозначного определения процессов, – выявления вариативности и формирования общей ментальной модели.
И вот вы встречаетесь с кем-то еще из компании за чашкой кофе и сравниваете что вы делаете в рамках одних и тех же процессов. С удивлением вы понимаете, что в рамках одних и тех же процессов действуете по-разному. Это происходит от того, что ваши ментальные модели отличаются.
Чем ниже актуальность документов, тем выше вариативность ментальных моделей среди сотрудников.
Немалая часть знаний о процессах в компании хранится в головах сотрудников. EventStorming можно использовать для однозначного определения процессов, – выявления вариативности и формирования общей ментальной модели.
❤7😢1
Event Storming
Сравнение 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
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
❤6🔥5👍3
Думаю, будет полезно опубликовать ответ здесь.
Привет, хочу провести сессию Event Storming, но не уверен что до конца понял его. Есть какие нибудь референсы, чтобы потренироваться, по типу: вот задание и ответ, сделай по заданию и сверь с ответом?
Боюсь, что такого не будет, это ведь исследовательская практика, а каждая предметная область – уникальна в своем представлении в голове каждого конкретного человека и цель – построить общую, непротиворечиваю, согласованную ментальную модель, а обозначения в event storming – удобный способ фиксации этой единой ментальной модели. Обсуждения, мысли, идеи, дополнительный контекст все равно остаются в головах, но теперь в синхронизированном состоянии.
У меня есть в тренинге по Event Storming несколько заданий, в которых дается уже готовая модель и в ней нужно найти антипаттерны, вроде «множественное толкование», «скрытый смысл», «нарушение симметрии» и прочие, в беклоге есть на правах идеи оформить это в статью, а может будет проще и удобнее в видео, но это будет точно не в этом и не в следующем месяце.
Для тренировки можно, например, загуглить уже готовые примеры результатов, скопировать хоть картинку к себе на лист миро и везде, где есть подозрение на скрытую сложность формулировать на стикерах вопросы и размещать их рядом с тем местом, где вопрос возник. Это немного подготовит к проведению сессии. Вопросы желательно формулировать полные, не просто «А что здесь написано?», а «Событие Документы Загружены может содержать скрытую сложность, какие именно документы загружены?». Для того, чтобы было проще нужно постараться поставить себя на место человека, которому нужно написать по этой модели код (если мы говорим про разработку). Код не терпит двусмысленностей, он выполняет определенный алгоритм и если из формулировки не ясно (не непонятно, а именно не одно не понятно), как это реализовать, то есть «можно так, а можно же и так», то модель должна быть уточнена для избавления от подобных предположений.
Привет, хочу провести сессию Event Storming, но не уверен что до конца понял его. Есть какие нибудь референсы, чтобы потренироваться, по типу: вот задание и ответ, сделай по заданию и сверь с ответом?
Боюсь, что такого не будет, это ведь исследовательская практика, а каждая предметная область – уникальна в своем представлении в голове каждого конкретного человека и цель – построить общую, непротиворечиваю, согласованную ментальную модель, а обозначения в event storming – удобный способ фиксации этой единой ментальной модели. Обсуждения, мысли, идеи, дополнительный контекст все равно остаются в головах, но теперь в синхронизированном состоянии.
У меня есть в тренинге по Event Storming несколько заданий, в которых дается уже готовая модель и в ней нужно найти антипаттерны, вроде «множественное толкование», «скрытый смысл», «нарушение симметрии» и прочие, в беклоге есть на правах идеи оформить это в статью, а может будет проще и удобнее в видео, но это будет точно не в этом и не в следующем месяце.
Для тренировки можно, например, загуглить уже готовые примеры результатов, скопировать хоть картинку к себе на лист миро и везде, где есть подозрение на скрытую сложность формулировать на стикерах вопросы и размещать их рядом с тем местом, где вопрос возник. Это немного подготовит к проведению сессии. Вопросы желательно формулировать полные, не просто «А что здесь написано?», а «Событие Документы Загружены может содержать скрытую сложность, какие именно документы загружены?». Для того, чтобы было проще нужно постараться поставить себя на место человека, которому нужно написать по этой модели код (если мы говорим про разработку). Код не терпит двусмысленностей, он выполняет определенный алгоритм и если из формулировки не ясно (не непонятно, а именно не одно не понятно), как это реализовать, то есть «можно так, а можно же и так», то модель должна быть уточнена для избавления от подобных предположений.
👍11
Нужно ли разработчикам/тестировщикам/админам знать бизнес-модель компании/продукта в которой они работают? (напишите в комментариях чем это, на ваш взгляд, помогает или почему в этом нет смысла).
Позже напишу причем тут бизнес-модель :)
Позже напишу причем тут бизнес-модель :)
Anonymous Poll
94%
Да
6%
Нет
Ответ Альберто Брандолини, изобретателя 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.
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.
👍1😢1
Почему разработчики не играют в “правда или действие" после сессии Event Storming?
Потому что правда уже на стикерах, а действия в плане 👌
Потому что правда уже на стикерах, а действия в плане 👌
👍1🔥1
Подготовил небольшое выступление о гранулярности событий, пока раздумываю о том, стримить здесь или как митап провести, чтобы повысить качество самого выступление, хочу попросить в комментариях написать ваши вопросы, проблемы, случаи из жизни, связанные с гранулярностью событий и в выступлении постараюсь дать ответы на вопросы и/или прокомментировать ситуации.
Под гранулярностью будем понимать объем деталей и информации, передаваемой посредством событий.
Под гранулярностью будем понимать объем деталей и информации, передаваемой посредством событий.
👍5🔥2
Выделенное зеленым касается любых обсуждений (здесь речь о Miro Board, поэтому «доска»), но Event Storming в первую очередь.
Одно из отличий онлайн от оффлайн в том, что онлайн теряется язык тела, а он крайне информативен.
Если при обсуждении говорящий отвернулся от поверхности со стикерами и говорит в аудиторию, то, вероятноо всего, на поверхности недостаточно информации, чтобы к ней обратиться.
Если же говорящий обращается к аудитории посредством информации на поверхности, то есть указывая на конкретные стикеры в модели, то информации достаточно для конкретно этого обсуждения и она зафиксирована в визуализации модели.
Онлайн мы лишены такой роскоши, как язык тела, поэтому обсуждаемые стикеры можно выделять, обводить, в miro использоваться функцию «собрать всех вместе», то есть каким-то образом акцентировать внимание аудитории на обсуждаемом блоке информации.
Этот нюанс в онлайн работает не так эффективно, как оффлайн, потому что ведущий и участники не увидят/не заметят того подсознательного, что делает наш мозг с нашим телом и, таким образом, фасилитатору чаще приходится явно уточнять: «обсуждаемая сейчас информация отражена в нашей модели? каким образом? требуется ли ее уточнить для того, чтобы обсуждение было более продуктивным?», то есть выразить явно в речи и действиях на экране то, что в оффлайн было бы подсознательным и не расходовало дополнительную энергию нашего мозга и время проведения сессии.
Одно из отличий онлайн от оффлайн в том, что онлайн теряется язык тела, а он крайне информативен.
Если при обсуждении говорящий отвернулся от поверхности со стикерами и говорит в аудиторию, то, вероятноо всего, на поверхности недостаточно информации, чтобы к ней обратиться.
Если же говорящий обращается к аудитории посредством информации на поверхности, то есть указывая на конкретные стикеры в модели, то информации достаточно для конкретно этого обсуждения и она зафиксирована в визуализации модели.
Онлайн мы лишены такой роскоши, как язык тела, поэтому обсуждаемые стикеры можно выделять, обводить, в miro использоваться функцию «собрать всех вместе», то есть каким-то образом акцентировать внимание аудитории на обсуждаемом блоке информации.
Этот нюанс в онлайн работает не так эффективно, как оффлайн, потому что ведущий и участники не увидят/не заметят того подсознательного, что делает наш мозг с нашим телом и, таким образом, фасилитатору чаще приходится явно уточнять: «обсуждаемая сейчас информация отражена в нашей модели? каким образом? требуется ли ее уточнить для того, чтобы обсуждение было более продуктивным?», то есть выразить явно в речи и действиях на экране то, что в оффлайн было бы подсознательным и не расходовало дополнительную энергию нашего мозга и время проведения сессии.
👍5❤1
Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming»
Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂
Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.
Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).
Like/Share 🙂
Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂
Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.
Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).
Like/Share 🙂
❤32👍22🔥10
Event Storming pinned «Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming» Он в большей степени для тех, кто хочет узнать что такое Event Storming: - Основные сценарии использования - Основные элементы - Основные структуры - Основные эффекты - Основные артефакты…»
Event Storming
Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming» Он в большей степени для тех, кто хочет узнать что такое Event Storming: - Основные сценарии использования - Основные элементы - Основные структуры - Основные эффекты - Основные артефакты…
«Введение в Event Storming»
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂
Запись (2 часа)
https://www.youtube.com/watch?v=yAiqKwFqwwU
Доска из стрима
https://miro.com/app/board/uXjVM6wX96s=/?share_link_id=290297488404
Раз здесь качество не очень хорошее, больше в телеграме с шарингом экрана не буду проводить стримы, будет в zoom+youtube в формате митапа.
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂
Запись (2 часа)
https://www.youtube.com/watch?v=yAiqKwFqwwU
Доска из стрима
https://miro.com/app/board/uXjVM6wX96s=/?share_link_id=290297488404
Раз здесь качество не очень хорошее, больше в телеграме с шарингом экрана не буду проводить стримы, будет в zoom+youtube в формате митапа.
👍25🔥11
На чем набить руку в Event Storming?
Я вчера упомяул про один действенный способ потренироваться в технике Event Storming: детские игры.
Например:
- 12 палочек
- Классики
- Тише едешь, дальше будешь — стоп
- Море волнуется раз
- Казаки-разбойники
- Вышибалы
- Ножички
- Колечко-колечко
- …
Почему на них удобно тренироваться?
1. Вы все играли в какие-то из этих игр, а значит являетесь экспертами в преметной области
2. У всех этих игр есть ограниченная предметная область, – есть начало и есть конец
3. Описание и правила этих игр легко можно найти в интернете, это прекрасное подспорье к тому, что вы помните из детства
4. Это приятные воспоминания и это не связано с текущей повседневной деятельностью
Мы отлично понимаем как играть в эти игры, но игра и выражение игры в модели – не одно и то же, выразить в модели игру бывает достаточно сложно.
Сначала имеет смысл поразбираться самому, разобрать хотя бы несколько игр.
Затем, если в вашем окружении это возможно, можно выбрать игру, и провести сессию уже с небольшим числом участников, это будет тренипровка фасилитации.
Вероятность успешного проведения боевых сессий вы таким образом гарантированно поднимаете, потому что когда будете строить модели игр вы будете сталкиваться с ситуациями, которые сходу не сможете разрешить, но подумаете, погулите, спросите, поробуете так и так и вот у вас уже есть вариант решения, а значит во время боевой сессии для вас это уже не будет проблемой.
UPD: можете скидывать то, что получилось в комментарии к этому посту :)
Я вчера упомяул про один действенный способ потренироваться в технике Event Storming: детские игры.
Например:
- 12 палочек
- Классики
- Тише едешь, дальше будешь — стоп
- Море волнуется раз
- Казаки-разбойники
- Вышибалы
- Ножички
- Колечко-колечко
- …
Почему на них удобно тренироваться?
1. Вы все играли в какие-то из этих игр, а значит являетесь экспертами в преметной области
2. У всех этих игр есть ограниченная предметная область, – есть начало и есть конец
3. Описание и правила этих игр легко можно найти в интернете, это прекрасное подспорье к тому, что вы помните из детства
4. Это приятные воспоминания и это не связано с текущей повседневной деятельностью
Мы отлично понимаем как играть в эти игры, но игра и выражение игры в модели – не одно и то же, выразить в модели игру бывает достаточно сложно.
Сначала имеет смысл поразбираться самому, разобрать хотя бы несколько игр.
Затем, если в вашем окружении это возможно, можно выбрать игру, и провести сессию уже с небольшим числом участников, это будет тренипровка фасилитации.
Вероятность успешного проведения боевых сессий вы таким образом гарантированно поднимаете, потому что когда будете строить модели игр вы будете сталкиваться с ситуациями, которые сходу не сможете разрешить, но подумаете, погулите, спросите, поробуете так и так и вот у вас уже есть вариант решения, а значит во время боевой сессии для вас это уже не будет проблемой.
UPD: можете скидывать то, что получилось в комментарии к этому посту :)
👍20😱3❤1