Teknik çevikliğin düşmanı teknik borç
İyi borç sizi yükseltir, kaldıraç olur. Kötü borç ödediğiniz faizle birlikte döndürülemez bir noktaya gelebilir, sizi bağlar.
Borç en yalın haliyle, bir şeyi ileride ödeme niyeti ve sözüyle bugün ödünç almaktır. Türk Dil Kurumu borcu şöyle tanımlıyor;
Geri verilmek üzere alınan veya ödenmesi gerekli para veya başka bir şey.
Borcu iyi borç ve kötü borç olarak tanımlamak doğru olur. Eğitiminiz için borçlanıyorsanız, bu sayede daha iyi bir gelecek elde edebilirsiniz, iyi bir borçtur. Pahalı bir tatil, lüks bir yemek için borçlanmak getirisi sınırlı olduğu için kötü borca örnek olabilir.
İyi borç sizi yükseltir, kaldıraç olur. Kötü borç ödediğiniz faizle birlikte döndürülemez bir noktaya getirebilir, sizi bağlar, içine çeker, yok olursunuz.
Finansal borçla benzer özellik taşıdığı için “teknik borç” ilk olarak Ward Cunningham tarafından kullanılmış. Agile Manifesto’nun da yazarlarından olan Cunningham, 1992’deki OOPSLA konferansında şöyle diyor:
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.”
Cunningham’ın söylediklerini özetlersek, işleri hızlı ve dağınık yapmak aynı finansal borçta olduğu gibi bizi borçlandırır. Yine finansal borçta olduğu gibi, hızlı ve yanlış seçimlerimiz ve uygulamalarımız için ekstra efor harcayarak faiz öderiz.
Teknik borcu birden fazla şekilde tarifleyebiliriz, ilk aklıma gelenler;
- Teknik borç, gerçekte teslim edilen ile vaat ettiğimiz arasındaki farktır.
- Teknik borç, bir yazılımı geliştirirken zaman ya da paradan tasarruf etmek adına verilen yanlış kararların sonucu teknik çevikliğin kaybedilmesidir.
- Teknik borç, pazara hızlı çıkmak için bazı “detay”ların görmezden gelinmesi ve sonrasında düzeltilmemesidir.
- Teknik borç, uygulamanın başkaları tarafından görünmeyen kısımlarında, işlerin çok ta olması gerektiği şekilde olmamasıdır.
- Teknik borç, uygulamanın belli bir şekilde görünmesi için hızlıca bulduğunuz çözümlerdir.
- Teknik borç, geliştirme bittikten sonra bulduğumuz daha iyi bir yoldur.
- Teknik borç, güncelliğini yitirmiş yazılım ve iç içe geçmiş uygumalardır.
Finansal borcun hayatımızdaki bazı hedeflere daha erken ve hızlı ulaşmamızı sağlaması gibi, teknik borcun da her türlüsü kötü değildir. İyi yönetildiğinde büyük faydalar sağlar.
“If you’re not embarrassed by the first version of your product, you’ve launched too late.” – Reid Hoffman
Eğer yeni bir ürün geliştiriyorsanız, sıfır teknik borçla çıkartmaya çalıştığınızda birileri muhakkak sizden önde olacaktır. O yüzden planlı, karar olarak alınmış ve yönetilebilir bir borç ürün yönetimi için stratejik bir hamle olarak kullanılabilir.
Teknik borcun zorlayıcı tarafı, genelde insanların sizi bu borç konusunda zorlamaması… İnsanlar çağrı merkezinizi arayıp, mimarinizi değiştirmeniz gerektiğinizi söylemez. Çalıştığı sürece ses çıkartmazlar… Bu yanıltıcı durum, “yalancı refah” borcun arkaya itilmesine, gözden uzakta kalmasına, göz ardı edilmesine neden olur. Tâ ki işler döndürülemez noktaya gelene kadar …
Birikmiş borç teslimat hızını yavaşlatır, ekibin moralini bozar, verimsizlik, uyuşlukluğa neden olabilir, geciken aksiyon ileride önüne geçilemeyecek hale gelebilir. Bu işlerin sayısı arttıkça ilgilenmek daha zor hale gelecek, ertelenen işler kod kalitesini kötüleştirdiğinden geliştirme hızı düşecek, dokunmaktan korkulacak ve bu sonsuz bir döngü içinde başarısızlığa kadar gidecektir.
Teknik borç, teknik çevikliğin önündeki en önemli engellerden birisi. Biz lTunes’da teknik borcu kabul edip, kucaklamaya çalışıyoruz. Önemli olan;
- teknik borcun nereden geldiğini bilmek,
- maliyetinin farkında olmak,
- şeffaf şekilde göstermek,
- mümkün olan aşamalarda ölçülebilir müşteri çıktılarıyla teknik borcun azaltılması gayretlerinin nasıl birleştirebileceğine çalışmak
- sürekli bir borç ödeme akışı sağlamak
diye düşünüyoruz.
- Borcu yönetmek adına board’ta borcu yeni özellik istekleriyle birlikte önceliklendiriyoruz.
- Geriye atılmasına ya da gizlenmesine neden olacak farklı bir backlog ya da takip yöntemi kullanmıyoruz.
- Bir özellikten artan bir borç varsa intangible CoS’uyla onu yeniden board’ta konumlandırıp, devam eden planlamalarda önceliklendirilmesine çalışıyoruz.
- Farklı Şeyler Günü gibi fırsatları teknik borcun ödenmesi için de kullanıyoruz.
- Ekip dashboard’unda metrik olarak tutuyor, kontrol altında kalmasına çalışıyoruz.
Teknik borcu ödeme faaliyetlerindeki akış, teknik olarak çevik kalabilmek için elzem. Bu konuda başka pratikleriniz varsa dinlemekten mutluluk duyarız.
