Большинство из нас, занимающихся программным обеспечением, имеют скромное представление о техническом долге, но задумывались ли вы когда-нибудь обо всех затратах за весь срок службы?
В этой статье мы рассмотрим фиктивный технический долг от начала до разрешения.
Моя цель - заставить вас задуматься о техническом долге с разных точек зрения.
Принятие технического долга
Наш сценарий начинается с того, что компания упорно работает, чтобы уложиться в срок. У демонстрации на крупной торговой выставке есть огромные финансовые преимущества.
Это последний спринт перед демонстрацией. Дела идут хорошо, но график плотный. В стойке Кайла описывает функцию, над которой она работает, и то, что степень сложности намного выше, чем ожидалось.
По оценкам Каля, чтобы выполнить эту функцию должным образом, потребуется восемь часов, но в спринте не осталось времени. Двейн предлагает предложение, которое позволило бы команде удовлетворить критическую потребность всего за три часа.
После некоторых размышлений команда решает использовать краткосрочный обходной путь и создает элемент невыполненной работы, чтобы должным образом очистить функцию после крайнего срока.
Команда выполняет функцию, как и планировалось, сроки соблюдаются, и компания получает прибыль от решения команды.
К этому моменту команда получила пять часов продуктивности (основная сумма по ссуде) от взятия долга.
Ранний интерес
После демонстрации компания взяла на себя ряд ключевых продаж и взяла на себя обязательства, которые стали огромным достижением для компании. Это захватывающее время для компании, и команда рада, что их работа вознаграждается.
Из-за нескольких ошибок, обнаруженных во время демонстрации, а также из-за некоторых необходимых новых функций, тикет о техническом долге не прошел в следующий спринт.
Кроме того, во время спринта Дуэйн обнаруживает, что из-за обходных приемов, предпринятых командой, теперь ему нужно потратить дополнительный час на разработку при внедрении новой функции. В нашей финансовой метафоре это можно представить как интерес.
Давайте сделаем паузу и посмотрим на этот сценарий на диаграмме водопада. Это финансовая диаграмма, на которой показаны финансовые транзакции с течением времени. В конце концов, кажется уместным только представить финансовую метафору, такую как технический долг, с помощью финансового графика.
Мы читаем эту диаграмму как рассказ слева направо. Здесь мы получили пять часов продуктивности, взяв на себя долг, но потеряли один час из-за работы, что привело к чистой прибыли в четыре часа продуктивности.
Дополнительный долг
Во время следующего спринта перед командой стоит задача погасить технический долг.
Однако, прежде чем Кайла сможет начать работу над этим, возникает пара срочных ошибок, которые необходимо добавить в спринт. Эти ошибки возникают из-за обходного пути. Репликация каждой ошибки, написание теста, исправление, тестирование и исправление в производственной среде занимает три часа.
Кроме того, у Кайлы не хватило времени, чтобы выплатить долг, поэтому он переходит к следующему спринту.
В результате наша диаграмма водопада теперь выглядит так:
На данный момент команда потеряла два общих часа продуктивности из-за первоначального ярлыка - и они даже не начали выплачивать первоначальный технический долг.
Истинная стоимость технического долга
Как и ожидалось, задача погасить первоначальный долг переходит в следующий спринт.
К счастью, на этот раз команде ничего не мешает, и Кайла может полностью погасить долг, потратив на это еще пять часов.
В целом это приводит к потере производительности от принятия решения до семи часов. Кроме того, это решение вызвало некоторые недостатки, с которыми сталкивались клиенты, что подорвало пользовательский опыт и доверие.
Вдобавок к этому с ошибками и задачами по выплате технического долга связаны альтернативные издержки. Другими словами, поскольку команда работала над этими элементами, они не могли работать над другими улучшениями программного обеспечения.
Так что это значит? Не должна ли команда брать в долг?
Я бы сказал нет. На самом деле это довольно идеальная история с точки зрения урегулирования технического долга. Долг был взят разумным и преднамеренным фактором. Без этого решения компания не смогла бы выбраться на свидание и потеряла бы 100 000 долларов на продажах и сделках.
Помимо этого, команда настойчиво расставляла приоритеты по долгам и ошибкам, которые из-за них возникли.
Нет, просто потому, что долг стоил команде гораздо больше времени на разработку, не означает, что это было плохое решение. Но мы должны помнить, беря в долг, что погашение долга будет намного больше, чем повышение производительности, если оно когда-либо будет выплачено.
Несчастная правда
Это подводит нас к досадной правде: история этой команды, полностью выплачивающей долг, очень необычна.
Я бы сказал, основываясь на собственном опыте, что большая часть технических долгов не решается.
По моему опыту, долг может жить - и часто остается - до тех пор, пока продукт не будет выведен из обращения. Фактически, я наблюдал, как серьезный кодекс технической задолженности дублировался и служил основой для будущей работы.
Если вы позволите техническому долгу сохраняться в вашем коде, он послужит архитектурной основой для будущего кода.
Большинство команд не берут на себя технический долг так намеренно, как это сделала наша команда в этой статье. Это означает, что они вряд ли получат много или потенциально какую-либо выгоду от взятия этого долга.
Другими словами: если бы вам пришлось взять на себя пять часов технического долга, вы бы предпочли, чтобы это было сделано для крупной продажи или потому что разработчик однажды почувствовал себя немного ленивым?
Итак, каковы наши основные выводы?
- Технический долг в конечном итоге стоит намного больше, чем время, которое вы потратили бы на его правильное выполнение.
- Краткосрочная техническая задолженность может быть ключевым преимуществом для организации.
- Технический долг часто представляет собой постоянный риск для качества.
- Технический долг следует отслеживать и определять приоритеты.
