Yazılımda Çeviklik İflas mı Etti?

Çevikliğin Böylesi başlıklı yazımı okudunuz mu? O yazımda çevik kelimesinin yerli yersiz her şey için kullanıldığını ve bu yüzden anlam erozyonuna ugradığından bahsetmiştim. Bu yazımda çevikliğin tanımını yapmaya çalışacağım.

Martin Fowler bu link üzerinden ulaşabileceğiniz yazısında şöyle diyor:

… lack of rigorousness is part of the defining nature of agile methods, part of its core philosophy. … Any attempt to define a rigorous process that can be tested for conformance runs contrary to [the agile] philosophy.

Martin Fowler yazılımda çevikliğin belli bir çerceveye sokulmuş bir süreç (process) olarak tanımlanmasının mümkün olmadığını, bunun çeviklik filozofi ve düşüncesine ters düştüğünü söylüyor.

Bazı kesimler Martin Fowler’in sözlerini çevikliğin iflası olarak yorumlayabilirler. Onların mutlaka katıksız bir tanımlamaya ihtiyacı var, çünkü ipe sapa gelmeyen bir şeyin pazarlamasını yapmak mümkün değil. Bu yüzden çeviklik filozofisinin sadece bir kısmını ihtiva eden yarım yamalak çevik süreçler tanımlamaya ve satmaya çalışıyorlar. Onlar için önemli olan elle tutulur, gözle görülür ve ölçülebilir bir süreç tanımlaması yapmak. Eğer A, B, C adımlarını uygularsan, X, Y neticesini elde edersin diyebilmek istiyorlar. Keşke müşteri gereksinimleri odaklı yazılım bu kadar basite indirgenebilseydi!

Bu sebeptendir ki birçok sözde çevik süreç ile istenilen neticeler elde edilemiyor, çünkü sürecin ihtiva ettiği adımları birebir uygulamak her projede mümkün olmuyor. Doğal olarak bu durumda sürecin yeniden tanımlanıp, ihtiyaçlar doğrultusunda yeniden yapılandırılması gerekiyor. Sözde çevik süreçler bu değişime izin vermedikleri için yazılımda çeviklik yarı yolda kalıyor.

Benim Çeviklik Tanımım

Ben yazılımda çevikliği bir soğanın kabukları gibi iç içe geçmiş, değişik katmanlardan oluşmuş bir yapı olarak görüyorum. En üst katmanda değişikliklere karşı koymadan, onlarla beraber yaşayabilmek için gerekli olan cesaret yer alıyor. Yazılımda çeviklik cesaret ile başlar ve en içteki katmana kadar varlığını sürdürür. Değişiklikle yaşamak ve yeni yollar, yöntemler keşfetmek için birey ve ekip bazında casaret gereklidir. Bunun olmadığı yerde sadece sözde çeviklik olabilir.

Sözde çevik süreçlerde cesaretin yerini sabit süreç tanımlamarı alır. Bunlar tek tek ve sırayla atılması gereken adımlardır, bir nevi yemek tarifidir. Değişikliğe bu şekilde bilinçaltı karşı konulmaya ve her şey daha kontrol edilir hale getirilmeye çalışılır. Yazılım projelerinde değişmeyen tek parametrenin değişikliğin kendisi olduğunu düşünecek olursak, sabit süreç tanımlamaları ile buna karşı koymanın imkansız olduğu ortadadır. Sabitlik isminden de anlaşıldığı gibi dinamizmin karşıtıdır ve ani değişikliklere cevap verebilecek nitelikte ya da değişikliklere adapte olacak yapıda değildir. Değişikliğe karşı koymanın tek yolu, ona karşı koymamak ve onunla beraber yaşamayı ögrenmekten, bunun yolu da cesaret ve cesaretli olmaktan geçer.

Casaret aynı zamanda müşteriye devamlı ne istediğini sorabilmektir. Bu amaçla yazılımda çeviklik çok kısa döngülerin doğurduğu geribildirimlerden beslenir. Bu döngülerin başında proje gidişatını yönlendirmek için kullanılan iterasyon bazlı planlama yer alır. Değişikliğin her an damdan düşer gibi projeyi alt üst edebilecegini varsaydığımızda, buna karşı koymanın en kolay yolu, projeyi kısa ve tanımlanmış zaman dilimlerinde müşterinin gereksinimlerini tatmin edecek seviyeye getirmektir. Bu örneğin bir ya da iki haftalık bir zaman dilimini ihtiva eder. Bu zaman diliminde müşteri kendisi için önemli olduğunu düşündüğü gereksinimlerini tespit edip, gerçekleştirilmek üzere yazılım ekibiyle paylaşır. Yazılım ekibi müşterinin seçmiş olduğu gerekli gereksinimleri hayata geçirir. Ekip seçilen gereksinimlerin öngörülen zaman diliminde tamamlanır tarzda olmasına dikkat eder. Öngörülen zaman dilimi tamamlandığında müşteriye çalışır bir prototip sunulur ve kendisinden geribildirim sağlanır. Bu noktatan itibaren müşteri gidişati kontrol edebilir bir araca sahiptir: çalışan bir prototip. Çoğu zaman müşteri bu prototipe bakarak sahip olduğu gereksinimleri doğru olarak tanımlamadığının farkına varır. Bu kendisi ve yazılım ekibi için bir geribildirimdir ve değişikliğin habercisidir. Bir sonraki çalışma safhasında (iterasyon) ekip bu geribildirimden beslenerek, müşterinin gereksinimlerini tam anlamıyla tatmin edecek değişikliklere gider.

Geribildirim alma çevikliğin ana temellerinden birisini teşkil etmektedir. Müşteriye ne istediğini sorarak, iterasyon bazlı çalışıp prototipler oluşturarak, sürekli entegre edip, entegrasyon seviyesinin ne durumda olduğunu sorgulayarak, birim testleri yazıp, uygulamanın test edilbilirliğini ölçerek birçok katmanda geribildirim ediniyoruz. Bu bizim yazılımcılar olarak müşteri gereksinimlerinin ifade edilmesi ile yazılımcılar tarafından tatmin edilmesi arasında nerede durduğumuzu anlayayıp, tartabilmemiz için çok önemli bir veri olma özelliği taşımaktadır.

Teknik olarak yazılımda çevikliği incelediğimizde çevik olmanın çekirdeğinde çok önemli bir metodun yer aldığını görmekteyiz: uygulamayı yeniden yapılandırma. İngilizce refactoring olarak isimlendirilen bu yöntem, biz yazılımcılara yeni müşteri gereksinimleri ile uygulamayı hamur gibi yogurma yetisi kazandırmaktadır.

Birçok sözde çevik süreci ya da çevik süreçlerin uygulandığı projeleri yakından incelediğimizde, başarısızlıklarının sebebinin uygulamayı hamur gibi yoğurma kabiliyetlerinin olmadığından kaynaklandığını söylemek mümkündür. Bazı sözde süreçler uygulamanın yeniden yapılandırılabilme özelliğine oluşturdukları gidişat planında yer bile vermemektedirler. Bir uygulamanın müşteri gereksinimlerine cevap verebilmesi için yeniden yapılandırılabilmesi gerekmektedir. Bunun ne olduğunu bile bilmeyen ya da tanımlayamayan bir çevik süreç nasıl çeviklik ibaresi olma savına sahip olabilir? Bunu anlamak güç!

Belki çevikliği tanımlamak kolay değil. Belki bu sebepten dolayı herkes her şeye çevik ismini takabiliyor. Ama bildiğim bir şey var, o da birim testi yazmadan ve sürekli refactoring yapmadan çevik olunamayacağıdır. Bu ikisinin nasıl yapılması gerektiğine dair birçok kaynak bulmak mümkündür. Martin Fowler’in Refactoring isimli kitabı yazılımcılara bu konuda ilham kaynağı olacaktır. Refactoring’i mümkün kılmak için birim testleri yazılması gerekmektedir. Bunu isteyen test güdümlü (Test Driven Development), isteyen klasik tarzda uygulamayı kodladıktan sonra yapabilir. Test güdümlü yazılımı şiddetle tavsiye etmekle beraber, klasik birim test yazılımını da hor görmüyorum. Uygulamayı hamur gibi yoğurabilmek için otomatik çalışan her türlü birim testi mübahtır. Bu birim testleri yeniden yapılandırma sürecinde oluşan hataları yazılımcıya gösterirler. Bunun yanısıra yazılımcının özgüvenini artırarak, daha cesaretli bir şekilde yeniden yapılandırma sürecine dahil olmasını sağlarlar. Birim testleri olmadan mantıklı çercevede uygulamanın yeniden yapılandırılması mümkün değildir.

Müşteri gereksinimlerini tatmin etmek için oluşturulan bir uygulama, üç katlı bir apartman gibi sabit bir yapı değildir. Uygulama devamlı değişiklige maruz kalır, çünkü müşteri kendi çalışma sahasında değişikliğe maruz kalmaktadır. Bunun doğal olarak uygulamaya yansıması gerekmektedir. Aksi taktirde uygulama müşterinin güncel gereksinimlerini tatmin edemez. Müşterinin gereksinimlerini tatmin edemeyen bir uygulama, işe yaramayan bir uygulamadır.

Demek oluyor ki “Birim testi yoksa refactoring yok. Refactoring yoksa çeviklik yok. Çeviklik yoksa, müşteri yok (olur)”. Benim çeviklik konusundaki formülüm bu.

EOF (End Of Fun)
Özcan Acar



Agile kategorisinden son yazılar

Share Button
0.00 avg. rating (0% score) - 0 votes

4 Comments

  • ersince76

    09 Ağustos 2012

    Guzel bir yazi elinize saglik.

    Bende cagristirdiklarini paylasmak istedim.

    Kanimca bir yazilim, bir bütün olarak yada bloklar halinde “kopyala yapistir” ile uretilmiyorsa sanat yapiliyordur. Ve sanat, icra edenin tarzini yansitir formule edilemez.(Keske yapilabilseydi)

    Bu nedenle hem yazilim proje yonetimi hem de yazilim gelistirme sanatcilara birakilmalidir diye dusunuyorum.

    Modelleme araclarimizin gercekligi eksiksiz insa edebildigini dusunmuyorum. Bu nedenle hem toplanan isterler hem de urun olan programlar koseli olacaklardir.

    Ote yandan test gudumlu yazilim gelistirme bu tikanmislikta bir cikis gibi gorunuyor. Yontemin bendeki yorumu su: “Gercekligi tam anlamiyla anlatamazsak -sunlari yapsin bunlari yapmasin- diyerek sinirlarini belirleyebiliriz.”

    Bu yaklasim sonunda yasayan ve doğal olarak evrilen kodlar çikacaktir. Varsin çirkin olsun

    Saygilar

    ersince76

  • Şükrü Uzel

    09 Ağustos 2012

    Hantalsan zaten çevik olamazsın. Sondan bir önceki paragraf olayı çok iyi özetliyor.

  • Selman

    07 Eylül 2012

    Son iki paragraf güzel özetlemiş

  • Pingback: Pratik Programcı Yayınları » Yazılımda Şemsiye Modeli

Bir Cevap Yazın