16 Nis 2015

Technical Debt(Gizli Tehlike)

Author: strongsoul | Filed under: Agile

Yazılım geliştirmede iki yol vardır, teki hızlı ve kirli diğeri ise biraz zaman alır ama temiz bir tasarım içerir, hızlı ve kirli olanın ileride oluşturacağı sorunlar aşikardır, bu yapılandırma bize teknik borcun ifadesini verir.

Teknik borç metaforu Ward Cunningham tarafından geliştirilmişdir. Takımların gözden kaçırdığı ve hatta tamamen yok saydığı teknik borçlar, zamanla birikerek projeleri başarısızlığa götüren önemli sebeplerdendir. Zamanında yapılmayan teknik iyileştirmeler, bir süre sonra “dokunulan yer elde kalıyor” cümleleri ile yankı bulup, iş verenin anlamakta zorlanacağı “bir süre ek iş alamayız ancak yatacakta değiliz” cümlesi ise iyi bir etki bırakmamaktadır.

Biriken borçlar sizi teknik iflasa götürebiliyor ve en sonunda çöpe atılmış işe yaramaz bir yazılım ile başbaşa kalabiliyorsunuz.

Kod gelişime açık olarak ilk başda yapılandırılmamış ise bu bir borç olarak yansıyacaktır, her borcun etkisi aynı şekilde değildir etkisini minimuma indirebilmek için erken müdahale şarttır. Kanayan yaraya acilen müdahale edip kan kaybını arttırmamak gerekir 🙂

Zaten borçlu olan bir geliştirmeyi onu arttıracak şekilde birleşik bir borç yığını haline sokmamalıdır zira kaliteyi getirmeyen her kod bir teknik borca çıkacaktır.
Sprintte bitti kavramı çok önemlidir fakat done’ larda arka yüzey çok belirli değildir kodun kalitesi test sürecini ve yeni geliştirmelerin süresini azaltıp arttıracağından borçlanma bu durumda aslında done lar için ortaya çıkan bir tıkanmadır.

Teknik borcun çeşitleri şu şekildedir
. Naive – Tecrübesizlik, bilgisizlik ve vurdum duymazlıktan oluşan kod yığınlarıdır, büyük borçlar oluşturur.
. Unavoidable – ürünün üretimi sırasında zorunlu ortaya çıkardığı etkenlerdir, borcu düşüktür
. Stratejik – bilerek girdiğimiz borçtur kısa vadeli hedeflere ulaşmak içindir.

Yol açtıkları sorunlar ise şu şekildedir
. Dönüşü olmayan tahmin edilemeyen noktaya – kritik dağınıklık noktasına ulaşılır.
. Pazara çıkış süresinin artması ve buna bağlı düş kırıklığı, hüsran, gerilim takımdan şirkete yayılır.
. Bu süreçler ölçülebilir olmadığından müşteri anlayamaz.

Nasıl farkedilir? Bir önceki sprintte yaptıklarını öbür sprintte düzeltiyorsan tehlikedesin demektedir, teknik borç üst seviyelerdedir.

Çözüm :
Ne hesaplarsan hesapla müşteri memnun olmadıdır ilkesi ile teknik borcu görünür hale getirmek gerekir.

son söz olarak borç yiğidin kamçısıdır ne kadar çabuk ödenirse izleri ve acısı o kadar çabuk unutulur 🙂
ve Bonus : “Kamp yaptığın yeri bulduğundan daha iyi bırak!”

Yorum Bırakın