Технический долг

Спасаясь от черной дыры технического долга

//Сделать  (Шучу!)

А если серьезно: твой рефлекс стонет, когда ты видишь это? Да, мы тоже.

Традиционные программы имеют поэтапный подход к разработке: разработка функций, альфа, бета и золотой мастер (GM).

Каждый выпуск релиза начинается с фазы, на которой создаются новые функции и (в идеале) решаются остаточные проблемы, оставшиеся с момента последнего выпуска  релиза (но давайте будем честными: это случается редко). Цикл разработки достигает «альфа», когда каждая функция реализована и готова к тестированию. Бета-версия появляется, когда исправлено достаточно багов, чтобы обеспечить обратную связь с клиентом. К сожалению, пока команда занята исправлением багов, достаточных для выхода на бета-версию, появляются новые баги. Это хронический случай со взломом: исправьте одну ошибку и еще две - всплывает окно. Наконец, релиз достигает золотой вехи мастера, когда нет нулевых открытых багов. «Ноль открытых багов» обычно достигается путем исправления некоторых известных проблем и переноса остальных (больше всего?) до следующего выпуска релиза.

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

Там должен быть лучший путь.

 

Сокращение технического долга с помощью Agile

Agile внедряет качество в итеративный подход к разработке, поэтому команда может поддерживать постоянный уровень качества выпуска релиза после выпуска. Если функция не работает, она не отправляется. Находите что в это трудно поверить? Ну, есть хитрость: определение или переопределение определения «сделано».

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

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

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

Укрощение долга вашей команды

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

 

Определите это

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

Это включает в себя любые технические наиболее рациональные доработки, сделанные для соблюдения сроков доставки!

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

 

 Остерегайтесь тестирования спринтов и заданий

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

 

Автоматизировать ошибки

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

Когда начать?

Изменить философию команды (и ее участников) о том, как управлять техническим долгом, непросто. Бизнес-потребности иногда сокращают время разработки, чтобы быстрее выйти на рынок. Имея это в виду, давайте вспомним некоторые действия для укрощения технического долга:

• Обучите владельца продукта истинной стоимости технического долга. Убедитесь, что значения историй точны для будущих историй, которые требуют разрешения существующего технического долга.
• Разбейте на модули вашу архитектуру и примите твердое отношение к технической задолженности в новых компонентах или библиотеках приложения. Когда команда и бизнес увидят гибкость в этих новых компонентах, они, естественно, захотят распространить эту практику на другие части кода.
• Пишите автоматизированные тесты! Ничто не может предотвратить баги лучше, чем автоматические тесты и постоянная интеграция. Когда новая ошибка найдена, напишите новый тест, чтобы воспроизвести ее, а затем устраните проблему. Если эта ошибка когда-либо всплывет, автоматический тест обнаружит ее раньше, чем это сделают клиенты.

 

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

По материалам Agile Coach "Technical debt"