XP’nin temelini oluşturan beş öğe: basitlik, iletişim, geri bildirim, cesaret, saygı
6.2.1. Basitlik
Üretilen yazılımın her aşamasında herşey mümkün olduğunca basit yapılmaya çalışılmalıdır. XP 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 göre ş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, aylarca çalıştıktan sonra bir defada ortaya çıkan bir şey olmaktan ziyade devamlı olarak yapılan bir aktivitedir.
6.1.2. İletişim
XP tüm takım üyelerinin bir araya gelip çalışarak herbirinin kendi uzmanlık alanlarında yapacağı katkılarla yazılımı geliştirmeyi önermektedir. Programcıların yanı sıra müşteri de takımın bir parçası olarak kabul edilir. Müşteri isterlerin oluşturulması ve bunların önceliklerinin belirlenmesi, ortaya çıkacak yazılımda hangi özelliklerin olması gerektiği hususunda takımı bilgilendirir. Analistler müşteriye isterlerin ortaya çıkmasında yardımcı olur. Aynı zamanda yazılımın tam olarak nasıl çalışması gerektiği hususunda, bir son kullanıcının deneyimlerinden yararlanılması için takıma alınması iyi olur. Takım test uzmanlarını da içerebilir. Test uzmanları müşterinin kabul testlerini belirlemesinde aktif rol oynar. Tabii ki proje yöneticisi takımın bir parçasıdır ve ekibin doğru yolda olup olmadığını kontrol eder, koordinasyonu sağlar. Son olarak, harici yöneticiler de takım içerisine alınabilir. Onlar da projeye kaynak sağlar, finansörleri gelişimden haberdar eder. XP yazılımı geliştiren takım üyelerinin biraraya gelerek "yüzyüze" iletişim kurmalarını önerir.
6.2.3. Geribildirim
XP için en önemli geri bildirim aracı testlerdir. Yazılan en ufak kod parçasını dahi test ederek daha işin başında nelerin doğru nelerin yanlış gittiği anlaşılabilir. Buna “Birim Testi” denir. Daha sonra birimler bir arada çalışacağı için onları birleşik olarak test etmek gerekir bu da “Birleştirme Testi”dir. Birleştirilen birimler bir araya geldiğinde sistemi oluşturur ki buda "Sistem Test" olarak adlandırılır. Özellikle birim testleri çok önemlidir ve XP bu testlerin muhakkak yapılmasını öğütler.
Bir başka geribildirim aracı bizzat yazılan koddur. XP'deki "CodeSmell" (Kod koklama) yöntemi, yazılan kod ile alakalı bir problem varsa, izleri takip ederek, yani kodu inceleyerek, problemi bulmak için başvurabileceğiniz bir yöntemdir.
6.2.4.Cesaret
XP'de geliştirilen sistem, daha iyi çalışması için rahatlıkla korkmadan değiştirilebilir. Çünkü sağlam sistem testleri vardır. Birşeyler tamamladıktan sonra eğer ondan memnun olunmazsa yapılanlar çöpe atılıp tekrar başlanabilir. Bunun geliştirilen sistemi tehdit eden bir davranış olmadığını bilmek güven vereceği gibi, bu güven ileri doğru çabuk adım atmayı da sağlamaktadır.
6.2.5. Saygı
Organizasyonda takım elemanları diğerlerini ve yaptıkları işleri önemsemezler ise herhangi bir yaklaşımın başarılı işlemesi imkansız gözükmektedir. Bu nedenle takım elamanlarının birbirlerine ve işlerine saygısı projenin başarılı olmasına olumlu etki yapacaktır.
6.3. XP Pratikleri
Yıllardır süregelen proje gecikmelerine karşın elde edilen deneyimler, saptamalar ve gözlemler sonucunda XP pratikleri ortaya çıkmış ve bu pratiklerin uygulanması ile projelerde yaşanan problemlerin azaltılabileceği düşünülmüştür.
Genel olarak organizasyonların XP’ye yaklaşımlarında, pratiklerin tamamı değil de öncelikle bir veya bir kaçı seçilerek uygulamaya başlanmaktadır. Fakat pratiklere bir bütün olarak bakmak gerekir, çünkü pratiklerin birbirleri ilişkileri ilk bakışta görünenden çok daha fazladır. XP içerisinde, bir pratiğin zayıf noktaları diğer pratiğin kuvveti ile dengelenebilmektedir ve pratikler birbirlerini desteklemektedir.
İlk XP versiyonunda 12 adet pratik tanımlanmıştır: Planlama Oyunu, Kısa Sürümler, Metafor, Basit Tasarım, Test, Yeniden Yapılandırma, Çiftli Programlama, Ortak Sahiplenme, Sürekli Entegrasyon, Haftada 40 Saat, Müşteri ile İçiçe Olmak, Kodlama Standardı. Bununla birlikte XP’nin ilk versiyonunda uygulanması önerilen pratiklerin bazılarından gelen geri bildirimler neticesinde son versiyonda listeden çıkarılmıştır. İlk versiyondaki 12 pratik yeni versiyonda 13’ü temel 11’i bunlarla ilişkili olmak üzere toplam 24 pratiğe dönüşmüştür. “Metafor” ve “Kodlama Standardı” pratikleri ikinci versiyonda yer almamaktadır. Yeni versiyondaki 13 temel pratik arasında senaryolar, haftalık planlar, büyük projelerin parçalar halinde dörtte birinin planlanması, planlardaki sapmayı azaltacak güvenlik marjinleri, tüm ekibin beraber aynı ortamda yer alması, takım ruhunun oluşması, bilgilendirici çalışma ortamı, verimli çalışma, çiftli programlama, artımsal tasarım, ünite testleri, 10 dakika içerisinde sürüm oluşturabilme garantisi ve sürekli entegrasyon yer almaktadır.
Birinci versiyondaki 12 temel pratiğin yeni versiyondaki 24 temel pratiğe genişlemesi yaklaşımına ilginç bir örnek olarak “planlama oyununu” verilebilir. Planlama oyunu, ikinci versiyonda “senaryolar, haftalık planlar, büyük projelerin parçalar halinde dörtte birinin planlanması, planlardaki sapmayı azaltacak güvenlik marjinleri” olarak 4 farklı pratiğe ayrılmıştır. Bir diğer iyileştirme örneği olarak, ilk versiyondaki “haftada 40 saat çalışma” pratiğinin yeni versiyonda “verimli çalışma” olarak yeniden düzenlenmesi verilebilir. Böylelikle pratiklerin uygulayıcıları tarafından algılanması ve organizasyona uyarlanması kolaylaştırılmıştır.
Her iki versiyonda da bulunan XP pratikleri aşağıda açıklanmıştır:
6.3.1. Planlama Oyunu
XP yaklaşımında, son kullanıcı tarafı projenin içerisinde etkin olarak yer almakta ve kilit roller üstlenmektedir. Bu pratik, iş öncelikleri ve teknik kestirimler göz önüne alınarak bir sonraki sürümün içeriğinin hızlıca belirlenmesini kapsar ve planlar üzerinde çeşitli sonuçlar doğurur. Yazılım geliştirme her zaman, istekler ve bunların gerçekleştirilme olasılığı hakkındaki diyalogları içermektedir. Bir tarafta yazılımdan çeşitli beklentileri ve istekleri olanlar, diğer tarafta ise bu beklentilere cevap verebilme olasılığı ve imkânları üzerine çalışanlar yer almaktadır. Tarafların bu diyalogları ise projeye yön vermektedir. Projenin iş yönetimi tarafının, sürümlerin kapsamına, önceliklerine ve teslimat tarihlerine karar vermeleri gerekmektedir. Bu kararları sağlıklı verebilmeleri için teknik yönden gerekli desteğin verilmiş olması gerekmektedir. Teknik insanlar, kestirimler yapmalı, sürece karar vermeli ve planlarda detaylı tarihleri belirlemelidir. İşte yazılım projesinin her iki tarafının da bir araya gelerek gerçekleştirdikleri bu aktiveler bir bütün halinde bu XP pratiği içerisinde yer almaktadır.
6.3.2. Kısa Sürümler
Her bir sürüm mümkün olduğunca kısa ve en değerli iş gerekleri içerir durumda planlanmalıdır. Bir veya iki aylık sürümler yılda iki sefer veya tek sefer planlanan sürümlerden daha iyidir.
Bu pratiğin düzenli olarak işlemesi için birkaç önemli nokta: - Planlama oyunu sonucunda ortaya çıkan öncelikler çerçevesinde oluşan en değerli hikayeler ilk sürümlerde gerçekleştirilmelidir.
- XP’nin bir diğer pratiği sürekli entegrasyon sayesinde, küçük sürümlerin paket haline getirilmesinde ki masraf minimum seviyeye indirilmelidir
6.3.3. Basit Tasarım
Doğru bir tasarımın özelliklerini sıralamaya çalışırsak; tüm testlerden başarıyla geçmiş, tekrarlanmış mantıklar içermeyen, tüm niyetleri programcıya açıklanmış ve mümkün en az sayıda sınıf veya metot kullanılmış tasarım diyebiliriz. Birim testleri ile tasarım XP içerisinde birbirlerine çok bağlı pratiklerdir. Tasarımın hiçbir şekilde karmaşık olmaması ve testlerden geçebilecek kadar olması, gelecek düşünülerek hiçbir şekilde eklemeler yapılmaması ve fazlasını içermemesi gerektiği vurgulanmaktadır. Endişe oluşturmayan değişimler, XP pratiklerinden yeniden yapılandırma (refactoring) adıma bırakılmalıdır
6.3.4. Test
XP pratiklerinde geliştirilen yazılımın testlerinde hem müşterinin hem de programcının sorumlulukları kapsamında yer alan alanlar bulunmaktadır. Müşteri veya son kullanıcı fonksiyonel testleri yazmakla sorumludur. Teslim alacağı ürünün isteklerini gereklerini karşıladığından nasıl emin olacağı sorusunun cevabını kendisi vermeli ve bu tespiti yapabilmek için gerekli testlerin içeriğini belirlemelidir. Programcılar her bir işlevsel özellik için birim testlerini yazmak ile sorumludur. Bu pratiğin önemli sonuçlarından biri, yazılımın tüm testlerden başarı ile geçtiği tespit edilince duyulacak güvendir. Duyulan bu güven ile bir diğer XP pratiği olan sürekli entegrasyonun gerçekleştirilmesi sancısız ve acısız olacaktır.
6.3.5. Yeniden Yapılandırma
Yazılım geliştirme XP mantığını kullanarak, önce yeni bir işlevsel özelliği eklediniz ve testinden de başarılı olarak geçtiğini saptadınız. Bundan sonra programcı, testinden yine başarı ile geçecek şekilde yeni eklediği özelliği daha basit gerçeklemeye çalışabilir. İşte bu iyileştirme çabası XP kapsamında “yeniden yapılandırma” olarak adlandırılmaktadır. Bu pratiğin yazılım geliştirme sürecinin içerisindeki rolü ve tam yeri konusunda çeşitli çalışmalar vardır. Ayrıca pratiklerin en çok tartışılan konusu olarak öne çıkmaktadır. XP’nin bu pratik ile yazılım tasarım aşamasını hafiflettiği öne sürülmektedir.
6.3.6. Çiftli (Eşli) Programlama
XP mantığında tüm kaynak kodu üretimi iki kişi ve tek bir makine, tek bir klavye kullanılarak gerçekleştirilir. Bu çiftin içinde iki ayrı rol vardır. Bir kişi elinde klavye ile metodu en doğru şekilde nasıl gerçekleyebilirim diye düşünmekte, diğer eleman ise daha stratejik düşünmektedir. Bu pratik tamamen dinamik olarak işlemektedir, ve sabah veya öğleden sonra roller değişebilmektedir. Bu pratik ile ilgili yapılan çalışmaların ölçümleri çok kısıtlı olarak yayınlanmaktadır. Yayınlanan ölçümlerin değerlendirilmesi ile erişilen sonuçlar ise oldukça olumlu gözükmektedir. İlk bakışta çoğu programcının kuşku ile yaklaştığı bu konuda uygulamalar ile ilgili yazılar arttıkça daha olumlu bir tabana oturacaktır Çeşitli açılardan uygulanması en zor görülen XP pratiği olarak görülmektedir. Bu doğrultuda, bu pratiği organizasyonlara uygun hale getirmek için değişiklikler yapılabilir.
6.3.7. Ortak Sahiplenme
Bu pratiğin karşısında iki ayrı kaynak kodu sahiplenme modeli yer almaktadır.
Bunlardan en eskisi hiçbir sahiplenmenin olmadığı modeldir. Hiç kimse kaynağın hiçbir parçasını sahiplenmemektedir. Bir kişi kodda herhangi bir değişiklik yapmak istediğinde, kendine uyacak şekilde herhangi bir kaygısı olmadan, herhangi bir standart uygunluk gözetmeksizin bu değişikliği gerçeklemekteydi. Tabii bu
yaklaşımın kötü sonuçları çabucak ortaya çıkmıştır.
Bu durumu kontrol altına alabilmek için, bireysel sahiplenme yaklaşımı doğmuştur. Sadece bir kişi resmi bir şekilde kaynak kodunda değişiklik yapabilmektedir. Herhangi bir kişi kodda değişikliğe gerek gördüğünde, kaynak kodu sorumlusuna bunu resmi kanallardan bir değişiklik isteği ile bildirmektedir. Bu yaklaşımın en büyük dezavantajı, kaynak kodu sorumlusunun herhangi bir nedenle bu sorumluluğu devretmesi gerektiğinde ortaya çıkmaktadır. Bu anda, kaynak kodu devralmak için istekli bulmakta zorlanılmakta, istekli bulunsa dahi devir işleminin hiç kolay olmayacağı hem zaman hem gider açısından büyük maliyetler doğuracağı bilinmektedir.
XP yaklaşımında, takım içerisindeki herkes tüm sistem üzerinde sorumluluğu paylaşmaktadır. Tabii ki, herkes aynı düzeyde sistemin tüm parçalarına hakim olacak anlamına gelmemektedir bu yaklaşım. Ama çift programlama pratiğinin ve gözden geçirmelerin etkisi ile bireylerin sistemin tamamı üzerindeki bilgisi en yüksek düzeyde tutulmaya çalışılmaktadır.
6.3.8. Sürekli Entegrasyon
XP yaklaşımında geliştirme günü içerisinde kaynak kod sisteme en az bir defa entegre edilmelidir. Bunu sağlayacak makineler ve simülatörler üzerine çalışmalar yapılmalıdır. Bu altyapıya gerekli kaynağın ayrıldığı ve altyapının oluşturulduğu göz önünde tutularak, bu pratiğin uygulanması ile ilgili önemli noktalar:
- Sürekli entegrasyon ve test pratiklerinin birlikte uygulanması ile, sistemde oluşmuş herhangi bir hata veya kusurun tespiti hızlı ve çabuk şekilde yapılabilmekte, - Ayrıca işlevsel özellik eklemeleri ve düzeltmeleri de sürekli entegrasyon ile en üst seviyede test edilebilmekte,
- Çift programlama pratiği ile entegrasyon safhası süresi yaklaşık yarıya indirgenebilmektedir.
6.3.9. Müşteri (Kullanıcı) ile İç içe Olmak
XP anlayışında gerçek müşteri, geliştirme takımından gelecek sorulara hızlı cevap verebilmek, planları kolay yönlendirebilmek ve uyuşmazlıklara çabuk çözümler bulabilmek için takım ile birlikte oturmalıdır. Gerçek hayata baktığımızda belki de en zor şart, takım ile sürekli çalışabilecek son kullanıcılar bulmaktır. Son kullanıcı tarafının yöneticilerinden bunları istemek gerçekten zor görünmektedir. Gerek duyulduğu vakit zaman ayırtabilecek bilinçli bir müşteri tarafı oluşturmak mümkün gözükmektedir. XP içerisinde müşteri, fonksiyonel testleri yazmak, planlamalarda bizzat kilit rol oynayıp önceliklendirme yapmak, sürümlerin kapsamlarını belirlemekle yükümlüdür.
6.3.10.Kodlama Standardı
XP’nin birçok pratiği bu pratik ile yakından ilintilidir. Bunlardan “ortak sahiplenme” ve “çiftli programlama” en önemlileri ve direk olarak etkilenenleridir. Takım içerisindeki herhangi bir kişinin sistem yazılımlarının herhangi bir yerinde değişiklik yapabilme hakları olduğu bir durumda, belirli bir standart en çok aranılandır. Aksi durumda kaynak koda açıp bakan birinin bu kaynaktan neler algılayabileceği veya ne ile karşılaşacağı büyük bir soru işareti olacaktır. Yapılan araştırmalar sonucunda yayımlanan makalelerde, yazılım geliştirmede en çok rastlanan yanlışlık olarak “belirli bir kodlama standardının yerleşmemiş” olması olarak belirtilmektedir.