Попрощайтесь с техническим долгом: стратегии Agile для разработки без долгов

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

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

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

• переписывание хрупкого кода, который ломается при изменении связанной функции;

• рефакторизация модуля, не рассчитанного на масштабирование по мере увеличения количества пользователей или данных;

• замена устаревших зависимостей, которые больше не получают обновлений безопасности;

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

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

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

• Альфа-версия. Все функции внедрены и готовы к тестированию. 

• Бета-версия. Разработка этой версии начинается, когда исправлено достаточно багов, чтобы ее можно было продемонстрировать клиентам для получения отзывов. К сожалению, пока команда исправляет баги, чтобы создать бета-версию, появляются новые баги, которые усугубляют технический долг. Это как бороться с гидрой: исправьте один баг, и сразу появятся два новых. 

• Версия без багов. Как правило, для этого исправляют ряд известных проблем, а остальные откладывают до следующего релиза. 

Если откладывать исправления багов, технический долг накапливается и растет как снежный ком. Бэклог увеличивается, и устранить проблемы становится все сложнее. Разработка замедляется, сроки срываются, а клиенты страдают от сохраняющихся дефектов. Удержать технический долг под контролем помогут гибкие методологии разработки, которые позволяют применять более устойчивый подход.

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

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

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

• Деградация кода, которая со временем может коснуться даже хорошо написанного кода. По мере развития систем, изменения зависимостей и добавления новых функций ранее надежный код может устареть или оказаться несовместимым с новыми компонентами.

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

• Сжатые сроки. Когда команды по управлению продуктами стремятся ускорить поставку результатов, приходится экономить на качестве. Вместо правильных решений появляются временные «заплатки» и создается долг, который со временем увеличивается. 

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

• Некачественная коммуникация. Когда в методологии управления проектами Agile возникают проблемы, разработчики могут неправильно понять требования или сделать предположения, которые потребуют доработок. 

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

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

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

Вот наиболее эффективные способы выявления технического долга на ранних стадиях: 

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

• Показатели сложности. Инструменты, измеряющие сложность кода, помогают выявить проблемные разделы, требующие внимания. Высокая цикломатическая сложность или глубокая вложенность часто указывают на области, нуждающиеся в рефакторизации. 

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

• Мониторинг производительности. За большим временем отклика или резкими скачками использования ресурсов могут стоять технические проблемы, требующие внимания. 

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

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

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

1. Дайте четкое определение техническому долгу

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

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

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

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

2. Интегрируйте тестирование в рабочий процесс

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

Уточните, что «готовой» считается версия, которая не только обладает всеми функциями, но и прошла тестирование, подтвердившее готовность к выпуску. Это значит, что в исходную пользовательскую историю нужно отдельной задачей добавить тестирование. Если для исходной истории или исправления бага тестирование не выполнено, они не считаются готовыми. 

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

3. Боритесь с багами с помощью автоматизации

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

Это главный принцип разработки на основе тестирования — проверенной методики поддержания высокого качества в Agile-разработке.

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

• Объясните владельцу продукта реальные последствия технического долга. Уточните оценку сложности будущих пользовательских историй, для которых нужно погасить существующий технический долг.

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

• Создавайте автоматические тесты. Ничто лучше не предотвращает появление багов, чем автоматические тесты и непрерывная интеграция. При обнаружении бага создайте новый тест, чтобы воспроизвести проблему, а затем устраните ее. Если этот баг появится снова, автоматический тест выявит его раньше, чем с ним столкнутся клиенты.

Концепцию технического долга можно проиллюстрировать несколькими простыми примерами.

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

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

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

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

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

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

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

Попробовать Jira

Что такое технический долг в Scrum?

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

Как предотвратить технический долг?

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

Технический долг — это всегда что-то плохое?

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

На кого влияет технический долг?

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

Как измеряется технический долг?

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