Link: http://www.agilementor.com

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

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

• 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

Konuyla İlgili Kitaplar

XP ile oluşturulan çevik süreçte müşteri ve gereksinimleri merkezi bir rol oynamaktadır. Yazılım esnasında XP ile tam belirli olmayan ve çabuk değişikliğe uğrayan müşteri gereksinimlerine ayak uydurulabilir. Bu konvensiyonel yazılım metodlarda mümkün değildir, çünkü proje öncesi müşteri gereksinimleri en son detayına kadar kağıda dokülmüştür. Oluşan bir dokumentasyon baz alınarak, yazılım gerçekleştirilir. Proje ilerledikçe müşteri tarafından yapılması istenen değişikliklerin maliyeti çok yüksek olacaktır, çünkü mevcut yapı (tasarım – design) istenilen değişiklerin yapılmasını engelleyebilir yada yeni bir yapılanmaya gidilmesi gerekebilir. XP, kullanıldığı projelerde formalite ve bürokrasinin mümkün en az seviyeye çekilmesine önem verir. Çevik olabilmek için az yükle yola çıkılması gerekmektedir. Bu yüzden proje öncesi geniş çapta tasarım ve dokumentasyon oluşturulmasi izin verilmez. Bu kesinlikle dokümentasyon ve tasarım oluşturulmadan çalışıldığı anlamına gelmez!

XP Değerleri

XP dört değer üzerine kuruludur: Basitlik (Simplicity), İletişim (Communication), Geridönüm (Feedback) ve Cesaret (Courage).

XP’nin özü bu dört değer içinde yatmaktadır. Bu değerler yaşandığı taktirde XP ögrenimi ve kullanımı kolaylaşır. Bu değerlerin geçerlilik bulmadığı ortamlarda XP’nin uygulandığı söylenemez. XP ile verimli bir çevik süreç oluşturabilmek için bu değerlerin hepsinin kabul görmesi ve uygulanması gerekmektedir.

Bu değerlerin ne anlama geldiğini yakından inceliyelim. XP basit yöntemler aracılığıyla sonuca ulaşmak ister, çünkü sadece bu şekilde hızlı ve düşük maliyetli projeler gerçekleştirilebilir. Bunun yanısıra basit çözümlerle oluşturulan programın bakımı ve geliştirilmesi kolaydır. Basit çözümler kolay anlatılır ve adapte edilir. Bu zaman kazanılması anlamına gelmektedir.

Yazılımda en önemli konulardan birisi kalite kontrolüdür. XP projelerinde kalite kontrolü geridönüm (feedback) üzerinden sağlanır. Programcılar yazdıkları testlerden geridönüm alarak kaliteyi sağlarlar. Kısa zamanlarla yeni sürüm oluşturularak müşteri ve kullanıcılardan geridönüm aracılığıyla programın gereksinimleri tatmin edip, etmedigi kontrol edilir. Yazılım esnasında sürekli entegrasyon yapılarak, programın en son durumu hakkında geridönüm sağlanır. XP’nin uygulanabilmesi için değişik katmanlarda geridönüm mekanizmalarının oluşturulması gerekmektedir. İnsanlar için su ne ise, XP için geridönüm odur.

Tüm proje çalışanlarının sürekli olarak aralarında iletişim kurmaları gerekmektedir. Bireyler arası yüz yüze görüşmeler büyük önem teşkil etmektedir. Sadece bu sayede sağlıklı bilgi transferi gerçekleşebilir. Böylece yanlış anlaşılmalar ve bilinmeyenler ortadan kaldırılır. Eğer takım içinde iletişim ve interaksiyon güçlü ise, dokümentasyon oluşturma ve kullanma gereksiz hale gelebilir. Bu zaman kaybını önler. Dokümentasyon yazılımı ve kullanımı başka sebeplerden dolayı gerekli olabilir, ama projenin başarısı için dokümentasyon öncelikli rol oynamamaktadır.

Basit çözümler, geridönüm ve iletişim için cesaret gereklidir. Bu saydığımız değerler bireyler arası interaksiyonu ve iletişimi artıracağı için, bireylerin kendi iç dünyalarını terk edip, takımın bir parçası olmalarını kolaylaştırırlar. Bu kişisel gelişmeyi sağlar ve temelinde kişisel cesaret yatar.

XP Prensipleri

XP değerlerinden yola çıkarak onbeş XP prensibi oluşturulmuştur. Bunlar:

Rapid Feedback

Hızlı geridönüm

Sık ve hızlı geridönüm edinmek, projenin gidişatını olumlu etkiler. Geridönüm sayesinde yanlış anlaşılmalar ve hatalar ortadan kaldırılır.

Assume Simplicity

Basitliği tercih etmek

Basit çözümler kolay implemente edilir ve kısa zamanda oluşturulur. Bu geridönümün de hızlı bir şekilde gerçekleşmesini sağlar. Basit çözümlerin kavranması ve anlatılması daha kolaydır. XP programcılardan o anki gereksinimi tatmin etmek için basit çözümü bekler. Programcı gelecekte oluşabilecek eklemeleri ve değişiklikleri düşünmemeli, sadece ve sadece kendisinden o an için bekleneni en basit haliyle implement etmelidir.

Incremental Change

İnkrementel değişiklik

Basit çözümler uygulasak bile, yazılım sistemleri zaman içinde karmaşık bir yapıya dönüşebilir. Yapılan en ufak bir değişiklik bile, sistemin düşünmediğimiz bir bölümü üzerinde hata oluşmasına sebep verebilir. Oluşabilecek bu hataları kontrol altında tutabilmek için değişikliklerin ufak çapta olması gerekmektedir. Büyük değişiklikler beraberinde büyük sorunları getirebilir. Bu sebepten dolayı değişikliklerin ufak çapta ve sıklıkla yapılması gerekmektedir.

Embracing Change

Değişimi istemek

İlerliyebilmek için kendimize bir yön tayin etmemiz ve yeniliklere açık olmamız gerekiyor. Yeniliklere açık olmak cesaret gerektirir. Bilinmeyenle ugraşmak, rahatsız edici olabilir, ama başarıyı elde edebilmek için değişimi istemek gerekir.

Quality Work

Kaliteli iş

XP projelerinde kaliteli işin ortaya konabileceği bir ortamın oluşturulması geremektedir. Hiçbir programcı hatalı program yazmak istemez. Çalışma ortamınında etkisiyle yüksek kalitede yazılım yapmak  hem programcının özgüvenini artırır, hemde müşteriyi tatmin edici ürünlerin ortaya konmasını sağlar.

Teach Learning

Öğrenmeyi öğret

XP programcı takımlarında tertipcilik ve kıdem farkı yoktur. Tecrübeli programcılar bilgilerini daha az tecrübeli programcılarla paylaşarak, hem bilginin çoğalmasını sağlarlar, hemde takım arkadaşları ile teknik olarak aynı seviyeye gelirler. Programcılara komutlar vererek iş yaptırmak yerine, kendiliğinden bazı şeyleri öğrenerek, görevlerini yerine getirmeleri sağlanmalıdır.

Small Initial Investment

Az baslangıç yatırımı

XP en modern ve pahalı araç gereçlerle projeye başlanmasını beklemez. Başlangıç giderleri ne kadar düşük tutulabilirse, projenin iptali durumunda kayıplar o oranda az olacaktır. Başlangıçta tüm takımın dar bir finansman korsasını giymesi sağlanarak, proje için daha önemli görevlere odaklanmaları sağlanır. Bunu bir örnekle açıklıyabiliriz. Proje başlangıcında en son Oracle bilgibankası ve kullanıcı araçları (Toad gibi bir client program) satın alınarak, tüm ekibe bu bilgibankasını ve araçları nasıl kullanacaklarına dair seminer verilebilir. Bu çok masraflı ve bir o kadarda gereksiz bir şeydir. Projeye open source ve ücretsiz olan HSQL yada PostgreSQL bilgibankası ile başlanabilir. Programcı ekip böylece ne bir hafta tanımadıkları bir ürün için harcamış olurlar, ne de büyük masraflar yapılarak şu an için gerek olmayan bir altyapı komponenti satın alınmış olur. Gerekli araçlar zamanı geldiğinde edinilmelidir.

Play to win

Kazanmak için oyna

XP takımları kazanmak için oynar. Her zaman gözlerinin önünde nihayi sonuç vardır: programı tamamlamak ve müşteriye teslim etmek. XP programcı takıma tünelin sonundaki ışığı görmek için gerekli tüm imkanları sunar.

Concrete Experiments

Somut denemeler

Verdiğimiz kararların sonuçlarını kontrol edebilmek için denemeler yaparız, çünkü alınan kararlar her zaman doğru olmayabilir. Bir kontrol mekanizmasına ihtiyacımız  olduğu belli. Bu da somut denemeler aracılığıyla nerede olduğumuzu testpit etmekdir. Bu somut denemeler yazılım sistemleri içinde geçerlidir. Örneğin testler hazırlıyarak, oluşturuduğumuz mimari ve tasarımı kontrol ederiz.

Open, honest Communication

Açık ve samimi komunikasyon

Projenin başarılı olabilmesi için bireyler arasında açık ve samimi türde bir komuniksyonun olması gerekmektedir. Birçok projede bu böyle değildir. Çogu zaman bireylerin korkuları, deneyimsiz olmaları yada kendilerini çok beğenmeleri ve diğerlerini kendilerinden alt safhada görmeleri, açık ve samimi bir komunikasyon ortamının oluşmasını engeller.

Work with people’s instincs, not against them

Takımın içgüdülerini kullan, onlara karşı koyma

Bireysel içgüdü yanısıra, bireylerin oluşturdugu takımların da içgüdüsü vardır. Eger takım birşeylerin doğru gitmediği hissine sahipse ve bunu dile getiriyorsa, o zaman birşeyler yolunda gitmiyor demektir. Takımın içgüdüsüne kulak verilmelidir. Bunun göz ardı edilmesi, proje için olumsuz sonuçlar doğurabilir.

Accepted Responsibility

Sorumluluk üstlenmek

Sorumluluk birilerine verilmemeli, bireyler kendileri sorumluluk üstlenmeliler. Eğer bir bireye ya da bir takıma yapılması zor bir projenin sorumluluğu yüklenirse, bu birey ya da takım için motivasyonun düşmesini ve kaybetme korkusunun pekişmesini hızlandırır. Eğer bireyler ya da takımlar kendi sorumluluklarını kendileri seçerlerse, hem yaptıkları işte kendilerini iyi hissederler, hem de yüksek motivasyon ile üstlendikleri işi başarıyla tamamlarlar.

Local Adaptations

Sürecin ortam şartlarına adapte edilmesi

Büyük bir ihtimalle her takımın XP’yi Kent Beck’in anlattiğı tarzda harfiyen ugulaması mümkün değildir. Atalarımızında dediği gibi her yiğidin yogurt yeyiş tarzı başkadır. Amaç XP’yi harfiyen uygulamak değildir, amaç kısa bir zamanda projeyi başarılı bir sonuca ulaştırmaktır. Eğer proje XP’de yapılacak modifikasyonlarla başarıya ulaşacaksa, o zaman süreç üzerinde bu modifikasyonlar yapılmalı ve uygulanmalıdır. Bunda bir sakınca yoktur.

Travel light

Az yükle yolculuk yapmak

Projede hızlı ilerleyebilmek için fazla bir yükle yola çıkılmaması gerekmektedir. Beraber çalışmayı kolaylaştırmak için kullanımı kolay araç ve gereçler seçilmelidir. Formalitelerden uzak durulmalıdır.

Honest Measurement

Doğru ölçüm

Proje gidişatını kontrol edebilmek için değişik türde ölçümlerin yapılması gerekmektedir. Örneğin hazırlanan unit testleri ile sınıfların işlevleri kontrol edilir. Yapılan ölçümler doğru ve samimi yapıldıği taktirde kontrol mekanizması olarak kullanılan ölçümlerin bir anlamı vardır. Programcılar tarafından samimi ve doğru yapılmayan ölçümler projenin gidişatını olumsuz yönde etkiler.

XP Teknikleri (XP Practices)

Dört XP değer ve onbeş XP prensibi ondört XP tekniği ile desteklenmektedir. XP teknikleri programcıların XP değer ve prensiplerini uygulamada yardımcı olur. Kent Beck tarafından hazırlanan ilk XP versiyonunda oniki teknik yeralmaktaydı. Diğer çevik süreçlerin de etkisiyle Standup-Meeting’ler ve retrospektif toplantılar XP teknikleri arasına katıldı.

Bunlar:

On-site Customer

Programcıya yakın müşteri olarak tercüme edilebilir.

XP projeleri müşteri gereksinimlerine odaklı ilerler. Bu yüzden müşteri ve sistem kullanıcılarının projeye dahil edilmeleri gerekmektedir. Müşteri gereksinimlerini ekibe bildirir. Programacıların implementasyonu gerçekleştirebilmesi için müşteri tarafından dile getirilen gereksinimleri anlamaları gerekmektedir. Yanlış anlaşılmaları ve hataları gidermek için programcıların müşteri ve sistem kullanıcıları ile diyalog halinde olabilmesi gerekmektedir. Bu sebepten dolayı müşteri veya sistem kullanıcılarının programcıların erişebileceği bir uzaklıkta olmaları gerekir. Tipik XP projelerinde müşteri ve programcılar aynı odada beraber çalışırlar. Müşteri ekibin sorularını zaman kaybı olmadan cevaplar ve projenin ilerlemesine katkıda bulunur.

Standup-Meeting

Ayakta toplantı

Proje çalışanlari her gün 15 dakikayı aşmayan ve ayakta yapılan toplantılarda biraraya gelirler. Bu toplantının amacı, projenin gidişatı hakkında bilgi alışverişinde bulunmaktır.

Planning Game

Planlama oyunu

XP projeleri iteratif ve inkrementel yol alır. Bir sonraki iterasyonda yapılması gereken işleri planlama oyununda görüşülür ve sürüm ve iterasyonun içeriği tespit edilir. Planlama oyununa müşteri, kullanıcılar ve programcılar  katılır. Müşteri ve kullanıcılar daha önce kullanıcı hikayesine (user story) dönüştürdükleri isteklerine öncelik sırası verirler. Programcılar her kullanıcı hikayesi için gerekli zamanı tahmin ederler. Kullanıcı hikayelerinin öncelik sırası bu tahmine bağımlı olarak değişebilir. Planlama oyunlarında sürüm ve iterasyon planları oluşur.

Short Releases

Kısa aralıklarla yeni sürüm

XP projelerinde yeni implemente edilen ve değişikliğe uğrayan komponentler yeni sürümler oluşturularak müşteri ve kullanıcının beğenisine sunulur. Bu sayede hem müşteriler çalışır durumda olan programdan faydalanabilir hem de yeni sürümü inceliyerek, gereksinimleri ile örtüşüp, örtüşmediğini kontrol edebilirler. Eğer yeni sürüm müşteriyi tatmin edecek durumda değilse, gereksinimler değişikliğe ugrayabilir. Bu değişiklikler bir sonraki iterasyonda göz önünde bulundurularak, müşteri istekleri ile yüksek derecede örtüşen bir programın oluşturulması sağlanır.

Retrospective

Geriye  bakış

Proje çalışanları düzenli aralıklarla geriye bakarak, meydana gelen sorunları gözden geçirirler. Buradaki amaç gelecekte bu sorunların tekrarını önlemektir. Geriye bakış bir ila altıaylık zaman birimleri için tüm proje çalışanları yada seçilen bireyler tarafından yapılır. Geriye bakış toplantıları yarım gün ila üç gün arasında sürebilir.

Metaphor

Mecaz

XP projelerinde hazırlanan program için bir veya birden fazla, programın nasıl bir işlevi olacağını ekibin gözünde canlandırmalarını saglıyacak mecazi isim, öğe yada resimler kullanılır. Bunlar proje çalışanlarının ortak bir payda da buluşarak, ne yapılması gerektiği hakkında bir fikir sahibi olmalarını kolaylaştırır. Örneğin bir shop sistemi yazılımı yapılacak. Burada metaphor olarak alışveriş sepeti kullanılabilir. Alışveriş sepetini duyan her programcının aklında, bir shop sisteminin programlanması gerektiği fikri doğar.

Collective Ownership

Ortak sorumluluk

XP projelerinde programcılar ortak sorumluluk taşırlar. Bu her kod parçasının herhangi bir programcı tarafından gerekli durumlarla değiştirilebileceği anlamına gelir. Böylece yapılması gereken işler aksamaz, çünkü belli kod bölümlerinden belli programcılar sorunlu değildir. Aksine her programcı programın her bölümü üzerinde çalışma hakkına sahiptir. Bir programcının işe gelmemesi durumunda, başka bir programcı kolaylıkla onun görevlerini üstlenebilir.

Continuous Integration

Sürekli entegrasyon

Sistem değişiklikleri ve yeni komponentler hemen sisteme entegre edilerek test edilir. Sürekli entegrasyon sayesinde yapılan tüm değişiklikler her programcının sistem üzerinde yapılan değişiklikleri görmesini sağlar. Ayrıca sistem entegrasyonu için gerekli zaman azaltılır, çünkü oluşabilecek hatalar erken teşhis edilerek, ortadan kaldırılır.

Coding Standards

Kod standartları

Programcılar tarafından aynı kalitede kod yazılımı yapılabilmesi için, kod yazarken kullanılacak kuralların oluşturulması gerekmektedir. Kodun nasıl formatlanacağı, sınıfların, metot isimlerinin ve değişkenlerin nasıl isimlendirileceği kod standartlarında yeralir.

Sustainable Pace

Kalıcı tempo

XP projelerinde programcılar haftalık belirli mesai saatlerini aşmazlar. Gereğinden fazla çalıştırılan ve yorulan bir programcıdan verimli iş yapması beklenemez. Programcıların motivasyonun ve çalışma enerjilerinin yüksek olması için günde sekiz saatten fazla çalışmalarına izin verilmemelidir. Bazen fazla mesai saatlerine ihtiyaç olabilir. Eğer durum devamlı böyle ise, bu proje gidişatında bazı olumsuzlukların göstergesi olabilir.

Testing

Test etmek

Oluşturulan programların kalite kontrolünden geçmesi gerekmektedir. Bu yazılım esnasında oluşturulan testlerle yapılır. Programcılar komponentler için unit testleri hazırlar. Sınıf bazında yapılan bu testlerle komponentlerin işlevleri kontrol edilir. Müşteri gereksinimlerini test etmek için akseptans testleri hazırlanır. Komponentlerin entegrasyonunu test etmek için entegrasyon testleri hazırlanır.

Simple Design

Sade tasarım

Programcılar üstlendikleri görevleri (task) en basit haliyle implemente ederler. Bu programın basit bir yapıda kalmasını ve ilerde değiştirilebilir ve genişletilebilir olmasını sağlar. Sade bir tasarım yazılım sisteminin kompleks bir yapıda olmasını önler. Bunun yanısıra basit tasarımlar daha kolay ve daha hızlı implemente edilebilir. Basit bir implementasyonu anlamak ve anlatmak daha kolaydır.

Refactoring

Yeniden yapılandırma

Tasarım hataları yazılım sisteminin daha ilerde tamir edilemiyecek bir hale dönüşmesine sebep verebilir. Bu yüzden bu hatalar hemen giderilir. Bu yeniden yapılandırma işlemine refactoring ismi verilir. Hazırlanan unit testleri ile yapılan değişikliklerin yan etkileri kontrol edilir. Bu açıdan bakıldığında unit testi olmayan bir sistem üzerinde yeniden yapılandırma işlemi hemen hemen mümkün değildir, çünkü değişikliklerin doğurduğu yan etkileri tespit etme mekanizması bulunmamaktadır.

Pair Programming

Eşli programlama

XP projelerinde iki programcı aynı bilgisayarda çalışır. Bu sayede programcıların kısa bir zaman içinde aynı seviyeye gelmesi sağlanır. Ayrıca bu kalitenin yükselmesini sağlar.

XP Rolleri

Bir çevik projede ekip çalışanlarının sorumluluk alanlarını tanımlamak için roller tayin edilir. Her rol beraberinde bazı sorumluluklar ve tanımlanmış haklar getirir. Bu roller statik değildir. Ekip içinde değişik kişilere değişik roller verilebilir ve daha sonra rol değişikliği yapılabilir. Proje gereksinimleri doğrultusunda yeni rollerin oluşturulması mümkündür.

Müşteri (Customer)

Projenin var olma sebebi müşteridir. Müşteri ihtiyaç duyduğu ve gereksimlerine cevap verebilecek bir yazılım sistemi için yatırım yapan kişidir. XP projelerinde şu atasözümüz geçerlidir: “parayı veren düdüğü çalar!”.

Proje bünyesinde ne programlanması gerektiğini müşteri tayin eder. Müşteri yapılması gerekenleri kullanıcı hikayeleri (user story) oluşturarak ifade eder. Programcılar müşteriye bu süreçte yardımcı olurlar. Ama kullanıcı hikayelerinin oluşturulma sorumluluğu büyük ölçüde müştiriye aittir. Her kullanıcı hikayesi yazılım sisteminin bir özelliğini tanımlar. Programcıların implementasyonu gerçekleltirebilmeleri için kullanıcı hikayesini anlayabilmeleri gerekmekedir. Sadece bu durumda implementasyon süreci için bir tahminde bulunabilirler. Ayrıca oluşturulan kullanıcı hikayelerinin test edilebilir yapıda olması gerekmektedir.

Müşteri çalışma alanı (domain knowledge) hakkında bilgiye sahip olan kişidir. Programcılar müşteriye karşılaştıkları sorunları çözmek için sorular sorabilirler. Bu soruların cevabını en iyi verebilecek şahıs müşteridir.

Hangi kullanıcı hikayelerinin implemente edileceğine müşteri karar verir. Bu konuda müşteriye herhangi bir sınırlama getirilmez. Müşteri seçer ve programcılar implemente eder.

İmplemente edilen kullanıcı hikayelerini kontrol etmek amacıyla müşteri akseptans testleri tanımlar. Bu testler programcı yada testçi tarafından implemente edilir. Akseptans testleri kullanıcı hikayesini doğru implemente edilip, edilmediğini kontrol edici bir mekanızmadır.

Programcı

Sistem analizi, tasarım, test ve implementasyon programcılar tarafından yapılır.

Müşteri tarafından hazırlanan kullanıcı hikayelerinin implementasyon süresi programcılar tarafından tahmin edilir. Bu programcıların XP projelerinde proje planlama sürecine dahil edildikleri anlamına gelmektedir. Geleneksel projelerde bu tahminleri teknik bilgiye sahip olmayan yöneticiler yapmak zorundadır. Bu yüzden bu tahminler genelde gerçekleri yansıtmaz.

Her programcı test güdümlü (TDD – Test Driven Development) ve bir takım arkadaşıyla beraber çalışır. Pair programming olarak bilinen, iki programcının birlikte yazılım yapması, kısa zamanda kod hakkındakı bilginin tüm programcılar tarafından paylaşılmasını kolaylaştırır. Ayrıca pair programming programcılar arasında iletişimi ve takım içinde çalışabilme özelliğini artırır. Test güdümlü çalışmak bakımı ve geliştirilmesi kolay kodun oluşmasını sağlar. XP projelerinde programcılar herhangi bir satır kod yazmadan önce gerekli test sınıflarını oluşturarak implementasyona başlarlar.

Programcılar oluşturdukları testler yardımıyla hergün bir veya birden fazla şekilde modül entegrasyonu gerçekleştirirler. Sürekli entegrasyon programcılar tarafından oluşturulan modülleri entegre eden bir süreçtir. Her programcı bu süreçten geridönüm sağlıyarak, kendi yaptıklarının ne derecede sisteme entegre olduğunu ölçebilir.

Proje Menajeri

Proje menajeri müşteri ve programcıları bir araya getirir. Onların beraber çalışabilecekleri ortamların oluşmasını sağlar. XP proje menajeri tek başına proje planlamasından sorumlu değildir. Programcılara görev atamaz, onların kendi başlarına seçim yaparak, sorumluluk almalarını kolaylaştırır. Toplantı ve diğer buluşmaları koordine eder, takımın karşılaştığı sorunları ortadan kaldırmak için gerekli olanları yapar.

Koç

Çevik süreci tanıyan ve nasıl uygulanması gerektiğini bilen experdir. Koçun görevi proje başlangıcında çevik takımı oluşturmak yada bir araya getirmek ve onlara belirli bir süre rehberlik yapmaktır. Koç projede sorun çıktığı zaman yada takım XP yöntemlerinin dışına çıktığında müdahale eder. Zaman zaman koç implementasyonda aktif olarak rol alır. Örneğin unit testlerin nasıl doğru bir yapıda oluşturulabileceğini diğer programcılara gösterebilir.

Testçi

Müşteri tarafından oluşturulan akseptans testlerini implemente eden programcıdır. Aynı zamanda JUnit ve entegrasyon testlerinin implementasyonunda takım arkadaşlarına yardımcı olur.

Haklar ve Sorumluluklar

Proje çalışanları çoğu zaman içgüdüsel korku hissedebilirler. Bunun en büyük sebebi belirsizliktir. Ne ve nasıl yapılması gerektiği bilinmediği taktirde ekip içinde huzursuzluk doğar. Bu projenin başarısını negatif etkiler.

Projenin başarılı olabilmesi için çalışanların hissettikleri korkunun aza indirilmesi yada yok edilmesi gerekmektedir. XP bu konuda proje çalışanlarına bir takım hakların tanınması gerektiğini dikte eder. Hangi rollerin hangi haklara sahip olduğunu yakından inceliyelim.

Müşteri Hakları

Müşterinin sahip olduğu haklar şu şekilde özetlenebilir:

• Müşteri bütçe ve zaman planlaması yapabilmek için neyin yapılabilir olduğunu ve hangi zaman biriminde yapılabileceğini bilme hakkına sahiptir.
• Müşteri fikir değiştirerek, gereksinimler üzerinde değişiklik yapma ve yeni gereksinimlerin implementasyonunu talep etme hakkına sahiptir.
• Müşteri programcılar tarafından sağlanabilecek en yüksek verimi ve değeri elde etme hakkına sahiptir.
• Müşteri projede somut ilerlemeyi görme hakkına sahiptir. Bu kısa aralıklarla oluşturulan yeni sürüm ve akseptans testlerine olumlu cevap veren yeni implementasyonlarla sağlanır.
• Müşteri  bir sonraki sürümde implemente edilecek kullanıcı hikayelerini seçme hakkıda sahiptir.

Programcı Hakları

Programcının sahip olduğu haklar şu şekilde özetlenebilir:

• Programcı takım arkadaşlarına soru sorma ve cevap alma hakkına sahiptir.
• Programcı kullanıcı hikayeleri için implementasyon zaman tahmini yapma hakkına sahiptir. Programcı tahminler üzerinde değişiklik yapma hakkında sahiptir.
• Programcı, kendisine görev verilmesi yerine sorumluluk alma hakkında sahiptir.
• Programcının herzaman yüksek kalitede iş çıkarma hakkı vardır.
• Programcının hangi öncelik sırasına göre neyi yapması gerektiğini bilme hakkı vardır.

Süreç İşleyişi

XP projelerinde projenin gidişatını genel olarak şu şekilde özetliyebiliriz:

• Müşteri gereksinimleri ihtiva eden kullanıcı hikayelerini oluşturur. Bunlara öncelik sırası atar. Programcılar her kullanıcı hikayesi için implementasyon zamanını tahmin ederler.
• Müşteri  programcılarla beraber iterasyon(1-2 hafta) ve sürüm (1-2 ay) planını hazırlar. Her sürüm birden fazla iterasyon ihtiva eder ve müşteri tarafından kullanılacak özellikte çalışır bir sistemdir.
• Müşteri ilk iterasyon (1 hafta) için gerekli kullanıcı hikayelerini tahminleride dikkate alarak seçer.
• Programcılar iterasyon için seçilen kullanıcı hikayelerini implemente ederler. Kafalarda oluşan sorular müşteriye danışılarak cevaplandırılır.
• İterasyon sonunda programcılar müşteriye çalışır bir sistem sunarlar. Müşteri sistemi değerlendirerek programcılara geridönüm sağlar.
• Edinilen tecrübeler ışığında bir sonraki iterasyon planlanır. Eğer müşteri yeni gereksinimlerin implemente edilmesini isterse, bunlar için tekrar kullanıcı hikayeleri oluşturulur ve tahminler yapılır. Eğer yeni kullanıcı hikayeleri yoksa, mevcut kullanıcı hikaye listesinden en yüksek öncelik sırasına sahip olanlar seçilir ve bir sonraki iterasyondan implemente edilir.
• İlk sürüm sonunda oluşan yazılım sistemi müşteri tarafından produktif olarak kullanıma alınır. Başka sürümler planlandıysa bir sonraki iterasyonla devam edilir.

XP Proje Safhaları

Bir XP projesi değişik safhalardan oluşur. Her sahfa, bünyesinde kendine has aktiviteler ihtiva eder. Bir sonraki resimde bir XP projesinde olması gereken safhalar yeralmaktadır.

XP projesi şu safhalardan oluşur:

• Keşif safhası (Exploration Phase): Projenin başlangıcında keşif safhasını oluşturan aktiviteler yeralır. Bu safhada müşteri kullanıcı hikayelerini (user story) oluşturur. Programcılar teknik altyapı için gerekli deney (spike) ve araştırmayı yaparlar.
• Planlama Safhası (Planning Phase): Keşif safhasını planlama safhası takip eder. Bu safhada müşteri programcılar yardımıyla iterasyon ve sürüm planlarını oluşturur. İterasyon planlaması için oluşturulan kullanıcı hikayelerinin implementasyon süresi programcılar tarafından tahmin edilir. Müşteri kullanıcı hikayelerine öncelik sırası vererek, iterasyonlarda hangi kullanıcı hikayelerinin öncelikli olarak implemente edilmeleri gerektiğini tespit eder. Programcılar tarafından herhangi bir kullanıcı hikayesinin implementasyon süresi tahmin edilemesse, programcılar spike solution olarak bilinen basit bir çözüm implemente ederek, kullanıcı hikayesinin gerçek implementasyonu için gerekli zamanı tahmin etmeye çalışırlar.
• İterasyon ve Sürüm Safhası (Iterations to Release Phase): Kullanıcı hikayelerinin implementasyonu iterasyon ve sürüm safhasında gerçekleşir. Bir iterasyon bünyesinde implemente edilmesi gereken kullanıcı hikayeleri müşteri tarafından belirlenir. İmplementasyonunun işlevini kontrol etmek için müşteri tarafından akseptans testleri belirlenir. Bu testler programcılar yada testçiler tarafından implemente edilir. Her iterasyon sonunda müşteriye, çalışır bir yazılım sistemi sunulur. Bu şekilde müşterinin sistem hakkındaki görüşleri alınır (geridönüm). İterasyon son bulduktan sonra çalışma hızını tahmin etmek için bir önceki iterasyonunda elde edilen tecrübeler kullanılır ve iterasyon planı bu değerler doğrultusunda gözden geçirilir. Bir önceki iterasyonda oluşan hatalar bir sonraki iterasyonda gözden geçirilmek ve giderilmek üzere planlanır.
• Bakım Safhası (Maintenance Phase): Bu programın bakımının ve geliştirilmesinin yapıldığı safhadır. Bu safhada kullanıcılar için egitim seminerleri hazırlanır ve küçük çapta eklemeler ve sistem hatalarının giderilmesi için  işlemler yapılır. Müşterinin istekleri doğrultusunda bir sonraki büyük sürüm için çalışmalara başlanır. Bu durumda tekrar keşif safhasına geri dönülmesi ve oradan işe başlanması gerekmektedir.

Bu yazıyı PDF olarak edinebilirsiniz.

http://www.kurumsaljava.com/workspace/xp/extreme_programming_kodlari.zip

adresinden edinebilirsiniz.

Özcan Acar
EOF ( End Of Fun )