Просмотр исходного текста страницы Блог:Максима Цепкова/2023-09-17: Flow - конференция аналитиков от JUGru - хороший старт

{{Conf-Ref}}

В портфеле конференция [https://jugru.org/ '''JUGru'''] появилась новая - конференцию аналитиков [http://flowconf.ru '''Flow''']. Первая была осенью прошлого года в online, а в этом году конференция прошла в двух частях: online 4-5.09 и offline в Москве с трансляцией 11.12.09. Я выступал в онлайн-части, у нас было обсуждение с Юрием Куприяновым [[DDD: как жить в проекте без требований (обсуждение на Flow-2023)|'''DDD: как жить в проекте без требований''']]. К сожалению, посмотреть online практически не сильно получилось, а вот на offline-части я был, хотя тоже отвлекался на рабочие встречи. вообще covid и удаленка имеют оборотную сторону - участие в конференции - перестало быть препятствием для рабочих встреч. Понятно, что это вопрос индивидуальной организации рабочего времени, и я стараюсь. Но раньше-то было проще: ты на конференции и все.

В целом впечатления - очень позитивные. Много качественного контента. Если сравнивать с AnalystDays, то больше архитектуры и системного анализа, Flow несколько ближе к разработке - конференции дополняют друг друга. Так что у аналтиков появилась еще одна конференция, в дополнение к ЛАФ, AnalystDays и ArchDays. Я публиковал заметки о выступлениях, и собираю их в отчет. Но начну я с выступления Романа Пионтика, который посмотрел уже после конференции, при подготовке этого отчета.

= Роман Пионтик. Архитектура как код = 

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

Критическая часть. Что такое архитектура? Говорят, что это набор взаимосвязанных технологических и технических решений. В этом определении нет архитектора. И в DevOps разработки процессе архитектора тоже нет, функция архитектуры не выделена. Получается, что архитектура - это умозрительный феномен, который мы моем исследовать для влияния на него. В такой постановке роль архитектора софта сравнима с ролью архитектора городской застройки в условиях, когда люди массово строят самостоятельно и потому застройка получается сильно разнообразной с слабо соответствующей замыслам.

А еще человеку свойственно упрощать. При этом мир проще на становится, а качество решений, построенных на упрощенном описании оставляет желать лучшего.

Как предлагают описывать архитектуру. Известен ArchiMate. Но по факту, диаграммы - плохо читаются, язык мало известен. Кроме того, в язык зашита метамодель, претендующая на универсальность. Но универсальная модель работает только для стабильных доменов, а не для развивающихся.

Между замыслом и реализацией - разрыв. Архитекторы разъясняют замысел. А можно - просто сделать. Архитектурная функция в виде создания диаграмм - не эффективна. 

Что предлагается как решения? Архитектор 2.0 описывает архитектуру как код, на некотором языке. Описание в виде кода уже зарекомендовало себя для инфраструктуры, и предлагается использовать этот опыт.
* Единое пространство для описания, в котормо работают архитекторы и разработчики
* Версионирование на основе Git, хранение рядом с кодом
* Описание и использование архитектурных паттернов подобно использованию библиотек при разработке
* Включение работы с архитектурой в единый процесс разработки, по аналогии с DevOps
* Модульность и сегментируемость, деление на домены 

Осталось изобрести язык архитектуры. 
* Это не PlantUML и Structurizr - они предназанчены для описания диаграмм, а не для описания архитектуры как таковой. По необходимости их можно порождать.
* Описание должно читаться человеком и машиной, и порождаться человеком и машиной.
* Основой архитектуры сейчас являются контракты между доменами. Их описание понятно разработчикам, был пример. 
* Внутреннее устройство домена инкаппуслируется и отдается в управление команды домена. 
* Управление архитектурой - распределенное, на федеративных принципах. 
* Метамодель описания архитектуры - расширяемая, в том числе - для учета особенностей отдельного домена. 
* Все описания собираются в Архитектурный DataLake, и мы можем проводить анализ, соотносить структуры в разных доменах, выделять шаблоны. 

Есть пример реализации такого подхода, сделанный самим Романом - DocHub. Он не настаивает, могут быть альтернативные реализации. А можно подключиться к сообществу DocHub и начать его развивать - это open source проект. При этом низкий порог входя - есть plugin к IDEA, так что можно сразу использовать. 

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

Однако, в практическом применении подхода есть ряд проблем, с которыми неясно, что делать. И тут нужны практики. которые позволят с этим жить внутри разработанных инструментов. Какие я вижу проблемы?
* Каждая архитектура проходит этап эскизирования, когда формальное описание еще невозможно. И при проектировании у нас неравномерная картина: что-то уже определено достаточно конкретно, а что-то - еще в зоне неопределенности, и надо уметь делать такое смешанное описание.
* Взаимодействие между компонентами - это уровень архитектуры приложений. А есть еще бизнес-уровень, при этом для него тоже интересно описание архитектуры в виде кода, таким образом. чтобы можно было трассировать исполнение бизнес-процессов по цифровому следу в логах различных систем, соотносить идеальную картину с реальной. То, для чего замысливался Archimate - описание связи бизнес-приложения-компьютеры. Я вижу тут большой потенциал. И тут особенно важно как раз смешанное описание различной жесткости, потому что новый процесс не только проектируется в эскизах. он и отрабатывается со слабой формализацией, с опорой на разумное поведение людей, и при этом на этапе отработки тоже интересно наблюдать, как все реализуется - эскизные с некоторого уровня должны стать машиночитаемыми.
* Описывается конструкция, за рамками остаются основания для принятых решений. Почему систему разделили именно на такие компоненты? Почему были выбраны именно такие протоколы? И так далее. Понятно, что это, вероятно, текстовые описания, но важно, чтобы они были где-то в едином репозитарии, были предусмотрены места. Это как с описаниями классов и функций, обираемому по специальным комментариям в коде - эти комментарии должны быть структурными.

А еще у меня есть определенный скепсис, связанный с тем, что инструмент для описания архитектуры уже создавали - Enterprise Architect. Там тоже расширяемая метамодель, и много других возможностей. То есть подход, для которого создавали инструмент - тот же самый. Успеха не получилось, инструмент - сложен, и есть кейсы, когда он используется аналитиками внутри, а для разработчиков порождаются документы, потому что разбираться в моделях разработчики не хотят. Есть кейсы, когда возможность создания единой модели - игнорируется, вместо нее используется много фрагментарных. И так далее. И с этим связаны сомнения. Но понятно, что довольно много недостатков EA в DocHub преодолено за счет версионирования моделей, текстовых описаний, открытого кода и доступного развития сообществом. Этого может оказаться достаточно. Но, может быть, проблемы не только в инструментах, но и в подходе.

А если говорить об альтернативных инструментах, то полгода назад на конференции TrueTech я слушал рассказ X5 про создание своего инструмента для ведения архитектуры предприятия. Перед решением о разработке они смотрели DocHub, правда это было полтора-два года назад. Но им было важна связь с бизнес-процессами, а этого действительно нет. Но в отличие от DocHub их инструмент пока недоступен - они говорили, что готовы к пилотам с заинтересованными компаниями с тем, чтобы убрать специфику, и только потом будут делать доступное решение. Подробности можно посмотреть в [[Блог:Максима Цепкова/2023-05-04: TrueTechDay - живая конференция и хороший контент|моем отчете]]. 

= Данила Старосек РСХБ. Границы проекта в условиях the roof is on fire=

Основной тезис доклада: хаос на проекте в условиях приближающихся сроков - хорошее время для интенсивного, взрывного роста на испытательном сроке. Иллюстрирован собственным кейсом. Ему неудобно говорить от первого лица, поэтому аватар-растение Митроша. Он что-то умеет в аналитике, запустил несколько проектов, окунулся в банки, работал с БД, хочет освоить фронт и бэк. Проект Единый фронтальное решение ЕФР - интеграция всей работы операциониста, стартовал с зимы, он пришел летом, команда собралась, но уже приближается первая контрольная точка, а работа не продвигается. При этом команда новая, большая неизвестность по legacy и менеджменту.

Первая неделя - все хорошо: документация, техзадания, инструкции. Потом опытные аналитики уходят в отпуск - лето, и он остается один в команде микросервиса (1 аналитик, 5 разработчиков). И Митроша начинает тушить пожары в эти две недели. Чтобы не тормозился проект.

Выводы этого процесса - на что фокусы внимания в ходе тушения пожаров.
* Выделить границы своих компетенций. У них есть системный аналитик и бизнес, и к бизнесу ходит он. А для архитектуры есть архитектор
* Не все в твоих силах, особенно когда всего неделю
* Надо определить ЛПР по видам вопросов и ходить к ним, это не всегда начальник, специализация коллег
* Определить мотивацию участников. Примериваем ролевые шляпы: тестировщик, аналитик, проджект, смотрим на мир через них. Тестировщик хочет, чтобы багов не было, а не докапывается к твоей работе.

Confluence. Митроша думал, что он есть - а там все сложно. И, в частности, важно не кидать ссылку на статью, а рассказывать структуру оглавления - понимание структуры дает возможность самому искать.

Инструкции по повседневным делам: назначить встречу, зарезервировать переговорку. Об этом была устная традиция. Когда он сделал инструкцию - начали пользоваться, уважение повысилось, потому что человек 10, оказывается, тоже не знали. При этом инструкция 15 минут. а работать на репутацию будет постоянно.

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

Но он оказался завален работой. Все идут к нему, много самой разной работы координатора. Для него выход воспользоваться scrum. Разбить проект на спринты. Контрольная точка в августе, мы в середине июля, раскидываем по спринтам и начали обсуждать. И наконец вагончик стронулся. Появились экранные формы, появился функционал.

= Ольга Пономарева Райффайзен. Возможности Миро для работы аналитика =

Хороший доклад в интерактиве с участниками про использование Miro. Если кратко, то это Miro - супер-инструмент для быстрых набросков, а вот для дальнейшего оформления - по-разному. Но есть много способов: есть много шаблонов и интеграций, в том числе от сообщества, есть встроенный PlantUML, которым удобно делать sequence-диаграммы и не только их, есть плугин для голосования, и его можно использовать для согласования, и ряд других приемчиков. Но есть альтернативы, например, доски для ретро и дизайна можно ввести в Figma, и тут у аудитории разный опыт. А требования и базы знаний - уже в Confluence, и версии надо отдельно сохранять. Все не перескажешь, надо смотреть. А из ограничений - число бесплатно доступных досок и размер самой доски, и второе - опасно, потому что с некоторого объема доска начинает виснуть, то есть ты добавил кусочек - и доска стала плохо работать.

= Юрий Куприянов. Скрытая работа аналитика по проектированию систем = 

Хороший доклад о том, что требования и проектирование неразрывны. Потому что анализ - он про деление на части и описание каждой системы. А системы-то еще нет, как разделить на части то, чего нет? Делается переход: делим на части требования, и аналитик их структурирует, и тогда получаются требования вместо системы, и реализуемость каждой части становится сомнительна. Где граница требований и проектных решений? Например, данные: концептуальная, логическая, физическая - но это про реляционку, а где мы это решили. Аналогично UX: сценарии пользователя описываем на языке форм. А если там не форма, а чат-бот. Или даже в шагах: запросить отчет - получить отчет: почему два шага, может отчет сразу придет без запроса; почему именно отчет. Требования: полные, непротиворечивые: как мы перешли от неполных и противоречивых к полным и непротиворечивым? Это е проверяется только проектировочным решением!

Независимость требований от реализации - иллюзия. Они зависят от проектных решений. Никаких целей, структуры, объектов не существует, мы их создаем в процессе проектной работы! Поэтому у нас есть совместный процесс придумывания, нет никаких требований, есть консультация заказчика на тему, что бывает и вместе с ним придумываем, как будем делать решение. Совместный дизайн с заказчиком. 

* Изменяйте чрезмерно структурированных, переупрощенных, рационализированных требований
* Признавайте двусмысленность и неопределенность
* Рассматривайте структурирование требований и проектирование решений как один процесс
* И лучше, когда анализ и проектирование делают одни люди.

Что мы проектируем: взаимодействие пользователя, структуры данных, взаимодействие с внешними системами, внутреннее устройство системы. Четыре специализации: UX (и это про удобство работы, а не дизайн), проектировщик БД (раньше разработчики, а сейчас серая зона), проектировщик интеграции (раньше архитекторы, а теперь хотят системных аналитиков - то же, но подешевле), архитектор софта (или разработчик). Вы можете в той или иной мере выполнять их все. И дальше было по каждой из них куда смотреть и как делать, записано пунктиром.

* Взаимодействие пользователя с системой. Главное - не с системой взаимодействовать, система - посредник взаимодействия между людьми и надо именно это проектировать. Заказ такси - взаимодействие с водителем. Редакторы - там все равно описание объектов реального мира и вопрос, как мы с ними работаем. Задача пользователя, шаги, принимаемые решения, какая информация нужна, какими объектами манипулирует. Все сложно, и не часто хочется заниматься. Сполски Руководство по UI дизайну для программистов. Дэн Браун 8 принципов информационной архитектуры, Курс Копылова Дизайн интерфейс для не дизайнеров.
* Хранение данных. Концептуальная, логическая и физическая. Обычно детализируют. Реально все не так. Концептуальная модель - то, что в мире, о чем говорит бизнес, не думая о системы. А дальше смотрим и пытаемся понять, на что похоже: объекты, изменения объектов, журнал работы и так далее. И исходя из природы выбираем подход к хранению, не обязательно реляционный - в Амазоне или другом облfке их множество. И дальше настраиваем в конкретном выбранной продукте хранения.  
* Интеграция. Нет там требований, ее надо проектировать. А это других денег стоит. И дальше - набор ссылок, что делать.
* Архитектуры. Самое главное в этом - как команда разработки разбита по отдельным командам - закон Конвея. Архитектурные стили. Способ развертывания - аналитик об этом вообще не думает, а он влияет на способ независимой доставки частей. Нефункциональные требования критично влияют на архитектуру, и вот этой части аналитик обычно не умеет совсем. Характеристики системы, которым должна отвечать система. А регулярно их просто вставляют в ТЗ, особо не вникая, потому что не понимают. Литература: Ричардс и Форд Фундаментальный подход к архитектуре и Современный подход к архитектуре, еще несколько книг. Роль аналитика тут - организатор и фасилитатор работы, чтобы бизнес-заказчики и разработчики искали реальное решение там, где оно нужно.

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

= Святослав Котусев. Корпоративная архитектура: мифы и реальность =

Тут надо сделать преамбулу, которой не было в докладе. Под архитектурой предприятия в докладе подразумевалась практика работы архитектора предприятия, а не описание архитектуры как таковой. И это один источник мифов: фокус на описании, а не на процессе. А второй источник мифов - фокус на инструменте.

Теперь кратко содержание доклада. 7 мифов.  
# Корпоративная архитектура - это план, как ИТ-ландшафт связывается с бизнесом. Продумали, сделали кучу диаграмм, потом реализовали. Так не бывает, в компаниях все динамично меняется, драйверы бизнеса меняются, сам план настолько сложен, что останется на полке. Реально это много документов, которые помогают разным людям принимать решения на разных уровнях. Решения про направления инвестиции денег. Решения про старт проектов. Планы конкретных проектов. И так далее.
# Архитектура предприятия - это некоторая пирамида, где мы шаг за шагом что-то послойно делаем. Текущее, потом по шагам идем. Реально архитектура не может быть проектом, потому что организация живет и все изменяется. Реальна архитектура - это практика, это превращение решений бизнеса в проектные решения. 
# Работа архитектора - это очень умный человек, который лучше всех знает, как (должен) быть организован ИТ-ландшафт, который понимает про бизнес и ИТ, придумал, принес и все исполняют. Эта задача, неподъемная для одного человека, очень всего много. Реально архитектор организует и ведет процесс планирования, это экспертная, а не менеджерская роль. Архитектор может, используя свое знание ИТ, представить идеи, которые бизнесу понравятся. В любом случае, планы возникают в коллаборации многих специалистов бизнеса и ИТ. Но архитектор договаривается о принятии решений.
# Миф что корпоративная архитектура - воплощение в жизнь системного мышления, которое говорит про синергию, оптимальные решения и так далее. Проблема в том, что решения - коллективны, и сколько бы один человек не мыслил, решение будет принято в коммуникации. Печалька, если архитекторы занимаются мышлением, а не коммуникациями и порождают кучу пусть умных, бумаг. Хорошее решение - то, которое всех устраивает, а не то, которое кто-то придумал. И артефакты должны помогать принять решение. Системное мышление хорошо, но миф плох тем, что смещает акцент с коммуникации на мышление. 
# Миф, что архитектура предприятия - про моделирование, описание в правильной нотации, например, Archimate. Проблема в том, что архитектура решает проблемы согласования бизнеса и ИТ, и руководители должны работать совместно. Руководители бизнеса нотацию Archimate не поймут, нужен PowerPoint и простые диаграммы. Интуитивно понятные диаграммы. А это - отдельное искусство, которым надо владеть. А еще Achimate позиционируется как язык для корпоративной архитектуры, но реально его используют мало, и ниша применения непонятная: для коммуникации с бизнесом не подходит. Хотя для внутреннего документирования архитекторами AsIs - может подойти. 
# Роль фреймворков в архитектуре предприятия. Есть списки, в некоторых до 50 штук? самые известные Захман, TOGAF. И впечатление, что главное в архитектуры предприятия про следование фреймворку. Это не так, ни один фреймворк не имеет успешной реализации, все они - продукт маркетинга, Захман работал маркетологом в IBM... Фреймворки FEF и DOD - есть публичные отчеты о том, что они промотали гигантские деньги, но ничего не сделали - анализ 10-летнего использования.
# Исторический миф. Что EA предложил Захман в 1987, дальше пошли следующие. Реально все началось раньше, в 1951 первый проект внедрения системы расчета зарплаты, и там был человек Maestro of Technology, и он выполнял роль EA. D 1962 статья Master Plan of Information System в Harvard Business Review: пошаговый план, который мы можем увидеть в TOGAF, все это очень старое. То есть тема архитектуры - очень старая. А Захман - просто большой маркетинг от IBM.

Три верхнеуровневых процесса.
* Стратегия - Взаимодействие с руководителями бизнеса и формирование дорожных карт для инвестиций
* Тактика - Формирование проектов на основе дорожных карт
* Оптимизация - Анализ существующего ландшафта и предложения по его улучшению

И он собрал Enterprise Architect on a Page - то, что используется, можно загуглить по этой фразе.

Набор документов архитектора.
* Business Capacity model
* Technology Reference 
* IT Investment roadmaps
* Detailed solution design

Как сочетается с Agile? Все равно есть архитектурные решения: набор технологий, способ встройки системы в ИТ-ландшафт, безопасность. И это - поле действия архитектора.

= Денис Цветцих. C4 model =

Модель для описания архитектуры приложений и частично технологического уровня, сделал Simon Brown. 4 основных диаграммы: контекста - система в окружении пользователей и систем; контейнеры - состав системы из отдельно развернутых частей, например, клиент-сервер-база данных; компоненты - декомпозиция компонента на группы функций, например jar или dll; код - диаграммы классов. И три дополнительных диаграммы: ландшафта показывает более далекое окружение системы, над контекстом; динамическая - взаимодействие при обработке бизнес-процесса, через нумерацию стрелочек и детали сообщений; развертывания - ноды и масштабирование. Диаграмм кода и компонентов обычно строят IDE или EA, а остальные можно строить в разных инструментах: draw.io, Miro, Figma, Lucidchart, IcePanel.io - рисуют картинки, PlantUML и Structurizr - от автора c4 позволяют описывать псевдокодом. 

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

Дам часть ссылок. Для кода полезен SOLID, описан у Теплякова "Паттерны проектирования на .Net" - там современное описание, у Эрик и Элизабет Фримен легче, классика Гамма и Хелм Приемы ООП и паттерны - 30 лет назад, уже многое встроено в язык, устарело. 

Компоненты - надо знать слои: чистая архитектура, луковая архитектура, best practice для каждого уровня - rich, anemic, event, ORM, аспекты и т.п. Модульный монолит или микросервисы, способы блокировки и так далее. Фаулер Шаблоны корпоративных приложений. И еще много - DDD, Чистая архитектура, книжки от MS. Но там есть хорошие и вредные советы, надо различать.

Контейнеры - соответствие системы целевому назначению - реализация фич и атрибутов качества. Надо знать стек технологий, распределенные отказоустойчивые системы, способы хранения данных, message broker, CQRS и так далее. Доклад Помодорова, там детали

= Денис Бесков. Радикальное ускорение аналитических работ методикой Event Storming =

Доклад из двух частей: проблемы классического подхода и Event Storming как метод решения этих проблем. Проблемная лично часть для меня - достаточно понятно и давно известна. Тем не менее, классические постановки по цепочке бизнес - модель бизнеса - требования - модель системы - система по-прежнему широко используются, потому что именно они положены в основу многих методологий. Именно поэтому фокусировка на этих проблемах - ценная часть доклада. Проблемы таковы.
1) Длинная цепочка преобразований, которая идет с искажением информации, особенно когда ситуация в бизнесе меняется в ходе проекта и надо изменить уже проработанные постановки.
2) Интервью с заказчиком дают противоречивую информацию, выявление противоречий и согласование - непросто и небыстро, особенно если интервью параллельно ведут несколько специалистов.
3) Описания бизнес-процессов в формальных нотациях (ARIS, IDEF0, BPMN, UML) непонятны заказчикам, они не могут их верифицировать, при этом создается ложное ощущение полноты информации. То же касается структур данных - диаграмм классов и ER-диаграмм. Впрочем, я лично тут не до конца согласен: да. полные нотации действительно непонятны, но если использовать ограниченные нотации и вести коммуникацию, то верификацию можно получить. 
4) Требования часто скрытым образом содержат частные проектные решения, выработанные конкретным аналитиком, и неясно, что в них обусловлено предметной областью, а что - доопределено им произвольно. При этом решения являются фрагментарными, локальными.
5) Функциональные требования дают плохую основу для декомпозиции системы, так как не дают представления о структуре системы.

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

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

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

Отметим, что такое представление о предметной области хорошо совместимо с современными шаблонами реализации. основанными на независимых сервисах, управляемой событиями (event sourcing) и сообщениями, и разделяющем чтение информации и команды (CQRS). 

Применение начать лучше внутри команды, для синхронизации контекстов и онбординга новичков. А далее можно попробовать с лояльным клиентом на небольшом проекте. получить опыт и расширять использование, делиться с коллегами. Event storming хорошо применим для большинства проектов. В нем нет необходимости для простых систем с CRUD операциями и слабой бизнес-логикой. Для отчетных систем есть модификация model storming - там нужен фокус на данных и их обработке. 

Источники на русском - Сергей Баранов и Евгений Пешков, на английском - Брандолини и khononov (в процессе перевода).
{{wl-publish: 2023-09-17 14:46:22 +0300 | MaksTsepkov }}