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

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | 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 омут» и ни капельки не пожалели об этом.