В современном мире скорость поставки новой функциональности является определяющим критерием успеха ИТ-команд. Как правило, основными негативными факторами здесь являются дефицит ресурсов (времени, людей) и избыточная коммуникация для координации. Сегодня я хочу рассказать о прогрессивном подходе к организации команд, призванном ускорить поставки новой функциональности.

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

Потоковая команда - это коллектив, ориентированный на единый, значимый поток работы. Команда уполномочена создавать и предоставлять потребительские или пользовательские ценности как можно быстрее, безопаснее и независимей, не требуя передачи другим командам части работы для выполнения. (Skelton M., Pais M. Team Topologies. — IT Revolution, 2019)

Традиционный подход

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

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

Отказ от традиционного подхода

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

Построение потоковых команд

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

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

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

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

Слабо связанные команды

Общими характеристиками автономных, слабо связанных команд, по мнению авторов книги "Ускоряйся!", являются возможности:

• Вносить крупномасштабные изменения в проект своей системы без разрешения кого-либо за пределами команды;

• Вносить крупномасштабные изменения в проект своей системы, не полагаясь на то, что другие команды будут вносить изменения в свои системы, и не создавая значительного фронта работ для других;

• Завершать свою работу, не общаясь и не координируя свои действия с людьми, не входящими в их команду;

• Развертывать и выпускать свой продукт или сервис по требованию, независимо от других сервисов, с которыми он взаимодействует;

• Проводить большую часть своего тестирования по мере необходимости, не запрашивая интегрированной тестовой среды;

• Выполнять развертывания в обычное рабочее время с минимальным временем простоя.

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

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

Существует множество изменений, которые следует рассмотреть на пути к построению потоковых команд. Я выделю следующие моменты:

• Взаимосвязь между организацией и архитектурой;

• Размеры команд;

• Типы моделей владения;

• Роль платформы;

Взаимосвязь между организацией и архитектурой

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

Любая организация, разрабатывающая систему, неизбежно создаст проект, структура которого будет копией коммуникационной структуры организации.

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

Размер команды

Небольшие команды работают быстрее, чем чем большие. Данное утверждение привело к появлению термина команд на две пиццы. Суть его заключается в том, что максимальный размер команды должен быть таким, чтобы ее можно было накормить двумя пиццами. Это не очень полезная единица измерения, однако смысл в том, что оптимальный максимальный размер команды - 8 человек. Эта команда должна быть ориентирована на клиента и владеть всем жизненным циклом своих сервисов. Было проведено научное исследование (Rodriguez D., Sicilia M. A., Garcia E., Harrison R. Empirical Findings on Team Size and Productivity in Software Development), результаты которого показали, что производительность труда имеет наихудшие показатели для команд, чья численность 9 и более человек. В книге "Думай как Amazon" есть замечательная цитата Джона Россмана про команды на две пиццы:

«Команда на две пиццы» автономна. Взаимодействие с другими командами ограничено, а когда оно происходит, то хорошо документируется, а интерфейсы четко определены. Она владеет всеми аспектами своих систем и несет за них ответственность. Одной из основных целей стало снижение накладных расходов на коммуникации в организациях, включая количество совещаний, координационных центров, планирование, тестирование или выпуски. Более независимые команды работают быстрее.

Типы моделей владения

Выделяют две основные модели владения кодом - сильное и коллективное владение.

• Сильное владение
  Команда владеет микросервисом и сама решает, когда и какие изменения в него вносить. Если сторонняя команда хочет внести изменения в этот микросервис - ей необходимо отправить запрос на изменения команде-владельцу. Команда может владеть более чем одним микросервисом.

• Коллективное владение
  Любая команда может изменить любой микросервис. Необходима тщательная координация, чтобы не мешать другим командам.

При сильном владении команда сама принимает решения о стандартах и применяемых технологиях. Данная модель владения повышает автономность команд. Чем более сильную модель владения может принять команда, тем меньше требуется координации, и следовательно, тем более продуктивным может быть коллектив.

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

Роль платформы

Дополнительно к общей концепции команд поддержки, потоковым командам потребуется набор инструментов самообслуживания, позволяющим им выполнять свою работу - это платформа.

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

Платформе также требуется команда, которая будет управлять ее жизненным циклом. Команда платформы должна выяснять, с какими трудностями сталкиваются ее пользователи (программисты потоковых команд), и находить решения.

Заключение

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