Обзор книги “Топологии команд” (“Team Topologies”) — Часть I

Рис.1 “Обложка книги”
Рис.2 “4 типа команд и 3 вида их взаимодействия”
  • Топологии команд, которые работают на ускорение потока
  • Эволюция взаимодействия команд для инновация и быстрой доставки
Рис.3 “Содержание книги”

Команды как средство доставки

Проблемы с организационными диаграммами

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

Рис.4 “Оргструктура с горизонтальными связями, отображающими коммуникации”
Рис.5 “Структуры внутри организации по книге Organize for Complexity, by Niels Pflaeging”
Рис.6 “Препятствия на пути к быстрому потоку работ”

Закон Конвея и почему он имеет Значение

Про закон Конвея мы уже упоминали в первой главе, но во второй мы обсудим его подробнее и начнем с цитаты самого Мелвина

Рис.7 “Поток работ четырех команд”
  • слой приложений — отдельные по командам
  • общая база данных — так как DBA был общий
Рис.8 “Архитектура приложения тех же четырех команд”
Рис.9 “целевая архитектура с независимыми сервисами с подходом“shared nothing””
Рис.10 “Целевая структура четырех команд”
  • Коммуникации между командами обычно должны быть редкими по сравнению с тем, как проходить общение внутри команд
  • Коммуникации между сдвоенными командами проходят со средней интенсивностью — например, между командами, которые сотрудничают в рамках крупного проекта или значимой фичи

Team-First Thinking

В этой книге собственное определение команды

Рис.11 “Числа Донбара”
Рис.12 “Модель Такмана”
  • storming — шторм мнений и точек зрения
  • norming — нормализация работы
  • performing — команда “тащит”:)
  • Посторонняя когнитивная нагрузка (extraneous) — относится к окружению, в котором выполняется задача. Например, как задеплоить этот компонент или сконфигурировать этот сервис
  • Уместная когнитивная нагрузка (germane) — относится к аспектам задачи, которая требует специального внимания к обучения или высокой эффективности. Например, как этот сервис будет взаимодействовать с сервисом ABC
  • Одна команда может быть ответственной за несколько “простых” доменов (до трех)
  • Команда, отвечающая за комплексный домен, должна отвечать только за этот комплексный домен
  • Одна команда не должна отвечать за два комплексных домена
Рис.13 “Маппинг между системами и командами — стандартный vs Team-First”
  • Уменьшить влияние отвлекающих факторов, лишних встреч, писем или тикетов из саппорта
  • Изменить стиль менеджмента на обсуждение целей и результатов вместо предписания конкретного способа выполнения работы
  • Повысить качество опыта разработчиков (developer experience) посредством использования кода и API с хорошей документацией, консистентностью, хорошим UX и инженерными практиками
  • Использовать платформу, которая специально создана для облегчения создания софта на ее основе

P.S.

Неплохо дополняет книгу отчет 2021 State of DevOps Report от Puppet.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.