Techrospective: Teknik Borç Yönetimi İçin Yeni Bir Sprint Etkinliği

Click here for the English version

Teknik borç nedir, neden bırakılır?

Teknik Borç (Technical Debt), temel olarak yazılım geliştirirken, ideal olduğunu düşündüğümüz ancak ciddi efor/zaman alacak yöntemler yerine basit ama çok daha hızlı sonuca ulaşabileceklerimizi tercih etmek olarak özetlenebilir.

Günümüzde müşteri ihtiyaçlarının, taleplerinin anlaşılmasından, geliştirmelerinin tamamlanıp üretim ortamında kullanıma sunulmasına kadar geçen sürenin olabildiğince kısa tutulması, ürünlerin yaşam döngüsünde kritik öneme sahip. Bu anlamda yeni bir özellik geliştirirken en ideal tasarımla, yöntemle ilerlemek üretim ortamına çıkışı örneğin 2 hafta öteleyecekse, bunun yerine 3–4 günde tamamlanabilecek bir yol tercih edilebilir.

Burada konu neredeyse tamamen bir taraftan alıp diğer tarafa verme (trade-off) meselesiyle doğrudan bağlantılı. “Hem en ideal tasarımı yapalım ve uygulayalım, hem de en kısa sürede geliştirmeler tamamlansın” diyemiyoruz. Mutlaka bir taraftan taviz verme durumundayız. Bu yazılım geliştirme işimizin doğasında olan ve neredeyse her aşamasında karışımıza çıkan ve iyi yönetmemiz, çözmemiz gereken bir olgu.

Tam olarak nelere “Teknik Borç” denilebileceği, hangi konuların bu kapsama girdiği üzerine gördüğüm kadarıyla ortak bir fikir oluşmuş değil ve hakkında uzun tartışmalar yapılmış. Bir kesim “Kullanıcı ara yüzündeki bir eksiklik teknik borç olmaz, bu bir Arayüz Borcu’dur” diyerek teknik borçları kategorize etme eğiliminde, bir başka kesim “Bilmeyerek, yetkinlik veya bilgi eksikliğinden bırakılmış borçlara teknik borç denemez” şeklinde çıkarımlar yapmakta.

Bu uzun tartışmalara dahil olma niyetinde olmamakla birlikte, benim kanaatim, yazılım geliştirme yaşam döngüsünde, bilerek veya bilmeyerek bırakılmış tüm borçların teknik borç kabul edilmesi gerektiği. Bütüncül bir bakış açısıyla teknik borçlara bakmanın, hangi teknik borcun, hangi şartlar altında, ne zaman çözülebileceği kararını verme açısından çok daha doğru olacağı fikrindeyim.

Teknik Borç Yönetiminde Yaşadığımız Zorluklar

Tespit edilmiş, edilebilmiş teknik borçların tümünü görebilmek ve bunları yönetebilmek ise çok da kolay değil. Günümüzde yazılım geliştirme takımlarının muhtemelen çok da iç açıcı olmayan bir yüzdesi teknik borç kavramını özümsemiş ve bu konuyu yönetmeye çalışıyor. Bunu yönetmeye çalışan takımların da tahminen büyük bir kısmı da belli bir düzen, standart, konuya özel bir etkinlik olmadığından sıkıntı yaşıyor.

Teknik borçları tespit etmek, detaylandırmak, kategorilere ayırmak, sürekli takip etmek bir kenara dursun, bu borçların hangisinin, ne aşamada çözüleceğinin kararını verebilmek asıl sorun.

Yeni Sprint Etkinliği: Techrospective

Tüm bu sorunları adresleyebilmek ve daha iyi teknik borç yönetimi yapabilmek adına SabancıDx’te biz Techrospective adını verdiğimiz bir etkinlik düzenlemeye başladık.

Techrospective, (kısaca Techro diyoruz), her sprintte bir kez yapılan, iki haftalık sprintler özelinde yaklaşık bir buçuk saat süren bir etkinlik.

“Techrospective” adı nereden çıktı diye soracak olursanız “Teknik bir retrospective yapmalıyız, bunun da adına Techrospective diyelim” şeklinde kendiliğinden gelişti. “Techrospective” adını araştırdığımızda bir sprint etkinliği adı olarak kullanan göremedik. Daha önce bu isim kullanılmış ancak geçmiş dönemin teknolojik gelişmelerinin ele alındığı bir etkinlik olarak düzenlenmiş. Biz de kolay ve akılda kalıcı, amacını anlatan bu ismi kullanmaya karar verdik.

Techro’larda Neler Yapıyoruz?

Techro’nun çıkış amacı teknik borçlarımızı yönetebilmekti ancak bu etkinlikle daha fazla ihtiyacımızı adresleyebileceğimizi gördük ve Techro’nun olası gündem maddelerini 6 başlıkta topladık.

1. Teknik Borçlar: Techro’nun en önemli gündem maddesi teknik borçlar. Bu madde kapsamında eğer yoksa mutlaka bir “Teknik Borç Tahtası” oluşturuyoruz. Bu tahtaya tespit ettiğimiz borçlarımızı olabildiğince detaylı açıklamasıyla giriyor ve önceliklerini belirliyoruz. En öncelikli borçları, zaman planımızı sarsmayacak şekilde, ortak karar ile bir sonraki Sprint Backlog’una alabilmek adına, Product Owner’ın da onayını alarak, Product Backlog’una taşıyoruz.

Prensip olarak teknik borçların, teknik borç tahtasında sürekli hareket halinde olması gerekli. Yeni teknik borçlar geldikçe tahtaya eklenmeli, eski borçlar zamanla tamamlanmalı. Az hareket gören, yeni borçlar eklenmeyen bir tahta bir şeylerin yanlış gittiğinin göstergesi.

2. Yazılım Kalitesi: “Yazılım Kalitesi” çok geniş bir konu ve özel uzmanlık istiyor. Bu uzmanlığın ise geliştirme takımının tamamına, hatta yazılım geliştirme yaşam döngüsünde rol alan her role yayılması kritik öneme sahip. Bu bilinçle Techro’ları fırsat bilip iki temel konu hakkında değerlendirmelerde bulunuyor, etkinliğin bir kısmını bunlara ayırıyoruz.

• Unit/Integration Test yeterliliğini ölçüyoruz, eğer ekipte bu konuda bilgi eksikliği varsa tamamlamaya, engeller varsa ortadan kaldırmaya çalışıyoruz. Gerek görürsek tüm bir etkinliği bu konuya ayırıp, “Mob Programming” yaklaşımı ile test yazıyor, test yazma altyapısını geliştiriyoruz.
• Düzenli yapılan “Statik Kod Analizi” çıktılarını değerlendiriyoruz. Bu çıktıların hangilerinin ilgili proje dinamiklerine göre “hatalı pozitif” olabileceğine karar veriyor, bunları ayıklayıp kalanları Teknik Borç Tahtası’na giriyoruz. Bu aşamadan sonra önem derecesi yüksek olanları da dikkate alarak aynı teknik borçlar gibi, ortak karar ile bir sonraki Sprint Backlog’una alabilmek adına, Product Owner’ın da onayını alarak, Product Backlog’una taşıyoruz.

Bu madde özelinde, departman/kurum özelinde yazılım kalitesi konusunda uzman profesyonellerin, başka ekiplerde de olsalar, etkinlikte yer almasının bize büyük değer kattığını gördük. Bu konudaki bilginin ve alışkanlıkların yaygınlaştırılması çok mühim ve uzman profesyonellerle çok daha hızlı ve verimli ilerleyebiliyoruz.

3. Süreç İyileştirme: Biz yazılımcılar bazen geliştirme yaparken yaşadığımız aksaklıkları sineye çekebiliyor, alışkanlık oluşturabiliyor ve verimliliğimizi ciddi etkilese bile hayatımıza böyle devam edebiliyoruz. Bu gündem maddesi ile oluşan bu körlüğü kırmaya ve yazılım geliştirme süreçlerimizi iyileştirmeye, engelleri ortadan kaldırmaya çalışıyoruz.

Bu madde kapsamında örnek olarak aşağıdaki konuları konuşabiliyoruz:

• Kullandığımız bir geliştirme aracının performansından veya bir özelliğinden memnun değilsek bunu eklentilerle geliştirebilir miyiz veya yeni bir geliştirme aracına geçebilir miyiz diye tartışıyoruz.
• Geliştirme için kullandığımız bilgisayarların problemlerini tartışıyor, genel bir sıkıntı varsa ilgili birimlere çözmeleri için gidebiliyoruz.
• Ekipte bir kişi bulduğu bir araç ile daha verimli çalıştığını iletiyor ve diğer arkadaşlarına bunu aktarıyor, birlikte değerlendiriyoruz.

Bunlar sadece birkaç örnek, temel amaç gün içinde sürekli yaşadığımız ve bizi yavaşlatan sorunları çözebilmeye çalışmak.

4. Kişisel Gelişim: Hemen her sektörde kişinin kendini geliştirmesi önemlidir ancak yazılım geliştirme işinde bu konu bir zorunluluk. Bugün doğru bildiğimizin bir süre sonra hatalı olduğunu görebiliyoruz, bugün bildiğimiz bir yöntemin zamanla anlamını yitirdiğini, çok daha verimli yeni yöntemlerle ilerlememiz gerektiğini fark ediyoruz. Bu açıdan bir yazılım geliştiricinin mesleki açıdan hayatta kalabilmesi kendini geliştirebilmesi ile doğrudan bağlantılı.

Bu gündem maddesinde her katılımcı “Geçen sprintte yeni ne öğrendim, kendimi hangi açılardan geliştirdim” başlıklarında paylaşımlarda bulunuyor. Temel prensip olarak her sprint mutlaka yeni bir teknoloji, yöntem vb. bir konuda geliştiricinin kendini eğitmiş olmasını bekliyoruz. Yeni bir konu öğrenilmeden, kendini geliştirmeye zaman ayrılmadan bir sprint geçirilmişse bunu “kişisel teknik borç” olarak kabul ediyoruz.

Yazılım geliştiricilerin kendilerini geliştirmesinin hem kendisine ve geleceğine yatırım olduğunu, hem de çalıştığı kuruma, ürüne, ekibe doğrudan katkı olarak döneceğini unutmamak gerek. Bu anlamda eğer kişilerin kendilerini geliştirmeyi engel teşkil eden durumlar varsa bu konuları da konuşup çözmeye çalışıyoruz.

5. Dokümantasyon: Neredeyse tüm yazılım geliştiricilerin ortak dertlerinden biridir çalışmalarının dokümanlarını yazmak. Biz de yaklaşım olarak, statik, çok detaylı, bir kez yazıp sonra uzun süre bakılmayan dokümanları yazmaya sıcak bakmıyoruz. Ancak belli ölçüde ve mutlaka yaşayan, sürekli güncellenen bilgilerin de yazılı olması gerektiğinde hem fikiriz. Bu anlamda her proje özelinde “Wiki” sayfaları oluşturuyor ve kurguluyoruz. Bu gündem maddesinde Wiki’nin önemi tekrar vurgulanıyor ve güncelliği kontrol ediliyor, farkındalık artırılıyor. Yazılım geliştiricilerin Wiki’yi aktif olarak kullanması, başucu dokümanı gibi hissetmesi ve sıkıştıklarında veya bir konuyu hatırlamada zorlandıklarında ilk başvuru noktası olması hedefiyle bilgilerin girişin yapmasını amaçlıyoruz. Bu anlamda Wiki’de olabilecek örnek başlıkları aşağıdaki gibi özetleyebiliriz:

• Projede Geliştirme Yapmaya Başlarken Gerekenler: Bu, ekibe yeni dahil olanların hızlıca adaptasyonu için kritik bir başlık.
• Temel Diyagramlar: Ürün/süreç akış/sekans/blok diyagramları, topoloji, network vb.
• Kodlama Standartları: İsimlendirme standartları, kodlamada tercih edilen yöntemler vb. detaylı olmayan, ekip genelinde standartları oturtmayı hedefleyen bir bölüm.
• Ürün/Proje Özelindeki Prosedürler: Örneğin “Yeni mikro servis ekleme prosedürü”, “Modül yetkilendirme sistemi”, “Yeni zamanlanmış görev ekleme prosedürü” vb.
• Temel Mimari Kararlar (Lightweight Architecture Decision Records): Proje özelinde alınan mimari kararların kısa ve basit bir dille tarihçesiyle tutulduğu bölüm. Bu kararların Wiki yerine kaynak kod ile birlikte yönetilmesi tarihçe ve gelişim/değişim takibi adına daha doğru olabilir. Bunu yapanlar için Wiki’de sadece ilgili kaynağa link verilmesi yeterli.

Bunların hepsi ve hatta daha fazlası da olabileceği gibi, sadece belli başlıkların Wiki’de bulunması tercih edilebilir. Bazı başlıklar sadece ilgili dokümanlara, kaynaklara link verilerek de doldurulabilir. Burada temel amaç, ekibi yormak ve doküman doldurma gibi sıkıcı bir işle boğmak değil, ekibin ortak bir bilgi dağarcığı kütüphanesi oluşturabilmesi, her bireyin kendi özelinde tuttuğu notların ortaklaştırılması ve -sonda yazıyorum ama en önemlilerinden biri- yeni gelen ekip üyelerinin adaptasyonunun çok daha hızlı yapılabilmesinin önünü açması.

6. Özel Bir Konuda Detaylı Tartışma: Şimdiye kadar anlatılan gündem maddelerinden farklı olarak bu konu başlığında ekibin tartışmak istediği ve net bir çözümünü bulamadığı veya ortak noktada buluşamadığı bir sorunu, yöntemi Techro’da konuşuyoruz. Herkesin kabul edebileceği ortak bir çözüme ulaşmayı hedefleyerek, konuyu her açıdan irdeleyerek en uygun teknik çözümü bulmaya çalışıyoruz.

“Bu kadar çok gündem maddesiyle zaman planına nasıl sadık kalıyorsunuz?” sorusu hemen akla gelebilir. Her gündem maddesini her etkinlikte konuşmayabiliyoruz. Teknik Borç Tahtası’na her etkinlikte mutlaka bakıyoruz, ilgili değerlendirmeleri yapıyoruz. Sonrasında o etkinliğe özel konuşulmak istenen özel bir konu varsa tartışıyoruz, yoksa diğer maddelerle devam ediyoruz. Zaman, gündem maddesi planlamasını o etkinlik içerisinde birlikte yapıyoruz. Eğer Techro zamanı aşılacak gibiyse ve konuşulması gereken kritik konular varsa, yeni ve konuya özel ayrı oturumlar planlıyoruz.

Techro’ların bir diğer önemli noktası da her katılımcının mutlaka söz ve aktif rol almasını sağlamak. Etkinliklerde her katılımcının sesini duymak, fikrini öğrenmek ve iş birliğini, etkileşimi artırmak, hem çok sesliği teşvik etmek, hem farklı fikirleri duymak hem de ekip içi iletişimin geliştirilmesi için de çok değerli.

Techro’lara tüm geliştirme ekibi ve konusunda uzman diğer ekiplerden ilgili kişiler katılıyor. Eğer organizasyonunuz uygunsa, birden fazla veya en ideali, tüm ekiplerin Techro’larına katılan bir rolün bulunmasını önemli görüyorum. Bu role sahip kişi her ekibin iç dinamiklerine, yaşadığı sorunlara, geliştirdikleri çözümlere vakıf oluyor ve bilginin ekipler arası yaygınlaşmasında kritik rol oynuyor. Bu kişinin katıldığı etkinliklerde dışarıdan bir göz olarak yapacağı yorumlar ve geri bildirimler de ekip adına çok değerli.

SabancıDx’te uzunca bir süredir Techro etkinliklerini yapmayı sürdürüyoruz. Tüm etkinliklere Mimar rolündeki en az bir arkadaşımız (çoğu zaman iki) ve Yazılım Kalite Takım Lideri rolündeki arkadaşımız katılıyor. Kendi organizasyonumuzda gelişim kaydedebileceğimiz alanların tespiti ve çözüm üretme konusunda bulduğumuz bu çözümün bize çok katkıları olduğunu söyleyebilirim.

Benzer sorunlar yaşayanlara faydası olması umuduyla paylaştığım bu yazımı okuduğunuz için teşekkür ederim.