13 Temmuz 2013 Cumartesi

Agile buluşmanın ardından: Teknik Borç

Agile Turkey'in düzenlediğin Agile Buluşmalar'ın 8'incisi 23 Mayıs günü Meydan AVM'de bulunan Caribou Caffee'de gerçekleşti. Buluşmada, agile aktivitelerine katkılarından tanıdığımız, PSM ve PSPO sertifikalarına sahip deneyimli Scrum Master Atilla Alkoç bizlere "Teknik Borç (Technical Debt)"tan bahsetti. Yaklaşık 15 kişilik katılımcı kitlesi ile teknik borcu tüm detayları ile konuştuk. Bunda Atilla Bey'in konusuna bir akademisyen titizliğinde hazırlanmış olmasının da katkıları olduğunu belirtmem gerek. Buluşma sırasında katılımcıların deneyimlerini paylaşması ile çok zengin bir içeriğe ulaşmış olduk.

Yazılım takımlarının yoğun tempo içerisinde çokça gözden kaçırdığı, ve hatta tamamen yok saydığı teknik borçlar, zamanla birikerek projeleri başarısızlığa götüren önemli sebeplerden. Zamanında türlü nedenlerle yapılmayan teknik iyileştirmeler, bir süre sonra sizi ve takımınızı "neresine dokunsak patlıyor" ya da "projeyi baştan yazmamız gerek" noktasına getiriyor. İş birimlerinin ve proje yönetiminin anlamakta zorlandığı "bir süre yeni özellik ekleyemeyeceğiz, ancak bizi hala finanse etmeniz gerekiyor" durumu da çoğu kez bu nedenle oluşuyor. Biriken teknik 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.

Buluşma sırasında almış olduğum notları şöyle listeleyebilirim.
  • Metafor, XP'nin ilk versiyonunda olan bir kavramdı. Teknik olan kavramları teknik olmayan kavramlarla ilişkilendirmek demektir. "Technical debt" de bir metafordur.
  • Technical Debt metaforunu ilk isimlendiren kişi, Wiki kelimesinin de isim babası olan Ward Cunningham'dır. 
  • "İyi mimari", kodu rahatça genişletebileceğimiz yapıya denir.
  • Rahatça genişletebileceğimiz yapıka kavuşmak için kodu "refactor" ediyoruz. "Refactoring" genel olarak, yazılımın dış dünya ile olan bağlantılarını aynı bırakıp, içini yeniden düzenlemek şeklinde tanımlandırılabilir.
  • Yeni bir şey eklemek için kodu önceden hazırlamanız gerekir. Eğer hazırlamazsanız, gelecekte problemlerle karşılaşırsınız.
  • Eğer hazırlamazsanız, bu projenin hesabına yazılmış bir borç olarak yansır. Tıpkı ortalığı günlerce dağıtmak sonrasında toplamak zorunda kalmak gibi.
  • Borçta faiz de işler. Her borcun faizi aynı olmaz. Faizi yüksek şeyleri bekletmemeli. Hemen müdahale etmeli.
  • Bileşik Faiz: Borcu ödemeden yeni özellikler eklemeye çalışmak :)
  • "Sprint"te bitti kavramı çok önemli. Bir PBI'ın bittiğini "bittinin tanımı (DoD)"na bakarak karar veriyoruz.
  • Teknik borcun içine bir süre sonra her türlü ekstra iş girmeye başlıyor. 
  • "Bittinin tanımı (DoD)" eksikliğinden teknik borç oluşuyor. Çok fazla manual test yapmak bile teknik borçtur.
  • Kaliteden ödün verdiğin herşey bir tenkik borçtur. Bunun da ucu çok açık. Eğer "bittinin tanımı (DoD)" olgun değilse, teknik borcun hala vardır.
  • Teknik borcu ödediğin nokta bazı zamanlarda "release'e özel yada refactoring'e özel sprint hazırlamak" olabilir.
  • Amerika'da teknik borcun götürüsü yılda 1 milyar doları geçmiş durumda.
  • Yöneticiler artık bilançoda kısa ve uzun vadedeki teknik borcun durumunu görmek istiyorlar.
  • Teknik borcun türleri vardır: 
    • Naive / unintentional (Safça ya da bilmeyerek yapılmış): UncleBob buna teknik borç demiyor, "dağınıklık (mess)" diyor. Kalitesiz programcılar ve iş süreçleri nedeniyle oluşuyor. Burdan ortaya çıkan şeye "özensiz tasarım (sloppy design) diyoruz. Sorumsuzluktan, tecrübesizlikten ve bilgisizlikten oluşuyor. En büyük riski olan bu.
    • Unavoidable (Kaçınılmaz):  Ürünün gidişatına göre oluşur. Engellenemez, riski düşüktür.
    • Strategic (Stratejik): Bilerek girdiğimiz borç. Kısa vadeli hedeflere ulaşmak için alınabilir.
  • Yol açtıkları sorunlar ise kısaca şöyle:
    • Tahmin edilemeyen dönüşü olmayan noktaya (Unpredictable tipping point) ulaşılıyor. Buna "kritik dağınıklık (critical mess)" da deniyor. İpin ucu bildiğiniz kaçıyor. Ufak değişiklikler büyük değişikliklere yol açıyor.
    • Pazara çıkış süreniz (Time to delivery), hata sayısı, maliyetler artıyor. Kod çürüyor, ürün yaşlanıyor (product acrophy). Tahminler (Estimates) tutmuyor. Yazılımcıların anlık perfomansı azalıyor. Düş kırıklığı, hüsran, gerilim takımdan şirketlere yayılıyor.
  • Ölçülebilen süreçler ve ölçümler olmadığı için müşteri anlayamıyor.
  • "Testi kısarsak hızlanırız" dediğinde kısa vadede hızlanıyor ancak teknik borç artıyor. Aslında gerçek olmayan bir hızda (velocity) çalışıyorsun.
  • Bunun son noktası: yeni bir şey üretememek ve hep maintenance yapmak oluyor.
  • Bir önceki sprintte yaptıkların işi öbür sprintte düzeltiyorsan tehlikedesin demektir. Teknik borç çok üst seviyelerdedir.
  • İş birimlerinin (Business) ve ürün sahiplerinin (PO) teknik borcu bilmesi gerekli.
  • Safça yapılan borçları hemen düzeltmemiz gerekli. Eğitimlerle başlabilir.
  • TDD ve refactoring yapmak ve "bittinin tanımı (DOD)"a uymak gerekli.
  • Teknik borcu görülür hale getirek gerekir. Buna iş birimi seviyesinde bilançoda görülmesi dahil.
  • Teknik borçlar için kendine has "liste (backlog)" oluşturulabilir.
  • Bazen %5 - %30 arası tahminlere (estimation) yada kapasitelere giydiriliyor. Bu da bir yöntem.
  • İzci kuralı teknik borçları yoketmek için gerekli.
  • Ürün sahibi (PO) için müşteri memnuniyeti en önemli KPI'dır. Ne hesaplarsan hesapla, müşteri memnun olmalı.
Teknik borç, iş birimi, ürün sahibi, proje yönetimi ve yazılım takımları tarafından mutlaka bilinmeli, eğitimler ile üzerine mutlaka kafa yorulmalı. Teknik borçtan kaçış olmadığına göre, "en hızlı şekilde borçtan kurtulmak için ne yapılmalı" konusunda çalışmak her takımın öncelikli görevlerinden olmalı.

Teknik borç konusunda daha fazla bilgi için aşağıdaki bağlantılara göz atabilirsiniz.


Herkese az borçlu mutlu günler diliyorum.

0 yorum:

Yorum Gönder

Template developed by Confluent Forms LLC; more resources at BlogXpertise