Bu yazımda sizelere test güdümlü yazılım sürecinin, yazılım tasarımı üzerindeki etkilerini bir örnek üzerinde aktarmak istiyorum. TDD ile birlikte oluşan tasarım, kendiliğinden oluşan birşey değildir. Testler şekil aldıkça, oluşturmak istediğimiz tasarımın modeli de gözümüzde canlanmaya başlar. Oluşturduğumuz testler, programın gelecekteki kullanıcılarını (client) simule ettiği için, programın nasıl kullanılacağını testler bünyesinde gözlemlemek kolaylaşmaktadır. Bu süreç, sınıfların ve metotların kullanıcı gözüyle (client) tasarlanmasını sağlar. Bu sayede basit ve kullanışlı API (Application Programming Interface)’ler oluşur. Test güdümlü yazılım tasarımı devamlı zorlar ve yetersiz kaldığı yerlerde refactoring yöntemleriyle yenilenmesini sağlar. Bu süreç sayesinde kendisini devamlı yenileyen ve yeni gereksinimlere cevap veren bir tasarım oluşur.

Bu yazıyı PDF olarak edinebilirsiniz.

EOF (End of Fun)
Özcan Acar

Her doküman oluşturulduğu ilk saniyeden itibaren bir versiyon ihtiva eder. Bir versiyon,  dokümanın geleceğe doğru olan yolculuğunda durak yaptığı istasyonlardan birisidir. Zaman içinde doküman değişikliğe uğrar. Her değişikliğin ardından dokümanın yeni bir versiyonu oluşur. Dokümanın herhangi iki versiyonu arasındaki fark, bu iki versiyonun oluşumu için geçen zaman diliminde, doküman üzerinde yapılan tüm değişiklikleri ihtiva eder.

Bu yazıyı PDF olarak edinebilirsiniz.

Konuyla İlgili Kitaplar

EOF (End of Fun)
Özcan Acar

XP projelerinde müşteri gereksinimlerinin yer aldığı kullanıcı hikayeleri oluşturulur. Bir kullanıcı hikayesi sistemin tipik bir özelliğini bir ya da iki cümle ile anlatan araçtır. Örneğin üye girişi olan bir sistemde, şöyle bir kullanıcı hikayesi düşünülebilir:

Kullanıcı isim ve şifreni kullanarak sisteme giriş yapar.

Kullanıcı hikayeleri hikaye kartlarına (story card) yazılır. Bu kartlar sürüm ve implementasyon planları yapılırken kullanılır. Her kullanıcı hikayesinin implementasyon zamanı programcılar tarafından tahmin edilir. Müşteri kullanıcı hikayelerine öncelik sırası vererek implementasyon sırasını tayin eder. Programcılar tarafından yapılan tahmin ve müşteri tarafından belirlenen öncelik sırası kullanıcı hikayesinin üzerinde yer aldığı hikaye kartlarına not edilir. Ayrıca müşteri tarafından oluşturulan akseptans (onay/kabul) testleri hikaye kartlarının arka bölümüne not edilir.

Bir kullanıcı hikayesinin büyüklüğü ne kadar olmalı?

Bu sorudaki büyüklük sıfatı ile kullanıcı hikayesinin kaç günde implemente edilebilir olduğu kastedilmektedir. Programcılar tarafından kullanıcı hikayelerin implementasyon süreleri gün bazında tahmin edilir. Bir kullanıcı hikayesinin en fazla dört yada beş günde implemente edilebilir yapıda olması gerekmektedir. Daha fazla zaman gerektiren kullanıcı hikayelerinin müşteri tarafından bölünerek, küçültülmeleri gerekmektedir.

Kullanıcı hikayelerini kim oluşturur?

Kullanıcı hikayelerini müşteri oluşturur, çünkü gereksinimleri en iyi bilen müşteridir.

XP projelerinde müşterin programcılarla beraber çalışması talep edilir. Müşteri kendi işini bırakıp, nasıl proje için çalışabilir? Başka işi yok mu?

Bu genelde müşterinin kendi işini gücünü bırakıp, projede başka işlerle uğraşması gerektiği şeklinde değerlendirilir, ama durum öyle değildir. Müşterinin programcılara yakın bir yerde olması, programcıların oluşan sorulara kısa sürede müşteri yardımıyla cevap bulmalarını kolaylaştırır. Asıl maksatta budur zaten. Müşteri gün boyunca programcıların sorularına cevap verir. Bunun yanı sıra kendi günlük işlerini takip eder. Çoğu zaman günlük işleri yapabilmek için bir bilgisayar yeterli olacaktır. Müşteri kendi işlerini yaparken ara sıra programcılara zaman ayırarak, soruları cevaplar.

Birden fazla müşteri varsa, hangisinin sözü geçerlidir?

Proje ekibinin karşısında sadece bir müşteri olmalıdır. Eğer birden fazla müşteri varsa, bu şahıslar bir araya gelerek, tek bir şahıs gibi programcı ekibi ile iletişim kurmalıdırlar.

Sürüm planını kim oluşturur?

Sürüm planı müşteri ve programcılar tarafından ortaklaşa oluşturulur. Ne ve hangi sıraya göre yapılması gerektiği müşteri tarafından belirlenir. Bu yüzden sürüm planının oluşumunda müşterinin ağırlığı daha fazladır. Planlama için zaman tahminleri programcılar tarafından yapılır. Bu şekilde programcılar proje planlama sürecine aktif olarak katılarak sorumluluk alırlar.

Sürüm planını ne oranda sabittir?

Proje başında oluşturulan sürüm planı projenin çeşitli safhalarında değişikliğe uğrayabilir. Bu doğaldır. Müşteri yazılım sisteminin ilk sürümleriyle gereksinimlerinin ne olduğunu daha iyi anlayabilir ve mevcut kullanıcı hikayeleri üzerinde değişilik yapılmasını talep edebilir ya da yeni kullanıcı hikayeleri oluşturabilir. Bu durumda sürüm planının değiştirilmesi gerekmektedir.

Sürüm ve iterasyon arasındaki fark nedir?

Sürüm yazılım sisteminin belirli bir versiyondaki halidir. Her yeni sürüm yeni özelliklerin implemente edildiği ve müşteri tarafından produktif kullanılan program versiyonudur. XP projelerinde her yeni sürüm bir ile dört ay süren bir çalışma sonunda oluşturulur. Müşteri tarafından seçilen kullanıcı hikayeleri belirli bir zamansal uzunluğa sahip olan iterasyonlarda implemente edilir. İterasyonlar bir ile dört haftalık zaman birimini kapsarlar.

Bir önceki resimde yer alan sürüm beş iterasyondan oluşmaktadır. Her iterasyon iki hafta sürmektedir. Sürüm onuncu haftanın sonunda oluşturulmaktadır.

Hangi kullanıcı hikayesiyle işe başlanır?

Bu sorunun cevabını sürüm ve iterasyon planı verir. Sürüm ve iterasyon planlarında müşteri tarafından belirlenen kullanıcı  hikayeleri yer alır. Müşteri, kullanıcı hikayeleri için sahip oldukları değere göre öncelik sırası belirler. Sürüm ve iterasyon planlarında kullanıcı  hikayeleri bu öncelik sırasına göre yer alırlar. Programcılar her iterasyonda, o iterasyon için seçilmiş olan kullanıcı hikayelerini öncelik sırası yüksekten düşüğe doğru implemente ederler. Buradaki ana amaç, müşteri için en değerli özelliklerin yer aldığı bir sürümü oluşturarak, müşteri tarafından kullanılabilir hale getirmektir. Bu yüzden her zaman müşteri açısından en değerli olan sistem özellikleri öncelikli olarak implemente edilir.

Kullanıcı hikayesi implementasyonu ne zaman tamamlanmıştır?

Programcılar bir kullanıcı hikayesini test güdümlü implemente ederler. Testler tamamlandıktan sonra akseptans testleri yapılmak üzere kullanıcı hikayesinin yer aldığı hikaye kartı (story card) testçiye (tester) devredilir. Testçi müşteri tarafından tanımlanmış olan akseptans (onay/kabul) testlerini implemente eder. Akseptans testlerini geçen bir implementasyon bitmiş olarak kabul edilir.

Mevcut projeler üzerinde XP uygulanabilir mi?

Bu büyük ölçüde projedeki JUnit testleri oluşturma alışkanlığına bağlı. XP test güdümlü implementasyonu şart koşmaktadır. Eğer programcılar tarafından programlara paralel olarak testler geliştiriliyorsa, test güdümlü implementasyona geçmeleri zor olmayacaktır. Bunun yanı sıra projedeki mevcut iletişim kültürü önemlidir. XP çok yönlü iletişimi gerekli kılmaktadır. Örneğin pair programming gibi tamamen iletişim ve takım işine bağımlı olan bir metot programcılar tarafından ne oranda uygulanabilir, bunun araştırılması gerekmektedir.

Sürekli entegrasyon, test güdümlü yazılım, müşterinin projeye dahil edilmesi, kısa sürelerde yeni sürüm oluşturulması gibi konular XP’yi yeni başlamayan projeler için zor adapte edilebilir kılmaktadırlar. XP’nin yeni projelerde adaptasyonu çok daha kolaydır.

Bir iterasyon süresi ne kadar olmalı?

Bu yazılım sisteminin sahip olması gereken özelliklerle doğru orantılıdır. Eğer iki ay içinde ilk sürüm oluşturulması planlanıyorsa, iterasyon süresi bir ile iki hafta olacak şekilde seçilebilir. Bunun yanı sıra müşteri tarafından oluşturulan kullanıcı hikayelerinin implementasyonu için programcılar tarafından verilen tahminlerin dikkate alınması gerekmektedir. Örneğin programcılar tarafından ortalama her kullanıcı hikayesi için bir ile iki gün tahmin edilmişse,  bir haftalık iterasyonda en az üç en çok beş kullanıcı hikayesi implemente edilebilir. Eğer kullanıcı hikayeleri ortalama dört veya üzeri günde implemente edilebilir durumda ise, o zaman interasyonun en az iki hafta olarak seçilmesi gerekmektedir. İterasyon süresi sabittir ve uzatılamaz, bu yüzden seçilen kullanıcı hikayelerinin seçilen sürede implemente edilebilir yapıda olmaları gerekmektedir.

Akseptans (okay/kabul) testlerini kim oluşturur?

Akseptans testleri kullanıcı hikayesini oluşturan müşteri tarafından tanımlanır. Akseptans testlerinin implementasyonunu programcılar yada testçiler üstlenir.

Kaç tane JUnit testi hazırlanmalı?

Produktif olarak kullanılan her sınıf için bir JUnit testi sınıfı oluşturulması gerekmektedir. Bu sınıf bünyesinde birden fazla test metodu yer alır. Produktif sınıfta bulunan her metodun test edilmesi gerekmektedir. Çoğu zaman oluşturulan test sınıfının büyüklüğü test edilen sınıfın 2-3 katı büyüklüğe sahiptir. Bu test adedi hakkında bir fikir sahibi olmanızı kolaylaştırır.

Kod paylaşımı nasıl yapılır?

Kod paylaşımını kolaylaştırmak için bir versiyon kontrol sisteminin kullanılması şarttır. Subversion son zamanlarda kullanılan en popüler açık kaynaklı versiyon kontrol sistemi haline gelmiştir.

Kurumsal Java Akademisi Subversion eğitimi »

Pair programming yaparken tecrübeli bir programcı ile tecrübesiz bir programcının beraber çalışması zaman ve kaynak kaybı değil midir?

Hayır! Pair programming tekniği ile programcıların teknik anlamda ayni seviyeye gelmeleri sağlanır. Tecrübeli programcılar can, tecrübesiz programcılar patlıcan değildir :) Tecrübesiz programcılar için seminer düzenlemek yerine, onlara pair programming seanslarında teknoloji ve proje hakkında bilgi transfer etmek daha mantıklıdır.

Pair programming iki programcının bir kişilik iş çıkarması anlamına gelmez mi?

Pair programming maliyetli bir yöntemdir. Lakin iki programcının beraber aynı implementasyon üzerinde çalışmasından sinerjiler doğar. Pair programming iş kalitesini yükseltir. Ayrıca pair programming ile kodun ve tasarımın iki değil dört göz ile kontrol edilmesini sağlanır.

XP projelerinde mimariyi ve tasarım nasıl oluşur?

Mimari (altyapı) proje öncesinde yapılan keşif safhasında (Exploration Phase) oluşur. Programcılar müşteri tarafından oluşturulan kullanıcı hikayelerini okudukça, neye ihtiyaç duyduklarını anlarlar ve ona göre altyapıyı geliştirirler.

Proje öncesi detaylı tasarım oluşturulmaz. Tasarım test güdümlü implementasyon esnasında programcılar tarafından oluşturulur. Eğer programcılar implementasyon esnasında sorunlarla karşılaşırlarsa, refactoring yöntemleri kullanarak tasarım üzerinde değişiklik yaparlar. Unit testleri refactoring işleminin yapılmasını kolaylaştırır. Yapılması gereken değişiklikler sonraya bırakılmaz, çünkü bu ilerde maliyetin yükselmesine sebep olabilir.

XP projelerinde mimariyi ve tasarımı kim oluşturur?

Programcılar.

Bilgi bankası olan bir sistemde test güdümlü yazılım nasıl uygulanır?

Bunun çeşitli yöntemleri vardır. Öncelikle bilgi bankası işlemlerinin DAO (Dao Access Object) tasarım şablonu kullanılarak bir interface sınıf arkasında saklanması en mantıklı çözümdür. Mock sınıflar kullanılarak DAO katmanı simule edilebilir. Bu sistemin diğer bölümlerinin test güdümlü implementasyonunu kolaylaştırır. DAO kullanıldığı taktirde, gerçek bilgi bankasına olan bağımlılık azaltılır. DAO interface sınıfını değişik türde implemente ederek, bilgi bankası yerine başka bir yapıda kullanılabilir.

Hibernate ve IBatis gibi bir framework kullanılması durumunda, test güdümlü yazılımı mümkün kılabilmek için bu frameworklerin sunduğu interface sınıflar (SessionFactory, Session vs.) mock nesneler ile simüle edilebilir.

Planlama pokeri nedir?

Programcı bir kullanıcı hikayesini implementasyon öncesi tüm detaylarıyla bilmek zorunda değildir. Bir kullanıcı hikayesini en son detayına kadar kavramaya çalışmak zaman kaybı olabilir, çünkü kullanıcı hikayesinde yeralan müşteri gereksinimi değişikliğe uğrayabilir. Bu genelde müşterinin programın ilk sürümlerini görmesiyle gerçekleşir. Çalışır bir program aracılığıyla müşteri gereksinimlerini daha iyi kavrayacak ve gerekli değişiklikleri talep edecektir. Bu sebepten dolayı implementasyona başlamadan önce kullanıcı hikayesinin ihtiva ettiği tüm detayları tespit etmek faydalı olmayacaktır, çünkü kullanıcı  hikayesi değişikliğe ugrayabilir. Programcı ekibin kullanıcı hikayesi hakkında implementasyon için gerekli zamani tahmin edebilecek kadar bilgiye sahip olması yeterli olacaktır.

Programcılar müşteri tarafından seçilen kullanıcı hikayesinin implementasyon süresini tahmin ederler. Bu tahminler planlama pokerinde yapılır.

Planlama pokeri yapılmayan tahminler bazen sağlıklı sonuçlar vermeyebilir. Bir programcı tarafından yapılan tahmin diger programcıları etkiliyebilir. Yada bazı programcılar herhangi bir sebepten dolayı tahmin etme sürecine aktif olarak dahil olmayabilirler. Bu gibi sebeplerden dolayı oluşan tahmin süreleri yanıltıcı olabilir. Daha geçerli tahminler elde edebilmek için planlama pokeri oynanır.

Planlama pokeri için kullanılan kartlar bir önceki resimde yer almaktadır. Her programcı bu kartların bir setine sahiptir. Planlama pokeri şu şekilde oynanır: Bir moderator ilk kullanıcı hikayesini okur. Müşteri bu kullanıcı hikayesi için implementasyon süresinin ne olduğunu sorar. Programcılar kısa bir zaman düşündükten sonra hep beraber planlama poker kartlarından birisini seçerek gösterirler. Çoğu zaman kullanılan kartlardakı değerler farklı olacaktır. En çok süreyi ve en az süreyi tahmin eden programcılardan bu sonuca nasıl vardıklarının açıklanması istenir. Verilen bilgiler dogrultusunda ortak bir değer bulunur.

Tahminler için hikaye puanları (story points) kullanılır. 1 hikaye puanı örneğin 1 iş günü (8 saat) olabilir. Programcılar her kullanıcı hikayesini kendi başına tahmin etmek yerine, kullanıcı hikayelerini birbirleriyle kıyaslıyarak tahminde bulunurlar. Örneğin kullanıcı hikayesi A için 2 hikaye puanı tahmin edilmişse, kullanıcı hikayesi B bu değer göz önünde bulundurularak tahmin verilir. Eğer kullanıcı hikayesi B A dan üç katı daha büyükse, o zaman B için tahmin 2×3 = 6 hikaye puanı olarak verilir.

Load Factor nedir?

Bir kullanıcı hikayesinin ideal şartlarda implementasyonu için gerekli zaman dilimi ile normal şartlarda implementasyonu için gerekli zaman dilimi farklı olacaktır. Örneğin programcılar gün boyunca yazılım haricinde toplantı, bilgi alışverişi gibi işler için zaman ayırmak zorundadir. Bir programcının sekiz saatlik bir iş gününde sekiz saat program yazabilmesi ideal zaman dilimi olarak tanımlanır. Toplantı ve diğer işler için kullanılan zaman ideal zaman diliminde çikartıldığı zaman normal zaman dilimi elde edilir. Kullanıcı hikayelerinin tahminlerinde ideal ve normal zaman dilimlerinin göz önünde bulundurulması gerekmektedir, aksi taktirde kullanıcı hikayesi için yapılan tahmin gercekleri yansıtmıyacaktır. Gerçekci bir tahmin yapabilmek için load factor olarak bilinen değer kullanılır. Bu değer bir kullanıcı hikayesinin implementasyonu için kullanılan zamanın ideal zamana bölünmesiyle elde edilir. Örneğin bir kullanıcı hikayesi için 1 iş günü (8 saat) tahmin edilmiş ve programcı kullanıcı hikayesini 2 iş gününde tamamlamış olsun. Bu durumda load factor 16 / 8 = 2  olacaktır. Load factor için 2 ila 5 arasında bir değer normaldir. Tahmin yapılırken tahmin edilen implementasyon zamanı load factor ile çarpılır. Örneğin programcı bir kullanıcı hikayesini 2 iş gününde implemente edebileceğini düşünüyorsa, kullanıcı hikayesi için tahmin süresi 2 değil, 2 iş günü x 2 load factor = 4 olmalıdır. Bu şekilde daha gerçekci tahmin elde edilir.

Programcılar load factor değerini göz önünde bulundurarak, tahminde bulunurlar.

Spike solution nedir?

Eğer programcılar bir kullanıcı hikayesi için tahminde bulunamazlarsa küçük çaplı bir demo implementasyonu yaparak implementasyon süresini tahmin etmeye çalışırlar. XP dilinde bu işe spike solution ismi verilir. İdeal şartlarda bu işlemin sürüm planlama oyunundan önce yapılmış olması gerekir. Buradan sürüm planlama oyunu için kullanıcı hikayelerinin oyun öncesi hazırlanmış olması gerektiği sonucunu çikartabiliriz.

Programcılar yaptıkları denemeler sonunda kullanıcı hikayesi için tahmin verebilecek duruma gelirler.
 

Özcan Acar

Şimdi şunu hayal edin: Yeni bir otomobilin tasarlanması projesinde yer aldınız. Otomobil tasarlandı ve otomobili oluşturan parçalar 5 değişik ülkede, 20 değişik firma tarafından üretildi. Bu ülkelerde kullanılan uzunluk ve ağırlık birimleri (metre, kg vs.) değişik olabilir. Görev dağılımı esnasında yanlış anlamalardan dolayı üretilen parçalar birbirine uyumlu olmayabilir. Eğer tüm parçalar üretildikten sonra bir çırpıda tüm otomobili oluşturmak isterseniz, üretim sürecinde meydana gelen hataları daha önceden tespit edemediğiniz için, yamuk yumuk bir otomobil ortaya çıkacaktır. Ama üretim esnasında koordineli bir şekilde otomobili parça parça bir araya getirip, parçalar uyuşuyor mu diye kontrol etmiş olsaydınız, meydana gelen uyuşmazlıkları çok erken tespit ederek, gerekli değişiklikleri yapabilirdiniz. Bu yazılım sektörü için de geçerli.  Oluşturulan sistem komponentleri ne kadar erken entegre edilirse, oluşan uyuşmazlıklar o kadar erken tespit edilir ve gerekli değişiklikler yapılabilir.

Sürekli entegrasyon çevik süreçlerde çok önemli bir yazılım metodudur. Sistem üzerinde yapılan her değişiklik sürekli entegrasyonu otomatik olarak gerçekleştiren sunucu tarafından kontrol edilir.  Yazılımda kırılmalar oluşması (compile hataları, eksik sınıflar vs.) durumunda, tüm ekip sürekli entegrasyon sunucusu tarafından uyarılır. Bu geribildirim sayesinde entegrasyonun ne safhada olduğu anlaşılır.

Sürekli entegrasyon hakkında diğer bir makalemi

http://www.kurumsaljava.com/2008/11/26/surekli-entegrasyon-continuous-integration/

adresinden edinebilirsiniz.

Özcan Acar

1. Çevik sürece hemen ve tüm neticelerine katlanarak mı geçilmeli?
2. Çevik süreç adım adım mı yerleştirilmeli?

Bu soruların cevaplandırılabilmesi, firma ve sahip olduğu çalışanlarının çalışma kültürü ile doğrudan orantılıdır. Genelde çevik sürecin uygulanmasının önündeki en büyük engellerden birisi, çalışanların sahip oldukları alışkanları ve çalışma yöntemleridir. Çalışanlar yeniliklere ve değişikliklere içgüdüsel olarak karşı koyarlar. Bu yüzden çevik sürece geciş gibi çok yan etkileri olabilecek bir girişimin başarısı, çalışanların değişimle yaşayabilme özellikleriyle doğrudan orantılıdır.

Çevik süreci adapte etmiş bir çok takım, yazılım esnasında içinden çıkılamaz problemlerle karşılaşmakta ve doğal olarak suçu çevik süreçte bulmaktadırlar. Acaba suç gerçekten çevik süreçte mi?

Eğer bir takım “çevik süreci adapte ettik, lakin karşılaştığımız sorunlar günden güne artıyor, işin içinden çıkamıyoruz” şeklinde kendini savunuyorsa, o zaman o takımın, çevik süreci nasıl adapte ettiğinin incelenmesinde fayda vardır.  İzlenimlerime göre, böyle takımlar tarafından çevik süreç ya yanlış  ya da eksik olarak adapte edilmektedir. Örneğin birçok takım sadece Scrum kullanarak çevik olabileceklerini düşünüyorlar.  Scrum hiçbir yazılım mühendisliği metodu ihtiva etmez! Eğer çevik olmak istiyorsanız, yazılım metotlarınızın çevik olması gerekmektedir. Bunu da en iyi sağlayayan Extreme Programming‘dir. Extreme Programming eşli programlama (pair programming – PP), sürekli entegrasyon (continuous integration – CI), test güdümlü yazılım (test driven development - TDD), müşteri ile beraber çalışma (on site customer) gibi birçok metoda sahiptir. Bu metotlar uygulandığı taktirde çevik çalışma ortamı oluşturulabilir ve oluşan sorunlar ortadan kaldırılabilir. Bu Scrum’ın gereksiz olduğu anlamına gelmez. Scrum proje planlama ve yönetme alanında kendine has yöntemleri ile çevik sürece katkıda bulunur. Scrum Extreme Programming ile birleştiği anda çevik süreç, gerçek ve oluşan sorunları aşabilen bir çevik süreç haline gelir, çünkü sorunları aşabilmek için ekibin elinde bir çok yeni teknik metot (PP, CI, TDD) bulunmaktadır. İşte çevik olmak isteyipte, olamayan takımların ana sorunu, PP, CI ve TDD gibi metotları tanımamaları ve bu yüzden dolayı uygulayamamaların da yatmaktadır. Atalarımızın da dediği gibi “alet çalışır, el övünür”. Eğer çekiciniz yoksa, çiviyi çakamassınız. Eğer sürekli entegrasyon yapmıyorsanız, o zaman müşteriye kısa aralıklarla, çalışan entegre bir prototip sunamazsınız. Test güdümlü çalışmıyorsanız, kodu yeniden yapılandırmanız (refactoring) hemen hemen imkansız hale gelir. Eğer kodu yeniden yapılandırmanız mümkün değilse, müşterinin yeni gereksinimlerini ya da istediği değişiklikleri implemente etmeniz imkansız hale gelir. Eğer eşli programlamıyorsanız, programcılar aynı seviyede koda hakım olamaz ve kod sahiplenmeleri başlar!

Şelale modelinden XP gibi bir çevik sürece geciç, hiç unit test yazmamış bir programcının, birden bire TDD tarzı programlama ile yüzyüze gelmesi gibi birşeydir.  Daha öncede belirttiğim gibi takımın bu gibi radikal değişikliklerle yaşayabilmesi ve kabullenmesi çok önemlidir.  Şimdi çevik sürece geçişin nasıl olması gerektiğini, yazının başında yer alan iki soruya doğrudan cevap vererek inceleyelim.

Çevik süreç adım adım mı yerleştirilmeli?

Çoğu takım çevik sürece adım adım geçmeyi tercih etmektedir.  Genelde takımın içinde bulunduğu ortam bu tür bir kararın verilmesini zorunlu kılmaktadır. Çevik sürece adım adım geçiş çogu zaman çok uzun sürebileceği için başarılı olmayacaktır. Buradaki başarısızlığın en önemli faktörü yine takım elemanlarının kendileridir. Takım elemanları sahip oldukları çalışma alışkanlıklarını bırakmakta çok zorlanacak ve dolaylı olarak istemeyerekte olsa yeni yerleştirilmeye çalışılan çevik süreci sabote edeceklerdir. Burada yeni çevik metotlar adapte edilerek, yazılımcı bir nevi soğuk suyun içine atılmalı ve yeni metotlarla yüzmeyi yani çalışmayı ögrenmesi sağlanmalıdır. Ancak bu şekilde sahış, değişikligi şok terapisi ile kabullenme eğiliminde olacaktır. Bu eski kuramların ve çalışma metotlarının tekneden atılmasını kolaylaştırır.

Çevik sürece hemen ve tüm neticelerine katlanarak mı geçilmeli?

Bu sorunun cevabı nettir: evet! Tamamen çevik bir yazılım modeline geçmek istiyorsanız, o zaman şimdiye kadar yaptıklarınızı unutmanız gerekiyor. Bu, şimdiye kadar çevik çalışmadığınız anlamına gelmez. Ama doğal olarak her çalışma ekibinin kendine has yöntemleri var ve bunları değiştirmeleri çok zor. Bu yüzden bir celsede çevik sürece geçip, uygulamaya başlanması gerekiyor, aksi taktirde çevik süreç işlemeyecektir.

XP nin temel prensiplerinden birisi de cesaret. Ekibin ve firmanın yeni bir başlangıç için tüm gücünü kullanıp, tam anlamıyla çevik sürece geçmesi lazım, yarı gönülle bu iş ne yazık ki yürümez!

Kısaca özetleyecek olursak:

1. Çevik sürece geciş hemen olmalı. TDD, CI, PP gibi teknikler hemen öğrenilmeli, zamana bırakılmamalı.
2. Sadece Scrum ile çevik olunması imkansız.  Scrum’ın yanında XP ya da FDD gibi teknik metotlar içeren bir çevik sürecin kullanılması gerekli. Gerekli teknik araçlar olmadan bir ev inşa etmeniz imkansız!

Kitabın ana konusu çevik süreç olan Extreme Programming’in uygulanış tarzını tanıtmaktır. Kitabın ilk bölümlerinde Extreme Programming hakkında teorik bilgiler yer almaktadır. Extreme Programming yöntemlerini uygulayabilmek için bu temel teorik bilgilerin alınmasında fayda vardır. Kitap 18 bölüm ve 504 sayfadan oluşmaktadır. Bu bölümlerin içerikleri özetle şöyledir:

Bölüm 1:
Birinci bölümde şelale (waterfall) tarzı yazılım yöntemleri ve projelerde oluşan sorunlar yer almaktadır. Bu sorunları gidermek için çevik süreçlerin kullanımı tavsiye edilmektedir. Extreme Programming (XP) bir çevik süreç olarak projelerde oluşan sorunlara cevap verebilecek yazılım metotlarına sahiptir. Bu bölümde Extreme Programming’in sahip olduğu değerler, prensipler ve teknikler tanıtılmaktadır.

Bölüm 2:
XP projelerinde sürüm ve iterasyon planları oluşturularak, projenin gidişatı belirlenir. Planlama oyunu olarak isimlendirilen süreçte müşteri tarafından, programcıların implemente (yazılım) edeceği özellikler seçilir. Programcılar gerekli tahminleri yaparak, müşterinin implementasyon için gerekli süre hakkında fikir sahibi olmasını sağlarlar. Bu bölümde sürüm ve iterasyon planlarının nasıl oluşturulduğu incelenmektedir.

Bölüm 3:
XP iletişime dayalı bir süreçtir. Ekip çalışanları arasında iletişimi güçlendirmek için günlük Stand-up (ayakta) toplantılar düzenlenir. Bunun yanısıra belirli aralıklarla retrospective (geriye bakış) toplantılarda projeye geri bakış sağlanarak, oluşan hatalar üzerinde tartışılır ve çözüm aranır.

XP projelerinde programcılar pair programming metoduyla eşli çalışırlar. Bu programcıların kısa sürede teknik alanda aynı seviyeye gelmelerini kolaylaştırır. XP projelerinde çalışma ortamının iletişimin önemi göz önünde bulundurularak oluşturulması gerekmektedir. Üçüncü bölümde Stand-up ve retrospective toplantılar yanı sıra, pair programming ve çalışma ortamının oluşturulması konuları tematize edilir. Bunun yanı sıra proje hakkında bilgilerin paylaşıldığı Wiki sistemleri hakkında bilgi verilir. Trac ve Bugzilla gibi araçlar kullanılarak bilgi ve hata yönetimi sağlanır.

Bölüm 4:
Bu bölümde XP projelerinde çalışma ortamlarının nasıl yapılandırıldığı ve ne tür araçlardan faydalanıldığı incelenmektedir.

Bölüm 5:
Teorik bilgilerin ardından, XP’nin nasıl uygulandığını göstermek amacıyla beşinci bölümde örnek bir XP projesi yer almaktadır. Bu bölümde müşteri gereksinimlerinin nasıl tespit edildiği ve sürüm ve iterasyon planlarının nasıl oluşturulduğu bir örnek üzerinde gösterilmektedir.

Bölüm 6:
Proje öncesinde sıfırıncı iterasyonda programcılar ihtiyaç duydukları teknik ortamı oluşturmaya başlarlar. Altıncı bölümde Eclipse, Ant, Tomcat, Subclipse, JUnit, HSQL, DBUnit gibi araçların kullanımı ve kurulumu incelenmektedir.

Bölüm 7:
Yazılım sürecinde uygulanması gereken tasarım prensipleri bu bölümün ana konusudur. Esnek bağ, açık kapalı prensibi, tek sorumluluk prensibi, Liskov yerine geçme prensibi, bağımlılıkların tersine çevrilmesi prensibi, arayüz ayırma prensibi ve paket tasarım prensipleri detaylı ve örnekli olarak bu bölümde incelenmektedir.

Bölüm 8:
Unit testleri oluşturularak sistem komponentleri yazılım esnasında test edilir. Akseptans testleri, entegrasyon testleri, regresyon testleri, performans testleri gibi değişik türde testler oluşturmak mümkündür.

Java projelerinde JUnit test frameworkü kullanılarak testler oluşturulur. Sekizinci bölümde JUnit kullanılarak unit testlerin nasıl oluşturulduğu uygulamalı olarak gösterilmektedir.

Bölüm 9:
XP projelerinde yazılım test güdümlü (Test Driven Development – TDD) yapılır. Dokuzucu bölümde TDD sürecinin nasıl çalıştığı ve programcıların TDD yöntemleriyle implementasyonu nasıl ilerlettikleri yer almaktadır.

Bölüm 10:
Onuncu bölümde pratik uygulamalı olarak shop sisteminin login modülü implemente edilmektedir. İmplementasyon için akseptans testlerinden yola çıkılarak, bilgibankasına kadar uzanan yapının adım adım TDD kullanılarak nasıl implemente edildiği gösterilmektedir. Bu bölümde sistem komponentlerini simule etmek için mock sınıfların kullanımı yer almaktadır.

Bölüm 11:
İmplementasyonun çalışır durumda olduğunu kanıtlamak için akseptans testleri oluşturulur. Bu testler kullanıcı hikayeleri gibi müşteri tarafından tanımlanır ve programcılar tarafından implemente edilir. On birinci bölümüde akseptans testlerinin hangi teknik ve araçlar kullanılarak implemente edildiği konusu incelenmektedir.

Bölüm 12:
On ikinci bölümün konusu Spring’dir. Spring frameworkü ile tasarımı ve teknik altyapısı güçlü, bakımı kolay ve kolay genişletilebilir programlar oluşturmak mümkündür. Spring sunduğu alt yapı hizmetleriyle programcıların hayatını kolaylaştırır ve programın test edilebilirligini yükseltir.

Bölüm 13:
Web aplikasyonlarının implementasyonu için Spring MVC frameworkü kullanılabilir. Bu bölümde Spring MVC’nin nasıl konfigüre edildiği incelenmektedir.

Bölüm 14:
Sürekli entegrasyon (continous integration) XP projelerinde uygulanan bir tekniktir. Programcılar tarafından kod üzerinde değişiklik yapılmasıyla beraber, mevcut kod derlenerek, sistem testleri çalıştırılır. Bu işlem sonunda kod üzerinde kırılmalar oluşmuşsa, programcıların konu hakkında email aracılığıyla dikkati çekilir ve hatanın bir an önce giderilmesi talep edilir. Sürekli entegrasyon ile her zaman çalışır bir sistemin olması sağlanır. On dürdüncü bölümde sürekli entegrasyon konusu incelenmektedir.

Bölüm 15:
İmplemenatasyonun hangi yöne gittiğini tespit edebilmek için yazılım metrikleri kullanılır. Bunlar sistemin belirli özelliklerinin ölçülmesi sonucu ortaya çıkan değerlerdir. On beşinci bölümüde sistem metriklerinin nasıl ve hangi araçlar kullanılarak ölçüldüğü gösterilmektedir.

Bölüm 16:
Kod paylaşımını kolaylaştırmak için versiyon kontrol sistemleri kullanılır. On altıncı bölümde açık kaynaklı olan Subversion versiyon kontrol sisteminin kullanımı açıklanmaktadır.

Bölüm 17:
Projenin gidişatını kontrol edebilmek için proje takip planları oluşturulur. Bu planlarda Burndown grafikleri kullanılarak görsellik sağlanır. Enformasyon radyatörü olarak tanımlanan metot ve yöntemler kullanılarak proje ekibinin ve diğer şahışların projenin gidişatı hakkında bilgi sahibi olması sağlanır. On yedinci bölümde sürüm ve iterasyon takibi konuları tematize edilmektedir.

Bölüm 18:
Son bölümde XP hakkında soru ve cevapları yer almaktadır.

Kitapta yer alan kodları http://www.kurumsaljava.com/workspace/xp/extreme_programming_kodlari.zip adresinden temin edebilirsiniz.
 

Yazar: Özcan Acar
Yayınevi: Pusula
Sayfa adedi: 504.
Online satış: http://www.Kitapyum.com

Ben de seminerlerimde kullanmak üzere bu poker kartlarını sipariş verdim.

• proje planının ne olduğunu,
• sürüm ve iterasyon planlamasının nasıl yapıldığını,
• sürüm ve iterasyon planlarının online ve offline ortamlarda nasıl tutulduğunu

yakından inceleyeceğiz.

Planlama pokeri oynayan programcılar

Bu yazıyı PDF olarak edinebilirsiniz.

Konuyla İlgili Kitaplar

Günümüze kadar uzanan süreçte yazılım sektöründe yapılan projeler nereye varacağı belli bile olmayan büyük maceralar haline gelmiştir. Bunun başlıca sebebi kullanılan yazılım yöntemlerinin gereksinimlere cevap verecek yapıda olmamasıdır. Çevik süreçler bu sorunu çözecek nitelikte.

Bu bölümde

• yazılım yaparken hedefin ne olduğunu,
• çevikliğin ve çevik sürecin ne olduğunu,
• çevik manifesto ve prensiplerinin ne anlama geldiğini,
• çevik sürecin diğer yazılım metotlarına kıyasla hangi farklılıkları beraberinde getirdiğini,
• hangi çevik süreç türlerinin mevcut olduğunu,
• bir çevik süreç olan Extreme Programming’in ne olduğunu,
• Extreme Programming’in hangi değer, prensip ve teknikler üzerine kurulu olduğunu

yakından inceleyeceğiz.

Bu yazıyı PDF olarak edinebilirsiniz.

Konuyla İlgili Kitaplar

Konuyla İlgili Kitaplar