Teknik borç bir metafor değil, bir maliyet kalemi
Teknik borç çoğu ekipte bir vicdan meselesi gibi konuşulur; oysa doğru çerçeve muhasebedir. Görünür kılınmayan borç faiz işletir: yavaşlayan geliştirme, artan hata oranı ve zorlaşan işe alım. Bu yazıda teknik borcu ölçülebilir bir maliyet kalemine dönüştürmek için kullandığımız yöntemleri anlatıyoruz.
Borcu görünür kılmak
Teknik borcun en tehlikeli hali, yalnızca geliştiricilerin zihninde yaşayan halidir. Biz her borç kalemini, ürün işleriyle aynı backlog'da, aynı formatta tutuyoruz: ne olduğu, hangi riski taşıdığı ve dokunulmazsa neyin pahalanacağı. Bir kalemi "kod kötü" diye değil, "bu modüle özellik eklemek 2 kat uzun sürüyor" diye yazdığınızda, önceliklendirme tartışması mühendislik jargonundan çıkıp iş kararına dönüşüyor.
Faizi ölçmek
Her borcun faizi aynı değildir. Nadiren dokunulan bir iç araçtaki dağınıklık düşük faizli borçtur; her sprintte üzerinde çalışılan çekirdek modüldeki kırılganlık ise yüksek faizlidir. Önceliklendirmede iki soru soruyoruz: bu koda ne sıklıkla dokunuyoruz ve dokunduğumuzda ne kadar yavaşlıyoruz? Yüksek trafik + yüksek sürtünme kombinasyonu her zaman listenin başına çıkar.
Teknik borcu sprint planına yazmadığınız sürece, onu her sprint gizlice ödersiniz — üstelik en pahalı kurdan.
Sprint planındaki yeri
Pratikte uyguladığımız kural, her sprint kapasitesinin belirli bir bölümünü — genellikle yüzde 15-20 — borç azaltmaya ayırmak. Bu oran pazarlığa kapalı olduğunda ekip "büyük refactor sprintleri" beklemek zorunda kalmıyor; borç, birikip krize dönüşmeden küçük parçalar halinde eriyor. Büyük yeniden yazımların aksine bu yaklaşım, ürün yol haritasını da durdurmuyor.
Sonuç
Teknik borç kaçınılmazdır; sorun borcun kendisi değil, yönetilmemesidir. Görünür kılın, faizini ölçün ve geri ödemeyi rutine bağlayın. Uzun ömürlü sistemler kurma yaklaşımımızı hizmetler sayfasında bulabilirsiniz.