Как эффективно управлять DevOps-командой. Советы проектным менеджерам

Всем привет! Я — Екатерина Гнедая, Project Manager в NIX.

Больше года я занимаюсь менеджментом DevOps-команды, которая задействована в разработке облачной SaaS-платформы. Среди моих задач — выстраивать и налаживать Scrum-процессы, решать трудности, которые возникают в ходе реализации проектов и помогать инженерам создавать полезный для бизнеса функционал.

В этой статье я опишу, с какими «болями» может столкнуться РМ в процессе менеджмента команды, которая состоит только из DevOps’ов, и что поможет справиться с этими сложностями.

Для начала расскажу о своей команде

Сегодня в моей команде работает 15 DevOps-специалистов. Особенность этого направления заключается в разнообразии используемых нами технологий. Кто-то хорошо разбирается в инструментах CI/CD и помогает разработчикам ускорить процесс доставки кода, а кто-то — с помощью Terraform, автоматизирует процессы развертывания инфраструктуры.

Независимо от выбранного направления, у наших DevOps’ов глобально существует три цели:

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

Ранее менеджмент команды DevOps’ов выполнял клиент, с помощью Team Lead на нашей стороне. Team Lead распределял задачи по направлениям так, чтобы ребята не мешали друг другу. Однако из-за большого количества задач в какой-то момент стало очень трудно мониторить прогресс DevOps’ов, и понимание клиента о текущей загрузке команды и возможности запланировать задачи в нужный срок, пошатнулось. Для того, чтобы сделать этот процесс более прогнозируемым и понятным, мы добавили в проект выделенного проектного менеджера (дальше PM), который помог специалистам эффективно координировать их общие усилия, четко планировать все действия и, что немаловажно, обеспечивать прозрачность — кто и чем занят. Этим PMом стала я :).

С чего мы начали

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

Чтобы осуществить переход к Scrum-процессам, первым делом я прояснила объемы задач, которые моя команда могла покрывать в течение одного спринта, учитывая нашу доступность (capacity). Также пришлось расставлять приоритеты, взяв на себя роль Product Owner. По истечению двух недель, которые отведены на спринт, мы предоставили клиенту результат, и спустя время вышли на наше среднее velocity (производительность команды или фактически выполненные задачи).

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

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

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

Поддерживайте бэклог в актуальном состоянии

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

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

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

Расставляйте приоритеты и визуализируйте загрузку

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

Мониторить, кто занят, а кто — нет, нам помогли созданные в Jira дашборды. Инструмент позволяет быстро визуализировать данные и делиться с клиентом занятостью и прогрессом ребят. Разобравшись с требованиями и настроив дашборды, мы создали разные лейблы для других шести команд разработки, по которым видно, с какой конкретно командой взаимодействует сейчас DevOps специалист.

Ищите союзников на стороне клиента

Данный совет хочется рассмотреть на примере ситуации, которая произошла с нами. На стороне клиента на нашем проекте есть архитектор, который «вставлял нам палки в колеса». Архитектор, будучи control freak-ом, не доверял команде и валидировал все решения самостоятельно, тем самым затягивая реализацию поставленных перед нами задач. Однако нам удалось найти с ним общий язык. Мы интенсифицировали наше с архитектором общение и на личных встречах, подробно рассказывали ему о текущем прогрессе команды. Также мы обсуждали стратегию на будущее, прописывали документацию об уже выполненных задачах и просматривали отчеты по статистическим метрикам о команде, вовлекая его во все наши процессы, проблемы и достижения.

Немаловажно отметить, что DevOps-команда помогала архитектору во время критических поломок на продакшене (outage), которые иногда случались ночью или на выходных. Таким образом мы добавили прозрачности в наше общение и отныне советуемся друг с другом и с регулярно демонстрируем экспертность команды своими решениями. В результате мы наладили с архитектором доверительные отношения и стали настоящими partners in crime :)

Проводите ретроспективу

Иногда у нас в команде пренебрегали Agile-практиками. На мой взгляд, это происходило потому, что люди не хотели погружаться в новые, неизвестные для них процессы и делали, как привыкли. Перестраивая work-flow команды под Scrum-процессы, я сталкивалась с сопротивлением отдельных членов команды и не пониманием, чем это будет полезно для нашей команды. Для того, чтобы решить эту «боль», я обратилась к ретроспективе. Это Scrum-церемония, во время которой команда анализирует основные сложности итерации и продумывает, как можно исправить или улучшить ситуацию. В течение нескольких Scrum-итераций мы смогли показать всем участникам нашей команды, что Agile-методы действенны. Мы закрыли оговоренные ранее проблемы, а процессы, которые были хаотичны, удалось отладить.

К чему мы в итоге пришли?

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

  • Создать актуальный бэклог и аккуратно заполнять Jira. Благодаря этому мы можем продемонстрировать клиенту текущую загрузку на проекте, рассказать о выполненных задачах, составить план разработок на следующий период и делать это мы можем в любой момент времени по запросу от клиента.
  • Следовать Scrum-рекомендациям, благодаря которым удается оперативно планировать и качественно работать с задачами «на вчера».
  • Разработать эффективные дашборды в Jira, которые помогают нам визуализировать работу команды и добиться прозрачности в общении с клиентом.
  • Улучшить процесс взаимодействия DevOps команды с клиентом — устранить излишний микроменеджмент со стороны клиента, добившись его расположения.
  • Регулярно фокусироваться на зонах роста для команды и внедрять согласованные улучшения.

Полученный в становлении DevOps-команды опыт, для меня бесценен. Я искренне благодарна ребятам за то, что в момент грядущих изменений мы не испугались, а нырнули с головой в «Agile омут» и ни капельки не пожалели об этом.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Из опыта могу сказать, что если ДевОпс и участвует в скраме, то в общем проектном, дабы быть в курсе — где, когда, и кому его помощь понадобится, что от него ожидается в рамках нового спринта, и т.д.
Но скрам в команде девопс’ов это наверное забавно)

Еще на ДевОпс валится обычно всякая срочная текучка, и от трети до половины этих задач вообще в виде jira-тикетов не существует.
Ну типа этого

DevOps-команда помогала архитектору во время критических поломок на продакшене (outage), которые иногда случались ночью или на выходных.

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

DevOps перешла на Scrum-фреймворк

Цікаво послухати чим цей скрам закінчився ))

Ще не бачив девопсів, що вписались в скрам і не полягли спринтами й кровію в землі

ПС по коментарям бачу я не перший з цею непоняткою, питань нема ^_^

Команда 15, 15!!!! Девопсів.
Мій проект на 50 девелоперів супорта команда з 4-5 девопсів і це в них ще був 24/7 он колл супорт.

Скільки девелоперів вони супортають?

Імхо, 15 інженерів це 3 повноцінні команди, понятно що один лід таке плем’я не тягнув.

Якщо девопс команді потрібен ПМ щоб налагодити комунікацію з клієнтом то це просто команда опсів але назвали по «модному»))

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

Зачем сразу так плохо о ПМе? :) Как говорится, не стреляйте в пианисткe, она играет, как может! :) В той ситуации, в которую попала. Другое дело, что попытка натянуть практики проектного менеджмента на сугубо сервисную функцию девопс выглядит, мягко говоря, не совсем адекватно. Здесь реально рулит классика ITIL/ITSM. Между разрабами и командой девопсов должен быть SLA с оговоренными сроками реагирования на заявки. Да и вообще, весь процесс лучше отслеживать не как задачи в обычной Jira Software для управления проектами разработки, а как тикеты в Jira Service Management.

Достаточно было просто навести порядок, использовать Канбан и разбить на две команды.

Нет понятно только, почему этим на занялся тим лид.

«Linux Administration/DevOps 14.01.2022
Ищем системного администратора для работы в команде единомышленников. Среди наиболее интересных задач — разработка и реализация кластерных и высокодоступных систем для сайтов и почты, создание новых Linux-дистрибутивов, работа с Cloud-сервисами и виртуализацией.»
Цікаво, це RedHat так пиляють чи Ubuntu?

Ранее менеджмент команды DevOps’ов выполнял клиент, с помощью Team Lead

Яка доля Team Lead DevOps на проєкті?

Интересно узнать — в текущей конфигурации dev-ops инженеры вообще не общаются с командами разработки? Все идет через тикеты и PM?

Архитектор, будучи control freak-ом, не доверял команде и валидировал все решения самостоятельно

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

Скромный вопрос — завоевание доверия работой по ночам/на выхах происходило за счет личного времени гребцов, или оплачивалось ?

«Чтобы оперировать с командами разработки одними и теми же терминами, моя команда DevOps перешла на Scrum-фреймворк» я правильно понимаю что это была единственная причина для выбора agile методологии? Было бы очень интересно увидеть метрики улучшения процессов, которые обосновывают решение.

Ну ладно еще если бы канбан некрещенный, но 15 девопсин по скраму гонять... Хотя... Учитывая вашу фантазию мадам — мы не могли с вами встречаться в одном из клубов по взрослым интересам города Киева? )))

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

Не, это происходило потому что им надо было работать.

І як довго ви вже працюєте по такому процесу?
Або вам дуже повезло з тасками та специфіками проектів, або гратися в скрам зі всіма церемоніями скоро набридне.
Зі свого досвіду. Маю схожу на вашу модель команди. При двотижневому циклі 50% юзерсторей успішно перекидувалось зі спрінта в спрінт, бо внєзапно з’являлося безліч уржент крітікал тасок на вчора. Перейшли на тритижневий спрінт, ситуація не дуже покращилася. Змінили православний скрам на канбан з регулярним беклог грумінгом — вуаля, ніяких несподіванок і поламаних спринтів.

Канбан — абсолютно адекватный подход. Тойота. Классика конвейера. Pull system. Задачи вытягиваются из бэклога тогда, когда высвобождается ресурс для ее выполнения, а не тогда, когда наступает какой-то высосанный из пальца дедлайн. Вообще — нехорошо высасывать из пальца. Как минимум — это не гигиенично... :)

Канбан — абсолютно адекватный подход. Тойота. Классика конвейера. Pull system. Задачи вытягиваются из бэклога тогда, когда высвобождается ресурс для ее выполнения, а не тогда, когда наступает какой-то высосанный из пальца дедлайн. Вообще — нехорошо высасывать из пальца. Как минимум — это не гигиенично... :)

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

Пробовал и скрам и канбан. Более непродуктивной работы чем скрам не встречал.

Ну, скрам нужен не для продуктивности. Иногда (а вернее — во многих случаях), заказчику нужно регулярно (например — раз в 2 недели) показывать что-то работающее. Дабы у него не пропадало желание и дальше оплачивать работу :). Ежели команда не в состоянии показывать прогресс ежедневно, топчется на месте и у нее всегда все в in-progress, вот тогда — scrum может и помочь. Если с умом подойти...

Як лейтенанту командувати генералами?
Була спроба знайти lead devops серед 15 девопсів?
І вже далі будувати відности з юнітом, який має керівника? Чи в зелених і бірюзових організаціях це не працює?
Люди все одно «бабуїни». В племенах на 10-25 людей завжди ж вожак, або вожак і неформальний лідер. Це генетика homo sapience.

15 DevOps-специалистов

в команді та

Scrum-фреймворк

це не ок, чим більше спеціалістів в команді тим менш ефективна комунікація, особливо з скрам фреймворком.

Взагалі ви пробували працювати з канбан дошкою без натягування скрама на це? Ви б не стикнулись з усіма труднощами, які ви описуєте:

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

Просто створюєте канбан дошку, працюєте над оцінюванням і пріорітизацією наявних в беклозі задач, ви як менеджер також ще думаєте над покращенням cycle time та throughput та й все, по великому рахунку.

Для devops та support команд підхід на основі канбану працює дуже добре.

я зашел сюда почитать про девопс...наивный

Сокращу до смысла: Ура, мы Жыру поставили

Запихнуть техподдержку в scrum это я вам скажу...

Точно! Натянули сову на глобус и радуются... :)

Улучшить процесс взаимодействия DevOps команды с клиентом — устранить излишний микроменеджмент со стороны клиента, добившись его расположения

Внезапно! Менеджмент может делать полезные штуки :)

Внезапно! Менеджмент может выдать любую глупость за полезную штуку :)

Внезапно! Любая штука «полезная», если так сказал менеджмент

Підписатись на коментарі