Teorik bilgiler sürekli olarak gerçekte olmayan bir proje ile ilgili idi ve başlarda biraz ütopik geldiğini itiraf etmeliyim.
Özellikle pair programming'in yönetici ve firma sahiplerini ürküttüğü bir gerçek, tek işi yapması için iki kişiye maaş ödemek ülkemiz koşulları için fazla iddialı gözüken bir uygulama.
1. Test Test ile ilgili genel makale için tıklayınız.
Test konusunda yöneticiler açısından çok katı bir yaklaşım bulunmakta, eğer iş gereksinimleri arasında testler yok ise veya hayati önem taşıyan bazı embedded sistemler sözkonusu değil ise, uygulayan kuruluş sayısı yok denecek kadar az.
Temel sebep, testin aslında gereksiz olduğunun düşünülmesidir. Sonuçta, yazılımsal testler, unit test vs., yazılımı direkt etkilemeyen şeyler arasında, bazı görüşler testlerin fazla idealist ve akademi yaklaşımı olduğunu savunmaktadır. Bu konuyu yöneticilere kabul ettirmek çok zor.
Extreme programming içerisindeki test yaklaşımı ise, genel olarak, sistemin testlerinin tümünün aynı yerde olması şeklinde. Yani, unit test, integration test, acceptance test gibi değişik testler değil, sadece bir tane test var, o da sistemi komple test ediyor.
Bence bu yaklaşımın avantajları ve dezavantajları var, testlerin ayrı olmaması, sistemin tamamının test edilebilirliğini artırıyor, ayrıca, bu şekilde test yazmak, ayrı ayrı testler yazmaktansa nispeten daha kolay ve daha az zaman alan bir iş.
Dezavantajlarına gelince, extreme programming veya agile metodolojilerin tümü gibi, testler, sadece üzerinde çalışılan sistem için geçerli. Yani sistemin bir parçasını alıp başka bir uygulamada kullanmanız durumunda - ki tamamiyle agile gidiyorsanız bu ne kadar olası o da ayrı bir tartışma konusu - testler eski sistemle beraber atılmak zorunda kalınıyor. Bu da özellikle bu durum için sakınca teşkil eder, zira testlere en çok ihtiyaç duyacağınız zaman refactoring zamanı, yani yazılımın belli kısımlarını alıp yeni bir sistemle beraber çalışması için değiştirmek istiyorsanız, testler size hangi değişiklikte nereyi bozduğunuzu işaret ettiğinden, değişiklik çok daha hızlı ve hatasız yapılabilir.
Extreme ile gidiyorsanız, eski testleriniz tamamen işe yaramaz durumdadır.
2. Test Driven Development
Agile'ın yaygın uygulamalarından birisi, test driven developmenttir. Yani, önce yazılım testleri yazılır. Daha sonra bu testlere uyacak olan kodu yazarsınız. Bu testler, büyük çoğunlukla yazılımın gereksinimlerinden oluşur, ayrıca boundary condition gibi durumlar da test edilir. Testler, sistemin çalıştığı zaman karşılaması gerektiği özelliklerin çerçevesini çizmiş olur. Daha sonra, bu testleri geçecek uygulama kodu yazılmaya başlanır. Class tanımlamaları dahi, önce bir miktar test yazıldıktan sonra yapılır.
Önce test yaklaşımından kasıt, testlerin tamamı bittikten sonra kodlamaya geçiş değildir, ki zaten agile practicelerde bir şeyin tamamını implement etmek gibi bir durum olamaz. Burada önemli olan nokta, önce bir miktarda olsa test kodu yazıp sonra o test kodunu geçecek kodu oluşturmak sonra tekrar test yazmaktır.
Test driven development ile yazılım geliştirmeyi biraz denedikten sonra hakikaten çok zevkli bir yöntem olduğunu hissettiğimi söylemem gerekir.
Bu yaklaşım her zaman kafamda bir takım sorular bıraktı. Öncelikle, mimari ile ilgili bir takım endişelerim vardı, test driven development yaparken nasıl mimari kurulabilir ? Buna agile takip edenlerin cevabı, refactoring esnasında olacaktır. Kod yazıldıktan sonra, kod yazma süreci içerisinde, kısa aralıklara, süreç içerisinde olan refactoring yapılması extreme in uygulamalarından bir tanesidir. Bu seanslar içerisinde kodun kendi kendisine şekilleneceği ve sistemin bir mimariye sahip olacağı şeklinde bir açıklamadır. Bunun sistemin ufak kısımları için olası olduğunu, ancak büyük çaplı değişiklikler, yani sistemin tamamını etkileyecek değişikliklerin bu yolla yapılamayacağı gibi bir gözlemim var.
Ayrı seanslar olarak yapılan mimari çalışmalar, unified processde olduğu gibi, kodu daha derli toplu tutarak merkezi bir kontrol sağlamakla beraber, software architect türü kişilerin bu işi yapmasına olanak sağlıyor. Extreme için koç roluü dışında tüm roller yazılımcı rolüdür, dolayısı ile bir kişinin diğerleri üzerinde bilgi üstünlüğü veya sistemi değiştirme yetkisinin olması pek yaygın bir anlayış değildir.
Başka bir durumda, test driven gidildiği zaman, extremein çoğu prensibinde karşılaşılan reuse sıkıntısıdır. Mevcutta hazır bir kod kütüphaneniz var ise test driven ile bunu hayata geçirmeniz pek mümkün değildir, çünkü her projede kod o anki ihtiyaçlara göre tekrar yazıldığından, hazır componentların implementasyonu düşünülmez.
Ayrıca, agile mantığı içerisinde olan o anda ihtiyaç olmayan özellikleri yazılıma eklememe mantığı ile gidildiği için sadece o kısımın sorunlarını çözecek olan bir kod parçası yazılacağından bu şekilde yazılan kodun tekrar kullanılabilme olasılığının çok az olmasının yanısıra, böyle üretilen uygulamaların, üretimi isteyen kurum dışında başlka kurumda implementasyonu da çok zordur, çünkü direk o kurum ihtiyaçlarına göre dikilmiş bir elbisedir.
3. Pair Programming
Pair programming, kavram olarak, iki yazılımcının bir bilgisayar karşına geçip, sırayla klavyeyi almaları ve kod yazmaları şeklindedir. Bu çiftteki kişilerin ikisi birden aynı anda kod yazamaz, yazmamalıdır. Birisi yazarken diğeri onu seyretmelidir. Tabii bu klavye değiştirme aralığı çok uzun bir aralık olmamalı, mesela 15er dakika ara ile yer değiştirilmelidir.
Uygulama esnasında, bir pair çalışmasında, bir kişinin test yazıp diğer kişinin kod ile bu testi geçtiği, daha sonra diğer kişinin başka bir test yazıp kod yazan kişinin tekrar onu geçmeye çalıştığı, daha sonra yerlerini değiştirdikleri bir uygulama gördüm. 3 er dakika ara ile klavye değiştiriyorlardı, ve aradaki tatlı rekabet gerçekten korkunç bir iş tatmini sağlıyordu.
Tek bir yazılımcının performansının pair performansı yanında 1/4 oranında olduğu kanaatindeyim, henüz bunu destekleyecek deneysel verilerim olmasa da, yazılım yaptığım süre boyunca, yanımda bir arkadaşımla beraber yaptığım herhangi bir çalışma esnasında, farkettim ki, daha kolay düşünebiliyor ve daha az kilitlenmeler yaşıyorum. Tek başıma kolayca çözemediğim bazı noktalarda çok hızlı sonuca gitmem mümkün oldu.
Kod yazma esnasında yazılımcı kendisini o andaki koda kaptırır ve sistemin tamamını düşünmeye çalıştığı zaman, biraz büyük yazılımlar için, kilitlenme noktasına gelir. Extreme deki uygulama, bir kişinin sistemin o anki durumuna odaklanırken diğerinin aynı zamanda sistemin tümünü de düşünüyor olmasıdır.
Pair programming esnasında, sürekli olarak aynı pairlerle çalışılmaz, eş değiştirme olayı sürekli devam eder. Yani iyi anlaşan iki kişinin sürekli bir arada olma ihtimali yoktur, ekip içerisinde sürekli bir pair sirkülasyonu vardır. Bu sayede, bir pair şu kodu ben yazdım diye bir iddiada bulunmaz, kod tüm ekibindir ve Extremein prensiplerinden biri olan kod sahipliğinin olmaması durumunu bu şekilde sağlanır.
Eş değiştirme esnasında, herkes sistemin tamamını öğrenir ve hiçbir bilgi ekipte belirli kişilerde kalmaz.
Bu durumun bir dezavantajı, kimsenin özelleşemeyecek olmasıdır. Persistence konusunda özelleşmiş kişiler veya prezentasyon konusunda özelleşmiş kişilerin getirebileceği hız ve avantajlardan mahrum kalınmış olur.
Pair programming in başka bir avantajı, proje esnasında hızlı bir eğitim sağlamasıdır. Ekibe dahil olan acemi yazılımcı, ustaların arasında çalışarak, beraber pair yapıldığı esnada, eğitimde dahi öğrenilemeyecek bazı bilgiler edinir. Çok kısa bir sürede acemi elemanlar iş yapabilecek düzeye ulaşır.
Aynı şekilde projeye yeni katılmış elemanlarda bir süre dolaştıktan sonra kod bilgisine sahip olmaya başlar. Kod sahipliği olmaması ile beraber bu özellik, extremei riskleri minimuma indirme açısından avantajlı yapar, zira en büyük sorunlardan birisi, bir projenin ortasında bazı elemanların ayrılması ile onların yapıtğı tarafın öğrenme sürecine girilme gereksinimi, elemanların ayrılmaması için astronomik maaşlar veya tavizler, en kötüsü projenin tamamen iptali veya kodun baştan yazılması gibi riskler ortadan kaldırılmış olur.
Ekip sürekli sirkülasyon halinde çalıştığı için, daha iyi bir kaynaşma mümkündür. Ekipin bağları daha sıkılaşır. Bu da gerçek ekip çalışmasına sebep olabilir. Tabii bu ekibin içerisine dahil olabilecek ve yazılım sektöründe çok sık görülen 007 tipinde sadece yalnız çalışabilen insanların olması ekip bütünlüğünü ve pair programmingi olanaksızda kılabilir. Çalışan seçiminde bu çok ciddi gözönüne alınması gereken bir faktördür.
Pair programming extreme de uygulandığı şekliyle, özelleşmeyi desteklememesi ile fazla iddialı gelse de, genelde başarılı olarak gördüğüm bir uygulama. Yeter ki yönetimin desteği alınabilsin.
4. Müşteri İlişkileri
Extremein müşteri yaklaşımı kesinlikle en müşkülpesent müşteri ilişkileri departmanını dahi memnun edecek şekildedir, eski deyişle müşteri her zaman haklıdır yaklaşımı mevcuttur. Her şeyden önce, tüm süreç aslında müşteri tarafından yönlendirilir. Müşteri, yazılım ekibinin içerisinde çok uzun sürelerle yer almalı, belirli mesaisini buraya ayırıp sistemin gidişatını kontrol etmelidir. Bu sayede, yazılım projelerinde büyük sıklıkla oluşan müşteri istekleri ve yazılım yetenekleri dengesizliği ortadan kalkmış olacak, çünkü istenmeyen gibi olan bir kısım var ise anında müdahele edilme şans doğacaktır.
Bir prensipte, kodun sürekli derlenebilir ve uygulamanın sürekli çalışır halde olması olduğundan dolayı, müşteri her istediği an uygulamanın son halini çalıştırıp görebilecek, sonrasında düzelttiği yanlış anlaşılmalar veya kendi fikrindeki değişiklikleri implement ettirebilecek, aynı zamanda yazılım yaparken yazılımcının farkettiği bazı şeyleri dinleyerek sistemde buna göre değişiklik isteyebilecektir.
Burada karşılıklı güven esastır, iki tarafta birbirini kandırmaya veya suistimal etmeye kalkmamalıdır.
Burada en önemli soru, ödemenin nasıl yapılacağı ve iş yükünün nasıl kaldırılabileceğidir. Buna cevap da planlama safhasından gelir. Bir özellik eklenmesi istendiğinde, sürecin en başından itibaren, bu özelliğin tahmini süresi ortaya çıkarılır ve iterasyon denilen uygulama versiyon bitişine kadar ekibin ne kadar sürelik iş yapacağı belirlenir .
Aslında bu konu biraz detaylı, çünkü her ekip aynı sürede işi yapamayacağı gibi, genelde yapılan işler birbirlerine de benzemez, o yüzden yazılımda en sıkıntılı şeylerden biri süre tespitidir. Extreme in bu konudaki çözümü, özelliklere süre değil puan vermek ve ilk safhalarda tespit edilen ne kadar sürede ne kadar puanlık iş yapıldığını tespit ettikten sonra belirli süreler için puan miktarında göre yapılacak işleri kararlaştırmaktır. Puanlama yazılım ekibi tarafından yapılsa da, o süre için yapılacak işlerin seçimi müşteri tarafından yapılır.
Ödeme, süreye bağlı olarak olur. Müşteri istediği özellikleri belirtir ve ekip bunun ne kadar sürede yapılabileceğini iletir. Yazılım ilerledikçe müşteri istediği anda süreci kesip bu bana yeterli diyebilir veya yeni özellik isteyebilir. Çalışılan süre kadar ödeme yapılır. Tabii bu durum, ihale gibi işlerde bu yöntemin kullanımını imkansız kılıyor, ayrıca karşıdaki müşterinin iyi niyetini sağlamak da işi yapan firmanın görevidir, öncelikle kendisine güvendirmesi gerekir.
İşi yaptıranın gerçek bir müşteri olmaması durumunda, paket program vs gibi yazılımlarda, müşteri olarak birisi seçilir, bu satış departmanından birisi olabilir, müşteri gibi davranarak onun yerine geçer.
Bu yaklaşımı doğru buluyorum, zira artık devir yazılım sahibinin istediğini yaptığı devir değil, öyle bir devir vardı, yazılımcının az ve müşterilerin temel ihtiyaçlarının dahi karşılanamadığı bir devir, ancak artık rekabet çok ve müşterinin kaçması çok kolaylaştı.
Devam edeceğimi umuyorum, tembellikte yapabilirim :)
