«DDD — правая штука!»

За этим провокационным заявлением (идеально подходящим для проведения сеанса unconf и привлечения людей) Саймон Шавено хотел задать себе вопрос о влиянии проектирования, управляемого предметной областью (DDD), на нашу организацию (Product-Tech) по производству программного обеспечения. Это произошло во время нашей первой не-конференции в Agicap, организованной для того, чтобы позволить специалистам по продукту и техническим специалистам встретиться для обсуждения, обучения, обмена мнениями, смеха и, прежде всего, повышения уровня нашей повседневной жизни.

Во время неконференции программа устанавливается аудиторией. Это делается во время начальной сессии «Market Place» утром. Во время этого первого пленарного заседания каждый может взять стикеры, маркер, а затем рассказать о своих сессиях перед всеми. Затем люди помещают их в программу дня (для получения дополнительной информации об этой неконференции есть эта ветка в твиттере )

Но вернемся к теме и интригующему сеансу, предложенному Саймоном.

Господство частной собственности?

Подводя итог первоначальному заявлению Саймона: если целые разделы нашей ИС принадлежат командам, каждая из которых отвечает за один или несколько ограниченных контекстов (BC), не сталкиваемся ли мы с программной версией частной собственности (с колючей проволокой вокруг BC и т. д.). .)? Отсюда и его провокационное « ДДД — правая штучка!

И второстепенный вопрос: «Не были бы мы более эффективны с организацией, основанной на фиче-командах? (при этом каждый может работать со всеми BC на пути к своим вариантам использования)»

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

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

Несколько наблюдений

• Эффективное программное обеспечение — это программное обеспечение, отвечающее бизнес-задачам . Под согласованным мы подразумеваем программное обеспечение, которое заимствует правильные термины из предметной области, которое правильно формулирует ключевые концепции бизнеса и как можно меньше вызывает случайную сложность, вызванную техническими проблемами. Это одна из основных проблем проектирования, управляемого предметной областью (DDD), как объясняется здесь за 3 минуты .
• Закон Конвея — это не тот вариант, которым можно было бы не воспользоваться. ‍♂️ Он немного похож на некоторые физические законы, такие как притяжение гравитации. Можно попытаться с этим бороться ;-) но на земле это все еще актуально. Закон Конвея — это закон 1967 года, который гласит, что
  «Любая организация, разрабатывающая систему (определяемую в широком смысле), создаст проект, структура которого является копией коммуникационной структуры организации».
  Иными словами, архитектура программного обеспечения обязательно является результатом способов общения людей, участвующих в его разработке. Например, компилятор, разработанный 3 командами, скорее всего, будет работать за 3 прохода или будет иметь 3 отдельных модуля.
• Обратный маневр Конвея (ICM) позволяет вам думать, что можно контролировать закон Конвея. Первоначально этот обратный маневр мудро рекомендовался для « разрушения разрозненности, ограничивающей способность команды к эффективному сотрудничеству». Но с годами трансформировался в глупую рекомендацию: « измените свою организацию, чтобы достичь своей целевой архитектуры ». Глупо, потому что помните: «Культура съедает стратегию за завтраком». Подробнее здесь, в этой интересной теме.
• Domain Driven Design не навязывает никакой организации. Он дает ключи к выживанию, в том числе в случаях неблагополучных организаций (с командами, которые находятся в состоянии войны или игнорируют друг друга). DDD помогает нам понять проблемы власти и социальные проблемы между командами. В результате это скорее инструмент освобождения от наших детерминизмов ( следовательно, левый инструмент, я бы сказал ;-)
• С другой стороны, DDD дает нам инструменты, позволяющие разрабатывать эффективное программное обеспечение, максимально согласованное с предметной областью. Среди них концепция ограниченного контекста (BC), которая предлагает нам разрабатывать модели для использования, окружать их и защищать от путаницы/ложных друзей/недоразумений, возникающих из других контекстов.
• Для большей согласованности и эффективности DDD также настоятельно рекомендует регулярно проверять наше видение и моделирование решения. Это также означает революцию и изменение моделей время от времени после озарения (так называемого прорыва в дизайне ). Вот почему мы регулярно проводим здесь сеансы контекстной карты, которые постоянно уточняют наше видение области с людьми, занимающимися продуктом.
• Команды разработчиков имеют хрупкий баланс. Требуется около 6 месяцев совместной жизни и межличностных отношений, чтобы команда разработчиков стала действительно эффективной. Вы добавляете или удаляете одного человека из этой команды, и это уже не та же самая команда (см. Динамическое повторное объединение ). С точки зрения эффективности я предпочитаю команды, которые остаются вместе и меняют темы, чем команды, которые просто взрываются/перераспределяются по темам. Конечно, если кто-то устал от своей команды или своих испытуемых, нужно сделать все, чтобы дать им возможность сменить команду (личное благополучие еще важнее для нашей коллективной эффективности).
• Наша текущая организация и наши команды здесь, в Agicap, скорее связаны с одним или несколькими ограниченными контекстами, чтобы принять во внимание сложность проблемы и извлечь минимальную выгоду из нашего соответствующего бизнес-опыта. Время от времени у некоторых команд может быть слишком большая область действия, и нам нужно лучше сократить и назначить наш ограниченный контекст. С другой стороны, это разделение бизнес-концепций должно оставаться связанным с бизнес-концепциями (вспомните DDD).
• Ничто не запрещает иметь фиче-команды в организации, которая занимается DDD , при условии, что все уважают границы ограниченных контекстов.
• В настоящее время мы предпочитаем практику Swarming (своего рода целевая группа, созданная из людей из нескольких команд, но где ответственность и право собственности на окончательный артефакт (инструмент, API, библиотека) определяются с самого начала. Это помогает чтобы избежать синдрома «Хорошо, мы что-то вместе делаем, но кто теперь это будет содержать?!?»). Помимо своей эффективности в привлечении нужных людей к сотрудничеству в зависимости от предмета, роение приносит большой социальный капитал нашей организации , временно продвигая межкомандные межличностные отношения (очень полезно в будущем, когда все вернутся в свою команду).
• Наша текущая организация продукта настроена на 1 менеджера по продукту (PM) на команду разработчиков, но, возможно, было бы интересно, чтобы менеджеры по продукту больше ассоциировались с бизнес-темами, чем со своей командой?

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

Примечание: этот пост является переводом французской статьи, написанной на прошлой неделе (14 октября 2022 г.)

Чтобы узнать больше об Agicap:

• Покажите мне свой домен ( сеанс контекстной карты мониторинга и прогнозирования денежных потоков )
• https://agicap.com/
• https://career.agicap.com/