Yazılım Ekiplerinde Teknik Borç Nasıl Görünür Hale Getirilir?

Yazılım ekiplerinin çoğu teknik borcun var olduğunu bilir. Ama bu borç çoğu zaman bir geliştiricinin kafasında, bir kod incelemesinin yorumlarında ya da bir ekip sohbetinde kalır. Planlama toplantısında yeni özellikler konuşulur, teknik borç ise "sonra bakarız" cümlesiyle kenara itilir. Sonuç olarak sistem bir sprint daha yavaşlar, bir release daha kırılgan hale gelir ve kimse tam olarak ne zaman bu noktaya gelindiğini söyleyemez.

Bu yazıda teknik borcun neden görünmez kaldığını, onu backlog içinde nasıl somutlaştıracağınızı ve hangi sırayla ele almanız gerektiğini anlatıyoruz. Amaç borcu sıfırlamak değil, ekibin kararlarını bilinçli hale getirmek.

Teknik borç neden görünmez kalır?

Teknik borç, iş hedefleriyle doğrudan ilişkilendirilmediğinde planlama dışında kalır. Bir ürün yöneticisi "ödeme ekranına yeni bir yöntem ekleyelim" dediğinde bu bir iştir ve kolayca kartlanır. Ama "ödeme modülündeki bağımlılıklar güncel değil" cümlesi bir iş tanımı gibi durmaz, bu yüzden önceliği düşük görünür.

Görünmezliğin birkaç tipik nedeni var:

• Kayıt yok: Borç, kod yorumlarında ya da bireylerin notlarında yaşar. Ekip dışından kimse bu notlara bakmaz.
• Ölçü yok: "Kod karışık" demek bir ölçü değildir. Hangi modülün, kaç kez değiştirildiğini ve her değişiklikte ne kadar süre harcandığını bilmiyorsanız borcun faturasını çıkaramazsınız.
• Dil farkı: Geliştirici "bu yapı tekrar yazılmalı" derken yönetici "bu neden şimdi gerekli" diye sorar. İki taraf da haklıdır ama ortak bir dil yoktur.
• Kriz beklemek: Borç ancak bir olay yaşandığında gündeme gelir. O noktada ödeme planı zaten pahalıdır.

Borcu backlog'da bir iş öğesi gibi yazın

Teknik borcu görünür kılmanın en pratik yolu, onu diğer işler gibi backlog'a yazmaktır. Ancak yazarken iki kuralı uygulayın: her kayıt bir sonucu tanımlasın ve her kayıt bir kişiye ya da takıma atanabilsin.

Kötü bir kayıt: "Veritabanı sorgularını iyileştir."

Daha iyi bir kayıt şöyle olur: "Sipariş listesi ekranında N+1 sorgusu var; 500 kayıtta sayfa yüklenmesi belirgin biçimde uzuyor. Hedef: sayfa yükleme süresini ölçülebilir bir eşiğin altına indirmek ve ilgili sorguyu tek sorguya çevirmek." Bu kayıt kimin ne yapacağını, neden önemli olduğunu ve bitince neyin değişeceğini söyler.

Her borç kaydına şu alanları eklemenizi öneririz:

• Etkilenen modül ya da servis
• Borcun türü: performans, güvenlik, bağımlılık, test eksikliği, mimari tutarsızlık
• Son üç ayda bu alana dokunan iş öğesi sayısı (bu veriyi issue geçmişinden çıkarabilirsiniz)
• Gecikmenin tahmini sonucu: hangi özellik yavaşlıyor, hangi hata sıklaşıyor
• Tahmini çaba: küçük, orta, büyük gibi kaba bir ölçek yeterlidir

Bu alanlar tam olmak zorunda değil. Önemli olan, borcun artık bir sayfada, bir kişinin hafızasında değil, ortak bir listede durmasıdır.

Önceliklendirme: hangi borç önce ödenmeli?

Her borcu aynı anda ödemeye çalışmak, ekibi tüketen bir tuzaktır. Bunun yerine borçları iki eksende değerlendirin: iş etkisi ve değişim sıklığı. Sık değiştirilen ve iş akışına yakın bir modüldeki borç, nadiren dokunulan bir yardımcı kütüphanedeki borçtan daha değerlidir.

Pratik bir sıralama için şu soruları sorabilirsiniz:

1. Bu borç bir güvenlik açığı ya da veri bütünlüğü riski taşıyor mu? Taşıyorsa sprint dışında bile olsa önce gelir.
2. Önümüzdeki iki çeyrekte planlanan özellikler bu alana dokunacak mı? Dokunacaksa borcu o özelliğin içine koymak çoğu zaman en ucuz yoldur.
3. Borç, geliştirici deneyimini ne kadar yavaşlatıyor? Her derleme ya da test döngüsünde kaybedilen dakikalar birikir.
4. Ödeme sonrası sistemde ölçülebilir bir fark görecek miyiz? Göremeyeceksek öncelik düşüktür.

Bu sorular sonucunda üç kategoriye ayrılmış bir liste elde edersiniz: hemen ödenecekler, bir sonraki özellikle birlikte ele alınacaklar ve izlenmeye devam edilecekler. Üçüncü grup da değerlidir çünkü "izlemede" olan bir borç zamanla büyüyorsa bunu fark etmenizi sağlar.

Sprint kapasitesinde borç için sabit bir pay ayırın

Teknik borç ödemesi sürekli "boş zaman olursa" yapılan bir iş olarak kalırsa hiçbir zaman yapılmaz. Bu yüzden sprint kapasitesinin belirli bir kısmını baştan borca ayırmak daha sağlıklıdır. Oran ekibe göre değişir; önemli olan oranın sabit ve görünür olmasıdır.

Uygulamada şu düzen işe yarar:

• Sprint planlamasında önce borç kapasitesi ayrılır, sonra yeni özellikler yerleştirilir.
• Borç işleri de sprint panosunda normal kartlar gibi görünür ve kapanış kriterleri vardır.
• Sprint sonu incelemesinde kapanan borç kayıtları ve bunların etkisi konuşulur.
• Kapasiteyi aşan acil durumlarda, hangi borç işinin ertelendiği açıkça yazılır. Sessizce atlanmaz.

Bu yaklaşımın bir yan faydası, geliştiricilerin borç konusunda sesinin duyulmasıdır. Artık "kod kötü" demek yerine "bu modül son iki sprintte üç kez hata kaynağı oldu, şu kayıt bunu kapatır" diyebilirsiniz. Karar veren kişi de neyi neden kabul ettiğini görür.

Ekip dışına anlatmak için birkaç ölçü

Teknik borç konusunda üst yönetimle ya da ürün ekipleriyle anlaşmak, çoğu zaman ölçüyü bulmakla ilgilidir. Kesin rakamlara ihtiyacınız yoksa bile eğilim gösteren birkaç göstergeyi düzenli takip edebilirsiniz:

• Bir özelliği tamamlamak için geçen ortalama süre, modül bazında
• Bir release sonrası geri alınan ya da hotfix gerektiren değişiklik sayısı
• Açık kalan teknik borç kayıtlarının sayısı ve yaşı
• Geliştiricilerin borç kaynaklı bağımlılık ya da yan etki nedeniyle yeniden çalışma yaptığı işlerin oranı

Bu göstergeleri ilk ay yalnızca izleyin, hedef koymayın. Eğilimi görmek, kararın dayanağı olur. Üçüncü aydan itibaren bu veriyi bir sprint sonu raporunda üç satırla paylaşmak, borç konusunu soyut bir şikâyet olmaktan çıkarır.

Sık yapılan hatalar

Teknik borç yönetimi girişimleri bazen şu nedenlerle dağılır: borç listesini tek seferde tüm ekibin önüne koymak ve on yıllık sorunları bir haftada çözmeyi beklemek; borç kayıtlarını çok ayrıntılı yazıp kimsenin okumadığı bir belgeye dönüştürmek; ya da yalnızca bir kişiyi borç sorumlusu yapıp ekibin geri kalanını bu konudan muaf tutmak. Bu hatalardan kaçınmak için listeyi küçük tutun, kayıt şablonunu sadeleştirin ve borç ödemesini ekip ortak sorumluluğu olarak tanımlayın.

Sonuç

Teknik borç kendiliğinden kaybolmaz; yalnızca görünmez hale gelir. Borcu backlog'a ölçülebilir kayıtlar olarak yazmak, onu iş etkisine göre önceliklendirmek ve sprint kapasitesinde sabit bir pay ayırmak, ekibin bu konuda bilinçli kararlar almasını sağlar. Başlamak için bu hafta yapabileceğiniz tek şey, bilinen üç borç maddesini bir iş öğesi olarak yazıp önümüzdeki sprinte koymaktır.

Borç kayıtlarını, sprint panolarını ve bu kararları tek bir yerde takip etmek istiyorsanız Subtask demosunu deneyerek ekibinizin iş akışına nasıl oturduğunu görebilirsiniz. Platform seçimi konusunda genel bir karşılaştırma için araç fazlalığının nasıl azaltılacağını anlatan yazımıza ve ekiplerde süreç kopukluğunun kökenleri için operasyonel verimsizlik nedenleri yazısına göz atabilirsiniz.