| Çevik (Agile) Modelleme Değerleri |
Ç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, Programlama.com üyeleri bu konuları duyup öğrenmesini sağlamak ve hafızalarınızda birer ışık yakmak amaçlı olarak çevirdim.
Herkese kolay gelsin