Teknik borç, birçok ekip tarafından bir düşman gibi görülüyor; "hiç teknik borcumuz olmasın" gibi ulaşılması zor bir hedef güdülüyor. Oysa teknik borç tamamen ortadan kaldırılacak bir şey değil, bilinçli olarak yönetilmesi gereken bir gerçeklik.
Her Teknik Borç Kötü Değildir
Bazen bir teslim tarihine yetişmek için bilinçli olarak "şimdilik bu şekilde yapalım, sonra düzeltiriz" demek doğru bir karar olabilir — yeter ki bu karar bilinçli alınsın ve unutulmasın. Sorun, borcun kendisi değil, fark edilmeden, planlanmadan birikmesi.
Teknik Borcu Görünür Kılmak
Kod içine // TODO: burayı düzelt yazıp unutmak yerine, bu tür notları ekibin takip ettiği bir backlog'a (Jira, Azure DevOps vb.) iş kalemi olarak ekliyorum. Görünmeyen borç yönetilemiyor; görünür kılındığında en azından bilinçli bir önceliklendirme yapılabiliyor.
Her Sprint'e Küçük Bir Pay Ayırmak
"Teknik borç sprint'i" diye ayrı bir sprint planlamak genelde iş birimi tarafından hep ertelenen bir öncelik haline geliyor. Bunun yerine her sprint'in kapasitesinin küçük bir yüzdesini (örneğin %10-15) teknik borç ödemeye ayırmak, bunu sürekli ve görünmez bir alışkanlık haline getiriyor.
Dokunduğun Yeri Biraz Daha İyi Bırakmak
Her teknik borcu ayrı bir görev olarak planlamak yerine, "boy scout kuralı"nı uyguluyorum: bir dosyaya dokunduğumda, orada gördüğüm küçük bir sorunu (kötü isimlendirme, eksik test, karmaşık bir metod) de düzeltiyorum. Bu küçük iyileştirmeler zamanla toplamda büyük fark yaratıyor.
İş Birimine Riski Anlatmak
"Teknik borç" terimi iş birimi için soyut kalıyor. Bunun yerine somut sonuçlarla konuşuyorum: "bu modülü değiştirmek şu an 3 gün sürüyor, borcu ödersek 1 güne inecek" gibi. Bu, teknik borç ödemeye zaman ayırmayı iş birimine daha kolay onaylatıyor.
Sonuç
Teknik borç, bir proje canlı kaldığı sürece asla sıfıra inmeyecek bir gerçeklik. Amacım borcu yok etmek değil; onu görünür, ölçülebilir ve bilinçli bir şekilde yönetilebilir tutmak.