Ana içeriğe atla

Teknik Borç Önceliklendirme Çerçevesi Şablonu

TL; TR: Önceliklendirme Kriterleri​

Teknik Borcun Önceliklendirilmesi: Kod Bilgisi. Ciddiyet. Bağımlılık ve Ölçek. Düzeltme Maliyeti

  • Kod Bilgisi. Kodla ne kadar aşinasınız?

  • Ciddiyet. Yazılımın işlevselliğini veya performansını nasıl etkiler?

  • Bağımlılık ve Ölçek. Kodun o kısmına kaç bileşen bağımlıdır? Etkilenen yazılım mimarisinin ölçeği.

  • Düzeltme Maliyeti. Teknik borç sorununu düzeltmek kaç hikaye puanına mal olur?

Toplam Puan = (Bilgi + Ciddiyet + Bağımlılık) – 3 * Maliyet

Ayrıca okuyun: Teknik Borcun Önceliklendirilmesi için 5 İpucu.

Teknik borç nedir?​

Teknik borç, yazılım geliştirmede kullanılan mecazi bir terimdir ve kısa vadede uygulanması kolay olan kodun, daha uzun sürebilecek daha sağlam veya ölçeklenebilir seçenekler yerine tercih edilmesiyle ortaya çıkan ekstra geliştirme çalışmasını tanımlar. Uzun vadeli sürdürülebilirlik, genişletilebilirlik veya güvenilirlik için optimize edilmemiş kısayollar alma veya kod yazma maliyetini ifade eder.

Teknik borç örnekleri arasında okunması ve anlaşılması zor spagetti kodu yazma, artık desteklenmeyen eski kütüphaneler veya çerçeveler kullanma, kod veya testleri belgelendirmede başarısız olma ve düzenli bakım veya güncellemeler yapmayı ihmal etme yer alır.

Teknik Borç Örnekleri​

Tipik Teknik Borç Sorunları:

  1. Eski veya kullanımdan kalkmış teknoloji kullanma: Eski veya desteklenmeyen teknoloji kullanmak uyumluluk sorunlarına ve güvenlik açıklarına neden olabilir.

  2. Zayıf kod kalitesi: Okunması, anlaşılması ve sürdürülmesi zor kod, hatalara, üretkenliğin azalmasına ve geliştirme süresinin artmasına neden olabilir.

  3. Dokümantasyon eksikliği: Kod, süreçler ve gereksinimleri belgelendirmede başarısız olmak, gelecekteki geliştiricilerin yazılımı anlamasını zorlaştırabilir ve geliştirme süresinin artmasına ve daha yüksek maliyetlere yol açabilir.

  4. Yetersiz test: Testi atlamak veya ertelemek, tespit edilemeyen hatalara, güvenlik açıklarına ve kullanıcı memnuniyetsizliğine neden olabilir.

  5. Mimari tasarım kusurları: Yazılımı optimal olmayan bir mimariyle tasarlamak veya ölçeklenebilirlik için planlama yapmamak, yazılım zamanla daha karmaşık ve sürdürülmesi zorlaştıkça teknik borca yol açabilir.

Teknik borç olarak kabul edilmeyen örnekler:

  1. Proje için kritik olmayan veya daha sonra tamamlanabilecek işleri kasıtlı olarak ertelemek.

  2. Bir son tarihi karşılamak veya hızlıca bir prototip sunmak için kısayol almaya yönelik bilinçli kararlar vermek.

  3. Proje hedefleri için hala kabul edilebilir olan optimal olmayan bir çözümü kasıtlı olarak uygulamayı seçmek.

  4. Zaman, maliyet ve iş gereksinimleri gibi diğer faktörlerle yapılan ödünleşmelere dayanarak, potansiyel sınırlamaları olsa bile belirli bir teknoloji veya aracı kullanmaya karar vermek.

  5. Yazılımı önemli ölçüde iyileştirmeyen rutin bakım görevlerini gerçekleştirmek.

Teknik borç problemi​

Teknik borcun ana problemi, zamanla birikebilmesi ve yeni özellikler eklemeyi, hataları düzeltmeyi veya kod tabanını sürdürmeyi zorlaştırmasıdır.

  • Özelliklerin geliştirilmesi daha uzun sürer

  • Daha Fazla Hata

Her zaman kodunuzu geliştirmek ile yeni özellikler eklemek arasında bir denge vardır.

Teknik Borç Önceliklendirme Kriterleri​

Bu kriterleri göz önünde bulundurarak, görev takibi sorunlarınızdaki teknik borcu tanımlamanıza ve ele almanıza yardımcı olan, iş değerini maksimize eden ve riski minimize eden bir önceliklendirme sistemi oluşturabilirsiniz.

Takımınızın daha iyi anlaması için kriterlerin adını ve açıklamasını eklemekte, değiştirmekte veya yeniden yazmakta özgürsünüz.

Her kriter için, hikaye puanı tahmini için en uygun ölçek olarak Fibonacci Dizisi değerlendirme ölçeğini kullanıyoruz.

.app panosunda Teknik borç önceliklendirme kriterleri

hi.ducalis.io panosunda Teknik borç önceliklendirme kriterleri

Kod Bilgisi​

Bir geliştirme ekibinin üzerinde çalıştığı kod tabanını anlama ve tanıma düzeyidir. Kodu anlama ve içinde gezinme yeteneğinin yanı sıra, projede kullanılan kod yapısı, tasarım desenleri ve en iyi uygulamaların anlaşılmasını içerir.

Kod bilgisi, bir geliştirme ekibi için kritik öneme sahiptir çünkü yüksek kaliteli kod yazma ve verimli bir şekilde sürdürme yeteneklerini doğrudan etkiler. Daha fazla kod bilgisine sahip ekipler daha hızlı ve doğru çalışabilir.

Kısacası, kod bilgisi bir geliştirme ekibinin beceri setinin önemli bir bileşenidir ve çalışmalarının kalitesini ve verimliliğini doğrudan etkiler.

  • 1: Yazar. O kod parçasını ben yazdım—bakımını yapabilirim ve açıklayabilirim.

  • 2: Bakımcı. O kodla çalıştım—nasıl çalıştığı hakkında soru yok.

  • 3: Ulaşılabilir. Ekip arkadaşıma sorabilirim ve bu konuda dokümantasyon okuyabilirim.

  • 5: Belgelenmiş. Üzerinde çalışmadım. Bununla ilgili bazı dokümantasyonumuz var.

  • 8: Anlaşılabilir. Üzerinde çalışmadım ama önemli bir çaba harcamadan nasıl çalıştığını öğrendim.

  • 13: Zorlayıcı. Nasıl çalıştığını bulmak için önemli zamana ihtiyaç var. O kod üzerinde çalışmadım, ancak üzerinde çalışan birine ulaşabilir veya dokümantasyon bulabilirim.

  • 21: Hiç duymadım. Ekibinizde o kodu bilen kimse yok veya yakında ayrılacaklar.

Ciddiyet​

Etki Ciddiyeti: Teknik borç sorununun yazılımın işlevselliğini veya performansını ne kadar etkilediğini belirleyin. Etkinin ciddiyeti yüksek, orta veya düşük olabilir ve bu, önceliklendirme için bir kriter olarak kullanılabilir.

  • 1: Hiç etkisi yok.

  • 2: Kozmetik: Bazı yerel bileşenler üzerinde sığ etki. Kaynaklar ve zaman müsait olduğunda gelecekte ele alınabilir.

  • 3: Küçük: İyi çalışıyor, ancak iyileştirebiliriz. Kaynaklar ve zaman müsait olduğunda gelecekte ele alınabilir.

  • 5: İnşaatçı: Üretkenliği yavaşlatır, kodu daha az sürdürülebilir hale getirir veya yeni özelliklerin eklenmesini engeller. Kaynaklar izin verdiğinde daha sonra ele alınabilir.

  • 8: Engelleyici. Yazılımın bir bileşeninde daha fazla geliştirme veya güncellemeyi engeller. Önemli sorunların ortaya çıkmasını önlemek için yakında ele alınmalıdır.

  • 13: Büyük. Birden fazla yazılım bileşenini engeller ve neredeyse kırar. Projeye ek riskler veya gecikmeler yaratır.

  • 21: Kırıcı. Yazılımı kullanılamaz hale getirir veya çözülmezse yüksek risk oluşturur.

Bağımlılık ve sistem ölçeği​

Kodun o kısmına kaç bileşen bağımlıdır? Etkilenen yazılım mimarisinin ölçeği:

  • 1: Önemsiz. Herhangi bir noktada geri ödenebileceği için göz ardı edilebilir.

  • 2: Küçük yerel. Tek bir metot, sınıf veya fonksiyonda kendi içinde yer alır. SOLID prensiplerini ihlal edebilir—yazılımın genel kalitesi üzerinde önemli bir etkisi yoktur.

  • 3: Orta düzeyde yerel: Birden fazla metot, sınıf veya fonksiyonu etkiler. Ayrıca istenmeyen sonuçlara yol açmadan değiştirilmesi daha zor olabilir.

  • 5: Küresel. Tek bir uygulamada veya serviste kendi içinde yer alır ancak daha geniş bir sistemdeki alt sistemler arasında SOLID ihlallerini içerir ve görünüşte ilgisiz alanlara yayılır. Ayrıca soyutlama katmanları arasında uyumsuzluk, entegrasyon noktası sorunları ve sıkı eşleşmeyi içerebilir. Bu borç, uygulamanın veya servisin tüketicilerini etkilemez, ancak servisin kendisi değiştirilirken hissedilir.

  • 8: Büyük küresel. Yazılımın kalitesi üzerinde daha önemli ve yaygın etki. Birden fazla alt sistemi içerebilir ve tüm uygulamayı veya servisi etkileyebilir. Ayrıca istenmeyen sonuçlara yol açmadan değiştirilmesi daha zor olabilir.

  • 13: Sistemik. Birden fazla uygulamaya, altyapıya veya ekibe yayılır. Bir veri deposunu paylaşan çok sayıda servisi, farklı sınırlandırılmış bağlamlar arasında yüksek eşleşmeyi ve teknik uygulamalar ile iş mantığı arasında keskin bir uyumsuzluğu içerir. Sistemik borç uzun vadede sürdürülemez ve acil dikkat gerektirir.

  • 21: Kritik. Yazılımın genel kalitesi için önemli bir risk oluşturur ve sistemin istikrarını ve güvenilirliğini etkileyebilir.

Düzeltme maliyeti​

Teknik borç sorununun düzeltilmesi kaç hikaye puanına mal olur?

  • 1: Efor yok

  • 2: Düşük maliyet: Sprint süresinin %10'u.

  • 3: Orta: Sprint süresinin %20'si.

  • 5: Önemli: Yarım sprint

  • 8: Yüksek: Bir sprint

  • 13: Çok yüksek: Bir sprintten fazla, ancak iki sprintten az. Birden fazla soruna bölünmesi önerilir.

  • 21: Aşırı pahalı. Bununla nasıl başa çıkılacağına dair şu anda hiçbir fikir yok. İki sprint ve daha fazlası.

Kriter açıklamalarını özelleştirin​

En iyi kriter açıklamalarının ekip arkadaşlarınız için daha kolay anlaşılır olanlar olduğunu unutmayın. Ne kadar spesifik kriter ve ölçek açıklamasına sahip olursanız, önceliklendirme süreciniz için o kadar iyi olur. Sprint sürelerini, bağımlılık açıklamalarını, engelleyicilerin tanımlarını ve kod bilgisinin anlamını belirtin. Kriter açıklaması düzenleme hakkında daha fazla bilgi edinin.

hi.ducalis.io'de ekibiniz için kriter açıklamalarını kişiselleştirmek kolaydır

Kriter Açıklamalarını Özelleştirin

Teknik borç değerlendirmesi için uygun olmayan kriterler​

İş değeri, tekrarlama, yaş ve kullanıcı deneyimi üzerindeki etki, teknik borcu değerlendirmek için güvenilir kriterler değildir.

Kullanmayın: İş Değeri veya Kullanıcı Deneyimi​

Kod kalitesi, dokümantasyon, test kapsamı ve yazılım mimarisi gibi faktörler nadiren gelir gibi iş metrikleriyle doğrudan ilişkilendirilir. Bu faktörler, geliştirme ekibinin değişiklikleri verimli bir şekilde yapma yeteneğini ve yazılımın genel kalitesini, güvenilirliğini ve ölçeklenebilirliğini etkiler.

Teknik borcun sürdürülmemesinin en popüler nedenlerinden biri, onu potansiyel gelir olarak değerlendirmektir.

Kullanmayın: Tekrarlama​

Teknik borç sorununun gelecekte tekrar ortaya çıkma olasılığını düşünün. Teknik borç tekrar ortaya çıkabilecek bir hata değildir. Geleceği tahmin etmek için zamanınızı boşa harcamayın.

Kullanmayın: Sorun Yaşı​

Eski kütüphaneleri daha erken yeniden düzenlemek açık ve basit bir fikir gibi hissedilebilir. Ancak kod iyi çalışıyor, yavaşlamıyor veya güvenlik açıkları oluşturmuyorsa neden buna zaman harcayasınız ki? Yaş, önceliklendirme kriteriniz olmamalıdır.

Teknik borç sorunları için öncelik puanı hesaplama​

Her zamanki gibi, teknik borç için en önemli sorunları belirlemek amacıyla doğru strateji için kriter ağırlıklarını dengelememiz gerekir. Varsayılan olarak, -2 ağırlığına sahibiz. Ekibinizde ne kadar az geliştirici kaynağınız varsa, ağırlığın o kadar negatif olması gerekir.

Teknik Borç önceliklendirmesi için .app'te Maliyet Kriteri kurulumu

'Maliyet' kriteri için ağırlık kurulumu

Nihai formül oldukça basittir:

Teknik borç iş listesi için sorunları toplama​

Ken Ruben tarafından Essential Scrum: En Popüler Agile Sürecine Pratik Bir Rehber

"Essential Scrum: En Popüler Agile Sürecine Pratik Bir Rehber" kitabında yazar Ken Ruben, teknik borcu tanımlamak için üç kategori kullanır: rastlantısal, bilinen ve hedeflenen teknik borç.

  • Rastlantısal teknik borç, geliştirme ekibinin rutin ürün kullanımı veya bakımı sırasında ortaya çıkana kadar var olduğunu bilmediği teknik borçtur. Örneğin, yazılıma yeni bir özellik eklerken, ekip yıllar önce koda eklenen ve değiştirilmeden bırakılan, beklenmedik davranışlara neden olan bir geçici çözüm keşfedebilir. Rastlantısal teknik borç ayrıca, kodun zamanla bozulması, işlevini ve kullanılabilirliğini değiştirmesiyle ortaya çıkan 'bit çürümesi' nedeniyle de oluşabilir.

  • Öte yandan, Bilinen teknik borç, geliştirme ekibinin zaten farkında olduğu ve yazılımda görebildiği teknik borçtur. Bilinen teknik borç örnekleri arasında zayıf kod kalitesi, dokümantasyon eksikliği veya yetersiz test yer alır.

  • Son olarak, hedeflenen teknik borç, geliştirme ekibinin belirli bir sprint veya sürümde ele almayı seçtiği bilinen teknik borçtur. Bu, teknik borcu azaltmak ve yazılımın kalitesini artırmak için kodu yenilemeyi, dokümantasyonu iyileştirmeyi veya test kapsamını artırmayı içerebilir.

Farklı teknik borç türlerini anlayarak, geliştirme ekipleri çabalarını önceliklendirebilir ve teknik borçla başa çıkmak için çalışarak yazılımın uzun vadeli sürdürülebilirliği ve güvenilirliği üzerindeki etkisini en aza indirebilir.

İpucu 1. Görev takibi araçlarınızda özel bir bölüm oluşturun​

Teknik borç sorunlarını hatalar veya özellikler gibi diğer sorunlardan ayırmak için bir özelliğe sahip olmak önemlidir. Özel bir etiket/label, sorun türü veya bileşen kullanın. Her zaman tüm sorunlarla birlikte tam iş listesine bakma ve türe göre filtreleme seçeneğiniz olmalıdır.

İpucu 2. Tutarlı bir format kullanın​

Teknik borç sorunlarını kaydetmek için, iş listesi aracınızda bir kullanıcı hikayesi veya görev gibi tutarlı bir format kullanın. Bu, teknik borç sorunlarını kolayca tanımlamanıza ve önceliklendirmenize yardımcı olacaktır.

İpucu 3. Net bir açıklama sağlayın​

Teknik borç sorununun net bir açıklamasını sağlayın; kod tabanı üzerindeki etkisini, düzeltmek için gereken tahmini çabayı ve olası riskleri veya sonuçları dahil edin.

İpucu 4: Rastlantısal teknik borcu toplamak için Kod Değişiklik Sıklığını kullanın​

Kod Değişiklik Sıklığı, bir yazılım sisteminin kod tabanında ne sıklıkla değişiklik yapıldığını gösterir.

Bir yazılım projesinin sağlığını ve kalitesini değerlendirmek ve potansiyel sorunları ve riskleri tanımlamak için kullanılabilir. Etkiyi değerlendirmeye, yüksek riskli alanları tanımlamaya ve kod tabanında değişiklik yapma konusunda bilinçli kararlar almaya olanak tanır.

  • Yüksek sıklık, sık güncellemeleri, iyileştirmeleri, istikrarsızlığı veya hataları gösterebilir.

  • Düşük sıklık, bakım veya gelişim eksikliğini gösterebilir ve bu da teknik borca ve diğer sorunlara yol açabilir.

Bu fikirle ilgili Adam Tornhill'in "

" konuşmasını izlemenizi şiddetle tavsiye ederiz.

İpucu 5: Kodunuzu Yavaşlık ve Güvenlik Açıkları için Otomatik Tarayın​

Kod analizleri için birçok araç vardır. Bunları deneyin ve bulunan sorunları görev takibi araçlarınızın iş listesine gönderin.

  1. Code Scene — Yazılımınızı kod, bilgi ve arkasındaki insanlar açısından görselleştirmek, anlamak ve iyileştirmek için tek bir araç. Otomatikleştirilmiş, önceliklendirilmiş ve eyleme dönüştürülebilir önerilere dayalı iyileştirmeler yapın.

  2. SonarQube: Kodunuzdaki güvenlik açıklarını, kod kokularını ve diğer sorunları tespit edebilen popüler bir araç. Çeşitli programlama dillerini destekler ve çeşitli CI/CD araçlarıyla entegre olur.

  3. OWASP ZAP: SQL enjeksiyonu, siteler arası betik ve diğer güvenlik sorunları gibi güvenlik açıklarını tespit edebilen açık kaynaklı bir web uygulaması güvenlik tarayıcısı.

  4. CodeClimate: Kodunuzu analiz eden ve kalitesi, sürdürülebilirliği ve güvenliği hakkında içgörüler sağlayan bulut tabanlı bir platform. Çeşitli programlama dillerini destekler ve GitHub, Bitbucket ve diğer araçlarla entegre olur.

  5. Snyk: Kodunuzu ve bağımlılıklarınızı güvenlik açıkları için tarayan ve düzeltme tavsiyeleri sağlayan bulut tabanlı bir araç. Çeşitli programlama dillerini destekler ve çeşitli CI/CD araçlarıyla entegre olur.

  6. AppDynamics: Uygulamalarınızın performansına yanıt süresi, hata oranı ve diğer metrikler dahil olmak üzere gerçek zamanlı içgörüler sağlayan bir araç. Performans darboğazlarını tanımlamanıza ve kodunuzu optimize etmenize yardımcı olur.

  7. Qodana. Sahip olduğunuz, sözleşme yaptığınız veya satın aldığınız kodun bütünlüğünü değerlendirin. CI/CD hatlarınızı JetBrains IDE'lerinden sevdiğiniz tüm akıllı özelliklerle zenginleştirin.

Sonuç​

Teknik borç, yazılım geliştirmede kaçınılmazdır ancak aynı zamanda ilerleme ve yeniliğe önemli bir engel olabilir. Ekibiniz için işleyen bir teknik borç önceliklendirme sistemi geliştirerek, etkisini en aza indirebilir ve yazılımınızın kalitesini ve güvenilirliğini zaman içinde koruyabilirsiniz.

Teknik borcun sadece bir geliştirici sorunu olmadığını unutmayın; tüm organizasyonu etkiler. Teknik borç yönetimini proje yönetimi süreçlerinize dahil ederek, herkesin etkisinin farkında olmasını ve bununla başa çıkmak için birlikte çalışmasını sağlayabilirsiniz.

Son olarak, teknik borçla başa çıkmanın tek seferlik bir olay olmadığını hatırlamak önemlidir; sürekli dikkat ve çaba gerektirir. Teknik borç iş listenizi düzenli olarak gözden geçirip güncelleyerek, potansiyel sorunların üstesinden gelebilir ve yazılımınızın uzun vadede sağlıklı ve güvenilir kalmasını sağlayabilirsiniz.

Sonraki: Teknik Borcun Önceliklendirilmesi için 5 İpucu

Güncelleme: Bu hafta