Как организовывать команды разработки Именно так называется короткая брошюра Дейва Фарли, которую я изучил. На 7 страницах он собрал ключевые моменты, которые стоит учитывать при дизайне команд.

Оптимальный размер команды: 5-9 человекТакие небольшие команды более эффективны и создают более качественный код. Дальше начинается чрезмерная когнитивная нагрузка и комбинаторная сложность в коммуникации.

Структура команд должна быть спроектирована с учетом закона КонвеяОб этом я писал здесь.

Team first подходОсновная рабочая единица – это команда, а не отдельный человек. Вокруг команды все и строится. Начать стоит с выравнивания команд с ограниченным контекстом (bounded context) по DDD так, чтобы каждая команда отвечала за свой кусок ценности. Сами команды рекомендуется привести к типам из Team Topologies.

Команды должны быть автономныОни должны уметь выполнять максимально полную часть работы, без необходимости в передаче работы между командами. В эту работу, помимо написания кода, входит: инфраструктура и эксплуатация, метрики и мониторинг, тестирования и QA, безопасность и вообще все, что нужно для разработки продукта. О кросс-функциональных автономных командах говорили уже из каждого утюга, но мы все еще часто встречаем такие антипаттерны: ▪️одна команда пилит back, а другая front; ▪️ответственность за архитектуру находится вне команды; ▪️за качество кода отвечает отдельная команда тестирования…

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

Меня зацепила цитата из State of DevOps, которая отражает большой процент проблем во взаимодействии команд: "Залог успеха – способность команды принимать решения и добиваться прогресса, не координируя свои действия и не спрашивая разрешения у людей вне команды"

Остается вопрос, хотят ли такой свободы и ответственности сами команды…