условно да

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

Мне оч нравятся все эти event storming что бы быстро все это дискаверить но с этим есть свои сложности особенно когда все на удаленке.

Спасибо большое.

Хотел как раз таки заняться event storming'ом в дальнейшем.

С разговора с руководителем проекта и менеждментом, предложив им это как решение определённых сложностей. Заведомо ответив на вопрос - зачем?

ты кстати провёл свой большой ивент-сторминг?

да, полный провал. Ну как... не полный но совершенно не то на что я расчитывал.

меняю стратегию, сначала череда маленьких process modeling а уже потом big picture на уже полу готовом борде

"Маша не ковыряйся в носу, когда я объясняю!"? :D
В смысле всех сосредоточить сразу не получилось?

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

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

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

А какие тулы использовал?

lucidchart board, teams. Для "парлельных обсуждений" на борде были размечены области (туда сразу key events разетили что бы таймлайн хоть какой был) и для каждой области сделали отдельную руму в тимс что бы люди могли свободно перемещаться (если фичу с брэйкаут румами в тимах сделают нормальной будет удобнее возможно).

В любом случае ивенты вешали только 4-5 человек из 20-ти присутствовавших. Остальные просто скучно наблюдали и может один стикер повесят. При этом поскольку что-то обсуждается постоянно нет возможности тихонько подойти к человеку и подсказать чего... через чат как-то не работает.

словом "быстро" не вышло. Будем делать медленно... Из положительного - вскрылось насколько сильно разные группы людей "не знают" продукт. А потому в целом нашлось N людей которые заинтересованы в том что бы такую штуку все ж добить.

У нас для подобного формата онлайн-дискуссий использовалась связка Miro + Zoom Breakout Rooms

ну тимс брэйкаут румы не позволяет людям переходить между комнатами а так разницы между miro и lucidchart особо нет (разве что мне miro нравится больше)

Гайз, вопрос наверное в раздел "безысходность и дзен" 🤙

Существует ли способ изящно управлять тем, какие фичи запустить в релиз на основе git?

Делать feature ветки из development и потом мержить их обратно, это понятная база. Но что делать, если было такох фичей несколько на релиз, и было принято решение не релизить одну из них в этот раз, потому что требования изменились, или забаговано так, что нужно переосмысление.

А если в рамках фичи сделался какой-то "фундаментал", которых использовали люди в рамках других фичей, потому что мы быстро делимся кодом в development?

Есть ли хороший релизный флоу? Что-то типа "у меня три фичи смержены в дев, сегодня резилим 2 из них". Ничего толкового не нагуглилось, все варианты на простые кейсы, типа что запланировали на "спринт", то и релизим.

Личный опыт или статья может?

Если следовать правилу один комит - одна фича, то можно черипикать их выборочно в релизную ветку из dev

А правилу этому следовать может помочь например gitlab, он умеет сквошить перед мержем, ну или личная культура 🙂

Feature toggle + branch by abstraction

Если в фиче А кто-то реализовал классный ValueObject, который использовали в фиче Б, а выбрали только фичу Б, черипик как-то разрулит это, или мы получим сломанную версию?