ERPakademi

Extreme programcılık, ‘önce uzun uzun tasarlama, sonra kodlarsın’ fikrinin projelerde baÅŸarısız olması ile ÅŸekillenmeye baÅŸladı. Arkasındaki ilgi, özellikle .com yıllarında daha artmıştır. Bunda, .com projelerinin zorluk ve zamanlama açısından yazılım takımlarına daha büyük yük getirmesi muhakkak rol oynadı. .Com devrinde herkes, piyasaya bir an evvel çıkabilmek için, programcılara ve danışman ÅŸirketlere büyük baskılar uygularken, bu baskıların sonucunda, bitirilmesi için 10-11 ay gerektiren proje idare yöntemleri tabii ki ‘çatlamaya’ baÅŸladı.

Eski yöntemler yerine yeni bir yöntem bulmak gerekiyordu, ve XP bu boşluğu doldurdu.

XP’nin bir ayrı doÄŸuÅŸ noktası, Kent Beck’in müşteri ve programcı gurupları arasında çok katı çizgiler çizmek istemesidir. Kent, bu iki gurubun birbirinin iÅŸlerine karışan ve sonuçta projenin seyrine köstek olan davranışlarını kaldırıp, yerine herkesin kendi iÅŸini gördüğü, ve kimsenin kimseye stres yaratıp, baskı uygulayamayacağı bir ortam yaratmak istedi. Çünkü projeyi bitirip/bitirmemek bir yana, Kent programcıların mutsuz ve motivasyon eksikliÄŸi yaÅŸadığını farketti, ve altta yatan bityeniÄŸini bularak çözümü saÄŸladı.

Müşteri/programcı çizgileri çizilince, müşteri projenin nereye gideceÄŸinin yegane sorumlusu oluyor, fakat aynı zamanda, hiçbir ÅŸekilde programcıya ‘ÅŸu iÅŸi daha hızlı yap’ deme hakkına eriÅŸemiyordu. XP, her dönemde iÅŸin ne kadar hızlı yapıldığını ölçerek, sonraki dönemler için ne kadar iÅŸ planlanacağını tahmin etmeye uÄŸraÅŸtı. Bir kere tahmin yapıldıktan sonra müşteri, özellik listesini ona göre çıkarıyor, ve sonra ‘müşteriliÄŸini bilerek’ daha fazla projeye karışmıyordu. Çünkü programcılık teknik bir olay idi, ve özelliklerin ne kadar hızlı yazılıp yazılmayacağı teknik dünyaya ait bir karardı.

Ayrıca, XP’nin teknik kodlama süreci/yöntemleri alanında da hayati tavsiyeler getirdiÄŸini görüyoruz. Kent, anlattıgı bir hikayede, rastladığı bir programcının öteki arkadaÅŸlarına sürekli fark attığını gözlediÄŸini söyler. Bu farkın altında, programcının her yazdığı 3 satıra takabül 1 satır da birim testi yazdığını farkedince Kent, bu yönteme daha dikkatle bakmaya baÅŸladı. Genelde programcıyı yavaÅŸlatılacağı düşünülen test yazmak eylemi, uzun vadede test eden programcının lehinde büyük farklar doÄŸuruyordu. Çünkü test yazan programcı, kodunu daha cesurca deÄŸiÅŸtirebiliyor, ve mimari deÄŸiÅŸiklikleri bile gözünü kırpmadan yapabiliyordu. Öyle ya, eÄŸer mimari deÄŸiÅŸikliÄŸi yaparken bir hata eklenmiÅŸ olsa, derlemeden sonra sürekli iÅŸletilen birim testleri, bu yanlışı anında yakalayıyordu!

Ve Kent, bu tekniği de XP dağarcığına kattı.

Mekan

Her hikayeye bir mekan gerekir. XP’nin mekanı, C2 projesi denen General Motors ÅŸirketinin bordro kontrol projesidir.

Bu proje, mimari olarak duvara tosladıktan sonra, projede olan Kent, uzun süredir planlamakta XP’yi deneme vaktinin geldiÄŸini anladı. General Motor ÅŸirketi yönetiminden izin istedi, ve kolları sıvadı.

Kent ilk önce, en büyük sorun olarak gördüğü iletiÅŸim sorununu çözdü. Programcılar ayrı odalarda, ya da aynı odada olsalar bile aralarında plastik duvarlarla ayrıli ‘hücrelerde’ iÅŸ yapmaya uÄŸraşıyorlardı, ve tabii ki iletiÅŸim kurmak zor oluyordu. Yazılım projelerinde herkesin bildiÄŸi bir vaka ÅŸudur: Yanınında olmakta olan bir konuÅŸma, sizin için önemli bilgiler içerir, kulak kabartırsınız, ve gerekli ise konuÅŸmaya katılırsınız. Bu gibi bilgi paylaşımı için hücre sistemi ölüm demekti. Ya da, herhangi birine bir soru sormak isteseseniz, ama soru sormak istediÄŸiniz kiÅŸi 50 metre ötede olsa, soruyu sormak için ne kadar zahmete katlanacaksınız? Kafanızı kaldırıp azıcık sesli olarak arkadaşınıza bu soruyu sormak daha iyi olmaz mıydı?

Ufak gibi gözüken bu tip şeyler, çok hızlı gerçekleşen yazılım projeleri için önemli faktörlerdi. Yazılımda, bilinen türden hammadde ve sanayii yoktur, herşey düşünce ve iletişim bağlamında gerçekleşir. Bu yüzden tek bir soru soramamak, hatalı bir kod ile hatasız arasındaki farkı belirleyebilir.

Bunu farkeden Kent, hemen herkesi aynı odada topladı, ve hücre duvarlarını kaldırdı.

Bir sonraki deÄŸiÅŸiklik, sürekli tümleÅŸtirme denen teknik akabinde meydana geldi. Kent, genelde XP yöntemini şöyle tarif eder. “Ä°yi olduÄŸu bilinen yazılım tekniklerinin sesini, sonuna kadar açmak”.

Gereksiz bir ifade gibi gelebilir, fakat örneklerle daha berraklaştırmaya çalışalım. Herkesin bildiği programcılık teknikleri arasında, bütün proje kodunu derleyerek, tümleştirmek (entegrasyon) ve testlerden geçirmek gelir. Yani, eğer programımızın kullandıği arayüzleri doğru kullanıp kullanmadığımızı anlamak istiyorsak, bütün kodu beraber derleriz, ve testlerden geçiririz.

Bu iÅŸlemi yapmak ‘iyi’ bir teknik olarak bilinir. EÄŸer iyi ise, niye her zaman yapmıyoruz? Kent, tümleÅŸtirme iÅŸini bir otomatik programa baÄŸlayarak, bu programın her yarım saatte bir bütün kodu otomatik derleyerek sonuçlarını projeye e-posta ile bildirsini saÄŸladı.

Bunun sonuçları tabii ki devrim oldu. Artık, eğer kaynak kod idare (KKİ) sistemine yanlış, hatalı, yanlış tümleşen bir kod parçası eklenmiş ise, otomatik derleyici bunu en az yarım saat içinde yakalayabiliyordu. Hata e-posta ile alındığında, proje takımı o anda yaptığı işi bırakıp, tamamen o hatayı düzeltmek ile uğrâşacaklardı.

Böylece, tümleşme hataları taa sonuç ortamına aktarıldıktan sonra değil, hata olduktan 30 dakika sonra yakalanıyordu.

Bir baÅŸka örnek kod kontrol sırasında oldu. Arada sırada baÅŸkasının kodunu kontrolden geçirmemiz, ve stil, teknik olarak bulduÄŸumuz düzeltmeleri arkadaşımıza bildirmemiz de ‘iyi’ bir teknik olarak bilinir.

Fakat normal projelerde bu teknik, genelde takım liderinin insiyatifi ile başlatılır, ve bir odaya doluşulur, yazıcıdan basılmış koda herkes bakar, ve fikirlerini söyler, sonra herkes odasına döner düzeltmeler yapılır.

Kent şöyle dedi: ‘Bu iyi bir teknik ise, niye her zaman yapmıyoruz?’.

Sürekli kod kontrolu yapabilmenin en iyi yolu olarak, tek kişinin kod yazması yerine bir başkasının sonradan kontrolü yerine, iki kişinin aynı anda kodlama yapması, ve sürekli birbirlerini kontrol etmesi fikrine erişti.

Bu yaklaşım da yazılım projelerinde bir devrim oldu.

Not: Bu çalışma, yazarın izni ile www.bilgidata.com sitesinden alınmıştır.