Мы открывали конференцию по инженерной культуре и практикам
DevOops 2021 с воркшопом про топологии платформенных команд. Конференция проходила с 8 по 11 ноября в онлайн формате и хорошо нам знакома, наш эксперт,
Игорь Курочкин, выступал в 2019 году с
рассказом про Team Topologies.
Перед воркшопом мы провели опрос участников, чтобы понять целевую аудиторию и собрать
проблемы платформенных команд. Опрос заполнило 26 участников, половина не слышала про книгу и топологии команд, а также не использовала платформенные команды. Основной проблемой отметили
взаимодействие платформенных и инфраструктурных команд с другими командами.
Это наш первый онлайн воркшоп, мы использовали Miro и Zoom, а воркшоп разделили на две части - теоретическую в виде выступления с презентацией, а для практической части использовали общую рабочую доску в Miro.
В теоретической части:
- Дали определение для внутренней платформы, платформенной команды и топологий команд. Под внутренней платформой рассматривали внутренний продукт, который предоставляет командам стандартизированные, повторно используемые сервисы и возможности, которые снижают операционную и техническую сложность. Платформенная команда определялась как команда, которая развивает и сопровождает такую платформу и отвечает за создание условий для эффективной работы других команд. Топологии команд (Team Topologies) были представлены как способ осознанного проектирования структуры команд и их взаимодействий;
- Рассказали какие практики и паттерны входят в подход Team Topologies. Показали, что Team Topologies — это не только классификация команд, а целостный подход, включающий паттерн Team First (команда как минимальная единица), учет когнитивной нагрузки (Team Cognitive Load), ориентацию на поток изменений (Flow of Change), типы команд и допустимые способы взаимодействия между ними. Отдельно проговорили, что топологии не являются статичными и должны эволюционировать вместе с организацией, ее целями, архитектурой и уровнем инженерной зрелости.
- Рассмотрели Team First паттерны для оценки состояния команд. Команду рассматривали как устойчивую, небольшую, кроссфункциональную единицу с общей целью и end-to-end ответственностью. Обсудили ограничения по размеру команды, стабильность состава, соответствие стадиям развития по Такману, автономность и наличие всех необходимых компетенций;
- Обсудили когнитивную нагрузку на платформенные команды. Разобрали когнитивную нагрузку как совокупность всего, что команда должна удерживать в голове: количество сервисов и доменов, легаси и новые системы, дежурства, инциденты, деплой, тестирование, коммуникации, тикеты и митинги. Показали, что платформенные команды часто перегружены, так как совмещают развитие платформы, поддержку, on-call и обучение. Обсудили практические способы снижения нагрузки за счет разделения ответственности, изменения границ команд и перераспределения функций;
- Показали как использовать VSM для поиска потерь и зависимостей. Использовали VSM как инструмент для анализа. Показали, как размещать команды вдоль потока и выявлять места передачи работы между командами, ожидания и зависимости, которые замедляют поставку. Обсудили, что передача задач и артефактов между командами почти всегда является источником потерь и сигналом к пересмотру топологии или способов взаимодействия;
- Рассмотрели базовые типы команд в подходе Team Topologies и обсудили переход к таким командам. Разобрали четыре фундаментальных типа команд: потоковые команды, платформенные команды, экспертные команды и команды сложных подсистем. Показали, какие реальные команды чаще всего попадают под эти определения, почему DevOps и SRE команды могут относиться к разным типам в зависимости от выполняемой функции, и почему совмещение нескольких типов в одной команде часто является индикатором перегрузки. Обсудили, что переход к этим типам — это процесс, а не одномоментная реорганизация;
- Построили матрицу целевых топологии с учетом инженерной зрелости и размера компании. Рассмотрели матрицу из четырех квадрантов, где по одной оси инженерная зрелость, а по другой — размер компании или системы. Показали, как на ранних этапах доминируют специализированные команды, а с ростом зрелости и масштаба появляются автономные потоковые команды, платформенные и экспертные enabling команды. Отдельно подчеркнули, что матрица — это ориентир, а не целевое состояние для всех, и что избыточная сложность на ранних стадиях вредна;
- Обсудили паттерны и антипаттерны способов взаимодействия. Разобрали три допустимых способа взаимодействия команд: ограниченное сотрудничество, взаимодействие как сервис и ограниченная поддержка. Показали, какие ожидания и паттерны поведения они формируют, и почему постоянное сотрудничество или постоянная поддержка являются антипаттернами. Обсудили эволюцию взаимодействий, когда команды переходят от сотрудничества и поддержки к self-service модели;
- Разобрали топологии таких компаний как Uchi.ru, X5 FoodTech, Yandex. На реальных кейсах показали, как применение Team Topologies помогает выявить избыточные зависимости и неэффективные способы взаимодействия. Разобрали эволюцию топологий со временем, роль платформенных и enabling команд в снижении когнитивной нагрузки и ускорении потока изменений, а также возможность применения подхода локально, не на уровне всей организации, а в пределах конкретного контура взаимодействий.
Практическая часть воркшопа состояла из 12 шагов и включала построение
AS-IS и
TO-BE топологий, диагностику команд на соответствие
Team First паттернам, оценку когнитивной нагрузки и определение способов взаимодействия платформенных команд.
Теорию послушали и посмотрели 193 участника, на практику осталось 91 участник, в результате построили 12 топологий на общей доске в Miro.
Отзывы участников:
- "Хорошее выступление. Хотелось бы услышать спикеров еще, с большим таймингом";
- "Очень важная тема. Интересный, насыщенный доклад";
- "На конференцию шел только ради этого доклада";
- "В целом понравилось как описали, старались нормально в рамках времени ответить на вопросы".