Article

Teknik Borç Backlog'u Nasıl Yönetilir? Alios ile

Teknik borç görünmez kaldığı sürece birikerek krize dönüşür. Alios'ta teknik borç yönetimini iş ağacı ve önceliklendirme rutiniyle nasıl kuracağınızı öğrenin.

Teknik Borç Backlog'u Nasıl Yönetilir? Alios ile

Teknik borç birikir. Sessizce, görünmeden, "sonra hallederiz" diye ertelene ertelene. Sonra bir gün prodüksiyonda kritik bir şey kırılır ve o kırılmanın kökü altı ay önce hızla yazılmış, test edilmemiş, refactor edilmemiş koda dayanır.

Problem teknik borcun varlığı değil. Her canlı ürünün teknik borcu var. Problem görünmez kalması. Görünmez olan yönetilemiyor, yönetilemeyen biriyor, biriken patlıyor.

Teknik Borç Neden Görünmez Kalıyor?

Teknik borç backlog'a girmiyor çünkü "acil" değil. Her sprint yeni feature talebi, yeni bug, yeni müşteri isteği var. Bunların hepsi teknik borçtan daha görünür, daha acil görünüyor.

Bunun yanında teknik borç ölçülmüyor. "Şu modül kötü yazılmış" bir gözlem, bir metrik değil. Sprint planlamasına sığdırmak için somut bir büyüklük, öncelik ve beklenen çıktı gerekiyor. Bunlar yokken teknik borç her seferinde erteleniyor.

Son olarak teknik borcun maliyeti görünmüyor. Refactor yapılmadığında ne kaybediliyor? Yeni feature ekleme süresi uzuyor, bug oranı artıyor, onboarding zorlaşıyor. Bu maliyetler hesaplanmadığı için tartışma sırasında "önemli ama acil değil" kalıbına giriyor.

Alios'ta Teknik Borç İş Ağacı

Alios'ta teknik borç yönetimi için ayrı bir üst node açılıyor. Bu node sprint backlog'undan bağımsız ama sprint planlamasında düzenli gözden geçiriliyor.

📁 TEKNİK BORÇ BACKLOG

├── 📁 Kritik — Prod Riski
│   ├── [ ] Auth modülü güvenlik güncellemesi
│   ├── [ ] Payment servis hata yönetimi eksik
│   └── [ ] Rate limiting yok — DDoS riski

├── 📁 Yüksek — Geliştirme Hızını Etkiliyor
│   ├── [ ] User service N+1 sorgu sorunu
│   ├── [ ] Test coverage %23 — kritik modüllerde yok
│   └── [ ] Deprecated kütüphane — 3 modülde

├── 📁 Orta — Sürdürülebilirlik
│   ├── [ ] Dashboard sorgu optimizasyonu
│   ├── [ ] Error handling standardizasyonu
│   └── [ ] API response format tutarsızlığı

└── 📁 Düşük — Nice-to-have
    ├── [ ] README güncelleme
    ├── [ ] Log format standardizasyonu
    └── [ ] Eski comment'lerin temizlenmesi

Her teknik borç node'u şu bilgileri taşıyor:

📌 TEKNİK BORÇ — [Başlık]
Öncelik: [Kritik / Yüksek / Orta / Düşük]
Kategori: [Güvenlik / Performans / Sürdürülebilirlik /
           Test coverage / Bağımlılık]
Tahmini efor: [Küçük / Orta / Büyük]
Etkilenen alan: [Hangi modül, servis veya özellik]

Mevcut durum:
[Ne sorun yaratabiliyor, ne riski taşıyor]

Beklenen çıktı:
[Yapıldıktan sonra ne iyileşecek]

Ölçüm:
[Öncesi: X — Sonrası hedef: Y]
Örnek: Test coverage %23 → %60
       Ortalama sorgu süresi 340ms → 80ms altı

Önceliklendirme Rutini

Teknik borç backlog'u her iki haftada bir 20 dakikalık review'a alınıyor. Sprint planlaması sırasında değil, ayrı bir slot:

📋 TEKNİK BORÇ REVIEW — İki Haftada Bir

1. Yeni eklenenler gözden geçirildi — öncelik atandı
2. Kritik node'lar mevcut sprint'e alındı mı kontrol edildi
3. Yüksek öncelikli node'lardan biri önümüzdeki
   sprint'e alınacak belirlendi
4. Kapatılan node'ların etkisi ölçüldü
5. Yeni incident veya prod sorunu çıktıysa ilgili
   teknik borç node'u önceliği güncellendi

Her sprint'te toplam kapasitesinin %15-20'si teknik borca ayrılıyor. Bu oran küçük görünüyor ama tutarlı uygulandığında borç birikmiyor.

Kapanış Kriterleri

Teknik borç node'u şu koşullar sağlandığında kapanıyor:

✅ Beklenen çıktı gerçekleşti
✅ Ölçüm yapıldı — hedef karşılandı mı?
✅ Test yazıldı (varsa)
✅ Review tamamlandı
✅ Yeni incident riski azaldı — doğrulandı
✅ Node açıklamasına "öncesi / sonrası" notu eklendi

Ölçüm: Ne Takip Edilmeli?

Teknik borcun etkisini somutlaştıran iki metrik:

Lead time: Bir feature'ın backlog'dan canlıya çıkmasına kadar geçen süre. Teknik borç azaldıkça lead time kısalıyor. Bu korelasyon sprint bazında takip edilebilir.

Incident oranı: Prodüksiyon olaylarının kaç tanesi teknik borçla ilişkili? Her incident postmortem'inde "root cause teknik borç muydu?" sorusu sorulup node'a işleniyor.

Bu iki metrik teknik borcun "önemli ama acil değil" kalıbından çıkmasını sağlıyor. Sayılar konuştuğunda sprint planlamasında yer açmak kolaylaşıyor.