Привет,
@igorovchinin
@Dima_SOI
@arbyzio
@polyackov_ot
@sliceoflife0101

Напомню, что завтра (1 марта 2024) мы встречаемся в чате https://news.1rj.ru/str/+sZztYHFuJKllZGNi в 18:00 по МСК.

Тема:
Будем тренировать методологию Event Storming на примере выдуманного кейса “Разработка приложения ‘Идем в поход’”

Цель:
Научиться применять методологию Event Storming для проектирования IT систем.
Это значит, что мы будем периодически останавливаться, чтобы что-то уточнить и\или делать шаги в сторону, чтобы понять как нужно действовать если у нас будет другой кейс или другие обстоятельства.

Регламент:
Работаем примерно 2 часа (до 20:00 по МСК). Как закончим, я попрошу каждого рассказать о своих впечатлениях. Это поможет нам синхронизироваться и, возможно, более эффективно провести следующую встречу.

Для избежания неловких ситуаций предлагается в рамках встречи называть друг друга полным именем независимо от степени знакомства. Обращение “по умолчанию” - на “ты”.

Подготовка:
Мы работаем на Белой Доске в FigmaJamp. Никита подготовил нам легенду и основные тезисы выдуманного кейса, за что ему большая благодарность.

Пожалуйста, пройдите по ссылке и убедитесь в том, что Вы можете со всем этим работать https://www.figma.com/file/dxLbfAqW03iPYEGyFYqj4G/Event-storming?type=whiteboard&node-id=0-1&t=d7DQBg7iplPjzU1c-0

Статью, над которой работали 2 года, официально считаем законченной (но это неточно 🙂).

Получилась инструкция к фреймворку Swagger, написанная в неформальном стиле.

🤔 Те, кто не знают что это такое и зачем нужно - узнают.

🧐 Те, кто слышал, но не понимает с какой стороны начать подступиться к Свагеру, найдут в статье свой путь.

😎 Те, кто давно работает с фреймворком, получат напоминалки-подсказки о:
- структуре документа,
- как создать,
- как оптимизировать,
- опубликовать в Confluence…
Всякое вот это, ведь держать такие вещи в голове не имеет смысла.

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

Ежели чего не дописали или какая-то информация устарела, пишите в комментах.

Как добиться согласованности 👯‍♀️ данных, если у тебя распределенная 📚 система, а взаимодействие между элементами осуществляется посредством очереди сообщений? 📬📭

Как обеспечить гарантию доставки данных и насколько сильно нужно стараться это сделать?

А какие вообще могут быть сценарии?

Игорь Овчинин (@igorovchinin) постарался ответить себе на все эти вопросы и рассказал что получилось в книжке статье с картинками. Теперь в комментариях ждет информации о том, чего он не учел?

https://notes-analyst.ru/stati/obespechenie-soglasovannosti-dannyh-v-raspredelennyh-sistemah-pri-vzaimodejstvii-cherez-ocheredi-soobshhenij/

Event Storming по переписке
Организационный пост

@polyackov_ot
@alexanderkrikunenko
@Dima_SOI
@arbyzio
@Nohwan
@sliceoflife0101
@vova_dev

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

Да, это не по канонам. Но я не вижу запретов на “попробовать”.

Стартуем сейчас. Если хотите позвать кого-то в процесс (из тех, кого нет в списке выше), лучше сделать это на текущей неделе. Напишите мне @jein_kraft ник участника в тг, чтобы я могла добавить его в закрытый канал и в чат.

Работаем с малыми итерациями с шагом - одна неделя. Дедлайн - вторник.

Каждую неделю я буду выкладывать пост с резюме по уже проделанной работе и задачей на следующую неделю.

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

Доска для работы

https://excalidraw.com/#room=d551383ae076bd5d2081,7KlSutOHA7x6rROeUYFp2w

Масштаб регулируется в левом нижнем углу.

В левой части рабочей области содержатся:
- Кейс (спасибо Полякову Никите @polyackov_ot за помощь в его формулировании);
- Легенда (чуть ниже). Здесь все необходимые для работы элементы. Для того, чтобы воспользоваться элементом выделите его с помощью кнопки 1 в верхнем меню (стрелочка), зажмите клавишу Alt на клавиатуре и потяните. Образуется копия элемента, которую вы сможете отредактировать по своему усмотрению. Для редактирования текста необходим двойной клик на область текста. Если элемент состоит из группы элементов (стикер и текст в нем), его удобно выделять не нажатием на элемент, а выделением всей области с группой. Если нужны какие-то элементы, напишете об этом в чате.
- Область для уточняющих вопросов к условному Заказчику (расположена левее описания кейса). Чтобы записать свой вопрос создайте копию предыдущего (выделить - зажать Альт - потянуть) и отредактируйте. Или воспользуйтесь кнопкой 8 в верхнем меню.

Вопросы по организации процесса - пожалуйста, в комментариях.

#ESWriting

Итерация 1: Страх чистого листа

Event Storming начинается с событий. Только с них и ничего другого. Если вы читали какие-то статьи про данный подход к проектированию и сбору требований, то могли видеть картинки с готовой, уже выстроенной структурой процесса. Там в качестве первой карточки указан Actor \ User. По привычке мы читаем любую информацию слева направо и думаем, что процесс нужно строить от действующего лица. Это ошибка. Мы пробовали. Не делайте так.

Event Storming начинается с оранжевой карточки. Метод, предложенный Эвансом, предусматривает 9 типов карточек. Каждая из них имеет свое значение и свой цвет. Сейчас нас интересует только оранжевая. Поэтому в легенде и на экране нет других стикеров, чтобы они не отвлекали. Сосредоточимся на событиях.

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

Мне всегда было сложно разместить самый первый стикер. Я не знала что спросить у заказчика, чтобы сразу повести беседу в нужном мне русле, а не уйти случайно в сторону. Как начать?

Придумала такое решение:
Самые первые вопросы, который я хочу задать условному Заказчику: “Как мы поймем, что процесс, который мы обсуждаем, завершился? Что сервис, который мы проектируем, успешно справился со своей задачей”?

В данном случае мы проектируем сервис “Идем в поход”. Мы будем считать, что сервис успешно отработал свою задачу, если группа пройдет поход и благополучно вернется.

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

Дальше должно быть чуть проще. У нас уже есть стикер, от которого можно плясать, как от той печки.

Следующие вопросы:

Что должно произойти, чтобы поход был успешно пройден?

Я предположила, что для этого потребуется сформировать группу (команду) и составить расладку по продуктам. Добавила еще два оранжевых стикера: “Команда сформирована” и “Раскладка продуктов составлена”

Господа, как вы думаете, что должно случиться, чтобы поход был успешно пройден?

Оформляйте свои предположения на оранжевых стикерах (см. предыдущий пост). Глаголы в форме прошедшего времени вам в помощь.

Встретимся в комментах
Следующая итерация - 18 июня.

P.S. Чтобы работа по этой сессии шторминга не потерялась среди других обсуждений, пожалуйста, оставляйте сообщения по теме штормига как ответа на пост каждого шага (сейчас как ответ на этот пост).


#ESWriting

Event Storming по переписке


Резюме по Итерация 1 - мы успешно победили чистый лист.

Признаться, я не ожидала, что предыдущая неделя будет настолько эффективной. Мы с Игорем были готовы штурмить вдвоем, если никто не включится в процесс. ЗдОрово, что нам не пришлось так упарываться.

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

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

Туриста оповестили, что его приглашают в команду на определенный поход

Говорят, есть “рисовалки” где у каждого стикера обозначен автор. К сожалению, Эскалидроу - не такая. Зато мы можем работать в ней без регистрации и имеем в запасе больше инструментов, чем просто стикеры.

В любом случае мы благодарны абсолютно всем, кто вложил свое время в это мероприятие. Было сделано достаточно, чтобы перейти к следующему шагу.

#ESWriting

Итерация 2: таймлиния, дубли и термины

Timeline - это понятие и элемент в Event Shtorming, которое всегда присутствует, но не обозначается явно. По-умолчанию считается что линия времени прямая, бесконечная и следует слева направо.

Первое действие, которое мы делаем после получения некоторого объема событий – упорядочение во времени. Так разрозненный хаос оранжевых стикеров превращается в то, что можно назвать системой. Кроме того, у нас появляется иерархия. Но она не вертикальная, а горизонтальная - события, которые случаются раньше, стоят ближе к началу.

Когда я попыталась выстроить все оранжевые стикеры в линию, то столкнулась с тем, что некоторые карточки выглядели дублирующими (обо одном и том же). Например:

Инициатива по походу сформирована

В системе зарегистрирован поход

Турист создал поход с указанием маршрута, сложности, временного промежутка, нужного инвентаря, макс. кол-вом людей

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

Турист подал заявку(и) на участие в походе

Туриста оповестили, что его приглашают в команду на определенный поход

Турист получил приглашение

Действительно ли все эти стикеры описывают одно и тоже событие, но по-разному?

На предыдущем шаге я задавалась вопросом: “Чего мы хотим?” и пришла к выводу, что - сходить в поход. Мой следующей вопрос: С чего поход начинается?

Мой ответ - смотря для кого. Для руководителя он начинается с готовности вести группу, а для рядового туриста - с готовности идти.

Значит туристы бывают рядовые и руководители. А рядовые туристы как-то делятся? У них есть роли: хронометрист, реммастер, ответственный за еду и прочее. Хотя, в коммерческом походе за еду, как правило, отвечает руководитель, он же гид. Либо, для этой задачи нанимаются специальные люди, которые идут с группой и обеспечивают их едой на бивуаках. Походы не одинаковы. События в них распределяются по-разному. Какие бывают походы?

Коммерческими называют походы, которые по своей сути являются продуктом. Это услуга. Основная цель предприятия – доход. Поход для них - это средство получения дохода. В обмен на деньги они берут на себя весь организационный процесс. Задача туриста-покупателя - суметь пройти.

Некоммерческие походы не приносят дохода никому из участников включая руководителя. Все организационные моменты равномерно распределяются в группе. Такие походы часто проходят со спортивной целью и имеют градацию по категориям.

Категорийный поход - тот, который соответствует определенному уровню из общепринятой классификации («Приложении 1. Методика категорирования пешеходного маршрута» к «Единой Всероссийской спортивной классификации туристских маршрутов (ЕВСКТМ)»). Для каждого уровня определенно время нахождения на маршруте и преодоление препятствий соответствующего уровня сложности. Также учитываются коэффициент трудности, географические особенности района, автономность и другие показатели. Часто, чтобы собрать категорийный поход, приходится тщательно выбирать регион и составлять хитрый маршрут.

Некатегорийный поход - тот, который делается “для души”, а не для спортивных заслуг. При составлении маршрута методика категорирования не учитывается.

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

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

Как видите, нам пришлось серьезно погрузиться в тонкости и разобраться в том, как оно бывает в реальной жизни \ как не бывает, а если не бывает, то может ли быть?

На этом этапе в Легенде появилось два новых элемента:
- стикер бирюзового цвета “Term”. Он нужен для того, чтобы зафиксировать те самые термины, которые мы выявили в процессе “погружения”.
- красная горизонтальная линия. Мы будем применять ее для обозначения и разделения параллельных процессов.

#ESWriting

Итерация 2: устранение дублей

Вы найдете термины на бирюзовых стикерах в верхней части доски.

А оранжевые с похожим содержанием я выстроила друг под другом. Давайте попробуем разобраться с первым столбиком вертикали.

Инициатива по походу сформирована

В системе зарегистрирован поход

Турист создал поход с указанием маршрута, сложности, временного промежутка, нужного инвентаря, макс. кол-вом людей

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

Турист подал заявку(и) на участие в походе

Туриста оповестили, что его приглашают в команду на определенный поход

Турист получил приглашение

Они точно дублирующие, или они просто звучат похожим образом, но обозначают разные события и должны быть разнесены по таймлинии? Может быть их можно сформулировать как-то иначе? О чем они?

Авторы стикеров – тут без вас никак. Разанонмизируйтесь )))

Так как мы проектируем систему, то можем оперировать только теми событиями, которые происходят в ее рамках. Допустим, поход начинается с того, что у кого-то случилось четко сформированное желание это сделать. То есть инициатива по походу сформирована. Но как об этом узнает приложение, которое мы проектируем?

Кажется, кто-то должен добавить в приложение поход. Или как-то обозначить свою готовность поучаствовать в нем (походе). Кто это? Турист - живой человек. Следовательно, в нашей системе должны быть зарегистрированные пользователи.

Ставлю оранжевый стикер “Турист добавлен” в самое начало таймлинии и сразу предлагаю переименовать его в “Турист зарегистрировался в приложении”

Как будто следующей карточкой должно быть “Поход заведен в приложении”.

Зафиксируем еще два термина:

Поход - массовая или одиночная прогулка на длительное расстояние, осуществляемое с определенной целью.

Турист - участник похода.

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

Я вижу этот процесса так:

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

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

Для того, чтобы было понятно, можно ли предлагать, например, другие даты или это уже “железно”, каждый элемент должен обладать статусом “утверждено \ не утверждено” (можно маркировать цветом).

Когда поход зарегистрирован в приложении (создан), он попадает в условный каталог походов и становится доступным для ознакомления всем зарегистрированным пользователям приложения и гостям.

Туристы, готовые участвовать в Походе, подают свои заявки на участие. Руководитель похода рассматривает заявки один или совместно с уже утвержденными участниками похода.

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

Таким образом два крайних стикера: “Туриста оповестили, что его приглашают в команду на определенный поход” и “Турист получил приглашение” я бы пока отложила в сторонку. Давайте без этого.

#ESWriting

Есть еще один дискуссионный стикер “Турист подписался на возможные ближайшие походы/Поставил статус, что готов пойти”. Мне кажется, что он нам точно понадобиться для туристов, которые не являются руководителями. Но как будто бы не сейчас. Зачем кому-то подписываться на поход, если он может сразу подать заявку? Допустим, если поход есть в системе, но находится в архиве. То есть проводить его в ближайшее время не планируют, но кому-то он нравится и хотелось бы пройти. Для архивных походов может пригодится функция “подписаться”. В этом случае не руководитель заводит поход, а поход будет искать своего руководителя. Интересная мысль. Но стоит ли ее описывать в самом начале?

Если все согласны с описанным мною выше процессом, то событийный ряд будет выглядеть так:

Турист зарегистрировался - Поход создан - Турист подал заявку \ Рассматривает заявку - Даты утверждены \ Маршрут утвержден \ Участники утверждены

События, обозначенные через дефис, идут последовательно, а через слеш - могут происходить одновременно.

При этом стикеры

Плановые даты похода и маршрут сформированы

Утверждены даты похода

Утверждена нитка маршрута

считаем дублирующими. Оставляем два: про даты и про нитку, так как это все-таки разные события, а не одно. Но ставим их друг под другом как те, которые могут случиться одновременно. Так мы разберемся со вторым вертикальным столбиком.

А для того, чтобы привести в порядок третий - из двух стикеров: “Группа туристов сформирована” и “Команда сформирована”, оставим только один - первый.

Есть возражения? Встречаемся в чате.

#ESWriting

Итерация 2: ответы на дополнительные вопросы к условному заказчику

Помимо прочего на предыдущем шаге у нас появилось два дополнительных вопроса к условному заказчику (вот как эффективно поработали).

Это сервис для города или распределенный по миру?

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

Сервис на одном языке?

Да, на текущем этапе сервис будет работать на одном языке. Более того, этот язык - русский. Почему? Потому, что я, как условный заказчик, нифига не понимаю в американских, турецких или балийских походах. Я знаю только ЕВСКТМ (Единый Всероссийский…)

#ESWriting

Резюме по Итерация 2

После второй итерации все доменные эксперты “встали и вышли”. Мне ещё предстоит разобраться в причинах возникновения этого эффекта. Сейчас - про походы.

Я остановилась на попытке разобрать карточки с событиями и выстроить их в порядке возникновения от более ранних к более поздним. В процессе поняла что какие-то стикеры хочется объединить, что-то убрать, а что-то – переименовать. И все это по отношению к самым ранним событиям. Буквально только старт процесса. У меня получилось что-то вроде горизонтальной пирамидки:

<турист зарегистрировался в приложении>
|
<поход создан в приложении>
|
<турист подал заявку на участие в походе> И <кто-то рассматривает эту заявку>
|
<даты похода утверждены> И <маршрут утвержден> И <участники утверждены>

Что дальше?

#ESWriting

Итерация 3: Error

Обычно после того как с составом группы датами и маршрутом все становится понятно начинается какая-то суета по поводу еды, снаряжения, транспорта, подготовке необходимых документов. И все это происходит одновременно. Раскладка никак не зависит от состава снаряжения, которое удалось раздобыть. Не зависят от всего этого ни документы, ни транспорт. Но внутри каждого из этих понятий существуют какие-то события. Это параллельные потоки. Обозначу их на Swim Line (плавательных дорожках). Но у меня уже как будто есть плавательные дорожки. Вот же стикеры стоят друг под другом и рассказывают про Даты, Маршрут и Участников. Еда, Снаряжение и Документы со всем этим никак не коррелируют. Как быть?

Сами собой в моих размышлениях выкристаллизовалась понятия, которые рискуют стать субдоменами для домена “Походы”. Я пока не знаю что с ними делать. Воспользуюсь красной карточкой.

Error в методологии Event Storming используется для обозначения того, на что стоит обратить внимание в уже составленной схеме. Это не обязательно ошибка. Может быть просто замечание. Я воспринимаю его как свободный стикер на котором можно написать то, чего не предусмотрено в методологии. Мне не нравится красный цвет. Хочется сделать его нейтральным. Но я столкнулась с тем, что базовую легенду менять нельзя. Те, кто уже знаком с методологией, глядя на схему автоматически считывают цвета и относят их к определенным типам (оранжевое – событие, бирюзовое – термин, синий – команда к действию и т.п.). Цветовое кодирование позволяет читать плоскую картинку как объемную модель. Но работает это только тогда, когда у всех одинаковый код. Иначе интерпретатор, работающий в наших сознаниях, ломается.

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

#ESWriting