Вводная
Я работаю над программным обеспечением с микросервисной архитектурой. Для примера предположим, что мы занимаемся системой, которая помогает врачу лечить домашних животных других людей. Целевая система это здоровые домашние животные.
В посте я фокусируюсь на архитектуре фича-команд, команд которые доставляют ценности, команд которые создают части нашей системы - программное обеспечение. Не пишу о том, что в окружении, а там у нас есть и визионеры, инженеры платформы управления.
Проблематика
Сейчас команды деляться у нас по ролям пользователей, “Команда клиентов” и “Команда врачей”.
Первая текущая проблемы - это высокая связанность команд, и клиенты и врачи работают с доменами “наблюдение за животными”, “жизненные показатели животных”, “статистика лечения животного”. Как следствие этого разделения у нас не всегда удается понять кто будет ответственен за новую часть системы и могут возникнуть даже дубли каких то частей, например “модуль статистики лечения для врача”, “модуль статистики лечения для клиента”. Решение тут - другая разбивка команд по доменам.
Вторая текущая проблема - это увеличение количества людей в команде настолько, что много времени у нас уже уходит на координацию между людьми. Решение тут - создание трех или четырех команд.
Варианты
Сейчас у нас два варианта деления команд после нескольких встреч по обсуждению проблематики.
Первый (1) - делимся на доменные команды и выделяем кор(enabling)-команду.
Второй (2) - делимся по концепции run/change/disrupt.
Мне нужно сравнить оба варианта по разным критериям, чтобы совместно с коллегами сделать выбор. Приоритет у нас
- простое управление
- оптимизация работы
- меньшая связанность команд (в идеале одна команда делает одну задачу)
