Teknik Borç Nedir?

İÇİNDEKİLER:
- Teknik Borç Nedir?
- Teknik Borç Türleri Nelerdir?
- Product Owner’ın Teknik Borç Hakkında Bilmesi Gerekenler
- Teknik Borç Nasıl Yönetilmelidir?

Yazılım geçmişli olmayan ekip üyeleri ve yöneticiler teknik borcun ne anlama geldiğini, nasıl ölçüleceğini ve nasıl ödenmesi gerektiğini nadiren bilir. Lakin, teknik borçları çözüme kavuşturulmamasından doğacak riskler sadece Development Team’i değil, diğer tüm paydaşları da zora sokabilir. 🤷 Bu teknik kavramı yönetebilmek için öncelikle ne anlama geldiğini ve neleri etkileyebileceğinin farkında olmamız gerekiyor. Bu yazımda, projede uygulanması istenen bir değişiklik ihtiyacı doğduğunda bunun neden her zaman hızlı bir şekilde gerçekleştilemeyeceğinden bahsedeceğim. 🧐

Teknik Borç Nedir?

“Teknik borç” terimi, yazılım geliştirme ekiplerinin kısa vadede hızlı proje teslimi sağlayabilmesi için uygulaması kolay çözümlere başvurmalarıdır. Ancak, mevcut mimariye uygunluğu değerlendirilmemiş bu anlık çözümler uzun vadede, genel kod yapısını; kirletir, hataya daha yatkın hale getirir ve gelecekte eklenecek yeni feature’ların geliştirilmesini yavaşlatır hatta imkansız hale getirir. Sonunda, bu borçları orijinal kodu temizleyerek “geri ödersiniz”. 💰

Teknik borç, yazılım geliştirme sürecinde daha fazla zaman alacak daha kaliteli bir yaklaşım kullanmak yerine, sadece şu anda düşünülmüş bir çözümün oluşturduğu maliyeti ifade eder.

Teknik Borç Türleri Nelerdir?

Development Team kaliteden ödün vermeden geleceğe dönük kodlar oluşturmaya çalışsalar bile, borçlar istemeden doğabilir. Bu, ürün gereksinimlerindeki değişiklikler, yeni trendlere uyma veya pazar koşullarının değişmesiyle tetiklenebilir.

Kasıtlı Teknik Borç

Eksiklikler her zaman hata anlamına gelmez. Bazen ekipler, ürünlerini daha hızlı piyasaya sürmek için kasıtlı olarak teknik borçlanır. Ekip bu kasıtlı teknik borçları proje boyunca yakından izlemesi şartıyla kabul edilebilir. 🕵️

Kasıtlı teknik borçlanma seçimi ile karşı karşıya kaldığınızda, fırsat maliyetini göz önünde bulundurmalısınız. Burada Product Owner’a büyük sorumluluk düşmektedir. Ürünü daha hızlı piyasaya sürmek için sorunları şimdilik gözardı etmeye değer mi, ürünün mevcut faydaları riske değer mi, ürünün repütasyonunu nasıl etkileyecek, gelecekte eklenecek yeni özellikleri nasıl etkileyecek vb. soruları ele alması gerekmektedir.

Evet, bazen riske değer. Eğer ekibiniz için de durum böyleyse, ürünü geliştirmeye devam ederken kasıtlı teknik borcunuzu izlemek ve yönetmek için gerekli adımları atmalısınız.

Teknik borç Product Backlog’da takip edilmelidir, aksi takdirde geri ödenmesi ve ekibinize gelecekte bir yük haline gelmesi muhtemeldir.

Kaçınılmaz Teknik Borç

Bazen sorunlar, Development Team’in kontrolü dışındaki faktörlerden kaynaklanır. Örneğin, 3rd party kaynaklı sistem yükseltmeleri veya 6 ay önce uygulanan bir çözümün bugün tercih edilmiyor olması, Development Team’in DoD tanımlarını güncellemesi (bir güvenlik zafiyeti farkedilmesi, mimari güncellemesi vs.), ürünün pazarda geri kalmasını önleyecek yeni trendler.. Bazen öyle sorunlarla karşılaşırsınız ki ona hangi açıdan yaklaşırsanız yaklaşın önlemek imkansızdır. Bu nedenle yöneticilerin her sistemin zamanla geliştirilmesi gerektiğini bilmesi gekir.

Bu tür bir teknik borçtan kaçınmanın en iyi yolu, mevcut mimariyi sürekli geleceğe hazır hale getirmektir. 🏃‍♂️

Kasıtsız Teknik Borç

Bu tür bir teknik borç, hatalardan ve sistemi yeteri kadar iyi okuyamamaktan kaynaklanmaktadır. Yeni özellikler, acil düzeltmeler, bug fixing gibi hızlı çözümler kodu spagettiye çevirir. 🍲 Çünkü acil bir anda odaklanılan ilk şey her zaman kalite yerine maliyet ve zamandır.

Tüm teknik borçlardan kaçınmak elbette mümkün değildir, ancak ürün yol haritası boyunca bunların nasıl yönetildiği ürünün yaşam süresini belirlemede genel bir izlenim yaratacaktır.

Product Owner’ın Teknik Borç Hakkında Bilmesi Gerekenler

Üründen sorumlu kişi olarak Product Owner, çoğu zaman kodun ne kadar temiz ve iyi yazılmış olduğu konusunda çok bir endişesi bulunmaz. Fakat temiz kod ürünün kalitesi için çok önemlidir. Çünkü teknik yapı (backend) belirlenen stratejik ürün hedeflerine ulaşılmasını doğrudan etkiler. Teknik borçlar çoğaldıkça, yeni fikirleri denemeyi, yeni özellikleri yayına almayı ve kullanıcı taleplerine hızlı bir şekilde yanıt vermeyi zorlaştırır. 😓 Kod ne kadar çok karmaşık ve mimari ne kadar az modüler olursa, ürünü değiştirmek bir o kadar uzun sürer ve pahalıya mal olur.

En kötü senaryoda; ekip, business taleplerine cevap verebilmek için kodun bazı parçalarının değişmesi veya tüm ürünün yeniden geliştirilmesi gerekebileceği bir durumla karşılaşabilir.🤯 İşte bu yüzden teknik borç finansal borç kavramından türetilmiştir. Finansal borç geri ödenmediğinde, faiz ödemeleri çoğalır ve sonunda işinizi felce uğratır.

Yukarıda teknik borcun ortaya çıkma sebeplerinden bahsettik fakat teknik borcu kimin takip etmesi ve önlemesi gerektiğinden tam olarak bahsetmedik.

Kimileri ürünün nihai sorumlusu Product Owner olduğu için tüm sorumluluğu ona devrederken, diğer bir görüş Development Team’in yönetmesi gerektiğini düşünmektedir. ⚔️

Teknik Borç Nasıl Yönetilmelidir?

Önümüzdeki altı ay boyunca ürüne yeni özellikler eklemeye devam edip sonrasında ayrı bir sessionda daha büyük teknik iyileştirme çalışmaları mı planlamalıyız? Yoksa henüz mimari esnekken teknik borcu şimdi ele almak daha mı mantıklı? İşte Product Owner’ın kilit rollerinden biri burada karşımıza çıkıyor.

Retrospective toplantıları ürünün yapılan geliştirmelerden ne derece etkilendiğini, teknik borç yaratıp yaratmadığını öğrenmek ve kayıt altına almak için ideal bir toplantıdır. Ek olarak, Product Owner ekipten ne kadar teknik borcun oluştuğunu, nerede bulunduğunu, durumun ne kadar kötü olduğunu gösteren verileri toplamasını talep edebilir. 📝 Örneğin, karmaşık kod bloğu, dependencies, test coverages vs.

Product Owner, ürünün teknik borcunun büyüklüğünü ve riskini anladıktan sonra, yapacağı ilk iş Development Team ile birlikte ürün hedeflerine ulaşma ve ürünün başarıya ulaşma konusunda ne kadar sorun oluşturacağını analiz etmektir. 📈 Gecikme maliyetini de hesaba katarak teknik borç şimdi mi ele alınmalı yoksa ertelenmeli mi nihai kararı vermelidir.

Yukarıdaki case’e iki yoldan yaklaşmakta fayda var.

1) Yapılması gereken iş o kadar büyük bir değişiklik ki bir Sprint’te tamamlanamayabilir veya takımın büyük bir efor harcamasını gerektirebilir. Risk ve Maliyet dikkate alınacak kadar büyüktür ve PO’nun en azından bilgilendirilmesi gereken bir seviyede olduğu kabul edilir. Yani kısaca, bu işe (rework) başka bir zamanda mesai harcanmalı ve yapılması gereken zaman PO tarafından belirlenmelidir.

2) Gerçekleştirilecek iş (rework) yukarıdaki büyüklükte değildir ve bu nedenle Development Team’in günlük işlerinin ve sorumluluğunun bir parçası olarak tamamlanabilir. Bazen gözden kaçan bir ayrıntı, iletişim eksikliği, teknik yetersizlik gibi konular rework yapmanın kaynağı olabilir. Bu tarz durumların sıklığı Scrum Master tarafından takip edilerek günlük rutinin içerisinde çözüme kavuşturulabilir.