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

В этой статье я продолжу рассказывать про книгу Team Topologies, которая мне понравилась и про которую я рассказывал в предыдущей статье. В этой статье мы рассмотрим вторую частьи, а именно “Team topologies that work for flow”, а “Evolving team interactions” рассмотрим в последней статье из этой серии.

Статичные топологии команд

Для достижения максимальной эффективности нам надо сознательно дизайнить команды, а не просто позволять им формироваться по воле случая. Такие сознательно сформированные командные структуры называются в книге командными топологиями (team topologies). Этот термин признает то, что команды должны быть внутри организации и одновременно между ними должны быть границы по зонам ответственности. В этой главе приводятся эффективные топологии, но начинается она с привычных антипаттернов в формировании команд, которые стоит знать всем менеджерам:

  • Ad hoc дизайн команд — лучше всего этот подход характеризует ответ “так исторически сложилось” на вопрос “почему такая структура команд”
  • Перемешивание участников команд — здесь мы натыкаемся на стоимость переключений контекста и на повторное прохождение стадии storming в модели командообразования Такмана (подробнее в предыдущей части ревью этой книги).

Старый подход к организации работы выглядел так

Здесь каждый шаг работы выполнялся в своем функциональном юните и дальше передавался по цепочке. Этот процесс работал, но сейчас он не приспособлен к желаемой скорости и сложности изменений. На смену ему пришел подход со Stream-Aligned Team без разделения команды по функциям и с гораздо более быстрой обратной связью. Здесь мы не передаем работу по этапам, а работаем до конца внутри команды. Дальше публикуем результаты и получаем обратную связь об их использовании и на базе них делаем дальнейшие улучшения.

Дальше описывается DevOps движение, которое возникло в 2009 году и которое изначально ставило себе целью устранить барьер между разработкой (development) и эксплуатацией (operations). Основной вклад был следующим

A key contribution of DevOps was to raise awareness of the problems lingering in how teams interacted (or not) across the delivery chain, causing delays, rework, failures, and a lack of understanding and empathy toward other teams.

В 2013 году авторы книги Team Topologies выпустили каталог DevOps Topologies, который отражал 2 основные идеи

1. There is no one-size-fits-all approach to structuring teams for DevOps success. The suitability and effectiveness of any given topology depends on the organization’s context.

2. There are several topologies known to be detrimental (anti-patterns) to DevOps success, as they overlook or go against core tenets of DevOps. In short, there is no “right” topology, but several “bad” topologies for any one organization.

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

  • Feature команда с высоким уровнем инженерной культуры и доверия внутри — кросс-функциональная команда, которая может доставлять ценность самостоятельно без зависимостей от других команд. Если таких команд несколько и они меняют общую кодовую базу, то возникают риски накопления технического долга в общих компонентах. Но если технический уровень команд высок, их работа в основном сконцентрирована внутри их модулей, а общие компоненты они развивают продуманно, то эта схема может хорошо работать.
  • Продуктовым командам нужна поддерживающая система. Обычно эти команды напоминают feature команды, но работают над набором фич или систем. Здесь команда имеет очень много зависимостей и естественной когнитивной нагрузки. Зависимости должны быть неблокирующими, а когнитивную нагрузку требуется уменьшать. Неблокирующие зависимости часто реализуются через self services (создание тестовых сред, модификация CI/CD пайплайнов, настройка мониторинга, …). В общем создание продуктовых команд без этой self service обвязки приводит к куче проблем.
  • Cloud teams — эти команды создают не инфраструктуру для приложений, а как раз self services для продуктовых команд, чтобы они могли просто и унифицировано использовать облачные платформы.
  • SRE команды имеют смысл на большом масштабе.

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

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

Иногда можно разделить обязанности, чтобы разбить функциональные колодцы. Стандартный пример — это DBA, которые раньше отвечали за администрирование баз данных команд разработки, включая помощь с моделями данных и сложными запросами. В новом мире они обычно предоставляют DbaaS (Database as a Service), которым пользуются end-to-end команды, которые сами отвечают за свою модель данных и оптимизацию запросов.

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

Четыре фундаментальные топологии команд

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

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

  • Stream-aligned team — этот тип команд занимается одним значимым стримом работ, которым может быть продукт или сервис, набор фич или user journey. Команда нацелена на создание и доставку ценности пользователем как можно быстрее без необходимости в передачи части работ другим командам. Это основной тип команд в организации и цель других типов команд в том, чтобы сократить нагрузку ну stream-aligned teams.
  • Enabling team — цель этого типа команд в том, чтобы помочь stream-aligned teams в повышении их возможностей. Для этого enabling team состоит из специалистов определенного технического или продуктового домена, которые активно взаимодействуют со stream-aligned teams для того, чтобы выяснить какие у них есть проблемы и дальше помогают научиться их решать самостоятельно. Enabling команда не должна диктовать технические решения другим командам, а должна помочь им понять и соответствовать техническим правилам и ограничениям, принятым на уровне всей компании.
  • Complicated-subsystem team — этот тип команд отвечает за построение и поддержку частей системы, которые завязаны на специальные знания так, что большая часть членов команды должна быть специалистами в этой области знаний для понимания и изменения частей сложной подсистемы. Цель команды в том, чтобы снизить когнитивную нагрузку на stream-aligned команды, которые работают с системами, которые включают такие сложные подсистемы. Такие команды создаются только для сложных подсистем, поэтому их не должно быть много в организации.
  • Platform team — цель этого типа команд в том, чтобы дать возможность stream-aligned командам доставлять свою работу с значительной долей автономии. Stream-aligned команды полностью отвечают за разработку, эксплуатацию и исправление своего программного обеспечения. Платформенные команды предоставляют внутренний сервис для снижения когнитивной нагрузки, которая ложится на stream-aligned команды во время работы над их сервисами. Платформенные команды обычно фокусируются на предоставлении меньшего количества сервисов, но с высоким качеством, чем большого количества сервисов, имеющих проблемы в надежности и качестве. Интересно, что сами платформенные команды внутри могут состоять из 4 фундаментальных типов команд — получается некоторая фрактальная структура.

Stream-aligned teams

Вернемся к Stream-aligned teams, которые являются основными в организациях. Важно понимать, что у них должен быть полный набор компетенций:

- Application security
- Commercial and operational viability analysis
- Design and architecture
- Development and coding
- Infrastructure and operability
- Metrics and monitoring
- Product management and ownership
- Testing and quality assurance
- User experience (UX)

и их ожидаемым поведением является следующее

- A stream-aligned team aims to produce a steady flow of feature delivery.
- A stream-aligned team is quick to course correct based on feedback from the latest changes.
- A stream-aligned team uses an experimental approach to product evolution, expecting to constantly learn and adapt.
- A stream-aligned team has minimal (ideally zero) hand-offs of work to other teams.
- A stream-aligned team is evaluated on the sustainable flow of change it produces (together with some supporting technical and team-health metrics).
- A stream-aligned team must have time and space to address code quality changes (sometimes called “tech debt”) to ensure that changing the code remains safe and easy to do.
- A stream-aligned team proactively and regularly reaches out to the supporting fundamental-topologies teams (complicated subsystem, enabling, and platform).
- Members of a stream-aligned team feel they have achieved or are in the path to achieving “autonomy, mastery, and purpose” the three key components of engaged knowledge workers, according to Daniel Pink.

Platform teams

Платформенные команды помогают stream-aligned teams в достижении их целей. На масштабе это становится еще заметнее. Ожидаемое поведение платформенных команд такое

- A platform team uses strong collaboration with stream-aligned teams to understand their needs.
- A platform team relies on fast prototyping techniques and involves stream-aligned team members for fast feedback on what works and what does not.
- A platform team has a strong focus on usability and reliability for their services (treating the platform as a product), and regularly assesses if the services are still fit for purpose and usable.
- A platform team leads by example: using the services they provide internally (when applicable), partnering with stream-aligned teams and enabling teams, and consuming lower level platforms (owned by other platform teams) whenever possible.
- A platform team understands that adoption of internal new services, like new technologies, is not immediate, but instead evolves along an adoption curve.

Авторы говорят о том, что этих четырех типов команд хватает для того, чтобы структурировать работу внутри организаций. Если у вас есть другие типы команд, то есть смысл привести их к указанным выше типам. Они показывают как это сделать с инфраструктурными и support командами, где первые конвертируются в платформенные, а вторые работают ближе к stream-aligned teams, которые развивают софт, который поддерживают support teams.

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

Выбор team-first границ

Глава начинается с видов монолитов

и дальше продолжается тем какие могут быть подходы к проведению границ в программном обеспечении или как авторы называют это “fracture planes” (плоскости разрушения).

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

Вот мы и закончили вторую часть книги, а именно “Team topologies that work for flow”. В следующей статье будет обзор последней части этой интересной книги. Последняя часть называется “Evolving team interactions for innovation and rapid 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.