Как «готовить» все задачи компании в едином трекере: рецепты от разработчиков Yandex Cloud и не только

Мы делимся с бизнесом теми технологиями и сервисами, которые сначала испытываем сами. Жить по Agile и контролировать поток задач нам помогает Yandex Tracker. Рассказываем, как эффективно разрабатывать и внедрять новые фичи, выстраивать коммуникацию распределённой команды и автоматизировать рутину.

Сервисы Яндекса разрабатывает множество команд. Для организации процесса разработки все они используют системы контроля версий, почту, мессенджеры и сервис для совместной работы и организации процессов Yandex Tracker. Мы поговорили с руководителями подразделений Cloud Security, Identity & Compliance, Managed Databases и UX/UI в Yandex Cloud и собрали небольшой cookbook с полезными рецептами-сценариями по управлению большим потоком задач внутри компании.

Запросы на обновления и фичи, поступающие в подразделение Cloud Security, Identity & Compliance, чаще всего масштабные. Это, например, реализация нового бэкенда, которым пользуются команды всех сервисов Yandex Cloud. Команда разрабатывает сервисы Identity and Access Management, Resource Manager и Audit Trails, криптографические сервисы и сервисы по работе с секретами, а также занимается организацией безопасности облака. Чтобы организовать разработку большой фичи, задействовать все причастные внешние команды и отследить результат внедрения, Cloud Security, Identity & Compliance используют Yandex Tracker.

Все команды Yandex Cloud придерживаются гибкой организации процесса разработки. В сервисе реализованы инструменты и подходы agile-разработки, такие как спринты и эпики. Эпик — это тип задачи, который позволяет группировать задачи, в том числе из разных очередей задач и спринтов, если они связаны общей темой.

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

Затем архитектор пишет High-level design документ, выкладывает его в отдельную задачу, если нужно помогает разработчикам разбить процесс на этапы, приоритезирует их и отдаёт в разработку. Разработчик самостоятельно декомпозирует большую задачу на много маленьких, и начинает работу. В Yandex Tracker эти задачи он помещает в одну и ту же очередь — общее пространство задач, над которым работает одна группа разработчиков.

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

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

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

Подразделение Managed Databases — это распределённые команды, которые территориально расположены в Москве, Санкт-Петербурге, Екатеринбурге и других городах. При этом бывают ситуации, когда одна и та же фича разрабатывается для разных управляемых баз параллельно, или изменения, внесённые core-командой, влияют на работу других команд.

Например, при разработке Managed Databases новых функций для клиентов облака, сначала нужно разработать бэкенд, и зачастую в его разработке участвует сразу несколько команд, в зависимости от того, какие из управляемых баз будут затронуты изменениями. Затем нужно подключить команды UX/UI для разработки фронтенда и дизайна для всех необходимых интерфейсов, а после этого привлечь другие команды облака, например, для создания документации и формирования публичного API. Поэтому во время разработки важна простота и скорость коммуникации между различными командами, иначе новая фича может никогда не «дойти» до пользователя.

Команды MDB, как и Cloud Security, Identity & Compliance, придерживаются agile-подхода и используют для разработки и коммуникации в работе над задачами Yandex Tracker. MDB используют эпики, если фича, которую нужно разработать, достаточно большая.

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

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

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

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

Команды MDB оценивают задачи либо эмпирически, исходя из собственного опыта, либо с помощью покера планирования в Yandex Tracker.

Разработчики забирают задачи из отдельного спринта, голосуют и выбирают наиболее приоритетные, подбирая количество задач под вместимость спринта в story points (относительная единица трудоёмкости задач). Спринты помогают задать сроки реализации, а использование покера планирования экономит время на оценку задач.

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

Команды UX/UI отвечают за фронтенд-разработку и интерфейс консоли управления Yandex Cloud, сайта, документации, мобильного приложения и других сервисов.

Разработчики и дизайнеры UX/UI также работают по методологии Agile. У команд есть текущий спринт и преспринты, которые состоят из списка задач-кандидатов на следующий спринт.

Это позволяет не потерять задачи, которые будут актуальны через 2, 4 или 6 недель или, в случае блокировки задачи текущего спринта, найти оценённые не заблокированные задачи в преспринте и приступить к их выполнению. При планировании спринта менеджер проектов UX/UI рассчитывает его вместимость в story points, актуализирует задачи с заказчиками и помещает их в спринт.

Определить, может ли сотрудник взять конкретную задачу, помогает группировка по исполнителям на Agile-доске в Yandex Tracker: там отображается количество story points конкретного исполнителя суммарно по всем задачам в планируемом спринте.

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

UX/UI работают над множеством интерфейсов, и, соответственно — с большим потоком задач. Чтобы оперативно реагировать на появление новых задач в Yandex Tracker подразделение использует триггеры. UX/UI настроили их таким образом, что при появлении новой задачи для неё автоматически проставляется ответственная подкоманда, которая, например, занимается конкретным разделом консоли управления облака. Также триггер срабатывает, чтобы призвать в неё сотрудника, забывшего указать спринт.

Чтобы не терять задачи в общем потоке, команды UX/UI используют компоненты, теги и интеграцию с Yandex Forms. Использование форм с обязательным выбором полей гарантирует, что задача попадёт в нужную очередь и в ней будут необходимые компоненты и теги. Обычно в формах требуется выбрать из набора необходимых параметров и вручную заполнить всего пару полей вместо нескольких десятков.

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

Кроме компонентов и форм, UX/UI используют теги, чтобы подсветить приоритетные, появившиеся ad-hoc задачи, или относящиеся к определённому проекту. Теги можно раскрасить в различные цвета и это визуально очень удобно.

Кроме интеграции с Yandex Forms, у сервиса есть интеграция с монорепозиторием, который используется только внутри Yandex. Разработчики UX/UI оформляют названия коммитов таким образом, чтобы они связывались с соответствующими задачами. В смежных командах также используются интеграция с Bitbucket. Она позволяет, например, посмотреть связанные коммиты в отдельной вкладке внутри задачи. Таким образом внутри Yandex Tracker можно отслеживать стадию разработки той или иной функции.

Некоторые средства автоматизации, статистику и отчётность команды организуют самостоятельно с помощью Tracker API. Так, команда UI/UX создала бота для Telegram. Ему можно передавать название задачи и компоненты, и он автоматически создаст задачу в нужной очереди Tracker с тегом, который говорит об автоматическом создании задач ботом.

Подписывайтесь на блог Yandex Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

Другие истории наших партнеров и клиентов, которые активно читают наши подписчики:

• История Webiomed: как перестать писать софт для рутины поликлиники и перейти к оперативному ИИ-прогнозированию
  
• Фрикулинг 2.0: зачем строят дата-центры в скалах и вечной мерзлоте
• Как делать уникальные продукты на базе open-source: вы тоже так можете

#yandexcloud #стартапы #бизнес #историиуспеха #облачные_сервисы