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

Но нельзя забывать о Законе Конвея, согласно которому, архитектура проекта будет повторят структуру организации. Таким образом менеджмент влияет на крупноблочную компоновку проекта сильнее чем архитектор.

Сейчас чаще стали говорить про Закон Конвея, учитывать его при формировании структуры команд и закладывать мероприятия по изменению текущей оргструктуры в соответствии с целевой архитектурой.

При определении скоупа ответственности команд есть несколько подходов. Устоявшийся в DDD – за конкретный контекст отвечает одна команда, а иногда не только отвечает, но и вносит изменения. Такой подход объясняется тем, что контекст инкапсулирует логику и содержит в себе модель, единый язык, какие-то неявные предположения. Команда, незнакомая с контекстом легко разрушит консистентность модели и языка, что приведет к деградации контекста. Вернон в своей книге явно высказывается за такой подход.

Чем плох такой подход:
1. Зависимости при e2e реализации фичи. Обычно задачи не ограничиваются одним контекстом. Возникает необходимость менеджить зависимости.
2. Неоптимальная нагрузка: команда А может умирать, работая над критичным сервисом, а команда Б будет полировать сервис, который прямо сейчас особо и не нужен. При этом команда Б не может помочь, так как зачастую нет достаточной экспертизы.
3. Контексты могут фризиться и умирать. Появляются новые. Команды тоже могут умирать и появляться. Необходимо балансировать нагрузку.

С другой стороны есть подход фреймворка LeSS – все работают везде. Здесь плюсы и минусы просто переворачиваются. Отдельно хотелось бы отметить когнитивную нагрузку. Разработчикам может быть неэффективно и очень некомфортно работать над огромной кодовой базой.

Все вышесказанное уместно и для микросервисов.

А как у вас? Какой подход вам ближе? Как работаете с перечисленными недостатками? Какие плюсы и минусы видите еще?

Пост навеян статьей и книгой Team Topologies