Опыт управления разработкой 110 продуктов одновременно

Несколько лет назад мне выпала уникальная возможность поработать на американский холдинг ESW Capital, состоящий примерно из 36 компаний. Несколько из них предоставляют ядро сервиса по разработке программного обеспечения. Остальные занимаются покупкой успешных на рынке США программных продуктов. Наиболее известной компанией этого холдинга в России является Crossover – один из бизнес-юнитов, предоставляющий сервис найма и управления персоналом.

Непосредственно поддержка продуктов осуществляется бизнес-юнитом Trilogy. Он представляет из себя фабрику разработки программного обеспечения. Причём фабрика – в полном смысле этого слова: вместо команд, сосредоточенных вокруг каждого продукта, в компании около 250 инженеров разбиты по функциональным отделам – конвейерам. Один отдел (Technical Product Management) пишет спецификации на новую функциональность, другой отдел реализует изменения по этим спецификациям (Feature), третий отдел с утра до вечера занимается исправлением дефектов (Maintenance), четвёртый выполняет тестирование (QA).

И, наконец, есть отдел старших архитекторов продукта (Product Chief Architect), которые призваны управлять всеми изменениями кода продуктов, на которые они назначены: автоматизировать сборки через процессы CI/CD, выполнять рецензирование изменений от других команд, согласовывать технические спецификации, актуализировать техническую документацию. В то время, когда я работал там, на одного архитектора приходилось в основном 1, иногда 2 продукта. Говорят, что позже это количество увеличили. Именно командой старших архитекторов мне и выпала возможность управлять. На 110 продуктов приходилось около 90 PCA.

В основном выбор продуктов для покупки в холдинге осуществляется исходя из размера базы пользователей и их приверженности. Причём приверженность далеко не всегда измеряется лояльностью. Так как в США хорошо развита патентная система, то бывают случаи, когда у пользователей просто нет никакой альтернативы дорогим решениям. Например, финансовая биржа NASDAQ использует, кроме прочих, базы данных Oracle. Чтобы выдержать нагрузку реального времени, запросы к ним распределяются через программный комплекс ScaleArc. Самое главное, что этот сервис был написан ещё в начале 90-х годов в Индии на языке C. Примерно такая же история и у других купленных холдингом продуктов.

Совершенно разные технологии от конца 80-х годов до современности. Наверняка кто-то ещё помнит продукты под брендом Kerio – они сейчас тоже в той фабрике, во владении бизнес-юнита Aurea SMB. В статистике репозиториев среди используемых языков чего только не было: Delphi, C, С++, C#, Objective-C, Java, Ruby, JavaScript, Python, Lisp, Haskel. Не видел только разве что ассемблера и таких консольных языков, как Pascal или Basic. Хотя не удивлюсь, если где-то есть код и с их использованием.

Подведём промежуточный итог. С одной стороны, имеется зоопарк из сотни мульти-технологичных продуктов, специализированные команды с дамокловым мечом в виде метрик персональной продуктивности, отсутствующая или неактуальная документация с потерянными при миграции ссылками на ресурсы. С другой стороны, вице-президенты бизнес-юнитов, которые хотят предоставить своим клиентам качественные, развивающиеся продукты. За что готовы вкладывать немалые деньги, но под строгий учёт расходов: при квартальной заявке внесения 100 улучшений или исправлений, эти 100 задач обязаны быть исправлены за квартал. Умножаем на 100 продуктов, получаем 10000 дефектов бедной команде обслуживания (Maintenance). Это требует скорости исправления одного дефекта каждые 3 часа при команде 60 человек.

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

Это даёт контрольный список требований к документации, которая является главным условием при размещении заявок на доработку продукта в фабрике разработки:

При этом слишком большой объём документации будет иметь обратный эффект производительности, так как время сотрудников будет уходить на чтение талмудов и попытки уложить в голове всю информацию, необходимость в которой отпадёт через 3 часа (в лучшем случае через 4 дня, при группировке задач по продуктам).

В качестве решения вместо полноценных диаграмм UML стали использовать упрощённую архитектурную модель C4. Более того, поддерживать их актуальность непосредственно в коде проектов, с рецензированием версий одновременно с рецензированием изменений. Конечно же, никто не запрещал другие виды диаграмм, но условие наличия, C4 а также поддержания актуальности всех их в виде кода было обязательным. В качестве реализации использовались такие продукты как Mermaid и PlainUML.

Что касается инструкций и требований к оформлению кода, они были автоматизированы как часть CI цикла. Для того, чтобы поддержать целостность этих данных между всеми проектам и в целях унификации, был определён стандарт их описания в виде конфигурационных файлов в YAML формате. Конфигурации по-отдельности описывали каждый собираемый контейнер и генерируемые им артефакты. Такой подход, в свою очередь, позволил создать надстройку над используемой системой CI/CD – Jenkins.

Подготовленный плагин считывал конфигурации систем продукта из центрального репозитория и на основе зависимостей и других настроек создавал задания сборки и распространения, которые для выполнения использовали указанные выше конфигурации сборки контейнеров. Инструменты сборки, юнит-тестирования и проверки стиля выбирались автоматически на основе указанных для контейнера технологий. Например, для проектов на Javascript для подготовки сборки автоматически вызывается команда npm install, затем одна из указанных webpack или vite, а для проверки стиля eslint. Для упрощения поддержки конфигурационных файлов проекты были разбиты на отдельные репозитории в соответствии с границами контейнеров C4.

Начиная с этого момента разработчики уже могли быстро, в пределах 20 минут, получить понимание взаимосвязи компонентов из разных подсистем и подготавливать окружение для разработки, выполнив одну универсальную для всех продуктов команду, которая настраивала необходимые инструменты и зависимости. Для того, чтобы легко разворачивать окружение времени выполнения для воспроизведения поведения продукта до и после изменений, была создана платформа DevSpaces, которая настраивает временное окружение в Kubernetes. И да-да, DevGraph – это также одна из компаний группы холдинга.

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

В этом месте, вероятно, очень хочется увидеть описание запуска юнит-тестов. К сожалению, несколько попыток осмысленно увеличить покрытие кода всех без исключений продуктов завершилось неудачами. Была даже создана отдельная команда – Handcrafted Unit Tests (HUT), которая писала тесты, доводя покрытие до 80%. Однако, для большинства продуктов это закончилось ситуацией, что обновление и исправление тестов занимало больше времени, чем внесение изменений в проект, из-за низкого качества использованных утверждений и неподходящей структуры у legacy кода. В итоге, норма покрытия кода тестами была установлена в 96%, однако на практике отключение тестов до исправления силами PCA стало обычным делом.

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

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

Допустим открыта “Главная” страница
Когда я нажимаю кнопку “Зарегистрироваться”
Тогда я вижу страницу “Регистрация”
И я вижу поле ввода “Введите вашу почту”
И я вижу поле ввода “Придумайте пароль”
И я вижу текст “Регистрируясь, я подтверждаю своё согласие на обработку данных”

Была разработана спецификация, которая описывала подобные предложения для разнообразных технологий и операций, такими как выполнение команд по протоколу ssh, управление базами данных, выполнение дочерних сценариев. Реализация выполнена на базе известной программы для тестирования на языке Python – pytest – как набор данных о состоянии. А также пакета behave, предоставляющий функциональность для определения и разбора предложений на языке Gherkin. Для взаимодействия с оконными интерфейсами были использованы Selenium и Appium, для подключения к сервисам – соответствующие библиотеки на Python.

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

Чтобы быстро нарастить покрытие продуктов конечными пользовательскими сценариями, подключили технических владельцев продуктов, то есть PCA. Когда количество тестов стало расти, наметилась новая проблема: слишком долгая проверка сборок продуктов. Чтобы сократить затрачиваемое на тестирование время, было принято решение задействовать уровень компонентов C4. Каждый сценарий отметили компонентами приложения, которые он тестирует. При этом команда инженеров при выполнении изменений кода отмечает затронутые компоненты со своей стороны. В результате время выполнения проверок сократилось более чем на 60% за счёт выборки только сценариев, которые проверяют работу изменённых компонентов и их соседей.

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

В качестве решения мы выстроили систему приоритетов выполнения задач между всеми командами. Для каждой из них создали так называемые рабочие очереди, которые описывали последовательность и количество задач, которые исполнители должны были закончить за рабочий день. Все задачи были разбиты по типам и для каждого типа создан отдельный тип задачи в трекере (Jira). Автоматизация процессов помогала вовремя создавать задачи динамические. Например, когда команда обслуживания переводила свою задачу в статус рецензирования, для рецензента создавалась отдельная задача и появлялась в соответствующей рабочей очереди. Когда рецензирование завершалось, менялись статусы сразу обеих задач.

Как итог всех этих изменений, нерегулярный выпуск сборок продуктов в пределах от 3 недель до 2 месяцев стабилизировался на сроке 1-2 недели. Каждая сборка содержала от 3 до 10 хорошо протестированных изменений с соответствующими обновлениями архитектурной документации и сценариев тестирования. Оставалось только получить одобрение от менеджера продуктов бизнес-юнита, которое запускало цикл автоматизированного развёртывания в публичную среду выполнения.

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

В первую очередь, все сотрудники уведомлялись о необходимости изменений на общекомандных совещаниях. Это уведомление раскрывало суть проблемы и примерное направление решения, которое будет формироваться в ближайшие 1-2 месяца. Перед тем, как создавать задачи на реализацию, подготавливался документ-спецификация, которая рассылалась всем задействованным командам на обсуждение примерно за 1-2 недели до начала внедрения. Очень важно, чтобы комментирование происходило с использованием технологий, позволяющих видеть вопросы и ответы всех участников: длинные переписки в письмах приводят к потере фокуса ключевых вопросов, а обмен личными сообщениями и вовсе к дублированию всех вопросов и объяснений. Когда по документу-спецификации достигается согласие, создаются задачи на её реализацию и начало изменений анонсируется в виде рассылки и устно на очередном общекомандном совещании.

Бизнес-результатами вышеизложенных изменений стали снижение и стабилизация времени доставки изменений в продуктах пользователям до 1-2 недель, сокращение затрат на линейный менеджмент на 30%, снижение стоимости выпуска каждого релиза продуктов на 20-40%.

Буду рад вопросам, комментариям и запросам. С удовольствием отвечу, подскажу, помогу всем желающим.