Привет, Хабр. Это Виталий Колесников из МТС Диджитал. В прошлом посте я рассказал, с чего мы начали внедрение производственного флоу в компании. Сегодня продолжим тему: объясню, как превратили его в продукт, интегрировали с инструментами разработки и тестирования, зачем создали объект для управления релизами. И, главное, какие результаты все это принесло бизнесу.
Выход из тени: процесс как продукт
В конце прошлого поста я говорил, что мы стали представлять свой производственный Workflow как сервис для команд. Дальше мы продолжили его развивать.
Первое, что сделали, — провели открытое демо. Организовали централизованное обучение PO, Agile-коучей и скрам-мастеров. Завели форму для ОС и обращений, чтобы сотрудники могли присылать нам запросы на развитие стандартного Workflow. Еще мы опубликовали свой бэклог в открытом доступе — там можно было увидеть запросы от всех команд и посмотреть статусы их реализации. Такой подход сильно увеличил на нас нагрузку. Теперь нужно было планировать разработку в Jira, обрабатывать запросы и параллельно проводить консультации — они «съедали» полноценную штатную единицу в день.
Когда команда Jira перешла на продуктовый подход и начала реализовывать новые автоматизации, ее трудозатраты увеличились на 30%. Ребятам пришлось поддерживать несколько экземпляров Jira, которые уже были в компании, плюс схемы новых процессов. Конечно, это тот еще квест. В итоге решили оставить один экземпляр Jira, мигрировать всех в нее и отказаться от поддержки нецелевых флоу производства. Так мы смогли оптимизировать затраты и сконцентрировать все силы для создания полноценного автоматизированного Workflow.
Чтобы снизить нагрузку моей команды из-за консультаций и поддержки, мы решили проверить гипотезу «Хороший портал стандартного производственного Workflow с путеводителем по его основным функциям и кейсам использования снимет с нас 50% нагрузки». Реализовали такой портал на базе Confluence. Итог даже лучше — трудозатраты на консультацию и поддержку сократились на 70%.
А вот как коллеги оценили наши старания. Это результаты опроса удовлетворенности сервисом по СSAT:
удобство использования Workflow — 54,13%;
управляемость бэклогом и планирование работ — 59,76%;
достаточность набора сущностей Workflow — 63,13%;
клиентоориентированность команды развития и внедрения Workflow — 71,63%;
компетентность и профессионализм — 71,94%.
На конец 2022 года стандартный Workflow подключили 130 продуктов:
К концу 2022-го мы создали процесс, который стал одинаково полезен для реализации Discovery и Delivery. А еще — обеспечил прозрачность и наблюдаемость рабочего процесса, к чему мы и стремились с самого начала.
Стандартный Workflow стал полноценным инструментом для того, чтобы не только организовать производство, но и провести продуктовую трансформацию. Одной из ее целей было повысить качество поставок ценности и фокус на ней. Поясню, о чем речь. Представьте приложение бронирования отелей. Фича «количество комнат» (она же ценность) позволяет пользователю выбрать подходящий номер. Без нее приложение было бы не таким удобным, в него бы заходило меньше людей — и компания несла бы убытки. Чтобы повысить качество поставки ценности и сфокусироваться на ней, нужно на регулярной основе проводить исследования рынка и CastDev пользователей. Только так мы можем убедиться в полезности реализуемых фичей.
Поэтому мы совместно с Agile-практикой сконцентрировались на развитии процесса Discovery и встраивании его в производственный жизненный цикл продуктов. И тут мы столкнулись с двумя новыми сложностями:
для стандартизации Discovery нам нужно было перенести все артефакты процессов продуктовых команд из Miro и Confluence в Jira;
владельцы продуктов по-разному представляли этапы Discovery и предъявляли к ним разные требования, а это усложняло стандартизацию процесса.
В итоге реализовали оптимальный вариант и стали обучать PO работе с такими этапами Discovery:
формирование воронки гипотез;
приоритизация гипотез;
валидация гипотез.
Третий был самым трудозатратным. В него входили:
анализ текущей ситуации, рынка и конкурентов;
проектирование и проведение исследований;
анализ результатов и создание или корректировка CJM, или карты пути клиента.
Работа с этапами была смоделирована в Jira при использовании объекта «Эпик» в бэклоге продуктов. Он вмещал в себя статусы, этапы исследований, проверки гипотез по фиче, проектирования архитектуры и так далее. Это позволило нам синхронизировать бизнес и ИТ, замотивировать команды и брать в работу только подтвержденные гипотезы. Результат — более рациональное планирование ресурсов и расход бюджетов на создание и развитие продуктов.
Интеграция процесса производства с инструментами разработки и тестирования
Мы добились хороших результатов, но исходную задачу все еще нельзя было считать выполненной. Нам предстояло развить производство (Delivery) настолько, чтобы мы могли предложить полезные решения даже зрелым командам — заинтересовать их сложнее всего.
На начало 2023 года в компании использовались такие инструменты:
для организации CI/CD — Bitbucket, Bamboo, GitLab, MS TFS;
для организации и управления тестированием — TestRail, Xray, Allure;
для управления задачами, планированием и разработкой — Jira, Asana, Trello, YouTrack.
Обычно команды сами разворачивали их и поддерживали на своих ресурсах. С внедрением техностратегии политика изменилась: всем продуктам предложили перейти на коммунальные инструменты — Jira, GitRails, Allure Test Ops. Мы этим воспользовались.
Нашей задачей было увязать коммунальные инструменты между собой, причем под управлением Jira. Сначала мы интегрировали Jira с GitRails: настроили триггеры в GitRails. Это позволило автоматически двигать статусы задач в Jira при отправке оповещений из GitRails, к тому же появилась визуализация в карточках панели разработчика по веткам, коммитам и связанным репозиториям.
Теперь об интеграции Jira c Allure Test Ops. В Jira начала отгружаться информация из Allure о выполненных запусках автоматических и ручных тестов в рамках «Историй» — элементов бэклога.
В самой Jira были реализованы автоматизации, которые позволяли:
двигать «Истории» в зависимости от статусов дочерних задач;
автоматически направлять задачи на аналитика, разработчика, архитектора — в зависимости от статуса процесса;
автоматически возвращать в работу задачи, отклоненные тестированием, и многое другое.
Когда мы внедрили эти интеграции, наш Workflow стал максимально автоматизированным. Теперь он позволял синхронизировать работу всей команды в одном месте — Jira. Ура, мы обеспечили управление производством!
К концу 2023 года теперь уже на стандартный производственный процесс (СПП) перешло 300 продуктов. Он стал «зонтом» над всем производством и объединил все этапы ЖЦ создания продукта. Такая концепция позволила повлиять на скорость работы команд, а это привело к сокращению T2M.
Костяком СПП стали Jira, GitRails, Artifactory, Harbor, Nexus, Allure TestOps, Chaos Engineering, Sunkey. Потом они образовали технологическую платформу Product Factory.
Структура процессов на конец 2023 года:
Релизный процесс как квинтэссенция производства
В конце 2023 года внутри модели СПП появился объект для управления релизами. Так мы смогли расширить функции процесса, во главе которого теперь стоит релиз — он объединяет в себе всю работу и формирует Release Notes. Все истории, входящие в него, связаны с конкретными Merge Request (изменениями веток кода), версиями микросервисов и репозиториями.
Еще на основе запусков ручных и автотестов внутри релиза автоматически формируется сводное цифровое заключение с результатами тестирования. Это нужно, чтобы принять решение о выпуске в продакшн. За первое полугодие такая реализация позволила увеличить количество продуктов, подключенных к СПП Product Factory, до 380-ти.
В начале 2024 года внутри Product Factory появился портал. Его цель — предоставить командам унифицированный набор преднастроенных инструментов, шаблонов, метрик, Quality Gates, которые нужны для выстраивания и управления релизным и производственным процессом:
Что получили команды
К чему мы пришли:
У команд появился готовый фреймворк и набор связанных между собой инструментов. Все процессы в СПП — теперь сквозные. С реализованными автоматизациями можно организовать процессы любой сложности и иерархии по всем направлениям производства: Discovery, аналитика, разработка, DevOps и так далее.
У всех команд есть доступ к метрикам. Опираясь на них, они могут улучшать свой процесс итеративно.
Используя CI/CD и объект «Релиз», можно выстроить релизный такт и проверить качество релиза.
Достичь всего этого было непросто. Впервые в компании мы применили подходы оптимизации, стандартизации и автоматизации производства на основе использования универсального Workflow и интегрирования процессов СПП в инструменты и витрины Product Factory. Конечно, мы на этом не останавливаемся. У нас большие планы на сервисы для организации разработки и развертывания проектов из шаблонов, но это совсем другая история.