Teknik borç (technical debt) nedir? Ekipte teknik borcu nasıl yönetir ve iş tarafına nasıl anlatırsınız?

Teknik borç, bugün daha hızlı ilerlemek için seçilen kestirme çözümlerin gelecekte yarattığı ek maliyettir. Ward Cunningham'ın benzetmesiyle, borcun faizi her yeni özellikte ödenen fazladan efor, yavaşlama ve hata riskidir. Her teknik borç kötü değildir; bilinçli ve geri ödeme planıyla alınan borç, pazara hızlı çıkmak için meşru bir araçtır.

Martin Fowler'ın teknik borç dörtlüsü

Türleri

• Kod borcu: tekrar, karmaşık fonksiyonlar, eksik testler.
• Mimari borç: sıkı bağlı modüller, ölçeklenmeyen tasarım.
• Altyapı borcu: eski framework/kütüphane sürümleri, manuel deploy.
• Dokümantasyon ve bilgi borcu: sadece bir kişinin bildiği sistemler.

Yönetim yöntemleri

1. Görünür kılın: borçları backlog'a etiketli iş olarak ekleyin; kod içine dağılmış TODO'lar yeterli değildir.
2. Etkiye göre önceliklendirin: sık değişen ve hata üreten bölgeler (hotspot) önce. git log ile değişiklik sıklığı ve karmaşıklık birlikte analiz edilebilir.
3. Kapasite ayırın: her sprint'in sabit bir yüzdesi (ör. %15-20) bakım ve borca ayrılabilir.
4. Boy Scout kuralı: dokunduğunuz kodu bulduğunuzdan biraz daha temiz bırakın.
5. Yeni borcu sınırlayın: Definition of Done'a test ve review kriterleri, CI'da statik analiz.
6. Büyük borçlar için plan: Strangler Fig deseniyle kademeli değişim; "her şeyi baştan yazalım" projelerinden kaçının.

İş tarafına anlatmak

Teknik jargon yerine iş metrikleri kullanın:

• "Ödeme modülünde her yeni özellik iki kat uzun sürüyor; son çeyrekte bu modül kaynaklı 6 production hatası oldu."
• "İki sprint'lik bir yatırımla bu alandaki teslim süresini yarıya indirebiliriz."
• Riskleri somutlaştırın: desteği biten bir framework sürümü güvenlik açığı demektir.

Örnek senaryo

Sık değişen bir faturalama servisinde testler olmadığı için her değişiklik manuel regresyon gerektiriyordu. Ekip, yeni özellik geliştirirken dokunulan her fonksiyona karakterizasyon testi ekleme kuralı koydu ve her sprint'in %20'sini bu alana ayırdı. Üç ayda servis kaynaklı hata sayısı ve regresyon süresi belirgin şekilde düştü.