Управление техническим долгом с помощью DX и ИИ

Каждая компания, большая или маленькая, беспокоится о техническом долге. Согласно оценкам Gartner, примерно 40% систем инфраструктуры имеют эту проблему. В опросе среди руководителей IT, проведенном McKinsey, почти треть участников считали, что более 20% бюджета на новые продукты уходит на решение проблем, связанных с техническим долгом. Но, вопреки тому, что многие думают, это не только проблема кодирования, но и проблема опыта разработчика (DX). Когда разработчики вынуждены работать с неадекватной архитектурой, устаревшими инструментами и низкокачественными процессами разработки, страдают производительность, результативность и моральный дух.

Приоритизация технического долга с учетом разработчика, сосредоточение внимания на том, как они подходят к работе, какие инструменты они используют и какие карьерные перспективы они могут получить, помогает командам сосредоточиться и выпускать продукты быстрее. Это объясняет, почему компании меняют подход к управлению техническим долгом, руководствуясь DX и увеличенным вниманием к инструментам, основанным на ИИ.

Защита DX

Процесс интеграции разработчиков часто оставляет желать лучшего. Иногда может потребоваться несколько недель, чтобы кто-то начал вносить свой вклад в проект. Как только они наконец смогли добавить небольшие функции или исправления, не редко бывает так, что непрерывная интеграция (CI) не проходит из-за чего-то совершенно не связанного с изменениями, которые они внесли. Это в основном означает, что тестовый набор не проходит из-за проблем с качеством, и разработчик не внес изменений, которые могли бы сломать тестовый набор. Это нестабильный, плохо написанный тест, который работает только 90% времени. Существующая команда, возможно, с этим согласна – это просто замедляет процессы – но инструменты могут быть устаревшими и деморализующими для кого-либо вне организации.

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

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

Кроме того, IDC ожидает, что рынок автоматизации тестирования программного обеспечения на основе ИИ будет продолжать расти на 31,2% в год до 2027 года, поэтому убедитесь, что вы используете эту технологию в полной мере.

Метрики и предупреждающие знаки

Существует множество метрик, которые можно отслеживать при оценке того, как технический долг влияет на вашу команду. Некоторые базовые метрики – это “время исправления” или “время реализации функции”. Допустим, вы заметили ошибку и знаете, как ее исправить. Некоторые инструменты могут отслеживать время, потраченное на написание кода и производство. Например, вы сможете увидеть, что очень небольшой патч занял два рабочих дня на исправление и выпуск, когда ваша команда должна быть в состоянии сделать это за несколько часов. Вы также можете отслеживать соотношения, такие как количество исправлений ошибок и количество реализованных функций.

Также существуют способы определить, когда проблемы с моралью влияют на производительность вашей команды. Лидеры DX могут проводить опросы раз в квартал, чтобы определить, насколько счастлив разработчик, работая над проектом или его частью. Они могут детально изучить конкретные области, такие как процесс CI. И вы всегда можете отслеживать текучесть кадров в вашей команде. Если вы заметите, что люди постоянно покидают команду, они могут чувствовать, что их проблемы не услышаны.

Работа с инструментами ИИ

Рост инструментов ИИ должен сделать разработчиков и инженеров более продуктивными и выпускать продукты быстрее, но технический долг замедляет этот процесс. Допустим, вы используете инструмент, такой как GitHub или Copilot, чтобы помочь с изменениями кода, затем отправляете запрос на слияние, и CI занимает несколько часов, чтобы ответить. Тем временем, работает ли разработчик над чем-то другим? Проверяет ли он электронную почту? Это переключение контекста и убийца производительности.

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

Существует случай для агентов ИИ с инженерами в качестве оркестраторов. Опрос Capgemini среди 1100 руководителей крупных предприятий показал, что 82% планируют интегрировать агентов ИИ в течение следующих трех лет, и они уже влияют на будущее работы. Вы можете смотреть на отчет об ошибке и видеть, что он достаточно мал, чтобы агент ИИ мог справиться с ним от начала до конца, экономя время вашей команды и освобождая их для более сложной работы. Однако иногда, когда мы слепо следуем этим инструментам, есть компромиссы, которые ИИ не может рассмотреть.

Это когда человеческое мнение становится решающим фактором.

Совмещение технического долга с целями

Как вы можете совместить уменьшение технического долга с целями, которых вы пытаетесь достичь, или измеримыми результатами? Это возвращается к приемлемому техническому долгу, и иногда в бизнесе необходимо выпускать продукты быстро. Вы можете сделать это, зная, что продукт не масштабируется, и могут возникнуть проблемы с производительностью со временем. Часто разработчик делает заметку, чтобы вернуться к этому позже, когда будет время решить эти проблемы, но это редко происходит. И когда эта плохая культура берет верх, когда вы постоянно должны выпускать продукты завтра, влияние долга становится очевидным.

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

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

Технический долг с процентами

Каждая организация может выделить несколько часов каждую неделю, чтобы улучшить свой DX и помочь уменьшить технический долг. Если нет, вы можете заплатить за это позже, вероятно, медленной производительностью, значительным замедлением скорости разработки или проблемами безопасности. Например, ваша команда инженеров и разработчиков могла откладывать обновления Ruby on Rails на десятилетие. Внезапно, стоимость проекта увеличивается на полмиллиона долларов, потому что версия Ruby отстает на четыре поколения, оставляя вас с массой кода и устаревшими зависимостями.

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