Çevik Dönüşümde Teknik Borç ve Mühendislik Yalanları: Yazılım Ekipleri Nerede Hata Yapıyor?

Gerçek çeviklik (Agile); sadece Scrum toplantıları yapmak veya duvarları renkli kağıtlarla donatmak değil, sağlam yazılım mühendisliği pratiklerini (XP, TDD, Otomasyon) kültüre entegre etmektir. Birçok kurum, "süreç" kısmını uygularken "teknik mükemmellik" kısmını atlar. Oysa kirli bir kod tabanı (Dirty Codebase) ve manuel test süreçleriyle "hızlı" olmak imkansızdır.

Bu rehberde, sektörde "Biz Agile olduk" diyen ama teknik borç batağına saplanan ekiplerin yaptığı en kritik hataları derledim. "Nasıl Agile (Çevik) Olunmaz?" yazı serisinin bir özeti gibi düşünebilirsiniz.

1. Kötü Kodları "Noel Baba" Düzeltmeyecek (Teknik Borç Gerçeği)

Elinizde kirli bir kod tabanı (Legacy Code) varsa, kapasitenizin tamamını yeni müşteri gereksinimlerine ayıramazsınız. Çevik dönüşümlerde yapılan en büyük hata; hızlanmak için kaliteyi feda etmektir.

Her iterasyonda kod tabanınızı biraz daha temiz hale getirmek (Refactoring) için çaba harcamalısınız. Az az da olsa kod kalitesini ve mimariyi düzeltmelisiniz. Kötü kalitenin üzerine kat çıkmaya devam ederseniz, daha hızlı gidemeyeceksiniz. Scrum sertifikaları sizi bu bataktan kurtarmayacak.

Acı Gerçek: Kalite problemlerinizi şeffaf bir şekilde ortaya koyup, düzeltmek için efor harcayın. Siz uyurken bir gece Noel Baba gelip kötü kodlarınızı düzeltmeyecek. Bu konuda bir mucize beklemeyin.

2. Otomasyon Olmadan "Hız" Sadece Bir Hayaldir

Makinaya yaptırabileceğiniz işleri insanlara yaptırdığınız sürece değişime hızlı adapte olamazsınız. İnsanlar makinalara göre yavaştır ve hata yapma olasılığı yüksektir.

Yazılım üretim sürecinde, özellikle Dağıtım (Deployment) ve Test gibi aktiviteleri otomatize etmek zorundasınız.

• Hızlı gitmek istiyorsanız, üretim sürecinizde otomasyonu artırın.

• Test ekipleriniz hala ekranın sağına soluna tıklayarak manuel test yapıyorsa, orada çeviklikten bahsedilemez.

• Gerçek çeviklik için muhtemelen bir ordu büyüklüğünde olan ve işleri tekrar tekrar test datası hazırlayıp manuel koşan test ekiplerinizi, "Test Otomasyonu" konusunda eğiterek işe başlayabilirsiniz.

  
  

3. "Teknik Borç" Aslında Nedir?

Teknik borç (Technical Debt), çoğunlukla kodlama aşamasında "yeterince iyi iş çıkartmamış olmanızın" sonucu değildir. (Tabii ki baştan savma işlerden kaynaklanan borçlar vardır, ama asıl mesele bu değildir).

Çoğunlukla teknik borç; geliştirdiğiniz uygulama hakkında daha fazla bilgi edindikçe, işi öğrendikçe "Refactoring" (Yeniden düzenleme) yapmamanızın maliyetidir.

Robert C. Martin'in dediği gibi: "Kod zamanla çürür."İlave gereksinimler ortaya çıktıkça ve uygulama genişledikçe bu çürümeyi engellemek gerekir. Çare? Sürekli Refactoring.

4. Extreme Programming (XP) Olmadan Scrum "Boş"tur

Yazılım geliştirmede gerçek çeviklik için sağlam mühendislik pratiklerine ihtiyacınız vardır. Sektördeki pek çok "Agile Koç", hayatında tek satır kod yazmamış olmasına rağmen yazılım ekiplerine akıl verir.

Eğer çeviklik mühendislik pratiklerini gözden kaçırırsanız, XP (Extreme Programming) yöntemlerini reddederseniz, vaat edilen o "üretkenliği" asla elde edemezsiniz.

Unutmayın: Tüm çevik yöntemler arasında XP en iyi tanımlanmış ve en eksiksiz olanıdır. Agile'ın neyle ilgili olduğunu anlamak istiyorsanız XP'yi (Pair Programming, TDD, CI/CD) anlamalısınız.

5. Pair Programming: İki Kişiye Bir İş Yaptırmak Mı?

"Ne gerek var yahu, 2 kişiye 1 iş yaptıracağımıza, 2 kişiye 2 iş yaptırırız, üretim 2 katına çıkar" diyen yöneticiler, Çevik Manifesto'nun ruhunu kaçırıyor demektir.

Eşli Programlama (Pair Programming); takım üyeleri arasında bilgi paylaşmanın ve "Bilgi Silolarının" (Knowledge Silos) oluşmasını önlemenin en iyi yoludur.

• "O işi yapan Ahmet askere gitti, kodun o kısmını kimse bilmiyor" demek istemiyorsanız, Pair Programming yapmalısınız.

• Bu pratik, hataları azaltır ve tasarım kalitesini artırır.

  
  

Sonuç: Mühendislik Kaslarınızı Güçlendirin

Renkli post-it'ler ve keyifli retrospektif oyunları, kötü yazılmış bir spagetti kodu düzeltmez. Şirketinizin gerçek anlamda çevik olmasını istiyorsanız, yatırımınızı "süreçlere" değil, "mühendislik kalitesine" ve "teknik yetkinliğe" yapmalısınız.

Ekiplerinizin teknik borcu yönetmesi, test otomasyonunu kurması ve modern mimarilere (Mikroservis, TDD) geçiş yapması için Programlama Eğitimlerimizi inceleyebilir, ileri seviye teknik atölyelerimize katılabilirsiniz.

---

Bu yazı, Onur Özcan'ın  "Nasıl Agile (Çevik) Olunmaz?" serisinin küçük bir bölümüdür. Toplamda 4 ayrı blog yazısı olacak şekilde paylaşılmaya devam edecek. Serinin tamamını beklemek istemiyor ve hemen okumak istiyorsanız, hazırladığımız e-kitabı buradan ücretsiz indirebilirsiniz.