Создание продуктивных команд

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

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

Illustration of feature crew and customer crew working together.

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

  • Четко определенные роли экипажа
  • Четко определенный процесс смены экипажа
  • Частые корректировки размера экипажа

Экипаж компонентов

Экипаж функций, или F-экипаж, фокусируется на будущем. Они работают в качестве эффективной единицы с четкой миссией и целью: построить и отправить высококачественные функции.

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

Когда член экипажа F присоединяется к беседе или иногда получает сосать в поток электронной почты, другие члены команды должны хвалить их: "Вы находитесь в экипаже F, что вы делаете?" Если член экипажа F должен решить критически важный вопрос, им рекомендуется делегировать его экипажу клиента и вернуться к работе с функциями.

F-экипаж работает как жестко вязаная команда, которая роев на небольшом наборе функций. Хороший лимит на ход работы (WIP) является двумя функциями в полете для 4-6 человек. Работая вместе, они создают глубокий общий контекст и находят критические ошибки или проблемы разработки, которые пропустят курсорный обзор кода. Выделенная команда обеспечивает более прогнозируемую скорость пропускной способности и время выполнения. Члены команды часто ссылаются на F-экипаж как безмятежный и сосредоточенный. Они находят его мирным и омолаживающим, чтобы глубоко сосредоточиться на признаке, чтобы выделить полное внимание к нему. Люди оставить свое время на F-экипаж чувство обновлено и достигнуто.

Экипаж клиента

Экипаж клиента или экипаж C ориентирован на данный момент и обеспечивает поддержку передней линии для проблем с клиентом и динамическим сайтом, ошибок, телеметрии и мониторинга. Экипаж C часто обнимает вокруг компьютера, отладка критической проблемы с динамическим сайтом. Их приоритетом является работоспособность live-site. Лазер, ориентированный на эту среду, они создают навыки отладки и анализа экспертов. Экипаж клиента часто называется командой щита , потому что она защищает остальную часть команды от отвлекающих факторов. Вместо того чтобы работать над предстоящими функциями, экипаж C является мостом между клиентами и текущим продуктом. Члены экипажа активны в электронной почте, Twitter и других каналах обратной связи. Клиенты хотят знать, что они услышаны, и работа C-экипажа заключается в том, чтобы услышать их. Команда C-экипаж сразу же выдает сообщения о проблемах, сообщаемых клиентом, и быстро участвует и помогает заблокированным клиентам.

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

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

Поворот экипажа

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

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

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

Размер экипажа

Размер экипажа зависит от поддержания работоспособности команды. Если команда имеет высокий уровень входящего числа вопросов live-site или имеет много технического долга, C-экипаж получает больше, и наоборот. Изменение размеров еженедельно увеличивает прогнозируемость в результатах и зависимостях команды. В течение нескольких недель команда может переместить всех в экипаж C, чтобы обратиться к отзыву от большого выпуска.

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

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

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

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

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

Корпорация Майкрософт является одной из крупнейших в мире компаний Agile. Узнайте, как корпорация Майкрософт упорядочивает команды в планировании DevOps.