Почему я предпочитаю Squads с Swarming, а не Feature Teams

Dec 01 2022
TLDR; Когда я говорю, что не являюсь поклонником модели Feature Teams, некоторые люди могут подумать, что это следствие отсутствия делегирования полномочий или даже организационного консерватизма. Это не то.

TLDR; Когда я говорю, что не являюсь поклонником модели Feature Teams, некоторые люди могут подумать, что это следствие отсутствия делегирования полномочий или даже организационного консерватизма. Это не то. В основном ради эффективности я предпочитаю отряды (т. е. автономные команды, специализирующиеся на бизнес-темах/ограниченных контекстах), НО в сочетании с методом роения, когда это необходимо. Предупреждение: этот пост также содержит мини-разглагольствования против печально известного Маневра Обратного Конвея ;-)

Эта статья следует за моей предыдущей публикацией ( Является ли DDD правой? ) , в которой говорилось о проектировании, управляемом доменом, и различных организационных проблемах. Статья, в которой я очень кратко упомянул, что не являюсь поклонником Feature Teams. Я объясню здесь, почему.

Затерянный мир Feature Teams

Я уже испытал причуду, когда все клялись фиче-командам. Это было в 2010-х, и большинство крупных организаций действительно думали, что это спасет их от проблем с культурой (), от их технического долга, а также от их бюрократической тяжести. Принцип прост: мы формируем клиентоориентированную команду, многопрофильную, но стабильную, перед которой будут регулярно ставиться разные задачи. Разные миссии, но каждый раз вокруг определенной функциональности, которой команда будет управлять одна от начала до конца (вертикальная нарезка). Для этого специализированная группа сможет в одиночку вмешиваться во все компоненты, которые будут стоять на пути (спереди, сзади, инфра, db и т. д.).

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

Предупреждение: понятие «функция» в функциональной группе не означает, что она отвечает за конкретный бизнес-домен (который будет ее специализацией). Нет, понятие «фича» скорее соответствует единице работы команды (которая может регулярно меняться). Специализированная команда немного похожа на A-Team: автономная команда, которая решает возникающие проблемы (в начале каждого эпизода) и постоянно меняет тему перед тем, как отправиться в новые приключения.

Специализированные команды — это команды А…

Но беда приходит, когда…

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

  • Проблемы параллелизма между командами при кодировании одного и того же компонента
  • Разнородная кодовая база, заканчивающаяся множеством различных подходов к проектированию. Это приводит к тому, что код становится сложнее читать/понимать/обслуживать/развивать (столкновение культур разработчиков?)
  • Краткосрочные ориентированные проекты, когда люди уделяют меньше внимания долговечности и ремонтопригодности полученного кода. Как если бы это было почти неотъемлемой частью их заявления о миссии.

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

Так. Как нам справиться со всеми этими трудностями?

Модель «отрядов» Spotify

Поэтому неудивительно, что в последующие годы появилась модель «отрядов» Spotify. Это началось с концепции междисциплинарной и стабильной команды (например, Feature team), но люди Spotify пошли дальше в аспекте автономии.

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

И не поймите меня неправильно: «Отряд» — это не просто «крутой» термин для обозначения команды. Отряды - это АВТОНОМНЫЕ команды. Мы даем им миссию, которая будет длиться с течением времени, и мы попросим их самостоятельно взять на себя ответственность за свой бизнес Домен.

Домен, над которым работает команда, должен уместиться в голове каждого

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

Примечание: работа над автономией для команд — одно из моих увлечений, о чем я недавно говорил в статье «Как не допустить, чтобы ваше стремление к автономии команд превратилось в хаос…

Squads и DDD: фантастический дуэт для решения сложных задач бизнеса

Автономия действительно является точкой соприкосновения между моделью «Отряды» и проектированием, управляемым предметной областью (DDD). Действительно, последнее предполагает, что мы согласовываем наше программное обеспечение с потребностями Доменов и разделяем наш продукт на разные автономные, но связанные «области», называемые Ограниченными Контекстами (например, Бухгалтерский учет, Продажи, Поиск и т. д.). Предполагается, что эти ограниченные области/контексты дают нам больше свободы и автономии для предоставления ценности (например, мы не обязательно хотим влиять и спрашивать мнение специалистов по маркетингу, когда мы меняем часть, касающуюся бухгалтерского учета). Подробнее о том, что такое DDD, можно посмотреть здесь ( Domain Driven Design объясняется за 3 минуты ).

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

Прежде всего, нам нужно хорошее время для выхода на рынок и автономные команды в принятии решений. Следовательно, мы соответствующим образом адаптируем нашу архитектуру, следуя границам нашей области. Наличие нескольких команд владельцев из одного и того же ограниченного контекста усложнило бы принятие каждого решения. BTW Domain Driven Design дал название ситуации, когда несколько команд используют один и тот же фрагмент кода: Shared Kernel .

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

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

Использование функциональных групп кажется неадекватным по существу для этой цели IMO.

В Агикапе

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

Но в отличие от ситуации со Spotify, где каждая команда (то есть «вся команда») действительно автономна в принятии решений, менеджеры по продуктам Agicap были теми, кто активно руководил фазой реализации разработки.

До сих пор это работало довольно хорошо. Особенно тот факт, что вместо владельцев продукта (PO) есть менеджеры по продукту, которые охватывают как этапы обнаружения, так и этапы доставки (очень эффективно).

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

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

Мы не «ресурсы», черт возьми!

Мое желание работать в автономных командах уходит корнями в середину 2000-х, когда я открыл для себя XP (экстремальное программирование) на работе. Я смог испытать мощь и локальную эффективность автономной команды XP в пилотном проекте в крупном инвестиционном банке. Невероятный опыт на стольких уровнях. Несколько лет спустя я также испытал разочарование от работы в крупной организации, которая не понимала динамику команд разработчиков и Dynamic Reteaming . Организация, которая снова и снова разбивала наши команды в соответствии с модными проектами.

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

Трата времени на перетасовку команд разработчиков сильно влияет на нашу эффективность. И еще: мы не машины! Мы люди с аффектами, связями и привязанностями, которые мы со временем переплетаем с нашими коллегами.

(

Маленькая скобка: Обратный маневр Конвея (ICM)

Это те самые причины, по которым некоторые из нас жалуются, когда слышат об обратном конвейерном маневре (ICM) . И я не говорю о том, что первоначальная версия ICM была прекрасной (т. е. «разрушала разрозненность, ограничивающую способность команды к эффективному сотрудничеству» ). Я говорю о том, как поколения консультантов превратили ICM в монстра Франкенштейна (то есть: « измените свою организацию, чтобы достичь своей целевой архитектуры» ).

По этой конкретной теме следите за предстоящей серией отличных статей от моего друга Сирилла ДЮПЮИДАУБИ (должны быть опубликованы очень скоро). Он был первым, кто предупредил меня об этом много лет назад, и объяснит, почему.

Некоторые люди, такие как Джон Катлер или Матиас ВЕРРАЕС ( Закон Конвея не применяется к жестким конструкциям ), уже поняли, что такие концепции, как обратный маневр Конвея, вероятно, были слишком амбициозными, учитывая функциональный и технический долг определенных архитектур:

« Наконец, легко сказать: «Просто усильте свои команды!» Даже с самыми лучшими намерениями это может быть непросто. Ваша текущая архитектура и организационная структура могут ограничивать ваши возможности. » ( Джон КАТЛЕРTBM 27/52: Уровни полномочий )

Некоторые из нас также говорят, что этот маневр неэтичен и чертовски наивен. Причина, по которой я даже говорю о мошенничестве для ICM.

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

Это тоже чертовски наивно, потому что скрытое лицо Айсберга, с которым вы столкнетесь, — это снова Культура. Вещь, знакомая таким энтузиастам управления изменениями, как я. Помните? Тот, кто съедает все стратегии за завтраком (ср. с Питером Друкером).

)

Сделав скобки на стороне человека, давайте вернемся к нашей основной теме: что Swarming может дать стабильным и автономным командам (например, Squad).

Роение: то небольшое дополнение, которое нам нужно для эффективной организации DDD

Хорошо. Во-первых: давайте объясним, что такое Swarming. Swarming похож на рабочую группу (поэтому временную), но в рамках которой мы с самого начала определили, кто будет нести ответственность за производственную поддержку любого полученного программного обеспечения (это еще более важно, если вы, как и мы, находитесь в «вы создаете это, вы запускаете его!» режим). Это проливает свет на множество коллективных дизайнерских решений и позволяет избежать известной ситуации при завершении оперативной группы: «Кстати: кто позаботится о поддержке того, что мы только что сделали вместе?!?» (долгое молчание ;-) Что касается оперативной группы, члены Роя приходят из нескольких разных команд и должны будут работать вместе, чтобы решить краткосрочную проблему (прежде чем вернуться к своей команде в конце дня).

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

Зачем нам Роение?

Если мы зайдем слишком далеко и неправильно поймем концепцию автономии, рекомендованную DDD, у нас может возникнуть соблазн спутать автономию с изоляцией. У нас также может возникнуть соблазн слишком сильно изолировать себя… Рассматривать каждую связь и каждое взаимодействие между BC как абсолютное зло, которого следует избегать.

Я видел многих людей, попавших в ловушку: они перестали думать о других и сосредоточились только на своих собственных Ограниченных Контекстах, на своей собственной команде. Легко забыть, что мы являемся частью экосистемы, в которой каждая часть играет свою роль, и где взаимодействия должны быть ограничены (конечно) (с точки зрения поверхности воздействия), но не должны игнорироваться. Наша работа должна быть полезной и используемой. Все (продакт-менеджеры, разработчики) мечтают о ситуации, когда нам никогда не понадобятся другие команды/BC, чтобы двигаться вперед и приносить пользу. Но все мечтают…

Тем не мение. Ничто из этого не соответствует тому, что говорит нам DDD. Вместо этого DDD хочет, чтобы каждый ограниченный контекст был, конечно, максимально автономным, но, тем не менее, полезным для нужд наших пользователей. Для этого нужно грамотно соединить разные БК, а не полностью скрывать их друг от друга. Именно для этого и предназначено большинство стратегических шаблонов DDD: помочь нам безопасно разрешить эти взаимодействия между BC.

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

Роение также может помочь нам выжить в ситуациях, когда наши БК еще не определены. Перед уточнением Домена или Карты контекста.

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

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

В заключение: Роение FTW!

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

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

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

Следующие шаги

Сегодня в Agicap технические специалисты очень близки со своими менеджерами по продуктам. Но следующим шагом на нашем пути к постоянному совершенствованию будет то, что менеджеры по продукту будут вовлекать технических специалистов еще раньше во время их открытия (знаменитый «сдвиг влево» для технических специалистов).

Я также хотел бы, чтобы мы начали рассматривать двойные пути непрерывного обнаружения / непрерывной доставки, столь дорогие Марти Кейгану и Джеффу Паттону. Это должно позволить нам еще больше направлять нашу энергию и инженерные силы ТОЛЬКО на проверенные идеи наших клиентов. Для дальнейшего улучшения соотношения затрат и результатов наших действий.

«Увеличивайте ценность, минимизируйте усилия» (Джефф Паттон)

Но это будет темой будущих постов, я думаю.

Томас ПЬЕРРЕН (вице-президент по инженерным вопросам в Agicap)

Чтобы узнать больше об Agicap:

  • Покажите мне свой домен ( сеанс контекстной карты мониторинга и прогнозирования денежных потоков )
  • https://agicap.com/
  • https://career.agicap.com/