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

Напомню, что завтра (1 марта 2024) мы встречаемся в чате https://t.me/+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