Coca Cola’nın kaç türü var, bilirsiniz… Cola light, Cola zero, Cola classic…. Çevik süreçler için de aynı şey geçerli. Ben çevik süreçleri agile zero, agile light ve hardcore agile ya da classic agile olarak üç bölüme ayırıyorum.

Agile Zero

Çalışma ortamında çevikliğe dair hiçbir ibare yoktur.

Belirtileri

• Projede hiçbir birim, entegrasyon ya da onay/kabul testi yoktur.
• Proje kesinlikle zamanında yetişmez.
• Yeni müşteri gereksinimlerinin uygulamaya eklenmeleri çok zaman alır, çünkü uygulama mimarisi esnek ve değiştirilebilir yapıda değildir. Öyle olsa bile testlerin olmaması, kodun ve mimarinin yeniden yapılandırılması engeller.
• Uygulamada çok bug vardır ve çoğu keşfedilmemiştir.
• Uygulama elden test edildiği için hem çok zaman kaybedilir hem de test geniş kapsamlı yapılamaz.
• Entegrasyon çok zaman alır ya da yer yer mümkün değildir, çünkü uygulama sürekli entegre edilmemiştir.
• Sürüm belli bir yazılımcının bilgisayarında alınır. O yazılımcı tatile gittiğinde başka bir kurban yazılımcı seçilir. Buna kısaca releaser hopping ismini veriyorum.
• Müşteriye belirli aralıklarla çalışan bir prototip sunulamaz, çünkü uygulama entegre edilemediğinden çalışır halde değildir.
• Yazılımcılar stres altındadır ve fazla mesai yapmaya zorlanırlar.
• Her şey önceden planlanmaya çalışılır. Buna müşteri isteklerinin tam teşekküllü yazılım öncesi tespiti de dahildir.
• Yazılım öncesinde uygulama mimarisi bir mimar tarafından tespit edilmiştir. Yazılımcılar bu mimaride öngörülen şartlara uymak zorundadırlar. Yeni müşteri istekleri ile mimarinin adapte edilmesi söz konusu iken, kod birim testleri eksikliğinden dolayı yeniden yapılandırılamaz. Böylece uygulama mimarisi yeni müşteri isteklerini taşıyacak şekilde adapte edilemez. Zaten mimar böyle bir şeye içgüdüsel olarak karşıdır. Kısaca yazılımcının uygulama mimarisini değiştirme konusunda inisiyatifi yoktur.
• Müşteri için piyasadaki rekabet şartlarının değişmiş olabileceği bilindiği halde, sürüm zamanları uzun tutulur. Bu uzun bir zaman diliminden sonra müşteriye sunulan sürümün müşterinin işine yaramayacağı anlamına gelebilir. Kısa zamanlı sürümlerle müşterinin fikri alınmış olsa idi, bu sorunun önüne geçilebilirdi.
• Son kullanıcılar tonlarca bug bulup, yazılımcıların uzun bir süre bu bugları temizlemek için uğraş vermelerine sebep olurlar. Böylece yeni müşteri gereksinimlerinin implementasyonu geriye atılır.

Agile Light

Scrum gibi bir çevik süreç kullanılıyordur. 

Belirtileri

• Ekip sadece Scrum kullanarak gerçekten çevik olduğunu düşünür.
• Projede hiçbir birim ve entegrasyon testi olmayabilir.
• Çeviklik sadece proje yönetiminden (sprint planlaması ve uygulaması) ibarettir.
• Sprint sonunda müşteriye çalışır bir sürüm/prototip sunulabilir.
• Yeni müşteri gereksinimlerinin uygulamaya entegrasyonu çok zaman alır, çünkü test güdümlü yazılım ya da eşli programlama metotları uygulanmaz. Uygulamaya yeni gereksinimlerin eklenebilmesi için uygulamanın yeniden yapılandırmaya ihtiyacı olabilir. Test güdümlü çalışma neticesi olarak geniş kapsamlı birim test seti olmadığı taktirde, uygulamayı yeniden yapılandırmak harikiridir.
• Ekip yazılımcılar ve testçiler olarak iki guruba ayrılır.
• Uygulamayı test etmek için geniş çaplı onay/kabul test setleri hazırlanır. Onay/Kabul testlerini hazırlayan testçi ekibidir. Onay/kabul testleri yazılımcılar tarafından geliştirilen birim testlerin yerine hem geçemezler hem de yazılımcılar tarafından kodu yeniden yapılandırmak (refactoring) için kullanılamazlar, çünkü koşturulmaları saatler alır.
• Uygulama bir sürekli entegrasyon sunucusu kullanılarak entegre ediliyor olabilir.
• Agile Zero da uygulama mimarisi için söylediklerim agile light için de geçerlidir.

Agile Classic

Ekip katıksız olarak çevik süreç metotlarını uygular. 

Belirtileri

• Ekibin parçası olan her yazılımcı test güdümlü yazılım yaparak geniş kapsamlı birim testi seti oluşturur. Test güdümlü çalışma zorunluluğu yoktur. Önemli olan testlerin gerçekleri yansıtacak şekilde kodu kapsamalarıdır (code coverage).
• Proje yönetimi Scrum’da olduğu gibi iterasyon bazlı yapılır. İterasyon uzunluğu 2-4 hafta arasıdır.
• Jenkins ya da Bamboo gibi bir sürekli entegrasyon sunucu kullanılarak kod devamlı entegre edilir.
• Kodu yaptığı değişiklikle kıran yazılımcının masasına bunu gösteren bir oyuncak ayı bırakılır. Bu oyuncak ayı kodu kıran bir yazılımcıdan diğerine el değiştirir. Her yazılımcı kodu kullandığı versiyon kontrol sistemine eklemeden önce (commit) tüm birim testlerini koşturarak, kodun içinde bulunduğu durumu kontrol eder. Çalışmayan ya da kırık kod eklenmez.
• Yeni müşteri istekleri zorluk çekilmeden uygulamaya dahil edilir, çünkü testler sayesinde kodun yeniden yapılandırılması (refactoring) kolaydır.
• İterasyon sonunda müşteriye çalışan bir prototip sunulur. Müşteri isterse bu prototipi aktif olarak günlük işinde kullanmaya başlar.
• Yazılımcının sorularını cevaplamak için ya müşteri ekibin yakınlarındadır ya da müşteriyi temsil eden bir vekil vardır. Yazılımcı sorularını doğrudan müşteriye ya da vekiline yöneltir. Müşteri ile yazılımcı arasına analist, proje yöneticisi, firma sahibi ya da başka bir şahıs giremez.
• Ekipte Scrum Master ya da Product Owner gibi roller yoktur. Ekibin dadıya ihtiyacı yoktur. Ekip içindeki yazılımcılar her şeyden sorumludur.
• Ekip uygulamayı müşteri isteklerinin öncelik sırasına göre geliştirir. Uygulamaya hangi özelliğin ekleneceğini her zaman müşteri belirler.
• Yazılımcılar mesailerini sekiz saat ile sınırlı tutarlar. Daha fazlasına gerek yoktur, çünkü yazılım geliştirme süreci planlandığı şekilde ilerler.
• Her iterasyon sonunda yazılımcılar bir araya gelerek, geçmiş iterasyonu analiz ederler (retrospective). Her yazılımcı düşündüğü artı ve eksiler hakkında düşünce beyan eder. Maksat başkası hakkında olumsuz fikir beyan etmek ya da sorumlu bulmak değildir. Bu da bir geri bildirim türü olduğu için ekip içinde bulunduğu durumu daha iyi kavrar ve tespit edilen olumsuzlukların bir sonraki iterasyonda meydana gelmelerini engeller.
• Uygulama mimarisi yazılım sistemi ile geliştirilir. Her yazılımcı inisiyatif kullanarak, uygulama mimarisini güncel implemente edilen müşteri gereksimini taşıyacak şekilde adapte edebilir.

Ne zaman çevik oluruz? Kodu hamur gibi yoğurabildiğimizde!

EOF (End Of Fun)
Özcan Acar