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

Рис.1 “Обложка книги”

Недавно вышла интересная книга Team Topologies, которая предлагает использовать Team-First подход при проектировании архитектуры программных систем, так и организации.

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

А вообще книга состоит из трех частей

  • Команды как средство доставки
  • Топологии команд, которые работают на ускорение потока
  • Эволюция взаимодействия команд для инновация и быстрой доставки

В каждой из частей по 3 главы, представленных ниже.

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

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

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

Для того, чтобы обойти проблемы формальной оргструктуры иногда выделяют и другие важные оргструктуры. Например Niels Pflaeging, автор книги “Organize for Complexity” выделяет следующие три структуры.

Рис.5 “Структуры внутри организации по книге Organize for Complexity, by Niels Pflaeging”

Причем последние две, неформальная структура влияния и структура создания ценности являются основными для понимания как работает организация. Подход Team Topologies учитывает важность этих структур и помимо этого добавляет динамику в эволюцию организации на основе обратной связи. Он предлагает новый способ размышлений относительно команд —чуть раньше мы уже упоминали про 4 типа команды + 3 типа взаимодействий, а дальше мы рассмотрим это подробнее. Книга во многом основывается на законе Конвея

Организации проектируют системы, которые копируют структуру коммуникаций в этой организации

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

И цель книги “Team Topologies” в том, чтобы дать вам правильный подход и инструменты для решения указанных выше проблем, а точнее

The goal of Team Topologies is to give you the approach and mental tools to enable your organization to adapt and dynamically find the places and timing when collaboration is needed, as well as when it is best to focus on execution and reduce communication overhead.

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

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

[Conway’s law] creates an imperative to keep asking: “Is there a better design that is not available to us because of our organization?”

— Mel Conway, Toward Simplifying Application Development, in a Dozen Lessons

и покажем пример как организация команд трансформируется в соответствующую архитектуру. Представим, что у нас есть четыре команды: A, B, C, D. В этих командах есть фронтендеры и бекендеры, но вот для организации слоя хранения бекендеры из всех команд должны общаться с централизованным DBA. Эта схема работ представлена на рисунке ниже.

Рис.7 “Поток работ четырех команд”

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

  • UI слой — отдельные по командам
  • слой приложений — отдельные по командам
  • общая база данных — так как DBA был общий

Эта архитектура выглядит как на картинке ниже.

Рис.8 “Архитектура приложения тех же четырех команд”

Видно, что она является повернутой на 90 градусов структурой команд. Как мы знаем такая архитектура имеет целый ряд недостатков, включая высокий coupling, сложность расширения и поддержки и т.д. Поэтому часто у компаний есть желание спроектировать и реализовать систему более качественно. А с этим может помочь инвертированный маневр Конвея (“inverse Conway maneuver”)

Organizations should evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done — from design through to deployment — without requiring high-bandwidth communication between teams.

В примере выше мы могли бы применить это следующим образом. У нас была бы целевая архитектура с независимыми сервисами с подходом“shared nothing”

Рис.9 “целевая архитектура с независимыми сервисами с подходом“shared nothing””

И для такой архитектуры нам нужна следующая структура команд

Рис.10 “Целевая структура четырех команд”

А вообще классно знать какие архитектурные практики поддерживают структуру команд, ориентированную на поток выполнения работ. Оказывается это все те же практики, которые обеспечивают хорошую архитектуру систем:

- Loose coupling — components do not hold strong dependencies on other components
- High cohesion — components have clearly bounded responsibilities, and their internal elements are strongly related
- Clear and appropriate version compatibility
- Clear and appropriate cross-team testing

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

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

Теперь время перейти к следующей главе.

Team-First Thinking

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

By team, we mean a stable grouping of five to nine people who work toward a shared goal as a unit. We consider the team to be the smallest entity of delivery within the organization. Therefore, an organization should never assign work to individuals; only to teams. In all aspects of software design, delivery, and operation, we start with the team.

Обычно стремятся ограничить размер команды максимумом в 7–9 человек, которых можно накормить двумя пиццами. Но не всегда это получается и зачастую важно знать, а как дальше масштабировать команды. С этим может помочь исследования антрополога Данбара, который предложил

Число Да́нбара — ограничение на количество постоянных социальных связей, которые человек может поддерживать.

Вот так они выглядят

Рис.11 “Числа Донбара”

И вот что значат

- Around 5 people — limit of people with whom we can hold close personal relationships and working memory
- Around 15 people — limit of people with whom we can experience deep trust
- Around 50 people — limit of people with whom we can have mutual trust
- Around 150 people — limit of people whose capabilities we can remember

И вот как эти числа раскладываются на команды

- A single team: around five to eight people (based on industry experience). In high-trust organizations: no more than fifteen people
- Families (“tribes”): groupings of teams of no more than 50 people. In high-trust organizations: groupings of no more than 150 people
- Divisions/streams/profit & loss (P&L) lines: groupings of no more than 150 or 500 people

Также важно понимать модель командообразования Такмана

Рис.12 “Модель Такмана”

Это простая модель, показывающая связь эффективности команды от стадии ее жизненного пути, которых изначально выделялось четыре:

  • forming — формирование команды
  • storming — шторм мнений и точек зрения
  • norming — нормализация работы
  • performing — команда “тащит”:)

а потом добавился еще пятый этап adjourning, на котором команда распадается. Модель интересная и полезная, но дальнейшие исследования показали, что эффекты storming присутствует в команде на протяжении всей ее жизни.

Для команд очень важно ограничивать когнитивную нагрузку, которая на них приходится. Когнитивную нагрузку хорошо описал психолог John Sweller как

the total amount of mental effort being used in the working memory

Он выделил 3 вида когнитивной нагрузки

  • Внутренняя когнитивная нагрузка (intrinsic) — относится к аспектам фундаментальным относительно пространства проблемы. Например, как выглядит структура Java классов или как создать новый метод
  • Посторонняя когнитивная нагрузка (extraneous) — относится к окружению, в котором выполняется задача. Например, как задеплоить этот компонент или сконфигурировать этот сервис
  • Уместная когнитивная нагрузка (germane) — относится к аспектам задачи, которая требует специального внимания к обучения или высокой эффективности. Например, как этот сервис будет взаимодействовать с сервисом ABC

Эту когнитивную нагрузку важно учитывать при формировании команд и подсистем, за которые они отвечают

Limiting the cognitive load for a team means limiting the size of the subsystem or area on which the team works, a tactic suggested by Driskell and colleagues in their research paper: “For those settings in which effective teamwork is critical, it may be necessary to structure the task to make it less demanding (i.e., by delegating subtasks), so that attention can be maintained on essential task and teamwork cues.”

Ограничивать когнитивную нагрузку можно используя подход с относительной сложностью доменов предметной области. Подробнее про домены можно почитать в книге “What Is Domain-Driven Design?

Есть следующие эвристики для маппинга между доменами и командами

  • Назначать каждый домен отдельной команде
  • Одна команда может быть ответственной за несколько “простых” доменов (до трех)
  • Команда, отвечающая за комплексный домен, должна отвечать только за этот комплексный домен
  • Одна команда не должна отвечать за два комплексных домена

Вот как выглядит стандартный маппинг между системами и командами и тот, что получается при Team-First подходе, который пропагандируется в книге.

Рис.13 “Маппинг между системами и командами — стандартный vs Team-First”

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

  • Обеспечить эффективное рабочее окружение — место общения команды, как едного целого
  • Уменьшить влияние отвлекающих факторов, лишних встреч, писем или тикетов из саппорта
  • Изменить стиль менеджмента на обсуждение целей и результатов вместо предписания конкретного способа выполнения работы
  • Повысить качество опыта разработчиков (developer experience) посредством использования кода и API с хорошей документацией, консистентностью, хорошим UX и инженерными практиками
  • Использовать платформу, которая специально создана для облегчения создания софта на ее основе

Автор классно определяет Team API, к которому требуется стремиться командам и который включает

- Code: runtime endpoints, libraries, clients, UI, etc. produced by the team
- Versioning: how the team communicates changes to its code and services (e.g., using semantic versioning [SemVer] as a “team promise” not to break things)
- Wiki and documentation: especially how-to guides for the software owned by the team
- Practices and principles: the team’s preferred ways of working
- Communication: the team’s approach to remote communication tools, such as chat tools and video conferencing
- Work information: what the team is working on now, what’s coming next, and overall priorities in the short to medium term
- Other: anything else that other teams need to use to interact with the team

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

В этой статье мы успели обсудить только первую часть книги, а именно “Teams as the means of delivery”. Продолжение можно прочитать в двух статьях:

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.