Çevik Modelleme Scott W. Ambler tarafından Extreme
Programming değerleri göz önüne alınarak geliştirilmiş ve içine alçakgönüllüğün
eklenmesi ile son halini almıştır. Extreme Programming değerleri iletişim,
basitlik, geribildirim ve cesaret değerlerinden oluşur.Çevik Modelleme yazılım
geliştirme açısından uyulması gereken kuralları ortaya koyar ve destekler.
Şimdi bu değerlere bir göz atalım:
İletişim
Projede yer alan herkes arasında çok iyi bir iletişim olmalıdır. Başarılı
yazılım geliştirme’nin birinci gerekliliği budur. İletişim, sözlükte yazdığı
kadarı ile kişiler arası belli işaret, hareket veya sembollerle bilgi alışverişi
yapılan genel sistemin adıdır. İletişim iki yollu bir sistemdir. Her iki tarafta
bilgi sunar ve kazanır. İletişimde aksamalar ortaya çıktığında problemler de
ortaya çıkar. Örneğin, bir yazılım uzmanı kendi yazdığı bölümün henüz tam olarak
bitmediğini iş arkadaşlarına söylememesi başka bir yazılım uzmanının bu problemi
ortaya çıkartmak için ekstra zaman harcamasına neden olabilir. Yazılımcılar
yazacakları sistemin prototipini müşteriye sunarlar ama müşteri onun prototip
olduğundan haberdar değildir ve gerçek sistemin hazır olduğunu zanneder.
Durup düşündüğünüzde modelleme işleminin aslında iletişimi arttırmak ve
geliştirmek için yaptığımızı görürüz. Müşteriniz, pek çok iş kuralından oluşan
karmaşik bir iş yapısını anlatırken sizin mantığı anlatan bir veri akışı şeması
çizmeniz, işlemi anlamınızı kolaylaştıracaktır. Genellikle, konu hakkında beş
dakikada cizeceğiniz bir model, o konu hakkında 5 saat okumaktan veya
tartışmaktan cok daha fazla sey öğretecektir. Modelleme, kendi fikirlerinizin
daha rahat anlaşılmasına, başka kişilerin fikirlerini daha rahat anlamanıza ve
en sonunda genel olarak tüm iş hakkında genel bir kanı oluşmasına neden olur.
Basitlik
Pek çok yazılım kitabı basitlikten söz eder fakat içerisinde geçen konulara ve
metodlara baktığınızda, yazılım geliştirme işini zorlaştırdığını görürsünüz.
Genellikle yapılan yanlışlar şunlardır.
Karmaşık yapıları erken uygulamak: İhtiyaç olmadan modellenen karmaşık yapılar,
yazılım uzmanlarının fazla mesai yapmalarına neden olur. Karmaşık yapıların
yavaş yavaş sindirilerek ve parçalara bölünerek modellenmesi ve en gerekli
kısmının ilk olarak yazılması gerekir. Müşterinize vereceğiniz ilk sürümde,
hayati önem taşıyan modüllerle ve en az hata ile ortaya çıkmalısınız.
Gereklilikler ortaya çıktıkça, müşteri de ne istediğini daha net görecek,
belkide karmaşik bir modülü programlamaktan kurtulacaksınız.
Gelecekte kullanılacak bölümler için fazladan modelleme/kodlama yapmak: Şu anda
üzerinde calıştıgınız bankacılık sisteminin, hayat sigortalarını
destekleyebilmesi için belkide sadece bir günlük bir modelleme gerekiyor, Neden
yapmayalimki? Evet, bu sistemi modellemek oldukça zevkli olacaktır fakat
yazılımınızı bugün olduğundan daha karmaşik bir yapıya sokmayacak mı?Yada
yazılım uzmanlarınız gelecekte olacak değişikliklere cevap verebilmek veya her
isteğe cevap verebilecek en iyi yazılımı yapma egosu ile çok fazla modelleme ve
kodlama yapma eğiliminde olabilirler. Müşteri isteklerini anlayarak, olabilecek
en basit, en verimli, en ucuz çözümü sunmak hedefimiz olmalıdır. Yarının
problemlerini yarın çözmeliyiz. Eger bugünden en basit çözüm üzerinde
çalışırsak, yarın yeni bir fonksiyon eklemeye kalktığımızda elimizdeki sistem
çok basit olacaktır.
Karmaşik altyapılar geliştirmek: Proje ekiplerinin yaptiği genel hata ilk
asamada gelecekte kullanmak üzere geliştirdikleri modüller, sınıf kütüphaneleri
ve iskelet yapılardır. Amaç bu parçalar lazım olduğunda elimizin altında
olmasıdır. Fakat bu amacin ciddi zararları vardır. Öncelikle müşterinizin
kaynaklarını, onlara elle tutulur bir ilk sürüm vermeden harcamış oluyorsunuz.
Müşteriniz sizden bazı işlerini kolayca yapabileceği bir sistem istiyor fakat
sizin ilk verdiğiniz şey hata-yakalama alt yapısı. Projenizi, hızlı ve
kullanilabilir bir fonksiyonellik sunmadığınız için riske atıyorsunuz. Ayrıca
hata-yakalama gibi alt-sistemleri projenin gidişati içerisinde zamanlada
geliştirebilirsiniz. Sadece ihtiyacınız gerçekten ortaya çıktığında.
Geribildirim
Yaptığınız işin doğru olup olmadığını anlamanın tek yolu farklı kişilerin
geliştirdiğiniz sistem hakkında test yapmaları ve sonuçları paylaşmanizdir
(geribildirim). Testi yapan kişilerden sonuçları doğru zamanda alıp sebeplerini
kısa zamanda bulmak çok önemlidir. Analizler sonucu ortaya çıkan modellerinizin
doğru olup olmadığını nasıl anlayacaksınız.
Modellemeyi takım halinde yapın. Yazılım geliştirme işi yüzme gibi değildir. Tek
başına yapmak tehlikelidir. Diğer kişilerle beraber çalıştığınızda sonuçlara
daha hızlı ulaşır, sebeplerini bulmak için zaman kaybetmemiş olursunuz.
Modelinizi doğru kişilerle inceleyin. Modellediğiniz işin, o işten anlayan
kişilerle birlikte incelenmesi gerekir. En güzeli modelleme sırasında bu
kişilerin işin içinde olmasıdır. Gereklilik modelleri son-kullanıcı ile beraber
yapılmalı, detaylı dizayn modelleri ise programlamayı yapacak kişiler ile
yapılmalıdır.Resmi toplantılar halinde düzenlenmesi ve proje başında ayda veya
haftada bir yapılmalıdır. Eğer bu mümkün değilse (organize etmesi zaman
alır)gayri resmi hızlı toplantılar ile yapılacak incelemeler modellerinize çok
şeyler katabilir.
Modelin uygulanması. Eğer hiç bir şekilde bir toplantı ayarlayamıyorsanız,
modelinizi doğrudan koda döker ve ilk sürümden sonra gelecek sonuçları
beklersiniz. Önemli olan testlerin zamanında yapılabilmesi ve hataların hızlı
olarak sebeplerine ulaşabilmektir.
Kabul testleri. Esas olarak modellerinizin müşteri isteklerini yansıtıyor olması
gerekir. Müşteriniz kabul testleri sırasında bu isteklerini değerlendirir ve
geri dönen hatalar ile gene modellerinizi test etmiş olursunuz.
Geribildirim olayında zaman kavramıda çok ilginçtir. Bir takım halinde
çalıştığınızda, geribildirim saniyeler yada dakikalar içinde olabilmektedir.
Gayriresmi toplantılarda ise geribildirim dakikalar yada saatler alabilmektedir.
Resmi toplantı geribildirimleri toplantı sırasında gelsede zaten organize etmesi
haftalar, aylar alabilmektedir. Uygulamayı yapıp ilk sürümü verdiğinizde
geribildirim saatler yada günler içinde olur. Kabul testlerinden sonra
geribildirim bir kaç hafta yada ay içerisinde gelir.
Zaman ne için önemlidir? Çünkü kısa zamanda gelen geribildirim, sizin
modellerinizden sapma olasılığınızı düşürür. Takım halinde çalışmanın en büyük
yararı geribildirimlerin hızlı olmasıdır. Yada kağıt üzerinde mükemmel görünen
modelin kodlanması ve ilk sürümden sonra gelecek geribildirimlerin işlenmesi de
metod olarak düşünülebilir.
Cesaret
Arkanıza rahatça yaslanıp genel durumu kabul etmek ve bir şeyleri geliştirmeyi,
düzeltmeyi denememek yada birisinin çıka gelip hataları düzeltmesini beklemek
çok kolay bir işdir. BT endüstrisinin bugünkü aksayan taraflarında
cesaretsizliğin büyük payı vardır. Çevik Metodolojisi size diğer insanlarla
beraber çalışmanızı, onlara güvenmenizi ve kendinize güvenmenizi öğütler. Bu
cesareti arttırır. XP veya Çevik Modelleme, yapabileceğiniz en basit modeli
yapmanızı söyler, çünkü yarının problemlerini yarın çözmek gerekmektedir. Çevik
Modelleme, gerçekten dökümantasyona ihtiyacınız olduğunda döküman yaratın der.
Beyaz tahta yada not defteri gibi en basit araçları kullanarak modelleme
yapmanızı öğütler. Karmaşık yazılım araçlarını ancak olabilecek en yüksek yararı
elde edebileceğiniz zaman kullanmanızı öğütler. Modelerimizin daha iyi
görünmeleri için zaman harcamamızı öğütler. Birlikte çalıştığınız kişilere
güvenmenizi, yazılım uzmanlarınında dizayn aşamalarında karar verebileceğini
söyler. Tüm bu söylediklerimizin hepsi cesareti arttırır. Cesaretli ekipler,
denemekten ve yanılmaktan korkmaz. Sonuçlara daha hızlı ulaşılır ve kat edilen
yol daha uzun olur.
Düşünün, firmanızda Modul Tabanlı Analiz ve Geliştirme kurallarını uygulamak
istiyorsunuz fakat endişeleriniz var. Seçim için cesaret gerekir. Her işin her
sektörün belirli riskleri vardır fakat risklerden kaçmak olsa olsa daha büyük
risklere yakalanmanıza neden olur (yağmurdan kaçarken doluya tutulma kuralı).
Cesaretli olmak sizinde hata yapabileceğinizi anlamanıza yardımcı olur.
Denemekten, yanılmaktan ve deneyim kazanmaktan korkmayın.
Alçak Gönüllülük
En iyi yazılım uzmanı her şeyi bilmediğini kabul edecek kadar alçak gönüllü
olandır. Gelmiş geçmiş en iyi Java yazılımcısı olabilirsiniz fakat her bir Java
API’sinin detaylarını tek tek bilmiyor olabilirsiniz. Çok iyi Java bilmeniz, çok
iyi arayüz tasarımlama yada mükemmel veritabanı tasarımcısı yada en iyi müzisyen
olduğunuz anlamına gelmez. Sadece çok iyi Java bildiğiniz anlamına gelir. Çok
iyi Java bilmeniz, yeni başlayan çıraklardan hiç bir şey öğrenemezsiniz anlamına
da gelmez.
Çevik Modelleme ve programlama yapan kişi proje ekibindeki herkesin bir uzmanlık
alanı olduğunu bilir ve ancak diğer kişilerin yardımı ile kendi işlerinin
başarılı bir biçimde biteceğini görür.Alçakgönüllülük, diğer kişiler ile
birlikte çalışmayı imkan dahilinde kılar. Çevik Modelleme yapan kişi diğer proje
elemanlarının farklı deneyimlerinin olduğunu, kişisel pek çok farklılıklar
olduğunu bilir ve saygı ile hareket eder. Patronları "yüksekte oturan kargalar",
son kullanıcıları "aptal kullanıcı", diğer departmanları "kafayı yemiş" olarak
değerlendirmek iletişim problemlerine yol açar, iletişimsizlik projenizi sekteye
uğratabilir. Zaman ve kaynak kaybından başka bir şey olmadığı sizde
görüyorsunuz.
Bu yazının amacı
Burada anlatılan modelleme kültürü CBD, UML ve eXtreme Programming ile analiz ve
modelleme yapan projeler tarafından benimsenmeye başlamıştır. Çok yeni olması
nedeni ile tamamen geliştirmeye ve deiştirmeye açık bir konudur.
Bu yazıyı Scott W. Ambler’in Agile Modelling (ISBN 0-471-20282-7) isimli
kitabından, sizin bu konuları duymanızı sağlamak ve hafızalarınızda birer ışık
yakmak amaçlı olarak çevirdim.
Bir kaç yararlı link:
http://www.ambysoft.com/ Scott Ambler’in web sitesi
Herkese kolay gelsin.
