Привет,
@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