Daha önceki yazımda bahsettiğim gibi master dersim için extreme programming ile ilgili bir sunum yapmıştım. Projenin ikinci safhası olarak sunumumu derli toplu bir şekilde yazmam istenmişti. Aşağıda da yazdığım yazı bulunmakta. Bir önceki yazıma göre daha derli toplu.

Yazıyı word halinde indirmek isterseniz :Sistem Analizi_XPdoc

eXtreme Programming

Mehmet Mert Öztekin¹

¹Bilgisayar Mühendisliği Departmanı, Bahçeşehir Üniversitesi, İstanbul

¹e-posta: mert@mertoztekin.com                          

Özetçe

Bu doküman, Çevik Programlama metodolojilerinden eXtreme Programming(XP) ile ilgili hazırlanmıştır. Doküman içerisinde XP’nin genel açıklaması, XP projesi takımı, XP pratikleri, ve proje planlamasından bahsedilmektedir.

1.      eXtreme Programming Nedir

1.1.   Çevik Metodolojiler ve Klasik Metodolojiler

eXtreme Programming Kent Beck tarafından ilk defa 6 Mart 1996 yılında ortaya atılan bir Yazılım Geliştirme Metodolojisidir (Software Engineering Methodology). İsmi daha çok yazılımın kodlaması ile ilgili gözükse de aslında tamamen insan iletişimi ve sonuç odaklılık üzerine kurulmuş tüm yazılım sürecini kapsayan bir metodolojidir.

eXtreme Programming, Çevik Yazılım Geliştirme(Agile Software Development) metodolojileri ailesindendir. Çevik metodlar, Klasik yazılım metodolojilerine(Ör: Waterfall) karşı geliştirilmiş ve klasik süreçlerin eksik ve sıkıntılarını giderme üzerine kurulmuştur. Klasik metodolojilerde adımlar,

Gereksinimlerin çıkarılması Analiz Tasarımın yapılması Gerçekleştirim İmplementasyon Test Bakım/Sürdürme

olarak planlanır. Projeye müşteri gereksinimleri çıkartılarak başlanır, analistler gereksinimleri detaylandırır, analizler yapar, muhtemel çözüm yöntemlerini düşünür, arasından en iyisini seçerler, sonra seçilen yönteme göre yazılım tasarımını hazırlarlar sonra gerçekleştirimde kodlama yapılır. Program yazıldıktan sonra testler tamamlanır ve program teslimi yapılır. Program teslim edildikten sonra zaman içinde oluşabilecek sorunlara karşı bakım yapılır. Tüm bu adımlar birbirinden bağımsız olarak yürütülür ve adımlar arasında geçişler çıktı dokümantasyonları olarak teslim edilir.

Bilgisayar programlamanın ilk yıllarında, işlemciler günümüzdekine oranla çok daha yavaştı. Eğer yazılan programda bir hata çıkar ise, bu hatayı düzeltip programı tekrar çalıştırmak günler veya haftalar sürebilirdi. Zaman ve para kaybetmemek için, programı çalıştırmadan önce programın olabildiğince iyi analiz edilmiş, iyi kodlanmış ve iyi test edilmiş olması gerekirdi.

Teknoloji ilerledikçe, işlemciler hızlandıkça ve programlama araçları güçlendikçe yazılım geliştirmede kolaylaştı. Eskiden yazıp test etmesi günler alan bir fonksiyon, günümüzde saatler içinde tamamlanabilmektedir. Çevik metodolojiler de bu varsayımla yola çıkmaktadır. Klasik süreçlerdeki gibi analize ve dokümanlara zaman harcamak yerine, daha az doküman ve analiz ile fonksiyonlar hızlıca kodlanarak müşterinin beğenisine sunulursa, hem müşteri tatmini artacak hem de yazılımın müşteri isteklerini karşılama oranı artacaktır. Müşteri fonksiyonun istediği fonksiyon olup olmadığını, klasik süreçlerdeki gibi uzun zaman sonra değil, kısa aralıklar ile inceleyerek denetleyebilecektir. İşte bu nedenlerle Çevik Metodolojiler günümüzde Klasik metodolojilerin yerini almaktadır.

1.2.   Extreme Programming Nedir

Extreme Programming Basitlik(Simplicity) , Geri Bildirimi(Feedback), Cesaret(Courage) ve İletişim(Communication) üzerine kurulmuş bir yazılım geliştirme metodolojisidir. Klasik metodolojiler, yazılımlarda değişimin zor olduğunu bu nedenle yazılımın her türlü beklenmedik olaya karşı planlanmış olması gerektiğini savunurken, XP yaklaşımı değişimin kaçınılmaz olacağına bu yüzden yazılımın ‘değişime’ kolaylıkla adapte olacak şekilde tasarlanması gerektiğini söyler[1].

1.2.1.           Basitlik

eXtreme Programming projesinin tamamı basitlik üzerine kurulmalıdır. Basitlik, sistemi günün ihtiyaçları ne gerektiriyor ise o şekilde tasarlamaktır. Kodlama, mimari, dokümantasyon, iletişim her şey basit olmalıdır. Basit olmayan her şey projeyi yavaşlatır. Basit tasarlanan bir sistem gelişmelere daha rahat adapte olur. Bu nedenle program ilk başta olabildiğince basit yazılmalı, gelen yeni isteklerde aynı basitlik anlayışı ile sisteme eklenmelidir.

1.2.2.           İletişim

Klasik süreç yaklaşımlarında iletişim, süreçler ve kişiler arasında gidip gelen dokümantasyonlardan ibarettir. eXtreme Programming’e göre proje boyunca çalışan varlıklar insanlardır. İnsanlar normal hayatlarında iletişim kurabiliyorlarsa, neden yazılım yaparken bunu dokümanlar üzerinden yapsınlar. Sağlıklı iletişim kuruldukça ve sürdürüldükçe, müşteri ne istediğini yazılımcılara iletebilir, yazılımcılar birbirlerine kodların nasıl çalıştığını iletebilir ve yazılımcılar müşterilere nelerin yapıldığını iletebilir. Hiç bitmeyen iletişim sayesinde her kişi proje daha fazla hakim olur ve süreç daha sağlıklı ilerler. İletişim gereksinimlerin çıkarılması aşamasında başlatılır ve program tamamen teslim edilene kadar hiç kopmadan sürdürülmelidir.

Müşteri, iş tarafı kararlarını almak ve önem derecesini belirlemek için programcılar ile birlikte çalışır. Müşteri, programı hem kullanacak kişiymiş hem de iş sahibiymiş gibi düşünerek kararlar almakla görevlidir.

1.2.3.           Geri Bildirim

Geri bildirim, sorular sorarak cevaplardan öğrenmek demektir. Müşterinin ne istediğini tam olarak bilebilmek için ona sormak gerekmektedir. Kodun istenen fonksiyonu gerçekleştirip gerçekleştirmediğini anlamak için test etmek gerekmektedir. Ne kadar kısa zamanda geri bildirim alınırsa, önlemler o kadar çabuk alınabilir.

XP hızlı ve sık geri bildirimi destekler. Tüm XP pratikleri kendi içinde geri bildirim içermektedir. XP 3 ana geri bildirim türü vardır:

Testlerden Geri Bildirim : Yazılımın kodlanması süresince ve sonrasında her zaman test yapılır. Bu testlerden çıkan sonuçlar değerlendirilir. Ve programın istendiği gibi çalışıp çalışmadığı denetlenir.

Müşteriden Geri Bildirim : Müşteri geri bildirimi, müşterilere soru sorarak alınan cevaplarla, müşterinin ne istediği, neler planladığı, sisteme genel bakışı konusunda bilgiler edinilir. İş tarafı ile ilgili tüm kanalları müşteri tek başına alacağı için projenin tamamında müşteri görüşleri çok önemlidir.

Yazılım Ekibinden Bildirim : Kodcular, analistler, testçiler proje süresince bilgi ve deneyimlerini birbirleri ile paylaşarak hem ortak dili konuşmaya başlarlar hemde geliştirilen yazılımda daha tutarlı olur. Tüm geliştiricilerin kavramlardan aynı anlamı çıkarması önemlidir ve herkesin ortak kavramları kullanması XP için çok önemlidir.

1.2.4.           Cesaret

XP’de cesaret, zor kararları gerektiğinde almak demektir. Eğer çalışmayan bir özellik var ise düzeltilmelidir. Eğer bir kod yeterince basit ve iyi gözükmüyor ise değiştirilmelidir. Eğer tüm işler söylendiği gibi yetiştirilemeyecekse, bu durum saklanmak yerine müşteriye açıklanmalıdır.

Cesaret XP’de adapte olunması en zor kavramlardan biridir. Çünkü hiçbir proje yöneticisi eksikliği söyleyen kişi olmak istemez. Fakat eksikliği ortadan kaldırmak için ya düzeltilmesi gerekmektedir yada ortaya çıkarılması. XP’de cesaret bu noktada ortaya çıkar.

1.3.   XP Takımı

1.3.1.           Müşteri (Customer)

Müşteri projenin asıl sahibidir. Bu bazı projelerde yazılımı yaptıran olabilirken, bazı projelerde yazılımı yaptırmakla görevli kişide olabilir. Müşteri iş kararlarını almakla yükümlü insandır. Müşteri aşağıdaki soruları cevaplamakla yükümlüdür

• Bu özelik ne iş yapıcak
• Özelliğin tamamlandığını nasıl anlarız
• Ne kadar harcama yapabiliriz
• Özellik üzerinde ne zaman çalışmaya başlayabiliriz

Müşteri, geliştiricilerle birlikte ve yakın çalışır. Hikaye kartları(Story Cards) yazar ve önceliklendirmesini yaparak takvimlendirir. Müşteri temel olarak “Ne” sorusuna cevap veren kişidir. Kabul testlerini hazırlar ve uygulayıp, özelliğin tamamlanıp tamamlanmadığını onaylar.
Müşteri “son kullanıcı” görevini görür. Yani programı kullanacak kişiymişçesine geliştiricileri ve projeyi yönlendirir. In-house bir projede son kullanıcı kendisi olabileceği gibi, dışarıya geliştirilen bir projede de son kullanıcıyı temsilen kararlar almakla yükümlüdür.  XP her zaman müşteriyi tek kişiymiş gibi düşünür. Müşteri tek bir kişiymiş gibi görüş bildirmelidir. Birden fazla müşteri fikri olmadan tek bir fikir ve karar üzerinden gidilmesi projenin sağlığı için önemlidir.

Müşteri Hakları,

• Bir sonraki iterasyona gerçekleştirilecek işleri seçmek
• Proje kapsamını göz önüne alarak, iterasyon planlarında yeni işler eklemek yada var olanları çıkarmak
• Kabul testlerini gerçekleştirerek, projenin gidişatını incelemek

Müşterinin Sorumlulukları,

• Geliştiricilerin teknik kararlarına saygı duymak ve benimsemek
• Riskleri doğru şekilde analiz etmek ve seçilen işlerin birbiri ile uyumluluğundan sorumlu olmak
• En çok getirisi olan işleri önceliklendirmek
• Kesinleştirilmiş hikaye kartları oluşturmak ve geliştiricileri yanıltmamak
• Takım ile birlikte çalışarak her zaman destek olmak ve iş ile ilgili soruları cevaplamak

1.3.2.           Geliştirici (Developer)

Geliştiricinin görevi müşterinin isteklerini yazılıma dönüştürmektir. Geliştirici, müşteri tarafından iletilen User Story’leri incelemek ve istenenleri birebir yazılıma dönüştürmekle yükümlüdür. Geliştiriciler müşteri isteklerine karışmaz, müşteri yerine iş kararları alamazlar. İş kararlarının alınması ile ilgili müşteriye önerilerde bulunurlar. Hangi işin ne zaman ve ne için yapılacağına müşteri karar verir. Geliştiriciler müşteri tarafından talep edilen özelliklerin ne kadar zamanda ve nasıl yapılacağına karar verir ve müşteriyi bilgilendirirler. Geliştiriciler aşağıdaki sorulara cevap verir:

• Nasıl gerçekleştiririz
• Ne kadar zaman alır
• Riskler nelerdir.

Geliştiriciler müşteri ile birlikte çalışarak istenen taleplerin detaylarını öğrenirler. İstenen talebin ne kadar süre alacağını, kendi tecrübelerine ve projenin gidişatına göre tahmin ederler. Bu tahminleri baz alan müşteri, hangi işine ne zaman yapılması gerektiğine karar verir.

Müşterinin yazdığı hikaye kartlarına göre, geliştiriciler görev kartları hazırlarlar. Bu görev kartlarında teknik olarak nelerin yapılması gerektiği açıklanır. Yeni veya denenmemiş teknolojiler konusunda müşterileri uyarırlar.

Geliştirici Hakları,

• Kendi iş yüklerini tahmin etmek
• Tahmin edilebilir ve akla uygun çalışma takvimi
• İş kararlarından uzak durma ve kararı müşteriye bırakma

Geliştirici Sorumlulukları,

• Takıma uyum sağlamak
• Sadece gerekli özellikleri yerine getirmek, projeyi ve kodu olabildiğince basit, iyi tasarlanmış ve tamamıyla test edilmiş şekilde bitirmek
• Müşteri ile her zaman bağlantılı olarak gerçekleştirilen özelliğin istenen özellik olduğundan emin olmak

1.3.3.           Yönetici (Manager)

Yöneticinin görevi geliştiriciler ile müşteri arasında liderlik yapmaktır. Yönetici iki tarafı bir araya getirir ve iki tarafı da gidişattan haberdar eder. Yönetici projeyi kuş bakışı izler. Geliştiricilerin kullanıcı hikayelerini zamanlandırması ve görev kartlarının paylaşmasına yardımcı olur(yardımcı olur, delege etmez), müşteri istekleri bir sonraki iterasyona yetiştirilemeyecekse alınması gereken kararlarda liderlik yapar.

1.4.   XP Pratikleri

XP’de 12 pratik bulunmaktadır. Bu pratikler birbirini destekler ve pratiklerden alınan geri bildirimler karar aşamalarında yardımcı olur. Sadece bazı pratikleri kullanarak iyi program yazmak mümkündür fakat XP en iyi tüm pratikler kullanılırken çalışmaktadır.

Her pratiğin bazı görevi vardır. Pratiklerin görevlerini ve birbirleri arasındaki ilişkileri öğrenmeden parçalar halinde kullanmak projenin başarısız sonuçlanmasına neden olabilir-yeterli birim testi olmadan refactoring yapmak altından kalkılamıyacak hatalara neden olabilir.

XP pratikleri 3 ana konuya ayrılır: kodlama pratikleri, geliştiriciler arasındaki iletişim, iş tarafı ile teknik taraf arasındaki iletişim.

1.4.1.           Kodlama Pratikleri

Kod yazmak, yazılım geliştirmedeki en önemli adımdır. En çok zaman ve kaynak kodlama esnasında harcanır. Bu nedenle XP kodlama konusunda önemli pratikler geliştirmiştir.

1.4.1.1       Kodlama Pratiği 1 : Basitçe Kodlama ve Tasarlama

Hedef: kolaylıkla değiştirilebilen bir yazılım geliştirme

Basitçe kodlama ve tasarlamak için müşterinin varolan isteklerini çözmek gerekmektedir. Gelecekte gelebilecek talepleri karşılamaktan kaçınılmalı ve günün ihtiyaçlarına odaklanmak gerekmektedir. XP’de basitliği sağlamak için 3 kural vardır:

1. Çalışabilecek en basit çözümü yaz (Do the Simplest Thing That Could Possibly Work)
2. İhtiyacın Olmayacak (You Aren’t Gonna Need It)
3. Sadece Bir Kez (Once and Only Once)

Basit tasarımların anlaşılması ve anlatılması daha kolaydır. Basit kod daha kolay test edilir, sürdürülebilir ve değiştirilebilir.

XP’de sistem tasarımına olabildiğince az zaman harcanır. XP ile istenen, zaman içindeki gelişmelere göre sistem tasarımının kendiliğinden oluşmasını beklemektir. Bu fikir diğer yazılım geliştirme metodolojilerinden oldukça farklıdır.

Gelecekte talep edilmesi muhtemel istekleri bugün çözmeye çalışmak gereksizdir ve hem zaman hemde kaynak israfına yol açar. Müşterinin henüz belirtmediği bir talepi gerçekleştirmek kumar oynamak gibidir-müşterinin ne isteyeceğini tam kesinlikle bilemezsiniz-.

Gereksiz özellikler sistemi daha fazla karışıklaştırır. Bu nedenle geliştiriciler, testler çalıştığı sürece kodu mümkün olabildiğince kısaltmak ve basitleştirmelidir.

Basit tasarım,

• Ortak Kod Sahipliğine
• Refactoring kolaylığına
• Daha rahat test yazılmasına

imkan sağlar. Ayrıca basit tasarım için aşağıdaki koşulların sağlanması gerekmektedir:

• Gerekli özelliklerin detaylandırılması için müşteri ile geliştiriciler arasında iyi bir iletişim olması
• Tüm ekibin değişime uyum sağlayabilecek özgüveni olması
• Basitliği her zaman sağlayabilecek deneyime ve isteğe ihtiyaç vardır.

1.4.1.2       Kodlama Pratiği 2: Refactoring (Yeniden Düzenleme)

Hedef: kodu en uygun tasarıma indirgeme

Refactoring, var olan ve çalışan program kodunu yeniden düzenleyerek olabildiğince temiz ve basite indirgeme işlemidir. Refactoring yapılarak tüm sistem daha basit, daha kolay değiştirilebilir ve daha kolay sürdürülebilir hale getirilir.

XP refactoring işlemini olabildiğince sık yapmayı önerir. Yazılan kod test edildikten ve sorunsuz çalıştığı anlaşıldıktan sonra refactor edilerek daha basit ve anlaşılır hale getirilmeye çalışılmalıdır. Sonuç olarak çıkacak kod yeniden değiştirilmemiş testlere uygulanır ve testlerin sorunsuz çalışıyor olduğu denetlenir. Uzun fonksiyonlar daha küçük ve anlamlı fonksiyonlara parçalanır. Değişken ve fonksiyon isimleri daha anlamlı ve standart isimler ile değiştirilerek anlaşılabilirlik arttırılır. Sonuç olarak daha kolay okunabilen, anlaşılabilen ve değiştirilebilen kod ortaya çıkartılır.

Refactoring tüm sistem tasarımını daha basitleştirir. Kodun tasarımını değiştirirken, programın fonksiyonları ve çıktıları değiştirilmez. Refactoring yapılmadan önce çalışan bir test, refactoringden sonrada çalışıyor olmalıdır.

Refactoring esnasında kod silmek çok olasıdır ve bundan kaçınılmaması gerekmektedir. Gereksiz bir kod-yazılması ne kadar zaman alsada- çalışan sistemden çıkartılmalıdır. Böylece basitlik ve yalınlık sağlanır. Ayrıca benzer fonksiyonu olan kodlar birleştirilip tekilleştirilerek sürdürülebilirlik kolaylaştırılır.

Refactoring,

• Basit mimari tasarıma
• Disiplinli ve tüm takım tarafından anlaşılır koda

imkan sağlar. Ayrıca refactoring için aşağıdaki koşulların sağlanması gerekmektedir:

• Disiplin, refactoring gereksinimlerini ve çözümlerini uygulamak
• Refactoringi daha güvenli yapabilmek için kapsamlı testler oluşturmak
• Tüm kodları değiştirebilmek için ortak kod sahipliği
• Takımla uyumlu değişiklikler yapabilmek için kodlama standartları

1.4.1.3       Kodlama Pratiği 3: Kodlama Standartları

Hedef: fikir iletişimini kod üzerinden sağlama

Kodlama standartları, geliştiricilerin kod üzerinden bilgi alış verişi yapabilmeleri için gereklidir. Program kodu, proje içindeki ana iletişim aracıdır. Özellik talepleri, dokümanlar her zaman dolaşır fakat yazılım projeleri kod ile yaşar.

Kodlama standartları alışkanlıktır. Tecrübe ve zamanla oluşurlar. Proje içinde de gelişmeye devam ederler.

İyi bir kodlama standardı emirlerle değil önermeler ile sağlanır. Projenin gidişatına göre tamamıyla değişebilir. Takım olarak çalışmak için takımın her üyesinin aynı dili konuşuyor ve yazıyor olması çok kritiktir. Bu hem hız kazandırır hemde hata olasılığını azaltır.

Kodlama standartları kısa ve akılda kalıcı olmalıdır. Kodlama standartları dokümante edilirken, standartların neler olduğu ile birlikte neden konduğu örnekler ile açıklanmalıdır. Böylece herkes ezberlemek yerine mantığı anlayarak daha rahat adapte olur.

Kod standartları,

• Kolay Refactoring yapılmasına
• Etkin şekilde eşli programlamaya
• Ortak kod sahipliğine

imkan sağlar. Ayrıca kod standartı için aşağıdaki koşulların sağlanması gerekmektedir:

• Geliştiricilerin takım oyununa uyum sağlaması
• Geliştiricilerin iletişimi iyi kurması

1.4.1.4       Kodlama Pratiği 4: Metafor Oluşturmak

Hedef: kodlama mantığını belirginleştirme

Proje ilerledikçe ortak bir metafor gelişir. Bu metafor sistemin çalışması konusunda bilgi vermek için yararlıdır. Oluşturulan metaforlar ciddi veya gayri ciddi olabilir. Amaç çalışma mantığını kolaylıkla anlaşılır şekilde takım içinde anlatabilmektir. Açıklayıcı ve akılda kalıcı olması gerekmektedir. İyi bir metafor, özenle hazırlanmış UML diyagramlarından çok daha kullanışlı olabilir.

Proje ilerledikçe metaforun gelişmesi ve sistemin güncel durumunu açıklayabilir halde tutulması gerekmektedir. Kodlama gibi metaforlarda olabildiğince kısa ve basit olmalı fakat sistem parçalarını anlatabilmek için yeterli bilgiyi barındırması gerekmektedir.

Metafor oluşturmak,

• Geliştiricilerin tüm sistem çalışması konusunda bilgi sahibi olması nedeniyle Ortak kod sahipliğine
• Basitliği ve kolay anlaşılırlığı sayesinde müşteri ve teknik kişiler arasında iletişim kolaylığına
• Basit sistem tasarımına

imkan sağlar.

1.4.2.           Geliştirici Pratikleri

1.4.2.1       Geliştirici Pratiği 1: Test Güdümlü Geliştirme

Hedef: kodun istendiği gibi çalıştığını görmek

XP’de ilk önce test yazılır. Test kod çalışmadığı için başarılı olamaz. Testi başarılı kılan kod yazılır. Yazılan kod refactor edilir ve testler tekrar yapılır. Bu döngü her zaman devam eder ve amaç yazılan testlerin doğru sonuç verdiği refactor edilmiş kodun yazılmasıdır.

Geleneksel test methodları, yazılan kodun düzgün çalıştığını görmek için yazılan test kodlarından oluşur. İlk önce program yazılır daha sonra ise programın düzgün çalışıp çalışmadığı kontrol edilir. Geliştirici programı yazdıktan sonra testlerini oluştururken, kodunun çalıştığına görmek için test yapmasıdır. XP’de ise önceden test hazırlanır ve testlerden geçen program kodu yazılmaya başlanır. Böylece geliştirici sonuç odaklı kod yazar ve buda işe odaklanmasını kolaylaştırır.

Bir iş sadece gerekli tüm testleri yazılmış ve başarıyla çalıştırılmış ise bitmiştir. Testi olmayan veya %100 başarı ile çalışmayan işler bitmiş sayılmaz ve bunun istisnası yoktur. Sisteme eklenen her yeni özelliğin testide olacağı için zaman içinde bir test ‘arşivi’ oluşur. Bu testler sıklıkla çalıştırılarak tüm sistemin sorunsuz işlediği denetlenir. Testler otomatik çalışacak şekilde olmalıdır. Bunun için kullanılan bir sürü unit testing frameworkü bulunmaktadır(c# için csUnit, Java için jUnit, PHP için phpUnit gibi). Projeye başlamadan önce unit test frameworkünüzü seçip kurulması ve tüm geliştirici ekibin bu framework konusunda yeterli eğitimi olması gerekmektedir.

“Hata yapabilecek herşey test edilmelidir”. Bir fonksiyon yazılırken fonksiyona ilişkin sorun çıkarması muhtemel her şey için test kodları yazılır.

Birim testleri kodun kalitesini arttırır ve programcıya rahatlık ve cesaret sağlar. XP’de çok fazla refactoring sıklıklıkla yapılmaktadır. Otomatik testler olmadan refactoring yapmak oldukça risklidir. Eğer yeterli test kodu varsa, refactoring yapıldıktan sonra tüm testlerin %100 çalışıyor olduğu kontrol edilmelidir. Ayrıca test kodları farklı geliştiricilerin kodları anlamaları içinde yardımcı olur. Kodun hangi işlemleri yaptığını test kodlarına bakılarak çözülebilir.

Birim testlerin önemi özellikle proje büyüdükçe ortaya çıkar. Yazdığınız her kod için test kodları yazdığınız için zamanla çok büyük bir test kodunuz oluşur. Bu iyidir çünkü tüm sistemin çalışmasını tek tuşa basarak ve tüm testleri çalıştırarak kontrol edebilirsiniz. Yazdığınız yeni kodlarda veya eskileri değiştirdiğinizde tekrar tüm testleri çalıştırarak sorunları takip edebilirsiniz. Eğer yeni bir eklentiden eski testlerde sorun çıkar ise sorunun yeni gelen eklenti ile ilgili olduğu kolaylıkla takip edilebilir.

Kabul testleri müşteriler ile birlikte tasarlanır ve gerçekleştirilen özelliğin, müşteri tarafından istenen özellik olup olmadığı denetlenir. Her iş için kabul testleri müşteri ile birlikte yazılmalıdır. Eğer tüm kabul testleri geçerliyse, o iş tamamlanmış demektir.

Test güdümlü geliştirme,

• Kolay Refactoring yapılmasına
• Sık tümleştirme yapılarak son durumun bir sistem üzerinde görülebilmesine
• Testler doküman olarak da kullanılabileceği için ortak kod sahipline

imkan sağlar. Ayrıca test güdümlü geliştirme için aşağıdaki koşulların sağlanması gerekmektedir:

• Geliştiricilerin test odaklı düşünmesi
• Kabul testlerini hazırlamak için müşteri ile iyi bir iletişim

1.4.2.2       Geliştirici Pratiği 2: Eşli Programla(Pair Programming)

Hedef: bilgi, deneyim ve fikirleri yaymak

XP’de programcılar çiftler halinde çalışırlar. Yani 2 programcı tek bilgisayarda çalışır. Programcının biri klavye başında kod yazarken diğeri de hem kodu kontrol eder hem de tüm sürece hakim olmaya çalışır. Programcı algoritmayı çözmeye çalışırken, diğeri sisteme uyumlu kod yazıldığından emin olur. İki programcının birlikte çalışması birbirlerini sonuç odaklı ve ‘uyanık’ kalmasında yardımcı olur. Programcılar tek başına çalışırken işe odaklanmakta zorluk yaşabilir.. Eşli programlamada programcılar birbirlerini durmadan “uyanık” tuttukları ve göreve birlikte odaklandıkları için ortaya daha kaliteli ve hızlı yazılmış bir kod çıkar. Hata sayısı daha az olur. Çiftler kendi içlerinde kısa aralıklarla durmadan görev değişimi yaparlar. Böylece çifti oluşturan iki kişide hem yazılan koda hem de sisteme daha rahat adapte olur. Ayrıca sık sık çiftlerde değişir, böylece herkes tüm sisteme olabildiğince hakim olur.

Genel yaklaşım iki programcının ayrı ayrı çalışarak daha fazla işi daha kısa zamanda tamamlanabileceğini söylemektedir. Fakat büyük projelerde bir kodun hızla yazılmasından çok, kaliteli yazılması daha önemlidir. Çünkü hızlı yazılan kod hataya daha açıktır ve genelde programlardaki hataları bulup düzeltmek ciddi bir zaman ve kaynak kaybına yol açabilir. Ama eşli programlama ile kod kalitesi arttığından, bakım ve destek masrafları azalır.

Programcılar genellikle yalnız çalışmayı severler. Eşli programlama ise sosyal bir olgudur. İki programcının kişisel egolarını geride bırakıp, işe ortak bir şekilde odaklanıp çalışması gerekmektedir. Bu hissiyatı sağlamak biraz zaman alabilir ama XP’ye göre eğer eşli programlama sağlanabilir ve tüm ekip buna ayak uyduru ise, proje çok daha sağlıklı ve hızlı şekilde ilerler.

Eşli Programlama,

• Ortak kod sahipliğine
• Test odaklı kod yazmaya
• Basit tasarım ve refactoringe
• Güçlü geliştirme pratiğine
• Uyumlu takım çalışmasına ve yüksek morale

imkan sağlar. Ayrıca eşli programlama uygulayabilmek için aşağıdaki koşulların sağlanması gerekmektedir:

• Eşli programlamaya uygun fiziksel ortam
• Eşli programlamayı uygulamak isteyen programcılar
• Eşli programlamayı uygulatmak isteyen yöneticiler
• Kodlama standartları

1.4.2.3       Geliştirici Pratiği 3: Ortak Kod Sahipliği(Collective Code Ownership)

Hedef: kodun sorumluluğunu tüm takıma yaymak

Ortak kod sahipliği, tüm geliştiricilerin sistemi oluşturan tüm kaynak kodu üzerinde eşit haklara sahip olması demektir. Her geliştirici gerektirdiği durumlarda istediği kodu değiştirebilir. Böylece kişiler kendi görevlerini tamamlamak için başka geliştiricileri beklemek zorunda kalmazlar. Yapılan her değişiklikten sonra testler çalıştırıldığı için sistemin hala istendiği gibi çalıştığı kontrol edilebilir.

Ortak kod sahipliğinin farklı bir türü olan özgün kod sahipliğinde alt sistemler yada modüller belli geliştiricilerin kontrolündedir. Bu alt sistemi yada modülü ilgilendiren bir değişiklik gerektiğinde, o geliştiricilerden değişiklik yapması istenir. Eğer kişi meşkul veya uygun değilse, istenen değişiklik yapılana kadar proje bekler. Böylece iş ve zaman kaybı oluşur.

Ortak kod sahipliği ile kodların ortak kullanılarak daha anlaşılır ve yalın olmasıda sağlanır. Herkes her kodu okuyabildiği için sistem içine yazılan yeni kodlarda var olan kodlara benzeyeceği için doğal bir kodlama standartı oluşur. Böylece her geliştirici her kodu okumakta rahatlık yaşar.

Ortak Kod Sahipliği,

• Her geliştiricinin sistemin tamamında rahatlıkla Refactoring yapabilmesine
• Eşlerin daha rahat yer değiştirmesine olanak

imkan sağlar. Ayrıca ortak kod sahipliğini uygulayabilmek için aşağıdaki koşulların sağlanması gerekmektedir:

• Geliştiricilerin rahat kod okuyabilmesi için Kod Standartları
• Yapılan değişikliklerin sorun yaratıp yaratmayacağını görebilmek için hazırlanmış birim testleri
• Tüm geliştiricilerin aynı kodu düzenlediğinden emin olmak için sık bütünleştirmeleri
• Değişikliklerin nerede yapılacağını bulabilmek için metaforu

1.4.2.4       Geliştirici Pratiği 4: Devamlı Bütünleştirme(Integrate Continually)

Hedef: yeni özelliklerin eklenmesindeki riskleri azaltma

Yazılan yeni özellikler sık sık ana kaynak kodu ile bütünleştirilerek, sistemin son halinin olabildiğince güncel olması gerekmektedir. Güncellenen ana sistemde testler çalıştırılarak yeni eklenen özelliklerin herhangi bir soruna yol açıp açmadığı incelenmelidir.

Geliştiriciler bir işi yazmaya başlamadan önce ana kaynak kodunu kendi çalışma ortamlarına indirerek en güncel versiyon üzerinde kod yazdıklarından emin olmalıdır. Böylece aynı anda farklı işleri yapan geliştiriciler bütünleştirme esnasında en az karışıklıkla mücadele ederler. Aksi taktirde, bir işi tamamlayan geliştirici, bütünleştirme esnasında değişiklikleri yaptığı kodların eski olduğunu fark ederse, bütünleştirme esnasında, güncel olan kodda sorun yaratmamalıdır. Bu riski en aza indirmek için, geliştiriciler çalıştıkları kodları olabildiğince güncel tutmalı ve sık sık bütünleştirerek diğer geliştiriciler ile paylaşmalıdır.

Devamlı Bütünleştirme,

• En güncel kodu refactor ederek daha iyi bir kod oluşturmaya
• Ana kaynak kodunu olabildiğince hızlı güncelleyerek daha seri yeni sürüm çıkartılabilmesine

imkan sağlar. Ayrıca devamlı bütünleştirme yapabilmek için aşağıdaki koşulların sağlanması gerekmektedir:

• Güçlü özellikleri olan bir kod havuzu programı (Repository)
• Bütünleştirme sonrasında sorunları farkedebilmek için testler
• Testleri hızlandırmak için otomatik bir test yazılımı

1.4.3.           İş Tarafı Pratikleri

Başarılı bir yazılım projesi sadece program kodundan oluşmamaktadır. Çok iyi test edilmiş tasarlanmış ve kodlanmış bir program, eğer müşterinin isteğini karşılamıyorsa, kullanışsızdır. Bu nedenle iş tarafından gelen taleplerin iyi yönetilmesi, iyi bir iletişim ağı ve ortak bir dil XP projelerinde çok önemlidir. Müşterinin işle ilgili karar alması, geliştirici tarafın teknik kararları alması birbirinden bağımsız iki süreç olsa da birbirini itekleyen ve destekleyen kavramlardır.

1.4.3.1       İş Pratiği 1: Müşteriyi Takıma Dahil Etmek

Hedef: iş tarafı ile ilgili açıkları hızla muhatabına yöneltebilmek

XP takımı sadece teknik kişilerden oluşmaz. XP takımında müşterilerde vardır. Müşteri iş tarafını temsilen takımda bulunur ve iş tarafı adına sorulara cevaplar verir ve iş tarafının kararlarını alır. Müşteri mümkünse tüm proje boyunca takım ile birlikte çalışmalıdır. Teknik taraf aklına takılan soruları kendilerince cevaplandırmak yerine müşteriye sormayı tercih etmelidir.

Müşteri planlamalarda eklenmesi gereken özellikleri belirler. Aynı şekilde özelliklerin istendiği gibi yapılıp yapılmadığını kabul testleri ile denetler. Bu testleri geliştiriciler ile birlikte yapar ve böylece onlarında hayal edilen sistemi anlamalarına yardımcı olur. Müşteri projenin kapsamı ve hedefini belirleyen kişidir ve bunu olabildiğince saydamlıkla yapar. Teknik kararlara karışmaz.

Müşterinin takıma dahil edilmesi,

• Planlamaların daha rahat yapılmasına
• Yaratılan yeni özelliklerden beklenenin karşılanıp karşılanmadığını kabul testleri ile incelemeye
• Sık sık yeni sürümler çıkartabilmeye

imkan sağlar. Ayrıca müşterinin takıma dahil edilebilmesi için aşağıdaki koşulların sağlanması gerekmektedir:

• Müşterinin projeye dahil olabilecek zamanı olması
• Teknik tarafla rahat anlaşabilmek için metafor

1.4.3.2       İş Pratiği 2: Planlama Oyunu

Hedef: en önemli işi planlamak

Planlama oyununda taraflar bir araya gelerek bir sonraki iterasyonda hangi ihtiyaçların karşılanacağına karar verirler. Planlama oyununun hedefi programa en çok değer katacak ihtiyaçların karşılandığını belirlemektir.

XP planlamaları iterasyonlar arasında yapılır. Bir iterasyon tüm geliştirme safhalarının bir kez tamamlandığı süredir. Müşteri yeni özellik ister, takım planlamasını yapar. Planlamaya göre kodlama, test ve bütünleştirme yapılır. Bu süreç 1 ila 4 hafta arasındadır.

Planlama oyunu her sürüm takviminin başında yapılır. Müşteri hikaye kartlarına istenen özellikleri yazar. Bu özellikler iş tarafınca, teknik bilgi içermeden, istenen fonksiyonu belirtir. Hikaye kartlarına bakarak, geliştiriciler tahmini geliştirme süresi verirler.

Hikaye kartlarına ve tahmini sürelere bakarak, müşteri hangi isteklerin sürüm planına dahil edileceğini, hangilerinin erteleneceğini belirler. Eğer bir sonraki sürüme kadar boş zaman kalırsa yeni özellikler ekleyebilir. Her istek bir iterasyondan daha kısa sürede tamamlanabilecek zorlukta olmalıdır. Eğer bir istek bir iterasyonda tamamlanamayacak ise, müşteriden bu isteği daha küçük parçalara bölmesi istenir. Böylece iterasyon sonunda işe ilişkin en azından bir parçanın müşteri kabul testine çıkarılması sağlanır.

İş istekleri belirlendikten sonra, geliştiriciler bu işleri alarak kendilerine görev kartları(task card) oluştururlar. Her görev kartında istenen işi tamamlayabilmek için gerekli teknik düzenleme veya eklenti yazılır. Her kullanıcı hikayesinin en az 1 görev kartı bulunmalıdır. Görev kartında kodlama-test-refactoring yapabilmek için yeterli bilgi olması gerekmektedir.

Hikaye kartları, iş tarafınca katkı değer sağlayacak özellikler göstermelidir. Program kullanıcılarının hemen fark edeceği ek özellikler olabileceği gibi, geliştiricilerin önerileri ile alt yapıda yapılacak geliştirmelerde olabilir. Buna veritabanı değiştirmek yada yeni bir alt yapı yazılımı güncellemesi olabilir. Bu tür alt yapı geliştirmelerinin yapılmasına karar vermek de müşterinin görevidir. Teknik taraf bu tür geliştirmeler konusunda müşteriyi ikna etmeye çalışır.

Planlama oyunu,

• Sadece müşterinin istediği istekler sağlanacağı için basit bir sisteme
• Sık sık yeni sürümler çıkartabilmeye

imkan sağlar. Ayrıca planlama oyunu için aşağıdaki koşulların sağlanması gerekmektedir:

• Takımla durmadan iletişim kuran aktif bir müşteriye
• Teknik kararları almak için müşterinin geliştiricilere, iş kararları almak için geliştiricilerin müşteriye karşılıklı saygı göstermesi

1.4.3.3       İş Pratiği 3: Sık Sürümler

Hedef: müşteriye yatırımlarının karşılığını sık sık göstermek

Her iterasyondan sonunda kabul testlerini tamamlandıktan sonra yeni bir program sürümü oluşturularak müşteriye teslim edilmesi müşteri için iyi bir avantaj sağlayacaktır. Böylece kısa vadede yatırımlarının karşılığını almaya başlayacak ve her yeni sürüm ile birlikte yazılımdan daha fazla fayda sağlayacaktır.

Sık sürümler sistemde bulunan hataların düzeltilmesi içinde faydalıdır. Kısa aralıklarla çıkan sürümler sayesinde kullanılan sistemdeki hata sayısı mümkün olduğunca alt seviyelerde tutulur. Eğer müşteri yakın zamanda yeni sürümle var olan hataların düzeleceğini biliyor ise bu hatalı özellikleri yeni sürüm gelene kadar kullanmamayı tercih edebilir.

Sık sürümler çıkartıldığından, gelişmelere göre daha iyi geri bildirim alınabilir. Böylece planlama oyununda karar alınırken bu geri bildirimler göz önünde tutularak işlerin önem derecesi belirlenebilir.

Sık sürüm yapabilmek için, sürüm yönetimi kuvvetli ve otomatik olmalıdır. Yeni sürüm çıkarma işlemi olabildiğince az efor harcanan bir şekilde planlanmalıdır ve uygulanmalıdır.

Müşteri sık sürümleri takip ederek projeye daha hakim olabilir. Yazılımın gidişatına göre projenin tamamlandığında alacağı faydanın hayal ettiği faydadan az olabileceğini görüp projeyi durdurma kararı alabilir. Tam tersi, alınacak faydanın hayal edilen faydadan fazla olduğunu görüp, projeye daha fazla kaynak ayırılmasını isteyebilir.

Sık sürümler,

• Müşterinin planlama oyununda takvimi daha efektik güncelleyebilmesine

imkan sağlar. Ayrıca sık sürüm çıkarabilmek için aşağıdaki koşulların sağlanması gerekmektedir:

• Iterasyonların kısa ve yönetilebilir olması için basit tasarım
• Tüm sistemin istendiği gibi çalıştığını görmek için otomatik testler
• Sürüm oluşturulabilir bir ortam sunabilmek için sık bütünleştirme
• Iterasyonda önem derecelerini belirleyebilmek için planlama oyunu

1.4.3.4       İş Pratiği 4: Dayanılabilir Çalışma Hızı

Hedef: eve bitkin değil yorgun gitmek

Her insanın doğal bir üretim seviyesi vardır. Bu seviye insandan insana değişkenlik gösterse de fiziksel ve zihinsel olarak bu üretimin belli bir limiti vardır. Limitleri zorlamak üretime zarar verir.

Bir iterasyondaki tüm işleri tamamlamaya çalışmak yerine, yetişmeyecek işi o iterasyondan çıkartmak daha risksiz bir seçimdir. İterasyon sonuna kadar yoğun şekilde çalışmak, bir sonraki iterasyon süresince yorgun ve isteksiz olunmasına yol açabilir.

Eğer içerisinde bulunduğunuz iterasyonda yetişmeyecek işler varsa fark edildiği anda takım ile durum paylaşılmalıdır. Başka bir geliştiricinin boş vakti olabilir ve yetişmeyecek iş o kişiye paslanabilir. Eğer başka bir geliştirici çıkmaz ise, müşteriden yetişmeyecek işi yada farklı bir işi iterasyon planından çıkartması istenir. Böylece iterasyon içindeki işler değişmiş olsada toplamda üretim saati sabit kalır.

Dayanılabilir çalışma hızında çalışmak üretimi yüksek seviyede tutar. Yorgun ve yoğun programcılar çözüm ararken, optimal çözüm yerine en kısa çözümü tercih etmeye başlarlar. En kısa çözümü seçmek projenin ilerleyen aşamalarında daha fazla refactoring yapılmasına ve daha fazla zaman harcanmasına sebep olur.

1.5.   İterasyon Planlaması (Iteration Planning)

XP’de her iterasyon, geleneksel yazılım geliştirme süreçlerinin hızlı ve küçültülmüş halidir. İterasyonlar döngü halinde tekrarlanarak proje devam eder.

Her iterasyonda projenin ana amacı sabit kalır-müşteriye en katı değer sağlayacak programı geliştirmek. Müşteriye değer sağlayacak kavramlar zaman içinde değişiklik gösterir. İterasyonlar ile müşteriye karar almada hız ve avantaj sağlanır. İterasyon planlama toplantıları müşterinin yönetiminde geçer. Müşteri yapılması gereken işlere karar verir, teknik taraf bu kararlarında müşteriye yardımcı olur.

Iterasyonların 1 ile 3 hafta arasında olması önerilir. Her iterasyonda hangi isteklerin (user story) yapılacağına müşteri karar verir(Her iterasyonda ne kadar story seçilebileceği zaten süreye göre limitlidir). Bitirilmesi gereken işlere karar verildikten sonra tüm işlere ilişkin geliştiriciler Görev kağıtları (Task) hazırlar. Tüm görev kartları oluşturulduktan sonra dublike olanlar aradan çıkarılır ve programcıların seçilmesi için masaya dizilir. Her programcı çifti istediği görevlere talip olur.

Her iterasyon bitişinde bir sonraki iterasyonda yapılması gereken işlere karar verilmek için toplanılır. Ayrıca biten iterasyonda tamamlanan işler müşteri tarafından kullanıcı kabul testinden geçirilir. Eğer kabul testinden geçemeyen işler olursa bir sonraki iterasyona yeniden eklenir.

1.6.   Sürüm Planlaması (Release Planning)

Sürüm planlaması iki farklı şekli vardır. Zamana göre ve kapsama(scope) göre. Sürümün ne zaman veya hangi işler tamamlandıktan sonra çıkarılacağına müşteri karar verir. Bu bazı durumlarda tek iterasyon sonunda olabilecekken bazende birçok iterasyon sonunda da olabilir. Özellikle projenin ilk safhalarında iş sahibini memnun etmek için sık sık sürüm çıkarımı yapılır.

Yeni sürüm çıkarıp kullanıcılara açmak, müşteri geri bildirimine ciddi katkı sağlar. Çünkü programı asıl yargılayabilecek kişiler programı kullanan insanlardır. Bu insanlara sık sık değişiklikleri göstermek ve değişiklikleri denemelerini sağlamak projenin daha belirgin planlanabilmesini sağlar. Programın nasıl gelişeceği, hangi özelliklerin eksik yada yetersiz olduğu yeni sürümlerin ortaya çıkarılması ile geri bildirim olarak kullanıcılardan alınır.

XP’ye göre bir projede sürüm planlaması yapılırken 4 ana değişken vardır.

Kapsam (Scope)  (Ne kadar iş yapılacağı)

Kaynak (Resource)  (Kaç çalışanın bu projeye dahil olacağı)

Zaman (Time)  (Deadline)

Kalite (Quality)  (Yazılım ve Test Kalitesi)

Bu 4 değişkeni göz önüne alınarak planlama yapılır. Bu 4 değişkenin de aynı anda maksimize edilmesi olanaksızdır. Tüm değişkenler birbirini etkiler(kaliteyi arttırırsanız zaman ihtiyacınız artar. Kapsam artar, zaman sabit kalırsa, kalite düşer vb.). Bazı projelerde bazı değişkenler sabitlenmiş olabilir (Ör. Zaman müşteri tarafından net olarak belirlidir). Bu değişkenler arasında karar kılmak tüm proje ekibinin görevidir ve gerçek doğru bir karar olmamakla birlikte proje ve duruma göre süreç boyunca değişkenlik gösterir.

2.      Kaynakça

[1]     Kent Beck “Extreme Programming Explained” Addison-Wesley Professional

[2]     Kent Beck, Martin Fowler “Planning Extreme Programming”, Addison-Wesley Professional QA 76.76 .D47/B43 2001

[3]     Ron Jeffries, Ann Anderson, Chet Hendrickson “Extreme Programming Installed” Addison-Wesley Professional QA 76.76 .D47/J44 2001

[4]     “Extreme Programming – Pocket Guide” O’Reilly

[5]     www.extremeprogramming.org

[6]     en.wikipedia.org/wiki/Extreme_Programming

[7]     www.jera.com/techinfo/xpfaq.html

---

[1] “Traditional Development says ’Change is difficult, so plan for every contingency before you start’. XP says ’Change is inevitable, so plan to adapt’” Extreme Programing Pocket Guide Sayfa 17