Extreme Programming ve Yazılım Mühendisliği

2014

Ferhat SARIKAYALCWAIKIKI

17.12.2014

İçindekilerGiriş..............................................................3

Yazılım Mühendisliği...............................................3Yazılım Geliştirme.................................................4

1. Tanımlama.....................................................41.1. Sistem Çözümleme...........................................4

1.2. Yazılım Proje Planlaması...................................41.3. İsterlerin Belirlenmesi....................................4

2. Geliştirme....................................................42.1. Yazılım Tasarımı...........................................4

2.2. Gerçekleştirim (Kodlama)...................................42.3. Test.......................................................4

3. Bakım.........................................................43.1. Düzeltici Bakım............................................5

3.2. Uyarlayıcı Bakım...........................................53.3. Geliştirici Bakım..........................................5

3.4. Önleyici Bakım.............................................5Yazılım Mühendisliği Metodolojileri................................5

1. V Modeli......................................................52. Klasik Çevrim Modeli..........................................6

3. Prototip Model................................................74. Artırımsal Model..............................................7

5. Spiral Model..................................................8Extreme Programming (XP)...........................................9

XP’nin İlkeleri...................................................101. Basitlik.....................................................11

2. İletişim.....................................................113. Geri Bildirim................................................11

4. Cesaret......................................................115. Saygı........................................................11

XP Uygulama Pratikleri............................................12

On-site Customer................................................12Planning Game...................................................12

Short Releases..................................................12Stand-up Meeting................................................12

Retrospective...................................................12Metaphor........................................................13

Collective Ownership............................................13Continious Integration..........................................13

Coding Standards................................................13Sustainable Pace................................................13

Testing.........................................................13Simple Design...................................................13

Refactoring.....................................................13Pair Programming................................................13

XP Rolleri........................................................14Customer........................................................14

Developer.......................................................14Project Manager.................................................14

Coach...........................................................14Tester..........................................................14

XP’de Sürecin İşleyişi............................................14Sürüm Planlama Oyunu..............................................15

GirişExtreme Programming (XP) metodu, bir çevik yazılım geliştirme metodudur. Her şey gibi Extreme Programming’de ihtiyaçlardan doğmuştur. Bu ihtiyacı doğru aktarabilmek için öncelikle yazılım geliştirme modellerini ve Yazılım Mühendisliğini iyi anlamak gerekiyor, böylece her şey daha anlamlı hale gelecektir. Bu sebeple Yazılım Mühendisliğindeki gelişimleri ele alarak başlayacağız ve sonra Extreme Programming metodunu açacağız, bu şekilde doğru bir kavrayış noktası verebileceğime inanıyorum.

Yazılım MühendisliğiYazılım Mühendisliğinin tarifini yapacak olursak, Yazılım Mühendisliği karmaşık veya basit amaca yönelik yazılımların geliştirilmesinde belirli ilkelere dayanarak, sistematik yöntem ve araçları da kullanarak, işin bölümlere ayrılması ve yönetilmesi işlemini yerine getiren bilimsel bir disiplinidir.

1950’li yıllarda bilgisayarların ortaya çıkması ile başlayan yolculuk, 1960’lı yıllardaki karmaşık yazılım ihtiyaçlarını ortaya çıkarmaya başladı. Özellikle soğuk savaş döneminde geliştirilen internetin atası olan ARPANET birçok şeyin miladı oldu. 1970’li yıllarda veritabanları ve veritabanı yönetim sistemleri hayatımıza girmeye başladı. Artık yazılımlar git gide karmaşıklaşmaya başlıyordu.

Artan yazılım karmaşıklığına rağmen yazılım geliştirme daha çok programcıların kişisel tecrübeleri ve zekaları ile doğru orantılı gelişiyordu. İlk defa 1968 yılında Almanya’da gerçekleştirilen NATO toplantısında Yazılım Mühendisliği terimi ortaya atıldı.

1968’de Yazılım Mühendisliği terimi ortaya atılmış olsa da 1980’li yılların ortalarına kadar ciddi bir yol kat edilemedi, hatta ölümlere bile yol açtığını söyleyebiliriz. Örneğin Therac 25 adı verilen radyoterapi cihazları için geliştirilen yazılımın başarısızlığı yüzünden hastalara aşırı dozda radyasyon verildi ve ölmelerine neden oldu.

Yazılım Krizi diye anılan 1965 – 1985 yılları arasındaki dönemden sonra yazılımlar, artık belli ilkelere dayanan sistematik yöntemler geliştirilmeye başlandı. Tabii durum birden düzelmedi, sonraki

yapılan en büyük hata da yazılım geçmişi olmayan kişilerin yazılım projelerini yönetmesi oldu. Günümüzde de yaygın olan inanış, iyi biryönetici her tür projeyi yönetebilir. Elbette konu yazılım gibi spesifik bir alansa bu tanım kesinlikle doğru değildir.

Yazılım projelerini yönetebilecek kişinin yalnız personel yönetiminibilmesi beklenemez, bunların yanında yazılım işini tanımlamak (amaç,kapsam ve varsayımları belirlemek), maliyet ve süre hesaplamalarını yapmak, uygun personel seçimi, uygun veritabanı seçimi, karmaşık yazılım süreçlerinde doğru kişiye doğru işi paylaştırması, ekiple aynı dili konuşabilen ve sürekli iletişim sağlayabilen biri olmak zorundadır. Bu da yazılım geçmişi olmayan biri için başarılması pek de mümkün olmayan birçok karmaşıklığı beraberinde getirir.

Yazılım Mühendisliğinde ilk ciddi çalışma 1987 yılında SWEBOK (Software Engineering Body of Knowlage – Yazılım Mühendisliğinin Çekirdek Bilgisinin Tanımlanması) projesi ile başlamıştır. 1999 yılında son halini aldı ve bir mühendislik dalı olarak 2003 yılında üniversitelerde okutulmaya başlandı.

Yazılım GeliştirmeBir yazılım ihtiyacının kapsamının netleşmesi sonucunda geliştirme ve kullanım süreci başlar. Bu sürece yazılım yaşam döngüsü diyoruz. Yazılım Mühendisliğinde farklı yazılım geliştirme metodolojileri mevcuttur; fakat hangi metot seçilirse seçilsin bir yazılım geliştirme üç temel evreden oluşur. Bunlar: Tanımlama, Geliştirme veBakım’dır. Kısaca açacak olursak:

1. TanımlamaTanımlama evresinde temel amaç ne yapılacağının netleştirilmesidir. Yazılım Geliştiricilere müşterinin istekleri analistler tarafından iletilir, böylece yazılımın genel işlevi, kısıtları, başarılı olma kıstasları gibi ayrıntılar belirlenmiş olur. Bu evrede üç temel işlev yerine getirilir:

1.1. Sistem ÇözümlemeYazılımından beklenen işlevler doğrultusunda, nasıl bir donanıma ve işletim sistemine gerek duyulduğu belirlenir.

1.2. Yazılım Proje PlanlamasıYazılım kapsamı netleştikten sonra insan, bilgisayar ve kullanılacak araçlardan oluşacak kaynak gereksinimi belirlenir; maliyet hesabı yapılır, görevler tanımlanır ve anaaşama noktaları belirlenir.

1.3. İsterlerin BelirlenmesiYazılımdan beklenen işlevler doğrultusunda genel başarım beklentisi, sistem arayüzleri gibi teknik detaylar belirlenir.

2. GeliştirmeBu evrede temel amaç yazılımdan beklenen işlevlerin nasıl geliştirileceğini belirlemektir. Yazılım mimarisi, veri yapıları,veri modelleri, tasarım yazılım standartları belirlenir. Bu evrede üç temel işlev yerine getirilir:

2.1. Yazılım TasarımıYazılım isterlerinin karşılanabilmesi için mimari, veri modelleri ve yapıları, algoritmalar, akış şemaları, modüller ve arayüzler görsel veya metinsel olarak ortaya çıkarılır. Yazılım tasarımı yapılmadan kodlama yapmak olanaksızdır.

2.2. Gerçekleştirim (Kodlama)Kodlama da dediğimiz bu bölümde yazılım tasarımına dayanarak uygun bir programlama dili ile yazılımın geliştirilme aşamasıdır. Bu bölümde artık çalışan yazılım elde edilmiş olunur.

2.3. TestBu aşamada artık tam olarak geliştirilmiş yazılımın müşteri istekleri doğrultusunda gerekli başarımı sağlayabiliyor mu testleri yapılır. Genel olarak bu bölümde muhakkak hatalar tespit edilir ve çalışmayı aksatan bu hatalar giderilerek müşteriye test etmesi için sunulur. Müşteri testlerinden de geçmesi durumunda yazılım geliştirme evresi bitmiş olur.

3. BakımBir yazılım müşteriye tesliminden sonra da genel olarak son bulmaz. Çünkü gerçek dünyada kullanılmaya başlandığında beklenmeyen durumlarla karşılaşılabilinir. Bazen programın kapsamı yeterli gelmeyebilir ve kullandıkça yeni ihtiyaçlar doğurabilir. Bazen de kullanılan bir veri tipi hatalı olabilir

veya beklenenden farklı sonuçlar üretebilir. Bu tür durumlarda gerekiyorsa yeni modüller eklenir veya mevcut üzerinde düzeltmeler yapılabilir. Genel olarak bakım etkinliklerini şöyle tanımlayabiliriz:

3.1. Düzeltici BakımÇoğunlukla kusursuz bir yazılımdan bahsetmek mümkün değildir, yazılım hayata geçtikten sonra ortaya çıkan bir takım terslikler yazılım geliştiriciler tarafından düzenli olarak giderilirler. Bu işleme düzeltici bakım diyoruz.

3.2. Uyarlayıcı BakımBazen yazılımın çalıştığı bilgisayar donanımı değiştirilmek zorunda kalınabilir. Bu gibi durumlarda uyumsuzluk problemleribaş gösterebilir. Yazılımın bu gibi durumlarda yeni donanım yapısına uygun hale getirilmesi için değişiklikler yapılır. Buişleme uyarlayıcı bakım diyoruz.

3.3. Geliştirici BakımKullanılan bir yazılım bir süre sonra gelişen teknolojide yetersiz kalabilir ve yeni ihtiyaçlar doğabilir. Yeni doğan ihtiyaçlardan ötürü yeni modüller geliştirilir ve yazılımın daha uzun zaman iş görmesi sağlanır. Bu işleme geliştirici bakım diyoruz.

3.4. Önleyici BakımYazılım geliştirme işlemi tamamlandıktan sonra yazılımcıların herhangi bir veri girişi durumunda hata oluşacağını tespit ettiği ve düzelttiği işleme de önleyici bakım diyoruz.

Yazılım Mühendisliği MetodolojileriYazılım Mühendisliği alanında bir yazılımın geliştirilmesi için bazımetotlar geliştirilmiştir. Mükemmel bir metottan bahsetmek mümkün olmasa da mükemmele ulaşmaya çalışılan yolda edinilen tecrübeler doğrultusunda bir takım sistematikler elde edilmiş ve belirli standartlara bağlanmıştır. Şimdi kısaca bu metotları inceleyelim.

1. V ModeliYazılım isterlerinin net tanımlanması ve belirsizliklerin çok az olduğu projelerde oldukça iyi sonuçlar vermektedir. Aşağıdaki şekilde de gösterilen V modelinin sol kısmı üretim etkinleri ile

ilgili iken, sağ kısım ise test etkinlikleri ile ilgilidir. Modelde testler sırasında bulunan hatanın düzeltilmesi için hangidüzeye dönülmesi gerektiği gösterilmektedir. Örneğin kabul testi aşamasında sorun ortaya çıktığında işin büyüklüğüne göre yeniden gereksinimlerin belirlenmesi gerekir.

2. Klasik Çevrim ModeliKlasik çevrim modeli, şelale (waterfall) ismi ile de anılır. Toplam 5 evre şeklinde ele alınır. Bunlar şekilde görülen evrelerdir.

Bu modelde tüm isterlerin baştan belirlendiği farz edilir. Bu sebeple de bir evre bitip diğer evreye geçildiğinde geri dönüş pek mümkün değildir. Geliştirilen yazılım müşteriye teslim edildiğinde ise geri dönüş pek mümkün olmadığı için yeni doğacak taleplere sıfırdan başlanması gerekir.

3. Prototip ModelYazılım geliştirmenin temel en büyük problemi tüm isterlerin belirlenmesidir. Bu gerçek hayatta neredeyse mümkün değildir. Çünkü kullanım sonucunda doğacak eksiklikler, hatalı sonuç üretenyapılar muhakkak olacaktır.

Bu problemlerin önüne geçmek ve müşteriyi işin içine dahil etmek için isterlerin anlaşıldığı kadarıyla bir prototip geliştirilir ve süreç prototipin onaylanması sonucunda gerçeklenmeye başlanır.

Prototip geliştirmede iki model benimsenmektedir. Bunlardan biri “At – Gitsin”, diğer ise “Evrimsel”dir.

At – Gitsin prototipler, genelde müşterinin isteklerinin net olarak anlaşılamadığı durumlarda hızlıca üretilen prototipi ifadeeder. Prototip temelde istekle ilgili müşterinin onayını netleştirmektir. Görsel kaygılar taşımadan geliştirilen bu prototip işi bittikten sonra atılırlar ve yazılım bu isteklere göre şekillenir.

Evrimsel prototipler ise müşterinin isteklerinin genel hatlarınınkesin olduğu; ama detaylar konusunda netlik olmayan durumlarda kullanılırlar. Müşterinin genel istekleri yerine getirildikten sonra müşteri testi sonucunda eksik görülen yapılar sürekli eklenerek evrimleşmesi ve olgunlaşması sağlanır.

Temelde projenin iptal edilmemesi için genel teslim beklentileri bu modelde net olmak zorundadır. Bu da köklü değişiklik taleplerine ayak uyduramayacağı anlamına gelmektedir.

4. Artırımsal ModelBu modelde temel mantık, tüm yapıyı tek bir parça halinde geliştirip teslim etmektense yapı parçalara ayrılır (modül) ve her bir parça birbirinden bağımsız geliştirilir, daha sonra bu parçalar birbirine entegre çalışacak hale getirilir.

Bunun için de yine temel gereksinimleri bilme zorunluluğu vardır,çünkü modül bazında geliştirme yapabilmek için bazı standartları belirgin halde olması gerekir, aksi halde modülleri birbiri ile iletişim kuramaz hale gelebilir.

Bu model de prototip model gibi müşteriyi projenin içine daha fazla dahil eder, böylece müşteri geliştirme aşamaları hakkında genel fikir sahibi olarak zamanında bazı aksiliklere müdahale edebilir.

5. Spiral ModelŞimdiye kadar ki modellerde genelde ardışık sırayla yazılım geliştirme söz konusuydu, Spiral model bu anlamda farklı bir konsept sunmaktadır. Spiral modelin her bir turu farklı bir safhayı temsil edebilmektedir.

Şekildeki sayıların açıklamaları ise şöyledir:0: Yaşam döngüsü planı1: Gerek Planı2: Geliştirme planı3: Entegrasyon ve test planı4: Kapsam5: Gereklerin belirlenmesi6: Tasarım ve gerçekleme7: Entegrasyoni ünite testleri ve kabul testleri8: Son ürün

Spiral modelde herhangi bir turda sabitlenilmez ve her bir tur ihtiyaç duyulan işlemler için atılır. İstekler gerçekleştikten sonra yeni bir ihtiyaç varsa tur yeniden düzenlenir.

Extreme Programming (XP)Extreme Programming (XP) metodu ilk defa 1999 yılında Kent Beck tarafından duyuruldu. Temelde XP metodu 1996 yılında Chrysler firmasındaki bir proje esnasında Kent Beck, Ron Jeffries ve Ward Cunningham tarafından geliştirildi.

XP’nin ortaya çıkmasındaki asıl etken Yazılım Mühendisliği metotlarının aşırı dökümantasyon ve zaman alıcı bir süreci beraberinde getirişine bir tepki olarak ortaya çıktı. Yukarıda incelediğimiz modeller genel olarak yazılımın geliştirilmesinden önceki analiz safhasının aşırı uzamasına neden olmaktaydı. Genelde bir analist tarafından isterler netleştirilmek zorundaydı ve bu gerçek hayatta çoğunlukla mümkün değildi.

Dünyada geliştirilen yazılımların %80’ini başarısız olmaktadır. Başarısızlık etkenleri arasında en önemlisi ise sürecin aşırı uzaması ile birlikte şevkin kırılması, personelin inancını yitirmesigibi sorunlar baş göstermekteydi. Diğer taraftan yazılım isterlerinibaştan almak da çoğunlukla tamamen mümkün olmadığı için ilerleyen safhalarda bazen yeniden baştan sistem ve yazılım tasarımına gidilmesi gerekebiliyor. Bu tür durumlara ise Yazılım Mühendisliğindeki tipik modeller ayak uydurmakta oldukça zorlanıyor,bazen de mümkün olmuyor.

Geleneksel tarzda yapılan projelerde gerekli değişikliklerin yapılması maliyete zamanla yükseltir.

XP’nin ortaya çıkmasına neden olan eleştiriler şunlardır: Çalışan program oldukça geç ortaya çıkıyor Çalışan program geç çıktığı için hatalarında farkına çok geç

varılıyor Verimli değil Esnek değil, yeni isterlere cevap verip ona uyum sağlayamıyor Değişiklik geç ve oldukça zor yapılıyor

Nihayetinde Kent Beck’in yayınladığı XP manifestosu ise artık yeni bir yaklaşım benimsenmesi gerektiğini ortaya koydu. Bu manifesto şunları içeriyordu:

1. Kişiler ve iletişim, süreç ve araçlardan önce gelir.2. Çalışır durumda olan program, detaylı dokümantasyondan daha

önceliklidir.3. Müşteri ile beraber çalışmak, sözleşmelerden ve anlaşmalardan

daha önceliklidir.4. Değişikliklere ayak uydurmak, bir planı takip etmekten daha

önemlidir.

Manifestonun içeriğini açmamız gerekirse “kişiler ve iletişim”den kasıt şüphesiz yazılımı geliştirecek ekip ve bunlar arasındaki iletişimdir. Genel olarak günümüz yazılım yaklaşımlarında ekip içi iletişim en büyük problemdir. Özellikle yazılım birden fazla kişi

tarafından geliştirildiğinde geliştirmeleri takip edebilmek, tecrübeve fikir paylaşımını sağlayabilmek oldukça önemlidir. Bu yüzden XP metodunda ekip aynı oda içerisinde yüzyüze bakacak şekilde oturtulur.

“Çalışır durumda olan program” dokümantasyondan daha öncelikli olmalıdır, çünkü kağıt üstünde yapacağınızı tüm analiz yüksek ihtimalle kağıt üstünde kalacaktır ve sürekli revize edilme ihtiyacıdoğacaktır, en azından gerçek hayatta bu genellikle böyle olmaktadır.

“Müşteri ile beraber çalışmak” elbette sözleşme ve anlaşmalardan daha öncelikli olmalıdır. Sonuçta müşterinin isteği üzerine yapılacak olan yazılımın müşteri talebini karşılamadığı durumda başarılı bir yazılımdan ve proje yönetiminden bahsetmek mümkün değil. Klasik yazılım metodolojilerinde genel olarak müşteri isterleri baştan alınmak istenir; ama gerçekte müşteri tüm istediğini tamamen aktaramaz ve sürekli revizyon yapılmak zorunda kalınır. Bu zaman ve maliyet kaybını çoğaltır ve çoğunlukla başarısız yazılımları ortaya çıkarır.

“Değişikliklere ayak uydurmak”, planı takip etmekten önemlidir, çünkü yukarıda da belirttiğimiz gibi müşteri isteklerini bir soluktasize asla iletemeyecektir, bunun için esnek ve hatta cesurca değişikliklere uyum sağlamanız gerekir.

XP’nin İlkeleriXP 5 temel ilkeye sahiptir. Bunlar:

1. Basitlik2. İletişim3. Geri Bildirim4. Cesaret5. Saygı

Şimdi kısaca bu ilkeleri açıklayalım.

1. BasitlikXP süreçlerinde değişime ayak uydurabilmek adına sürümler sadece ihtiyaca yönelik çıkartılırlar. Müşteri ile birlikte oluşturulan yazılım ihtiyacı temelde neyi kapsıyorsa yalnızca onlar yapılır,

böylece boşa adım atılmamış olur, kayıplar sıfırlanır. Her bir sürüm bir diğeri ile entegre olacağı için karmaşık yapılardan özenle kaçınılmalıdır.

2. İletişimXP ekibin iletişimini fazlasıyla önemser. Müşteri, yönetici, son kullanıcı, test uzmanı ve yazılım geliştiriciler ekibin bir parçasıdır. Ekip üyelerinin tecrübelerini ve öngörülerini paylaşması projenin başarısı için oldukça kilit konumdadır. Müşteri isteğini ortaya koyar, son kullanıcı bu durumda beklentilerini iletir, yazılım tasarım analistleri isteklerin belirginleşmesinde müşteriye destek olur ve yazılım geliştiriciler işin ne kadar zamanda biteceğini belirlerler. Ekibin her üyesi aşamaların içinde olduğu için işin takibi, ortaya çıkacak ürün nettir.

3. Geri BildirimXP’nin başarısının ardındaki en önemli adım geri bildirimdir. Bu da testler aracılığı ile yapılır. Yazılım geliştiriciler kendi yaptıkları kodları zaten test ederler; ama senaryolar içerisinde bazen beklenmedik sorunlar oluşabilir, bu sebeple bir test uzmanıtarafından senaryolar dahilinde yazılım test edilir ve eksik veyahatalı olan kısımlar iletilerek hemen değiştirilmesi sağlanır.

4. CesaretCesaret, yapılan işlerde gerekirse hemen değişiklik yapmayı simgeler. Bu klasik yöntemlerde pek tercih edilmeyen bir unsurdur, çünkü birçok şeyi baştan almak maliyetleri yükseltir; ama XP için bu göğüslenebilir bir şeydir, nihayetinde istekleri karşılayamadığı takdirde yazılımın başarılı olduğunu ileri sürmekmümkün değildir.

5. SaygıEkibin her bir üyesi diğerlerine saygı duymalıdır. Yaptığı iş ufak bile olsa her ekip üyesi tarafından saygı görmelidir, aksi halde ortaya başarılı bir proje koymak mümkün değildir. Örneğin test uzmanlı ile yazılımcılar sık sık çatışırlar. Yazılımcılar yazdıkları sistemin eleştirilmesini pek kabul edemezler, bu da XPiçin pek de cazip değildir. Bu yüzden saygı diğer ilkeleri yerinegetirebilmek için olmazsa olmazdır.

XP Uygulama Pratikleri

On-site CustomerEkipteki müşteri diye çevirebiliriz. Daha önce de dediğimiz gibi XP’de süreç müşteriye göre şekil alır ve onun istekleri doğrultusunda yazılım şekillenir. Bu yüzden müşterinin (genelde bir kişi tercih edilir; ama uyumlu ise birden fazla kişi de olabilir) ekipte olması önemlidir.

Planning GameOyun planı diye çevirebiliriz. XP iteratif (tekrarlanan, ardışık devam eden) ve inkremental (değişen, marjinal) bir yazılım metodolojisidir, bu yüzden tam bir takım oyunu gerektirir, bu nedenle her bir sürüm için ekip bir arada planı geliştirir. Plan herhangi bir iş için kaçınılmazdır, aksi halde süreçleri kontrol etmek ve ortaya düzgün bir iş koymak mümkün değildir.

Short ReleasesKısa Sürümler diyebiliriz. XP temelde kısa sürede ortaya çalışan bir uygulama koymak ister, böylece hem müşteri istekleri doğru alınır, hem memnuniyeti sağlanır hem de ekibi canlı tutmayı sağlar. Uzun vadeli işler genelde sıkıcı olabileceği için kısa vadede ortaya çıkan ürün geliştiriciler için de şevk vericidir. Bu yüzden basitlik tercih edilir.

Stand-up MeetingAyakta toplantı. Bu tür toplantılar en fazla 15 dakika olacak şekilde ayarlanırlar. Temelde yapılmak istenen projenin durumu hakkında bilgi alışverişinde bulunmaktır.

RetrospectiveGeriye bakış diye çevirebiliriz. Temel amaç yaşanan problemlerin analizini yapmaktır, böylece aynı hatanın gelecekte tekrar etmesinin önüne geçilmiş olur.

MetaphorMecaz. Mecaz kullanmanın maksadı geliştirilecek yazılımın içeriğihakkında ekibin bir fikrinin oluşmasıdır. Örneğin e-ticaret uygulaması geliştirecek ekip için alış veriş sepeti bir metafor olarak kullanılabilir. Böylece metafor ekibe söylendiğinde herkesin kafasında e-ticaret sistemi yazacağı fikri kolaylıkla oluşacaktır.

Collective OwnershipOrtak sorumluluk. Klasik modelde programcılar genelde yalnız kendi yazdıkları kodlardan sorumludurlar, klasik yöntemle çalışanprogramcılar başkalarının kodları üzerinde oynamak istemezler. Oysaki XP’de tüm programcılar kodu sahiplenir, gerektiğinde değiştirir.

Continious IntegrationSürekli entegrasyon. Projeye eklenen yeni bölüm veya komponentlersisteme hemen entegre edilir ve test edilirler. Bu hem diğer programcıların da gelişimi görebilmesini sağlar hem de daha sonrayazılımın parçalarını entegre etmek için ekstra zaman kaybı yapılmamış olur.

Coding StandardsKod yazma standartları. Birden fazla yazılım geliştiricinin yer aldığı uygulamalarda olmazsa olmaz bir durumdur. Ortaya kaliteli ve stabil çalışan bir ürün çıkarılabilmesi için değişken isimlendirmeden, kullanılacak alt yordam, fonksiyon formatına kadar belirlenir. Böylece her programcı bir başkasının koduna müdahale ettiğinde kodu okumakta zorlanmaz ve gerekli değişiklikleri yapabilir.

Sustainable PaceKalıcı Tempo. XP, haftalık 40 saat çalışma planı sunar. Yorgun, uykusuz bir programcı verimli olamayacağı için fazla çalıştırılmasına tamamen karşı çıkar ve günlük 8 saat olmak üzerehaftada 40 saat çalışmaya sadık kalır. Böylece projede aksamalar kolay kolay olmaz.

TestingTest etmek. XP testleri çok önemser ve muhakkak yapılması gerektiği üzerinde durur, hatta daha da ileri giderek önce gerekiyorsa test yazılımlarının kodu yazılır, sonra yazılım geliştirme aşamasına geçilir.

Simple DesignBasit tasarım. XP’de geliştirilen yazılım en basit hali ile geliştirilir, kompleks olmamasına özen gösterilir, böylece yeni geliştirmeler kolayca entegre edilebilir.

RefactoringYeniden yapılandırma. Yazılım tasarımı yapılırken yapılan bir hata bazen telafisi zor sorunlara yol açabilir, bunun için yazılan kod parçacığının yeniden yapılandırması gerekebilir.

Pair ProgrammingEşli programlama. Temelde aynı bilgisayarda iki programcının çalışması tavsiye edilir. Bir programcı yazarken diğer programcı kodlama yapısına dair düşünür ve tavsiyelerde bulunur, sonra diğer programcı yazmaya başlar ve diğeri aynı görevi yerine getirir. Bu hem programcı yedekliliğini sağlar, hem de kod yazanların kalitesinin yükselmesini sağlar.

XP RolleriBir proje geliştirilirken sorumlulukların net olarak tanımlanması önemlidir, aksi halde sorumluluk alanları muğlak olunca işin bir bölümü eksik kalabilir. Bunun önüne geçmek için XP’de çeşitli rolleroluşturulmuştur. Bu roller bazı sorumlulukları ve hakları beraberinde getirir. Şimdi bu rolleri inceleyelim.

CustomerMüşteri. Projenin sahibi ve odağındaki kişidir. Projenin gereksinimlerini kullanıcı hikayeleri oluşturarak verir. Kullanıcı hikayelerinin oluşmasına yazılım geliştiriciler de destek olur; fakat projenin sahibi olarak isterleri daha net bildiği için asıl hikaye sahibi müşteridir. Aynı zamanda yazılım geliştiricilerin sorularına cevap vermekte müşterinin sorumluluğundadır. Yazılım geliştirme bitip sürümün testleri yapıldıktan sonra kullanıcı hikayesine uyumluluğu konusundaki kontrolü de müşteri yapar.

DeveloperYazılım geliştirici (Programcı). Sistem analizi, tasarım, test veimplementasyonu yapar. Her bir yazılım geliştirici test güdümlü olarak çalışır. Yaptığı her bir parçayı / modülü test eder ve sisteme hızlı entegre eder.

Project ManagerProje yöneticisi, projenin planını tek başına yapamaz ve programcılara sorumluluklarını atayamaz. Programcılar çalışacakları uygulamaları kendileri seçerler. Yaptıkları iş dahaçok koordinasyonu sağlamak ve toplantıları düzenlemektir.

CoachKoç. Agile (Çevik) modeli iyi bilen ve nasıl uygulanması gerektiği konusunda uzman (expert) kişidir. Koçun görevi doğru ekibi bulmak veya bir araya getirmek ve yol gösterici rehberlik etmektir. Temelde yaptığı şey ekibin XP modelinin dışına çıkmasına izin vermemektir.

TesterTestçi. Yazılımın, müşteri tarafından oluşturulan kullanıcı hikayelerine uygunluğu kısmını kontrol eder, yazılım geliştiricilere hata veya eksiklik durumunda geri bildirim yapar.Aynı zamanda programcıların test yapabilmeleri için gerektiğinde yardımda bulunur.

XP’de Sürecin İşleyişiİlk olarak müşteri istediği yazılım için gerekli kullanıcı hikayelerini yazılım geliştiricilerin de desteği ile oluşturur.

Oluşturulan kullanıcı hikayelerinin her birine göre yazılım geliştiriciler tahmini geliştirme süresinin belirlerler.

Müşteri ve yazılımcılar oluşan kullanıcı hikayesine göre çıkarılacakolan sürümün planını yaparlar. Yapılan plana göre yazılım geliştiriciler kodlama işlemini gerçekleştirir. Test sorumlusu oluşan sürümün kullanıcı hikayelerine uygunluğunun ve çalışma zamanlı hata oluşup oluşmadığının kontrolünü yapar ve başarılı olan sürüm müşterinin kullanımına sunulur.

Müşteri kullanım sonrasında uygunluk durumu hakkında geri bildirimdebulunur ve çoğunlukla en az bir sürüm daha çıkarılmak durumundadır. Bazen de köklü değişiklik olur ve her bir sürüm için işlemler en baştan tekrar yapılırlar.

Sürüm Planlama OyunuXP’de bir sürümün ortaya çıkması için “Game Plan” sistemi uygulanır.Bu rekabetçi bir oyun değil, aksine uyumu gerektiren bir oyundur. Amaç geliştirilecek yazılımın planını dokümante edebilmektir, elbette klasik modeldeki gibi uzun dokümantasyonlardan bahsetmiyoruz, kısa ve anlaşılır bir şekilde az yazı yazarak planlanan bir süreçtir.

Sürüm planlama oyunu kısaca yukarıdaki şekilde gösterilmektedir. Öncelikle müşteri kullanıcı hikayesini oluşturur, bu hikayeye göre yazılım geliştiriciler hikayeyi küçük parçalara bölerler ve story

card denilen genelde kartondan yapılan hikaye kartlarına yazılır. Örneğin aşağıdaki resimde gösterildiği gibi kullanıcı girişi hikayenin bir parçasıdır.

Resimde görüleceği üzere Prio bilgisi işin önceliğini, Tahmin bilgisi ise hikaye puanı yani iş için ayrılacak tahmini zamanı belirtir. 1 hikaye puanı 1 iş gününe eşittir. 1 gün ise 8 saat olarak programlanır ve buna göre zaman tahminleri yapılır.

Sürümün detayları ortaya çıktıktan sonra öncelik sırasına göre genelde bir tahtaya sıralı şekilde story cardlar dizilirler. Yazılımgeliştiriciler öncelik sırasına göre story cardlardan seçimini yaparve geliştirmeye başlarlar. Geliştirdiği story card işlemi bittikten sonra tahta üzerinde bittiğine dair işaret koyar, böylece işin geldiği aşamayı diğer programcılar da rahatlıkla takip edebilirler.