Компонентные команды и фичатимы — meamka.me

Компонентные команды и фичатимы

written by Andrey Maksimov on 2021-12-16

Исторически в more.tv мы работаем в командах сформированных по принципу единой платформы, над которой они работают. Проект в их случае - это не всё море, но его часть: backend, iOS, web и т. п. Каждая команда имеет строгую типизацию и владеет ограниченным набором языков для разработки, а так же ограниченный набор возможностей для влияния на весь продукт, однако, способна решать узконаправленные их платформе задачи наиболее эффективно. Нет более быстрого способа решить большую задачу для бэкенда нежели чем с помощью команды бэкендеров. Однако, в реальном мире зачастую большие задачи на несколько разработчиков одной специализации часто существуют лишь на старте проекта, когда нужно подготовить базу для дальнейшей работы. Спустя месяцы после запуска как правило задачи сводятся к решению продуктовых задач вовлекающих несколько платформ, но имеющие меньший объём для каждой из платформ, нежели ранее. Возникает необходимость в пересмотре структуры разработки целиком.

Компонентные команды

Component and feature teams

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

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

Фичатимы

Фичатимы (см. рисунок выше) отчасти являются противопоставлением компонентным командам: они состоят из людей, способных решить бизнес-задачи от и до, end-to-end. Продолжая пример с приложением доставки, представим, что вам нужно определить ближайших свободных курьеров и показать их на карте в приложении, дабы клиент мог оценить как быстро найдётся курьер. Такая задача уже не под силу одной компонентной команде, ведь для её реализации нужна работа как с клиентской стороны, так и с серверной: приложениям курьеров нужно отправлять своё местоположение и статус доступности, а серверу синхронизировать эти данные между приложениями курьеров и клиента.

Если решать эту задачу компонентными командами, нам потребуется:

  • заранее определить форматы взаимодействия между приложениями
  • реализовать серверную часть
  • доработать курьерские приложения
  • добавить в клиентские запросы к серверу и карту курьеров

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

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

Минусы для таких команд противоположны компонентным:

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

Ресурсный пул

Resource pool

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

Плюсы такого подхода достаточно очевидны:

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

Основные минусы в данном случае это:

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

Подход more.tv

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

Однако, в какой-то момент стало понятно, что работа с компонентными командами, несмотря на всю свою понятность и простоту, не приносит нам того результата в скорости, которого мы хотим добиться. Мы уменьшили релизный цикл, перешли на тестирование пофично, реализовали CI/CD и добились значительного улучшения, но мы хотим большего :)

— Не томи, Андрей, расскажи как у вас построено сейчас?

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