Son zamanlarda yazılımla yakından ya da uzaktan ilişkisi olan herkesin ağzında olan kelime; çeviklikten bahsediyorum. İngilizce de agile, lean gibi kavramlar kullanılıyor ve artık her şey için kullanılmaya başlandı. Gören de zannederki artık her proje çevik yazılım yöntemleri ile yapılıyor, her şey yolunda.

2010 senesinde Londra’da yapılan Domain Driven Design exChange konferansında Eric Evans, yazılımda çevikliğin anlamının kaybolduğunu çünkü artık her şeyin çevik olarak isimlendirildiğini söylemişti. Ne kadar haklı. Aşağıdaki fotografı bir trende çektim. Artık iş verenler bile çevik kelimesini kullanarak yazılımcıları oltaya düşürmeye çalışıyor. Çevik bir fare, çevik bir klavye belki de çevik bulut (agile cloud) bile kullanıyorken bulabiliriz kendimizi yakında. Yaşasın hayatın her safhasında karşılaştığımız çeviklik.

Son günlerin en moda çevik terimlerinden birisi Scrum. Avrupa’da artık birçok proje Scrum ile yapılıyor. Proje yöneticileri Scrum’la oturuyor, Scrum’la kalkıyor. Scrum yazılımda yeni bir dönemin başlangıcı. Diğer çevik süreçler on, on beş yıldır piyasada olmalarına rağmen, Scrum iyi pazarlandığı için çeviklik deyince ilk akla gelen süreç oluyor. Şahsen Scrum yöntemleri beni elektrik gibi çarpmamış olsa bile (çok fazla etkilenmediğim anlamında), Scrum doğru uygulandığında bir projede çevikliğin başlangıcı olabilir. Bugüne kadar birçok Scrum projesinde çalıştım ve doğru düzgün uygulandığını görmedim. Eski proje yöneticileri şimdilerde Scrum Master olmuşlar ve eski yöntemleri ile projeleri sürdürmeye devam ediyorlar. Kafalarda değişen fazla bir şey olmamış. Scrum’ı elbise olarak almışlar, kendi bedenlerine uydurmaya çalışmışlar. Bu bir yere kadar doğru olabilir, ama daha doğrusu Scrum elbisesini alıp, bedeni ona göre uydurmaktır. Scrum harfiyen ne istiyorsa proje ve çalışmalar ona göre şekillendirilmelidir. Ama mevcut kafalar değişmedikçe Scrum ve diğer çevik süreçlerin başarılı olmaları mümkün değil. Çeviklik, eski kafaların eski yöntemlerle yaptıkları işleri kendi yöneticilerine satmak için kullandıkları bir kavram haline geldi. Scrum projelerinde edindiğim tecrübeleri size aktararak çevikliğin nasıl yarı yolda kaldığını ve gerçek çevikliğin ne anlama geldiğini aktarmaya çalışayım.

Katıldığım ilk Scrum projesini hatırlıyorum. Sıkı bir mülakatın ardından projeye alındım. Mülakat esnasında bana bir sürü Java bulmacası soruldu. Maksat ne kadar derin Java bilgisine sahip olduğunu anlamaktı. Ama test güdümlü yazılım ya da JUnit hakkında bir kelime bile edilmedi. Aynı tarzda mülakatlar ile başka programcılar da projeye dahil edildi. Onlarda da durum farkli değildi. Ben programlarımı test güdümlü yazmaya gayret gösterdim. Ama bazı programcılar kırık kodları versiyon kontrol sistemine ekledikleri için testlerim çoğu zaman çalışmıyordu. Bu beni çok rahatsız eden bir durumdu. Test yazmaya önem vermeyen bu tür programcılarla çok ağız dalaşımız oldu. Sürekli entegrasyon serveri kullanılmıyordu, test güdümlü çalışılmıyordu, müşteri gereksinimleri kullanıcı hikayeleri olarak hazırlanmamıştı. Hangi kullanıcı hikayesini ne kadar zaman diliminde tamamlarız diye tahmin etme oturumları yapılmıyordu. Ama bir Scrum ekibi ve projesiydik. Her sabah on beş dakika asker gibi sıraya girip, Scrum toplantımızı yapardık. Bunun neresi çeviklik, neresi Scrum. Günde on beş dakika toplantı yaparak çevik olunmaz! Zaman kaybından başka bir şey değildir, göz boyamacadır.

Çalıştığım diğer bir Scrum projesinde Scrum’ın doğru adapte edilmesi için gayret gösterilmişti. Bir sürekli entegrasyon serveri ve yazılım metriklerini takip etmek için Sonar sunucusu kullanıyorduk. Zaman yetersizliğinden dolayı programcılar test yazmaya önem vermıyorlardı. Ayrıca uygulama bir uygulama sunucusu içinde çalışmak zorunda olduğu için test yazmak kolay değildi. Mevcut testlerin hepsi entegrasyon testi tarzındaydı. En ufak bir değişiklikte bile yeniden bir EAR paketi oluşturup, tüm uygulamayı uygulama sunucusuna çekmek gerekiyordu. Uygulama sunucusunun ayağa kalkması beş dakika sürüyordu. Yazılım geliştirme tamamen uygulama sunucusu ile iç içe geçmiş durumdaydı. Uygulama sunucusunu kullanmadan yazilim yapmak mümkün değildi. Test eksikliğinden ve uygulamanın bir uygulama sunucusuna çekilmesi gerektiğinden, uygulamayı yeniden yapılandırmak çok zordu. Uygulamayı uygulama sunucusundan bağımsız bir hale getirmek için çaba sarfetmemiz gerektiği konusunda çok dil dökmeme rağmen bu gerçekleşmedi. Sonuç olarak çevik değildik, çevik olamadık. Her yeni bir ekleme ile uygulamayı değiştirmek daha da zora girdi. Eğer programcılar ölmedilerse hala yaşıyorlar.

Çevik Nasıl Olunur?

Çevik olmak öncelikle cesaret ister. Gelenekleri bir kenara itip, yeniden başlamayı gerektirir. Felç geçirmiş bir insanın yeniden konuşmayı ya da yürümeyi öğrenmesi gibi çeviklikte her şeyi unutup, yeniden öğrenmeyi gerektirir. Çevik olmayı zor kılan da budur. İnsanlar alışkanlıklarından kolay kolay vaz geçemezler. Radikal değişimleri sevmezler. Yeniliklere kolay kolay adapte olamazlar. Dünya yerinde dursun isterler. Ama yazılım yapmak gibi dinamik bir ortamda değişmeyen tek şey değişikliğin kendisidir. Bununla yaşamak her babayiğidin harcı değildir. Cesur olanların, yeniliklere açık olanların işidir. Buraya kadar olan çevikliğin edebi tanımıydı. Şimdi gelelim teknik tanımlamasına.

Çevik olmayı ben hamur yoğurma ile kıyaslarım. Hamuru, içinde yeterince sıvı olduğu sürece yoğurabilirsiniz. Sıvı azaldıkça hamuru yoğurmak zorlaşır. İçinde sıvı kalmamış hamuru yoğuramassınız. Bu analogiden yola çıkarak çevikliğin yazılımdakı tanımlamasını yapalım. Hamur oluşturduğumuz yazılım sistemi, sıvı birim testleri, yoğurma ise yeniden yapılandırmadır (refactoring). Birim testleri olmadan yazılım sistemini yoğuramassınız (yeniden yapılandıramassınız), ama her yeni müşteri gereksinimi ile sizden yazılım sistemini yoğurmanız beklenir. Oluşturduğunuz uygulamaya yeni müşteri gereksinimlerini eklemek, yani uygulamayı yoğurmak zorundasınız. Bu işi yapmak yani programcı olarak çalışmak istiyorsanız başka alternatifiniz yok. Patronunuz ve müşteriniz sizden uygulamayı yoğurmanızı yanı kendi isteklerine cevap verecek şekilde geliştirilmenizi bekler. Birim, entegrasyon ya da onay/kabul testleri yazmıyorsanız uygulamayı yoğururken sıvı buharlaşacak ve siz belli bir noktadan itibaren uygulamayı yoğuramama rizikosuyla karşı karşıya kalacaksınız. Ama sizden yoğurmaya devam etmeniz beklenecektir. Birçok proje ya da geliştirilen uygulama bu sebepten dolayı başarısız olmaktadır. Devam etmek istiyorsanız uygulamaya sıvı katmanız gerekir. Oluşturacağınız yeni testler hamurunuz için yeni sıvı olacaktır. Bu testler hamuru tekrar yumuşatır ve yoğrulmasını kolaylaştırır. Programcı testleri kullanarak uygulamayı yeniden yapılandırabilir (refactoring). Bu hamuru yeniden yoğurabilme yeteneğini kazanmak demektir. Testler yoksa yeniden yapılandıramaz. Yeniden yapılandıramassa uygulama sıvı eksikliğinden katılaşır ve yoğrulamaz hale gelir. Çevikliğin ve esnekliğin gizli anahtarları testler ve yeniden yapılandırmadır. Bu iki anahtarı kullanmayı bilen programcı çeviktir. Tüm çevik olma hevesinin temelinde bu iki element yatar. Bu iki elementin olmadığı yerde çeviklik olamaz. Uygulamayı istekler doğrultusunda yoğuramadıktan sonra ne proje yönetiminin, ne Scrum’ın ne de çok iyi programcılardan oluşan ekibin bir anlamı kalır. Proje yöneticisi istediği kadar tavana zıplasın; katılaşmış bir uygulayı yeni kod yazarak yumuşatamayız, sadece test yazarak ve devamlı refactoring yaparak bu amaca ulaşabiliriz. Yazılımda işin özü budur: hamuru devamlı yoğrulacak kıvamda tutmak. Hamuru yoğurabilmek demek müşteri gereksinimlerine cevap verebilmek demektir, yani anında görüntü. Anında görüntüyü katılaşmış bir hamurla, yani yazılım sistemi ile yapamayız. Çıkarılması gereken sonuç çok basit aslında: sadece çevik süreç uygulayan projeler yoğrulabilir hamur üretir ve müşterinin yeni gereksinimlerine cevap verebilir.

Çevik olabilmek için çevik yazılım metotlarına hakim olmak gerekir. Her sabah on beş dakika toplantı yaparak elde edilebilecek bir durum değildir bu. Çevikliği anlayanlarla, anlamayanlar arasındaki fark budur. Çevikliği anlamayanlar çeviklik buzulunun (eisberg) su üstündeki kısmını görürler. Su üstünde görünen kısım, su altında kalan kısımdan çok küçüktür. Asıl çeviklikle haşır, neşir olma su altında olur. Her şeye Scrum, lean, agile diye isim verenler su üstünde yaşarlar, suyun altında olup bitenlerden bihaberdirler, çünkü derine dalmaya korkarlar. Onlar değişikliği zaten sevmezler. Eski çalışma tarzlarına çeviklik etiketini yapıştırıp hayatlarına devam ederler. Çeviğiz diye kendilerini ve etraflarındaki insanları kandırırlar. Hamuru yoğururken sıvı tükenmeye yakın panik olurlar. Ne yapacaklarını şaşırırlar, neden böyle oldu diye kara kara düşünürler. Çevik olduklarına kendileri de o kadar inanmıştir ki, suçu çeviklikte bulurlar. Çevikliği sevmemeye başlarlar. Onlar için suçlu olan çevik olma paradigmasıdır. Bilmezler ki çevikliğin hakkını verememişlerdir, çünkü ne olduğunu tam olarak kavrayamamışlardır. Değişikliğe açık olmadıkları için kavramaları da kolay değildir.

Gelelim çevik olmayı anlayanlara. Onlar bahsettiğim iki anahtarın sahibidir. Test güdümlü kod yazmayı bilirler ve her fırsatta bunu uygularlar. Bunun yanısıra refactoring konusunda uzmandırlar. Her yeni müşteri gereksimi ile daha önce verdikleri tasarım kararlarını revide ederler. Uygulamanın katılaşmaya başladığında mevcut tasarımın yetersiz olduğunu anlarlar ve bu tasarımı bozup, yeni bir tasarım yapmaktan çekinmezler. Cesurdurlar. Bilirler ki ellerindeki testler yeniden yapılandırma işlemini mümkün kılar. Buradan çıkardığımız ilk sonuç şudur: çevik olabilmek için test güdümlü yazılım yapmak önem taşımaktadır. Test güdümlü yazılım yapılamıyorsa, o zaman uygulamanın büyük bir kısmını kapsayacak şekilde test kodu yazılmalıdır. Oluşturulan testlerin otomatik olarak çalışması gerekmektedir. Yeniden yapılandırma (refactoring) işlemlerinin birçok yan etkisi olabilir. Onları hızlı bir şekilde lokalize edebilmek için otomatik çalışan testlere ihtiyaç duyulmaktadır. Testlerin olmadıği ya da yetersiz olduğu projelerde programcılar yeniden yapılandırma işlemine cesaret edemezler. Cesaret edemedikleri için yazılım sistemi her gün biraz daha katılaşır ve bir zaman sonra yoğrulamaz hale gelir. Eğlencenin bittiği an budur. Bu noktadan itibaren programcılar için cehennem azabı başlar. Fazla mesailer yapılır, beraber ağıtlar yakılır, kollektif çığlıklar atılır, sende mi Brütüs, sana o kadar emek verdik, yaptıkların bize caiz mi diye yazılım sistemine yüklenilir. Ama Brütüs suçsuzdur. O beni yoğurmayın dememiştir ki. Yoğurma cesaretini programcılar gösterememiştir.

Gerçek çevikliğin temelinde gerçek yazılım mühendisliği metotları yatar. Birincisi test güdümlü yazılım; ikincisi yeniden yapılandırma (refactoring); üçüncüsü eşli programlama; dördüncüsü sürekli entegrasyon; beşincisi basit tasarım; altıncısı iteratif sürüm oluşturma; yedincisi ….

Bu metotların hepsi insanların bilgisayarları icadı ve program yazmaları ile birlikte yer yer uygulanmış metotlardır. Hiç biri yeni icat edilmemiştir Ama bundan on, on beş sene önce Extreme Programming (XP) olarak topluca karşımıza çıktılar. XP bünyesinde proje yönetimi için de metotlar barındırmaktadır. XP bu metotları Scrum’dan almıştır. Ama Scrum bünyesinde XP’nin sahip olduğu çevik metotlar yoktur. Bu yüzden içinde çalıştığım hemen hemen her Scrum projesi sadece kağıt üzerinde çevik olabilmiştir. Saha’ya inildiğinde çevikliğin bir tane atomuna bile rastlamak mümkün olmamıştır.

Sadece proje yönetmek ve programcıların ne yaptığını kontrol etmek için icat edilmiş sözde çevik süreçleri kullananlara sesleniyorum buradan. Gerçek çevik yazılım metotlarını kullanmadığınız sürece çevik olmanız bir hayal olarak kalacaktır. Bu yüzden sürdürdüğünüz birçok proje 130 km/h ile duvara tosluyor. Cesaret edip işin temeline inmeniz gerekiyor. Daha fazla mühendis olup, çevik metotlara hakim olmanız gerekiyor. Her gün on beş dakikalık toplantılarınızdan vaz geçin demiyorum. Bu yerinde bir aktivite. Ama zaman ayırıp bir mühendis kafasıyla sistematik olarak çevik yazılım metotları ile ilgilenin, onları öğrenin, onlara hakim olun, onlari uygulayın. Her Scrum projesini testlerin yine en son safhada yazıldığı ya da zaman yetersizliğinden dolayı yazılamadığı bir ortama çevirmeyin. Profilime ben de kulağa hoş gelen Scrum Master ünvanını koyarım. Ama bu benim ne kadar çevik metotlara hakim olduğumu yansıtmaz. Ünvanlardan çok, hakim olduğunuz gerçek çevik yazılım metotları ile övünün. Hamuru yoğuran ünvan değildir. Hamuru yoguran tecrübeli beyin ve sistemli ve sonuç getiren metotlar kullanmaya alışmış ellerdir. Gerçek yazılım mühendisleri ile düzmece mühendislerin arasındaki fark işte budur. Parayla satın alınan sertifikalar programcıyı programcı yapmaz. Bu sevdadan vazgeçin. Bu sözde çevik yöntemlerle ne dünyayı kurtarırsınız ne de yazılım dünyasına artı bir değer katarsınız.

Çekirdekte gerçek meselenin uygumalayı devamlı yoğurmak olduğunu göz ardı eden bu sözde çevik yöntemler, çevik teriminin her halt için kullanılması ve enflasyona uğramış olması, çevikliğin içinden çıkılamaz bir hale gelmesine sebep olmuştur. Kafalar iyice karışmıştır. Hangi yöntem çeviktir, nasıl çevik olunur, bu sorulara artık kimse net olarak cevap verememektir. Çeviklik artık ifade gücünü yitirmiştir. Bu gerçekten üzücü bir durum. Bir nevi komplo. Sanki eski şelale (waterfall) yöntemleriyle büyümüş bir zümre çevikliği ortadan kaldırmak için iş birliği içindedir. Böyle birsey yok doğal olarak. Fantazim yine kanatlandı.

Beni bir Scrum düşmanı olarak görmeyin. Doğru uygulandığında iyi bir başlangıç olabilir. Ne yazik ki Scrum’ın doğasından kaynaklanan bir sorun bu; Scrum’ı doğru uygulamak hemen hemen imkansız; her türlü uygulama tarzına açık; somut değil; isteyen istediği tarafa çekiyor, bu yüzden ortaya çok komik görüntüler çıkıyor. Scrum doğru uygulandığı taktirde ve proje bünyesinde XP vari yazılım metotları kullanıldığında bir proje tam anlamıyla çevik olabilir. Onun haricinde bu imkansız.

Çeviklikte her şeyin başı çevik mühendislik metotlarıdır. Bunun başında test güdümlü yazılım ve refactoring gelir. İçinde bu elementleri barındırmayan bir süreç çevik yazılım süreci olamaz. Para basmak ve dandik sertifikalar dağıtmak için oluşturulmuş sözde çevik süreçlerden uzak durmakta fayda var. Cesaret gösterip işin özüne inelim. Yeniliklere açık olalım. Yazılım mühendisi isek o zaman bir mühendis gibi çalışalım, sistemli ve metotlu. Buna izin verilmediği yerde durmayalım, baş kaldıralım. Yazılımda çeviklik sadece çevikliği kavramış mühendislerle mümkündür. Eski kafa bir proje yöneticisini Scrum Master yaparak proje çevikleştirilemez. Projede çevikliği yazılım mühendisleri ateşler, meşaleyi onlar ileri götürür, Scrum Master olmuş birisi değil. Onlar en fazla seyirci olabilirler. Sahada maçı oynayan çevik yazılım mühendisleridir. Çeviklik konusunda bunun harici her şey hikayedir.

EOF (End Of Fun)
Özcan Acar