Комментарии 2
Проблема в том, что наращивающие долг команды обычно забивают и на тесты, развивая систему по принципу «ничего не трогай, только добавляй». В этом варианте цена долга с ненаписанными тестами превысит цену полной переделки где-то вдвое быстрее.
Понравилась метафора "технический налог": Мы принимаем, что появление технического долга неизбежно, это не решение берём долг или не берём, он появляется "сам", в наших силах лишь стараться уменьшать налоговую базу и вовремя и регулярно платить, чтоб не допускать снежного кома пеней и штрафов. То есть в наших силах стараться не допускать появление большого долга при разработке с одной стороны, а, с другой, постоянно выделять часть ресурсов, например 10 или 20% рабочего времени непосредственно на его целенаправленное погашение. Редко же кто планирует уплату налогов по принципу "будут свободные деньги после релиза — заплачу, а пока есть более важные траты". Часто налоги платят даже раньше конечного срока уплаты. Да, иногда принимаются решения просрочить уплату, но с чётким пониманием, что а) заплатить придётся б) больше чем вовремя в) следующих платежей это не отменит и г) бьёт по репутации. Грубо говоря, можно принять решение день, отведенный в каждом спринте на рефакторинг, дописывание тестов, устранения причин варнингов и нотисов в разных логах и отчётах, обновление зависимостей и прочая, и прочая, и прочая, забрать для завершения важной фичи, но чётко понимая, что в следующем спринте это будет уже два дня (перенесеный день плюс "родной" день следующего спринта) плюс несколько часов "пеней и штрафов".
Технический долг