Extreme programlama basitlik, komünikasyon, feedback ve cesaretlendirme değerleri üzerine kurulmuş bir yazılım geliştirme disiplinidir. Bu disiplinde bir takım çalışması sz konusudur . Takımın her bir üyesi ufak tefek işler yapar . Bu takıma yeterli bir feedback sağlanmasıyla da takım kendi çalışmasının nerede olduğunu grebilir ve hızlarını duruma uygun olarak ayarlayabilir. Tüm takımExtreme programlamada, projeye katkısı olan her birey takımın bir parçası sayılır. Takım "Müşteri" nin çevresindeki ve etkileşimde bulunduğu bireylerden oluşur. Müşteri takım ile birlikte günaşırı çalışır. Planlama, Küçük Release' ler, Müşteri TestleriExtreme programlama nelerin yapıldığı ve nelerin yapılacağı ile ilgili basit bir planlama ve takip sistemi kullanır. Temel işler üzerine odaklanılarak, takım, müşterinin tanımladığı tüm testlerden geçen tamamen sistemle entegre ufak release' ler ortaya koyar. Basit tasarım, Eşli programlama, Test-tabanlı geliştirme, Tasarım iyileştirmeExtreme programcıları bir grup halinde ya da ikişerli gruplar halinde çalışırlar. Basitten karmaşık tasarıma doğru zaman içinde testler yapılarak gidilir. İhtiyaçlara gre tasarım zaman geçtikçe iyileştirilir. Devamlı entagrasyon, Kollektif kod sahipliği, Kodlama standardı Extreme programlama sistemi entegre tutarak devamlı çalışmasını muhafaza eder. Programcılar tüm kodları çiftler halinde yazarlar, tüm işleri hep beraber yaparlar. Kodlama yaparken belli bir düzene uyarlar. Dolayısıyla takımın her bir üyesi her kodu anlama ve geliştirme olanağına sahiptir. Sağlam Hız, Ortak VizyonExtreme programlamada takım sistemin ileride neye benzeyeceği ile ilgili olarak genel bir grüş orataya koyar. Herkes belirsiz olarak korunan bir hızda çalışır. Temel KavramlarTüm takımXP projelerine katkısı olan herkes takımın birer üyesidir ve birlikte çalışırlar. Bu takımda bir iş temsilcisi--Müşteri olmalıdır. Bu iş temsilcisi namı diğer müşteri gereksinimleri otaya koyar, ncelikleri tanımlar ve projeyi ynetir. Müşteri olayı ne kadar iyi bilirse o kadar iyi olur. Takımda tabii ki programcılarda olacaktır. Bu takımda tester'lar olabilir. Bu testerlar müşteri ile geçilmesi veya aşılması gereken testleri belirler. Analistler müşteri' ye gereksinimleri belirlemek noktasında yardım ederler. Genel olarak takımda bir koç vardır. Bu koç projenin takibini yapar ve hangi işlerin yapılması gerektiğini ortaya koyar. Ayrıca bir ynetici olabilir. Bu ynetici kaynakları temin eder, irtibat kurulması gerekli işleri yapar, aktivitelerin koordinasyonunu gerçekleştiririr. Aslında bu işlerin hiç birisi bir kişinin tek başına yapması zorunlu işler değildir. XP takımında yer alan her kişi yapabildikleri lçüsünde birşeyler yapar. En iyi takımda uzman hiç yoktur, sadece zel yetenekleri olan kişiler vardır. Oyunu PlanlamaXP' de planlama, yazılım geliştirmede çok nemli iki unsur üzerine gre şekillenir. Bunlar nelerin hangi tarihle bitirileceğini tahmin etmek ve ondan sonra hangi işlerin yapılması gerektiğine karar vermektir. Planlamada nemli olan projenin plana bağlı olarak yürümesidir. Ancak bu planlamadaki herşey gerçeğe uymayabilir. Çünkü neye ihtiyacımız olacağı ve ne kadar zaman alabileceğini kestirmek gerçekten güçtür. XP' de planlama yaparken bu iki soruya cevap aranarak plan oluşturulur. Plan oluşturma, müşterinin isteklerini programcıya sunduğu ve programcıların da onların zorluk derecelerini belirlediği bir aktivitedir. Elde bulunan maliyet tahminleri ve geliştirilecek programın zelliklerinin nem dereceleri bilgileri ile, müşteri proje planını şekillendirir. İlk başta elde edilen planlar gerçekten çok etksizdirler. Çünkü işe gerçek manada başlayana kadar işlerin ncelikleri ve maliyetleri ile ilgili bilgiler tam olarak belli değildir. Ancak buna rağmen oluşturulan ilk plan bazı kararları vermek için yeterli sayılabilir. Bundan sonrada belirli peryotlarla da plan güncel tutulur. İteratif planlama, takımın her 2 haftada bir yeni bir şey üzerinde çalışması üzerine kurulu bir planlamadır. XP takımları iki haftalık peryotlarla programı build ederler. Sonuç olarak iki haftada bir yeni zellikler eklenmiş faydalı programlar elde edilir. İteratif planlamada müşteri her zaman bir sonraki 2 haftalık peryotta neler yapılması gerektiğini belirtir. Belirtilen bu isteklere gre programcılar grevleri ve alt grevleri oluştururlar ve onların maliyetlerini tahmin ederler. Bu son zellik Plan oluşturma' da sylenenlerden bir parça daha ayrıntılıdır. Bir nceki iterasyonda ne kadar bir başarı sağlanmış olduğuna bakılarak, takım hangi işlerin bu iterasyonda yapılması gerektiğine karar verir. Bu planlar çok basit olmalarına rağmen müşterilerin sağladıkları bilgiler ve projeyi mükemmel bir şekilde ynetmeleri ynüyle çok iyidirler. Her iki haftada bir yapılan işler herkes tarafından kolay grülebilir, anlaşılabilir durumdadır. XP' de "yüzde doksanı tamam" diye bir tabir yoktur. İstenen zellik ya yapılmıştır ya da yapılmamıştır. Meselelerin herkes tarafından grülebilmesi anlaşılması bazı paradokslara neden olur. Bir yanda, bu mesele iyi gerçekleştirilmiştir ve müşteri işin yeterli olmadığını bu yüzden anlayabilirse projeyi iptal edebilir. Bir yanda da iş herkes tarafından çok iyi anlaşılmıştır, bir sonraki zaman diliminde yani namı diğer 2 haftalık peryotta neler yapılacağı belirlidir. Bu yüzden de XP projeleri daha az stres ve baskı ile ihtiyaç duyulandan çok fazlasını sunabilecektir. Müşteri TestleriMüşteri istediği her zelliği belirtmekle aslında bir takım testleri de ortaya koymuş oluyor. Bu testlere müşteri kabul testleri adını verebiliriz. Çünkü müşteri programda olması gereken bir zelliği dile getiriyor bizler de bu zelliğin yerine gelip gelmediğini bunun testini gerçekleştirerek karar veriyoruz. Bu testler hem geliştiricileri hem de müşterilerin onayından geçiyor. Otomasyon içinde yaşadığımız zaman baskılı ortamda nemli bir meseledir. Bu yüzden manuel olarak test yapmaktansa bu şekilde işleri otomatikleştirerek test yapmak çok daha hızlı sonuç almamızı sağlar. Bu gece en karanlık noktasına ulaştığında ışıkları kapatmaya benzer. En iyi XP takımları testleri kendileri hazırladıkları gibi onların çalıştırılmasını da kendileri gerçekleştirir. Takım, test çalışmaya başlayınca sonuç alınıncaya kadar testin doğru çalıştırılmasından sorumludur. Küçük Release'ler XP takımları iki yolla küçük relese' ler elde eder. Birincisi, takım herbir iterasyonda müşteri tarafından seçilen değerlere ve zelliklere gre test edilmiş, çalışan release' ler oluşturur. Müşteri oluşturulan evaluation ya da son kullanıcılara ynelik bu yazılımı herhangi bir amaç için kullanabilir. Burada en nemli şey, yazılımın her iterasyon sonunda oluşturulan bu release' lerinin müşteri tarafından kolay anlaşılabilir olmasıdır. Müşterinin herhangi bir release ile ilgili olarak kafasında en ufak bir soru işareti bulunmamalıdır. Bu zellik her şeyin açık ve meselelerin kolay handle edilebilmesini sağlar. İkincisi, XP takımları, son kullanıcılara ellerinden geldiği kadar sık aralıklarla release oluştururlar. XP web projelerinin günlük bazda release' i oluşturulur, daha kapsamlı projelerde ise aylık ya da daha kısa aralıklarla release oluşturulabilir. Bunlardan daha küçük yapılı projelerde bile en azından üç ayda bir release oluşturulmalıdır. Yani projenin nem derecesi ve büyüklüğü arttıkça relese oluşturma sıklığı doğru orantılı bir şekilde artmaktadır. Ne kadar büyük proje o kadar çok release demek oluyor bir bakıma. İyi versiyonlar oluşturmak imkansız grülebilir. Ancak meseleye şu açıdan bakılırsa daha iyi bir yorum getirilebilir. XP takımlarındaki herkes aynı zaman diliminde bununla uğraşmaktadırlar. Yani XP takımında yer alan bir birey bir işi sadece kendi takımının uğraşmadığının bilinci içerisindedir. Dolaysıyla ümütsizliğe kapılmaz. Ayrıca bu şekilde her zaman versiyon oluşturulacağının da bilinci içerisindedir. Dolayısıyla bu versiyon belki ktü olabilir ama bundan sonraki versiyon "İnşallah" daha iyi olacaktır diyerek meseleye bakabilir. Bu konu hakkında daha detaylı bilgi için "Devamlı Entegrasyon" blümüne gzatabilirsiniz. Şunu unutmayın: Oluşturulan bu ufak versiyonlar ya da release' ler her zaman müşteri testlerinden geçtikleri için, XP takımı bu release' leri sürekli güvenilir olarak kabul edecektir. Basit TasarımXP takımları projeleri gerçekleştirirken basit tasarımlar kullanır. Basit bir tasarımla işe başlanır ve çeşitli programcı testlerinden ve tasarım geliştirmeden sonra da bu basit tasarım korunur. XP takımı tasarımı sadece ihiyaç duyulan zelliklere gre şekillendirir. Eğer daha sonra olması istenen bir zellik varsa onun tasarımı daha sonra yapılır. Hiçbir şekilde boşa atılmış bir adım yoktur. İhtiyaçlar neyse tasarımda o şekildedir. Yazılım her zaman bir sonraki yapılandırılma ya da versiyon değişimi için hazırdır. XP' de tasarım sadece bir kez yapılıp bir kşede saklanmaz. Yazılım geliştirildiği müddetçe tasarımda geliştirilir. Release planlama' da ve iteratif planlama' da tasarım adımları belirlenir. Ancak bu plana rağmen takım hızlı tasarım çalışmaları yapar ve tasarım gzden geçirmeleri ile ilgili toplantılar yapar. Extreme programlama gibi artımlı ve iteratif yazılım geliştirme metodolojilerinde iyi tasarım her zaman gereklidir. İşte bu nedenden dolayı XP' de tüm yazılım geliştirme sürecinde tasarım yapılır ya da daha doğrusu vardır. Eşli ProgramlamaXP' de tüm yazılım eşli gruplar halinde yapılır. Bu yaklaşım yazılan her kodun başka kodu yazan kişinin dışında başka birisi tarafından da kontrol edilmesini sağlar. Ve sonuç olarak daha iyi tasarım, daha iyi test etme ve daha iyi kod ortaya çıkar. İki kişinin, bir programcının yapması gereken bir işle uğraşması belki verimsiz gibi grünebilir ama bu doğru değildir. Aslında bu daha verimlidir. Bu konuda yapılan akademik çalışmalarda bir kodun iki kişi tarafından yazılmasının, bir kişi tarafından yazılmasından daha iyi sonuçlar ortaya çıkardığını gstermiştir. Gerçekten şu sz çok doğrudur: 2 düşünen baş bir düşünen baştan daha iyidir. Bazı programcılar hiç denemeden eşli programlamaya karşı çıkarlar. Aslında bu çalışmayı birkaç hafta denerlerse sonuçlarını greceklerdir. Eşli programlamayı ğrenen programcıların %90' ı bu şekilde çalışmayı terecih etmektedirler. Eşli programlama daha iyi kod yazımını sağladığı gibi takım içerisindeki iletişimi de geliştirir. Eşler arasında değiş-tokuş ta bir kişini diğer kişilerin bilgi birikiminden yararlanmasını sağlar. Programcılar yeni şeyler ğrenirler, yeteneklerini geliştirirler ve artık takım için değerli bir eleman olurlar. Eşli kod yazma herkes için büyük bir kazançtır. Test Tabanlı GeliştirmeExtreme programlamanın en büyük zelliklerinden birisi de feedback ' in iyi sağlanmasıdır. Ancak biliyoruz ki iyi feedback ancak iyi testlerle elde edilen bir sonuçtur. İyi XP takımları test tabanlı yaklaşımı seçerler. Bu yaklaşımda yeni testler kısa çalışmların ardından hazırlanır ve çalıştırılır. Hemen hemen kodun yüzde yüzüne yakın bir kısmı fazla efor sarfetmeden test edilir. Testleri yazmak yeterli değildir: Onları çalıştırmakta zorundasınız. İşte bu extreme programlamanın gerçekten extreme olduğunu gsteren bir uygulamadır. Bu programcı testleri ve birim testleri bir araya getirilerek, her bir yeni release oluşturulduğunda, programcıların oluşturduğu her bir testin çalıştırılması sağlanır. Tüm testlerin %100' ü gerçekleştirilir. Bu şu anlama gelir : programcıların yaptıkları iş ile ilgili tüm feedback' lerin anında alınması sağlanır. Ek olarak bu testlerin gerçekleştirilmesi tasarımın geliştirilmesine katkı sağlamaz. Tasarım GeliştirmeExtreme programlama gerçekleştirilen her bir iterasyonun iş açısından nemli bir değer taşımasını sağlar. Bunu gerçekleştirebilmek için ise yazılımın iyi tasarlanmış olması gerekir. Bunun alternatifi belki biraz daha yavaş ve sizi sonuca gtürmeyecek yapıda olabilir. Bundan dolayı da XP devamlı tasarım iyileştirmesi anlamına gelen ve Martin Fowler' ın "Refactoring: Improving the Design of Existing Code" adlı kitabında geçen "Refactoring" yapısını kullanır. Refactoring süreci kod tekrarlarını oratadan kaldırmayı, modül için bağlılığı güçlendirip, modüller arası bağlılığı zayıflatma üzerine odaklanır. Yüksek cohesion ve zayıf coupling son 30 yıldır iyi tasarımın gstergelerinden en nemlileri olarak kabul edilmektedir. Sonuç olarak, Xp takımları iyi ve basit bir tasarımla işe başlarlar ve her zaman tasarımın yazılım için basit ve iyi olmasını sağlarlar. Bu onların hızının istikrarlı olarak korunmasını sağlar, hatta ve hatta proje ilerledikçe hızın artışını bile sağlarlar. Refactoring, tabii ki, zaman ilerledikçe tasarım değiştikçe hiç bir şeyin sonradan bir zarara yol açmaması için, güçlü testlerle desteklenir. Müşteri testleri ve programcı testleri aşılması gereken en nemli testlerdir. XP çalışmaları her birisini destekler: onların ayrı ayrı incelenmesi, test edilmesi, birlikte test edilmesinden daha az etkilidir, bunu unutmamak gerekir. Yani müşteri testleri ile programcı testleri birlikte değerlendirilirse sinerji oluştururlar. Devamlı EntegrasyonExtreme programlama takımları sistemin her zaman bir bütün olmasını sağlar. Bu yüzden belki günde 1 kez gerçekleştirilen build' ler bile yetersiz olabilir. Gün içinde birkaç kez bunu yapmak gerekebilir. Şyle bir rnek verebiliriz : 40 kişilik bir XP takımı günde en az 8 ya da 10 kez build yapar. Bu şekilde çalışmayan proje geliştirmelerinde haftalarca sistem entegre edilememiştir. Sonra da hep beraber derler "haydi arkadaşlar build yapalım. Yeni bir versiyon çıkaralım". Sorunlarda bundan sonra başlar. Sistem build edilemez ve kimse nedenini de anlayamaz. İşte XP' deki bu çalışmanın en büyük yararlarından birisi de bu tarz sorunların yaşanmasını engellemektir. Seyrek aralıklarla yapılan entegrasyon=bütünleştirme çalışmaları yazılım projesi üzerinde çeşitli problemlere neden olurlar. Bunlardan ilki, kritik nem taşımasına rağmen bütünleştirme çalışması son ana kadar yapılmamıştır ve takım bu konuda hiç bir tecrübeye sahip olmadan ya da pratik yapmadan byle bir çalışmanın içine girmiştir. Bu işin son anda yapılabilme olasılığı gerçekten çok azdır. İkincisi, seyrek aralıklarla birleştirilen kodlar genellikle olduğunu syleyebilirim - daha fazla hata içerir. Problemler tasarım zamanında entegre olmayan sistemin test edilmemesinden dolayı bulunamaz ve sisteme sessizce yerleşirler. Üçüncüsü, zayıf entegrasyon süreci uzun süre "kod değişmemezliği"ne neden olur. Kod değişmemezliği kısaca şyle açıklanabilir. Uzun bir süre gerçekten uygulamanız açısından kritik neme haiz program zellikleri üzerinde çalıştınız ve bitirdiniz diyelim ama en sonunda bu zelliği sisteme entegre etmeniz ve diğer modüllerle birlikte uyum içinde çalıştırımasını sağlamanız gerekir. Bu da ek zaman gerektirir. Sonuç olarak, pazardaki ya da son kullanıcılarınızla olan konumunuz zayıflar. Kollektif Kod SahipliğiBir extreme programlama projesinde yer alan herhangi bir programcı herhangi birisinin yazdığı kodu her zaman geliştirebilir. Bu yazılan her kodun herkesin dikkatini çekmesini ve sonuç olarak daha kaliteli ve daha az hatalı kod üretilmesi anlamına gelir. Diğer bir nemli yarar : her kodun bir sahibi olduğunu düşünelim. Bu durumda kullanıcılardan birisi bir kod yazarken başka birisinin sorumluluğunda olan bir yerin yapılmasını bekleyebilir. Bu bekleme zamanı içerisinde de belki hiç birşey yapılmayabilir. İşte byle durumlarda XP' nin nerdiği yapı bize beklememeyi, istenen ya da gereksinim duyulan bir şey hazır değilse ve orası da senin sorumluluğunda değilse bile senin hazır olmayan yapıyla ilgili kod yazma serbestliğini verir. Byle olmasaydı, o kodu hazırmış gibi düşünüp kendi sorumluluk alanımıza ekleseydik, bu sefer de birden fazla aynı kodun kopyası olacaktı. Bakım zorlaşacaktı. Modül içi bağlılık az olacaktı. Bu tarz kod yazımında dikkat edilmesi gereken en nemli noktalardan birisi de anlamadığınız kod üzerinde değişiklikleri krü krüne yapmamanızdır. XP, bu problemin ortaya çıkmaması için iki teknik üzerinde odaklanır: Programcı testleri hataları yakalayabilir ve eşli programlama ' da tanıdık olmayan kodların biraz daha anlaşılmasını sağlar. Ek olarak sylemek gerekirse, ihiyaç duyulan değişiklikleri gerçekleştirmenin iyi olup olmayacağını sağlamak için bu pratik çalışma şekli takım arasında iyici benimsenmelidir. Kodlama StandardıXP takımları genel bir kodlama standardını uygularlar. Bylece sistemdeki tüm kodlar tek elden çıkmış gibi grülür. Standardın ayrıntıları nemli değildir. nemli olan kodun tek elden çıkmış gibi grülmesidir. Ortak VizyonExtreme programlama takımları programın nasıl işleyeceği ile ilgili genel, ortak bir vizyona sahiptir. Biz buna metaphor diyoruz. Metaphor en iyi hali ile programın nasıl işlediği ile ilgili bir tariftir. Ajan-tabanlı sistemde arı kovanı rneği için tarif vermek gerekirse "polen toplamaya git ve topladığın polenleri kovana getir " gibi bir tarifini rnek olarak verebiliriz. Bazı zamanlar yeterli bir metaphor ortaya konamayabilir. Her ne durum olursa olsun, güçlü bir bakış açısı olsun ya da olmasın, XP takımları sistemin nasıl işlediği ile ilgili herkesin anlayabileceği isimleri kullanırlar. Eğer bir yere bir fonksiyon konacaksa herkes için anlamlı bir yerde olmalıdır. Sağlam HızExtreme programlama takımları uzun dnem çalışmayı düşünürler. Bu dnem içerisinde tarif edilemez bir şekilde hızlı ve sıkı çalışırlar. Bazen XP takımları etkili ve verimli oldukları zaman normalden daha çok çalışarak diğer zamanlardaki yavaşlıklarını telafi ederler. Başarısız projelerin birçok kişi tarafından da ortaya konan en nemli eksiklikleri hem yazılım ynüyle kaliteyi sağlamaması hem de üretim sürecinin uzun olmasıdır. XP takımları başarmaya kendilerini adamışlardır, başarısızlığa değil. SonuçExtreme programlama basitlik, iletişim, feedback ve cesaretlendirme değerleri üzerine kurulu bir yazılım geliştirme disiplinidir. Bu disiplin takımı basit işler çerçevesinde bir araya getirir ve yeterli feedback ile de takım üyelerinin kendilerini yola sokmasına katkı sağlar. XP ile ilgili genel sorular ve değişiklikler için bir makalemiz vardır. Bu konuda sorularınız ya da sorunlarınız olursa lütfen bize yazın. Sizin yazdıklarınız çerçevesinde de bu makaleyi güncelleyelim. Kayanak: Tahribat Araştırma geliştirme.. Google.com amca