Как мы построили систему управления проектами на базе Azure DevOps

Четыре трекера - это четыре разных процесса, шаблона проектов, системы сборки и развертывания, которые мы поддерживали. Путь к общему трекеру начался с эксперимента - перевести в Azure DevOps одну из команд из "не майкрософт" стека. Так совпало, что эксперимент прошел практически перед уходом на карантин из-за пандемии, но это нам не помешало. И меньше чем через год все наши инженеры переехали в Azure DevOps.

Почему именно Azure DevOps

Мы тщательно изучили возможности разных трекеров и выбрали платформу Microsoft Azure DevOps (ранее TFS). В своем базовом назначении, как универсальный инструмент планирования, Azure DevOps имеет ряд преимуществ:

• Удобный интерфейс планирования распределения задач и нагрузки по каждому человеку в команде с учетом отпусков и переключения на другие проекты;
• В режиме доски за 1 клик корректируются параметры задачи или создается новая;
• Автоматически пересчитывается remaining work на задаче при репортинге времени и обнуляется при ее закрытии;
• Есть возможность планирования на уровне фич, эпиков, а также можно проставлять аналог категории в поле Area.

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

Что мы получили от перехода на единую платформу управления проектами

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

Этапы перехода на единую платформу

Мы переводили команды одну за другой и в каждом случае делили процесс на несколько шагов.

1. Подготовительный этап: принципы ведения проектов. Первым делом мы ввели в компании единый свод правил и принципов ведения проектов. Закрепили операционное управление проектами в трекерах силами менеджеров. Перекрыли ручное создание задач, перевели всех в трекеры и отказались от процедуры проверки таймшитов. Так трекеры стали местом как управления, так и учета загрузки команд.
2. Внедрение единого шаблона проекта. Шаблон фиксирует простые и понятные статусы и правила перехода между ними: правила вложенности задач и багов внутри PBI, декомпозицию PBI на задачи, их статусы, категории, правила работы с тегами, обработки багов, которые получаем от клиентов.
3. Консолидация в рамках одной системы проектного управления. Затем мы начали переводить все команды в один трекер – Azure DevOps.
4. Интеграция с Git. На этом этапе у команд сохранялась гибридная модель работы, когда в качестве трекера уже использовался Azure DevOps, а для версионирования кода и организации CI/CD - Gitlab. Это упростило переход, так как командам не пришлось переучиваться на работу сразу с тремя инструментами. Изменения происходили постепенно: сначала трекер, потом Git, потом CI/CD. Но использование Gitlab потребовало создания специальной интеграции Gitlab – Azure DevOps, чтобы статусов в новом трекере менялись автоматически, в зависимости от действий с кодом.
5. Переход на использование Azure DevOps Git и выстраивание пайплайнов CI/CD. Финальным этапом стало создание новых пайплайнов сборки и развертывания приложений с использованием Azure DevOps CI/CD. В последние годы Azure DevOps был значительно доработан, и принцип создания пайплайнов практически не отличается от принципов Gitlab - это позволило командам и DevОps инженерам переработать пайплайны Gitlab на Azure DevOps без изменения парадигмы. Наличие пайплайнов сборки и разворачивания позволило командам перейти в Azure DevOps и полностью отказаться от Gitlab. Переход на Azure DevОps дал интеграцию, что называется, “из коробки”. Например, при создании Pull Request задача переводится в статус Code Review, а при сборке и выпуске релиза все связанные задачи отмечаются и можно посмотреть, что вошло в релиз.

План перехода команд на новый трекер

По каждому элементу роадмапа у нас был отдельный план. Здесь отрисуем шаги перевода команд на новый трекер. Остальное – темы, достойные отдельных статей.

1. Запустили двойную интеграцию, когда команда работала в старом трекере, но копии задач уже автоматом генерировались и двигались по статусам в Azure DevOps.
2. Подобрали дату на стыке спринтов, чтобы максимальное количество активных задач было закрыто, и «переключили рубильник». Разработчики увидели в новой системе все свои статусы.
3. Проработали изменения в структуре проекта и сформировали новый перечень бизнес-категорий для классификации задач.
4. В день «Ч» настроили проект и переключили на Azure DevOps. Команда начала работать в новом трекере.
5. По ходу работы проводили ежедневную сверку реестра задач на предмет совпадения типов задач, их параметров, наличия в спринте, статусов, плановых и фактических трудозатрат между двумя трекерами. При обнаружении расхождений исправляли ошибки интеграции.
6. Параллельно с этим для команды и заказчика было проведено демо новой структуры проекта и правил работы с ним.

Развитие инструмента: как кастомизировали Azure DevOps под свои нужды

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

Дашборды с ключевыми показателями процесса разработки и time-to-market продуктов.

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

Нам важно в реальном времени контролировать незавершённые задачи по текущему спринту, отслеживать задачи без оценки, незакрытые таски на проде, а также задачи - релиз-кандидаты. Всё это потенциальные источники рисков, с которыми нужно работать (менять приоритеты, корректировать ожидания заказчика и т.д.).

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

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

Ассоциирование автотестов с тест-планом.

Пайплайны Azure DevOps позволяют запускать автоматические тесты и получать по ним отчет. При этом было непонятно, как сопоставить этот отчет с чек-листом и сформировать его в нужном для нас виде. Поэтому в рамках перехода к концепции Software Developer in Test (SDET) мы разработали свое кастомное расширение для Azure DevOps, которое ассоциирует автотесты и тест-кейсы.

Интеграция с Jira, ServiceNow и другими системами.

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

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

Интеграция с MS Teams

Microsoft Teams мы используем для коммуникаций внутри компании и общения с заказчиками. Интеграция помогла организовать процесс, когда нужно быстро ответить заказчику на вопросы по задачам, при этом нужно еще общаться с командой и следить, не обновились ли комментарии.

Решением стал отдельный канал в Teams, где собираются события-комментарии из Azure DevOps .

Подводя итог

Переход на Azure DevOps и развитие инструмента под свои нужды позволили нам:

• Стереть границы между разными технологиями (.NET и JAVA, мобильная разработка) в организации процессов и единообразно оценивать time-to-market на разных продуктах.
• Обеспечить всем сотрудникам компании общее видение процессов и инструментов управления разработкой. Как следствие, упростились кросс-проектные процессы, ротации любых специалистов между командами, работа сотрудников в нескольких командах сразу.

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