http://blog.cenkcivici.com e taşındım. Aralık 19, 2007

WordPress erişimi Türkiye de engellendiği için blog umu http://blog.cenkcivici.com a taşıdım.

Hiz metrigi Eylül 30, 2007

Agile sureclerde en kritik metriklerden biri olan Hiz hesabini aciklamakta yarar var.

Hiz birim zamanda yazilim gelistirme ekibinin teslim ettigi kaliteli, test edilmis, gereksinimleri karsilayan, gercek ortama kuruluma hazir
ve en onemlisi musteriye deger saglayan ozelliklerin bir olcu birimi cinsinden toplamini ifade ediyor.

Birim zaman yinelemenin suresi. Bu 1-4 hafta arasi degisen bir sure olabiliyor. Genel tavsiye bu surenin mumkun oldugu kadar kisa tutulmasi.

Hizin olculdugu birim hikaye kartlarinin tahminlemelerinin yapildigi birim ile ayni. Story point, Real Days, Ideal Days, Gummy Bears,
Tshirt bedenleri gibi…

Hiz planlamaya yardimci oldugu gibi surecte veya proje sartlarinda bir degisiklik oldugunda bunun sonucunu en gec 1-2 icinde yineleme sonunda
gormemizi sagliyor. Her yineleme sonunda o yineleme performansi paylasiliyor.

Hizin bir baska yorumu musteriye kattigimiz deger miktari. Projeden musterinin sagladigi yararin somut bir olcusu. Sureclerimiz ve tum
pratiklerimiz bu yarari arttirmaya yonelik.

Analiz, test, kodlama, gozden gecirmeler, surekli entegrasyon, planlama toplantilari gibi faaliyetlerin tumu sonucta elde edilecek
yarari arttirdigi olcude faydali.

Yalin prensipler anlatilirken Toyota nin Value Chain e bir butun olarak baktigi ve ara surec adimlarinda ozel iyilestirmeler ve
olcumlere odaklanmadigi belirtilir. Ara surec adimlarinda yapilan iyilestirmeler sonucta elde edilen degeri arttirdigi olcude yararlidir.

GM, Ford gibi sirketler ara surec adimlarina odaklanip makinalari ve uretim hattini yuzde yuz calistirirken Toyota Just in Time calismayi
tercih etmis ve bunun sayesinde Amerikali rakipleri stok daglari, uretim fazlalari ve kalite sorulari ile ugrasirken Toyota uretim hizi,
kalitesi ve musteri memnuniyetinde liderligi ele gecirmistir.

Agile dusunce yapisinda da surece bir deger zinciri olarak bakmak hakim. Surecin ara adimlarinin etkinligini arttirmak ve bunu diger
adimlardan izole olcmek ve iyilestirmeler yapmaya odaklanmaz.

Hiz olarak ifade edilen olcum musteriye baska sureclerde olmayan karar kabiliyetini de verir. 2 haftalik gelistirme surecinin maliyeti teslim
edilen story point e bolunerek tek bir story point in ne kadara mal oldugu tahmin edilebilir. Bir sonraki planlama asamasinda diyebilirler ki

A ozelligi 3 story point. B ozelligi ise 2. Bir story point yaklasik 2 bin tl ye maloluyor. A karti daha pahali fakat bu karti onceden
yazilima ekletip kullanmaya baslayabilirsem onumuzdeki 6 ay boyunca 15 bin tl lik tasarruf saglayabilecegim. Daha pahali fakat oncelik A
olsun deyip bunun gelistirilmesini isteyebilir.

Ekipteki gecikmelerin para maliyeti bu olcumlerle daha kesin cikarilabilir. Butcede yapilacak degisiklikle ne kadar story point in
satin alinabilecegi gorulebilir.

Ozet olarak en kritik olculmesi gereken ekibin , sureclerin ne kadar deger saglayabildigi ve alt surec adimlarinin sonuc degere daha fazla
katkida bulabilecek sekilde iyilestirilmesi.

Bagimsiz, buyuk resmi gormeden iyilestirmeler yapmak sonucunda belki cok verimli(efficient) calisan bir surece sahip olabilirsiniz fakat bu
surecin bir butun olarak effective ve projenin ana hedefine dogru sekilde hizmet ettigi anlamina gelmez.

Bir sonraki yineleme plani Eylül 29, 2007

Bu yazida kisaca bir sonraki yineleme toplantisina girmeden once ne gibi hazirliklar yaptigimizdan bahsetmek istiyorum.

Bir yineleme basladiktan birkac sonra bir sonraki yineleme icin IPM 1 dedigimiz iteration planning meeting yapiliyor. Buna Analist, musteri , architect katilip bir sonraki yineleme kapsamina alinacak aday kartlari seciyor. Sonraki 4 gun boyunca bu kartlar is gereksinimleri acisindan  analist tarafindan detaylandiriliyor. Daha once bir paragraf olarak yazilan kart daha detayli hale getiriliyor, QA icin baslangic noktasi teskil edecek kabul kriterleri yaziliyor.

Bu asamadan sonra bir sabah butun bu aday kartlar panoya asiliyor. Tum gelistirici ekip bu pano onunde toplanip kartlari paylasiyor. Bundan sonra gelistiricin sorumlulugu sunlari kapsiyor.

1. QA ve BA ile gorusup kartin detaylarini tartismak ve gereksinimleri anlamak
2. Yineleme baslangic toplantisindan once gerekli aksiyonlar varsa bunlari bildirmek.
3. Ust seviyede bir task listesi cikarmak.Kodlari incelemek, gerekli kisilerle gorusmek
4. Nihai olmayan gercek gun olarak bir sure tahmini yapmak
5. Tum bunlari teknik lider ile paylasmak

Bu gozden gecirme ve hazirliktan sonra kart yineleme kapsamindan cikarilabiliyor. Ornegin maliyete gore musteri bunun yerine baska bir karti secmeyi tercih edebiliyor ya da teknik riskler mevcutsa baska kartlarin once hazirlanmasina karar verilebiliyor.

Kart yineleme kapsaminda kalirsa IKO(Iteration Kickoff) toplantisinda analist sirayla kartlari acikliyor. Bir karti acikladiktan sonra o karttan sorumlu gelistirici soz alip karti teknik acidan acikliyor ve task listesini paylasiyor. Diger gelistiricilerin sorularini cevapliyor ve kisa bir tartisma oluyor. Bu asamadan sonra tum ekip ayni anda tahmin veriyor. Cok buyuk ve cok kucuk tahminler varsa bunlar kendi tahminlerinin nedenlerini acikliyor ve bir ortak noktaya gelinmesi saglaniyor ve bu karta ekibin verdigi ortak tahmin olarak kaydediliyor. Ekibin bir onceki yinelemedeki hizina ve degisen sartlarina gore kapasitesi tahmin ediliyor ve buna gore kartlar yinelemede gelistirilmek uzere musteri oncelikleri uyarinca seciliyor.

Toplanti sonrasi bir ayakustu toplanti yapilip yeni kartlar gelistirilmeye baslaniyor.  Kartlar hakkinda onceden calisma yapmamiz toplantinin daha kisa surmesini ve yararli olmasini sagliyor. Riskler daha onceden gorulmus oluyor. Tum ekip uyeleri kartlarin nasil gelistirilecegi hakkinda kismen bilgi sahibi oluyor.

ObjectBuilder larin Test lerde kullanimi Eylül 29, 2007

Karisik bir domain modeli ustunde proje gelistirirken testlerin yazimi sirasindaki en buyuk problemlerden biri testler icin gereken objelerin olusturulmasi, gecerli degerlerin atanmasi oluyor.

Ornegin Musteri diye bir nesnemiz olsun. Sorumluluklarindan birisi musterinin son bir ay icinde yaptigi alisverisin toplamini dondurmek olsun. Musteri -> Siparis ->* SiparisDetay->Urun gibi bir nesne iliskisi olsun. Bu cok basit bir ornek. Gercek projelerde bundan cok daha karisik iliskilerle karsilasmak mumkun.

public void sonBirAyIcindekiAlisverisToplaminiDondurmeli() {

Musteri musteri = new Musteri();
Siparis siparis = new Siparis();
siparis.setTarih(gecenAy);
musteri.setSiparis(siparis);

SiparisDetay detay1 = new SiparisDetay();
Urun urun1 = new Urun();
urun.setFiyat(100);
detay1.setUrun(urun);
siparis.setDetay(detay1);

SiparisDetay detay2 = new SiparisDetay();
Urun urun2 = new Urun();
urun2.setFiyat(200);
detay1.setUrun(urun2);

//iki ay oncesine ait bir siparis
Siparis siparis = new Siparis();
siparis.setTarih(ikiAyOnce);
musteri.setSiparis(siparis);
//daha onceki ayni adimlari detay ve urun icin tekrarlayalim..

assertThat(musteri.getSonAySiparisToplami(),eq(300));

}
}

gibi bir test olsun. Bu testi okumak ne yaptigini anlamak cok zor. Test icin gereken objelerin kurulmasi testin okunurlugunu azaltiyor fakat bu obje grafigini bir sekilde olusturmak gerekiyor. Bir cozum bunu kolaylastiracak yontemleri nesnelere koymak fakat bu sadece testleri kolay yazmak icin olacagi icin cok iyi bir yol degil.

Bizim bircok projede kullandigimiz yontem Fluent Interface kalibini takip eden ObjectBuilder lar kullanmak. Bir onceki testi tekrar yazarsak.

Testimde benim icin sadece onemli olan dogru toplam ve tarihler.

public void sonBirAyIcindekiAlisverisToplaminiDondurmeli() {

Siparis gecenAykiSiparis = new SiparisBuilder().tarih(gecenAy).siparisDetayMiktar(100).siparisDetayMiktar(200).toSiparis()

Siparis ikiAyOncekiSiparis = new SiparisBuilder().tarih(ikiAyOnce).siparisDetayMiktar(500)..toSiparis()

//builder lar kendi iclerinde gerekirse urun ve diger obje grafini //olusturuyor.

Musteri musteri = new MusteriBuilder().siparisler(gecenAykiSiparis,ikiAyOncekiSiparis).toMusteri();

assertThat(musteri.getSonAySiparisToplami(),eq(300));

}

Builder lar objelerin sadece test icin anlamli olan ozelliklerini kullanarak ve gereksiz kisimlari default degerleri veya onemsiz objeleri kendi iclerinde olusturarak obje grafini olusturuyorlar. Testi okudugumuzda bir musteri nin iki siparisi oldugunu, birinin gecen ay digerinin iki ay once yapildigini goruyoruz. Beklenti gecen ayki toplamin dondurulmesi. Objelerin olusturulmasini Builder lara delege ederek Birim testi kodlari daha anlasilabilir kilinmis oluyor. Zamanla bu builder lar sayesinde test kodlarinin yazilmasi ve bakimi kolaylasiyor.

Selenium ile yazilan senaryo testleri ve Surekli Entegrasyon Eylül 29, 2007

Diyelim ki Selenium RC kullaniyorsunuz ve web sayfalari duzeyinde calisan kabul senaryosu testlerine sahipsiniz. Selenium web uygulamalarini test etmek icin opensource ve ayni amacli kullanilan parali araclardan daha kabiliyetli bir arac. Google dahi su an Selenium u testleri icin kullaniyor. Web uygulamasinin testleri surekli entegrasyon kapsaminda her kod degisikliginde calistirilabiliyor ve bir problem ciktiginda kurulumu kiriyor.

Buraya kadar hersey tamam fakat entegrasyon sunucusunda testlerden herhangi biri basarisiz oldugunda problemi cabuk tespit edip cozebilmemiz icin hangi testin basarisiz oldugunu, o anki web uygulamasinin ekran durumunu gormemiz gerekiyor.

Bunun icin selenium un calismasi esnasinda bir problem olursa o anki ekran goruntusunu capture ediyoruz(Junit testlistener vasitasiyla) ve CruiseControl un Artifact leri icinde yayinliyoruz. Web uygulamasi yardimiyla herkes bu screenshot lara erisebiliyor ve problemin ne oldugunu analiz edebiliyor.

Bununla ilgili bir blog yazisi
http://binil.wordpress.com/2006/12/22/taking-screenshots-with-selenium/

Testlerin paralel calistirilmasi Eylül 28, 2007

Daha onceki blog yazilarimda surekli entegrasyon kurulumu cercevesinde binlerce testi calistirdigimizdan bahsetmistim. Entegrasyon kurulumu
mumkun oldugu kadar kisa surede yapilmali.Otomatik testlerin calisma suresinin azaltilmasi icin uyguladigimiz
yontemlerden biri farkli kategorilerdeki testlerin paralel olarak calistirilmasi. Mock objelerle yazilan izole testler, veritabani ve
diger dis bagimliliklari kullanan entegrasyon testleri, javascript i test eden jsunit testleri gibi farkli kategorilerdeki testlerin ayni
anda calistirmaya basliyoruz. Bu sayede 15-20 dakika alabilecek toplam test suresi 10 dakikanin altina indirilmis oluyor.

Bir baska optimizasyon veritabani degisikliklerinin incremental olarak uygulanmasi. Bunu projemizde yazilan acik kaynak kodlu dbdeploy araci
yoluyla yapiyoruz.

Entegrasyonun hizli olmasi ekibin degisiklikleri daha sik entegre etmesini sagliyor. Bir degisikligin sonucunu daha cabuk gormek mumkun
oluyor.

Bug deyip duzeltip gecmeyelim Eylül 27, 2007

Agile sureclerle gelistirilen projelerin ozelliklerinden biri herhangi bir anda elde musterinin kullanimina hazir, mumkun oldugu kadar bug
lardan arinmis yazilimin gelistirilmis halde bulunmasi. Her yineleme bir onceki yinelemenin ustunde yeni ozellikler ekliyor ve bunlar kisa
araliklarla musteriye yayimlarla teslim ediliyor.

Buraya kadar hersey guzel fakat bu surekli yayim stresi icinde calisirken Agile ekipler yazilimda hatalar yapmiyor mu? Bu hatalarin
duzeltilme maliyetleri ile ilgili ne yapiliyor?

Halen calistigim proje su an 15. ayinda ve gercek ortama 21. yayimi yapmak uzere. Son 6 aydir her 2 veya 4 haftada bir gercek ortama
kurulumlar yapiliyor. Yazilim surekli hatalarindan arinmis durumda olmak zorunda.

Surekli tam zamanli calisan 10 a yakin testci var ve hata veritabanindaki toplam hata sayisi en fazla 20 civari oluyor. 80
kisilik bir projeyi dusunurseniz bu oldukca dusuk bir rakam.

Bunu nasil sagliyoruz?

1. Hatalari onlemenin ilk yolu ilk basta hata yapmamak.

Ilk basta hata yapmamanin yolu ekip ici iyi iletisimden, gereksinimlerin iyi anlasilmasindan , TDD gibi pratiklerin
uygulanmasindan, hikaye kartinin gelistirilme esnasinda QA, BA gibi ekip uyeleriyle dirsek temasinda olmaktan, Surekli entegrasyon,
Otomatik testler, QA , BA onayi asamalari gibi pratikleri uygulamaktan geciyor.

2. Yazilimda bir hata ciktiysa hatayi duzeltmeden once ana nedenini arastirmak ve tekrar ayni hatayi yapmamak icin careler aramak.

Yazilimda bir hata ciktiginda bu hatayi duzeltmeden once ana nedenini arastiriyoruz. Hata duzeltilmeden once hatanin cikis nedeni bulunmaya
calisiliyor, hangi tur yanlis varsayimdan veya bilgi veya iletisim eksikliginden kaynaklandi bu problemlerin kokenine inilmeye calisiyor.

Hatalar ve bunlarin kokenleri sureclerimizde, gelistirme pratiklerini uygulayis bicimlerimizde veya bilgi seviyemizde iyilestirmelere gerek
duyuldugu konusunda bize ipuclari veriyor. Bunlar degerlendirilip surecler, belli konulardaki bilgi seviyesi, uygulanan pratikler iyilestirilebiliyor.

Amac nedenleri ortadan kaldirip ayni tur hatayi tekrar yapmamak. Ornegin bu nedenlerin analizi sonucunda bizim yaptigimiz degisiklikler
sunlar oldu.

- Hikaye kartiyla ilgili gelistirme baslamadan once QA, BA , Dev in biraraya gelerek ayakustu bir toplanti yapmasi ve hikaye kartiyla
ilgili herkesin ortak anlayisa ulasmasi. Kisa araliklarla gosterilecek ozellikler ciktikca bunun QA ve BA e gosterilmesi

- Kart icin ilk once Dev in QA ile birlikte calisip kabul kriterlerini detaylandirmasi ve otomatik kabul testleri yazmasi

- Teknik konularda yapilan ogle arasi bilgilendirme toplantilari

- Otomatik testlerin kolay ve hizli calisir hale getirilmesi ve aractan bagimsiz yazilabilmeleri

-Teknik ekip liderleri ve mimarlara kolay ulasim.
-Yineleme suresinin yayim baskisi nedeniyle 1 haftadan iki haftaya cekilmesi.

gibi ilk aklima gelenler.

Agile büyük projelerde kullanılabilir mi ? Örnekleri nelerdir ? Eylül 18, 2007

Bu konudaki proje tecrübeleri son yıllarda artan biçimde yazılan makalelerde paylaşılıyor. Bizim Thoughtworks olarak yardımcı olduğumuz halen devam eden ve ekip büyüklüğü bakımından iki yüze kişiye yaklaşan projeler var. Hatta Amerika ‘ da büyük çaplı askeri projelerde dahi bu yöntemler kullanılmaya başlandı.

Bu projelerde Agile pratikleri küçük projelerde uyguladığımız şekliyle uygulamıyoruz. Genel pratikler ve yaklaşım aynı olmakla beraber bazı uyarlamalar yapmamız gerekiyor.

Bahsettiğim makalelerden bazıları

British Telecom da yüzlerce kişilik projelerinde aktif olarak Agile kullanıyor. BT nin hikayesi Agile öncesi ve sonrası durumu karşılaştırması açısından iyi.
http://www.infoq.com/news/Agile-Delivery-British-Telecom

Thoughtworks’ ün Offshore Agile uygulamaları ile ilgili bir makale. Bazı projelerimiz 3 farklı kıtaya dağılmış ekipler tarafından yapılıyor.
http://www.martinfowler.com/articles/agileOffshore.html

Caterpillar için yaptığımız bir proje hakkında bilgi
http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,67016,00.html
http://www.agilealliance.org/system/article/file/984/file.pdf

Bir finans şirketinin Agile case study si
http://www.cio.com/article/109751

Primavera da Scrum in yarattığı değişim
http://www.objectmentor.com/resources/articles/Primavera.pdf

Amerikan ordusunda bir projeden edinilen tecrübeler
http://www.stsc.hill.af.mil/crosstalk/2004/04/0404Willison.html

Sabre Havayolları’ nın XP kullanımı
http://www.computerworld.com/developmenttopics/development/story/0,10801,91646,00.html?nas=WS-91646

http://www.computerworld.com/developmenttopics/development/story/0,10801,91647,00.html?nas=WS-91647

HP’ nin mission critical projesine ait bir makale
http://www.ddj.com/architect/184405520

Sep 11 ertesi geliştirilen DNA testleri ile ilgili bir yazılım projesi
http://www.bio-itworld.com/archive/091103/soul.html

Avaya ‘ dan bir uygulama
http://www.agilealliance.org/system/article/file/1292/file.pdf

Agile süreçlerde süreklilik ve kişi Bağımsızlığı nasıl sağlanıyor ? Eylül 18, 2007

Projenin kişilere bağımlı olması büyük risklerden birisi. Kişilerin projeden ayrılma ihtimali gibi riskler olmasa dahi önemli sorumlulukların belli kişilere yüklenmesi bu kişilerin darboğaz haline gelmesi hemde proje maratonunda çabuk yorulması anlamına gelebilir. Bu nedenle bizim Agile ‘ da bu bağımsızlığı sağlayabilmek için uyguladığımız belli pratikler mevcut.

Birincisi bizim uyguladığımız Pair Programming pratiği. Kod gözden geçirmeleri gibi yararları yanında Pair Programming bilgininde paylaşılmasını sağlıyor. Bir hikaye kartı üstünde 3-4 günlük bir geliştirme süresi içinde 3 kişinin bu kart üstünde çalıştığı görülebiliyor. Bu 3 kişinin aynı iş hakkında bilgi sahibi olması demek. Hem alan bilgisi hemde teknik bilgi sürekli paylaşılıyor ve projeye yeni katılanlar ilk birkaç günden sonra yararlı hale gelmeye başlıyor.

Diğer bir pratik Collective Code Ownership. Üretilen kodların mülkiyeti bireylere değil tüm ekibe ait. Yani bir kişi A modülünden sorumlu olup onunla ilgili tüm geliştirmeyi yapmaktan sorumlu olmuyor. Proje süresinde herkes projenin farklı kod alanlarında çalışma imkanı buluyor.

Proje wikisi. Hep duyduğumız ön yargılardan birisi çevik süreçler genelde dokümantasyon sevmez denir fakat muhtemelen en yararlı dokümantasyonları üreten süreçler çevik süreçlerdir. Bir projeye başlarken ilk kurduğumuz araçlardan birisi TWiki gibi wiki araçları. Bu wiki üstünde ekipçe paylaşılması gereken bilgiler tutulur. Proje ortamı nasıl kurulur? Kullanılan teknolojiler hakkında bilgiler ,uygulanan mimari tasarım kalıpları, proje kurulumları için gereken yayım notları gibi.

Bir diğer bilgi paylaşımını kolaylaştıran faktör proje çalışma ortamının organizasyonu,
Aşağıdaki linkte bu tür bir proje ortamı görülebilir. Çevredeki duvarda Bug listeleri, Story panosu gibi bilgiler paylaşılıyor.
http://www.flickr.com/photos/95502668@N00/268581496/

Bu tür bir masa düzeninde genelde Dev ler orta kısma, köşelere ise Tester, Analist, Release Manager gibi kişiler oturuyor. Bilgi paylaşımım kolaylaşması için oturma düzeni Agile in üstünde durduğu konulardan biri.

Ayrıca bir başka konu kodların kolay anlaşılabilir ve iyi tasarlanmış olmasına verilen önem. Testler, Sürekli Entegrasyon, Refactoring gibi pratikler hayati öneme sahip. Değişikliklere adapte olur ilerleriz derken emniyet kemerleri gerekiyor. Projeden bir kişi gittiğinde yerine gelenin hatalı birşey yapmayacağının garantisini bu pratikler sağlıyor. TDD iyi tasarıma sahip, test edilebilir bir sistemi hedeflediği için yeni gelenlerin kodları anlaması kolaylaşıyor. Testler çoğu zaman kodun gerçekleştirdiği sorumlulukları ifade ediyor ve dokümantasyon içinde kullanılıyor.

Agile süreçlerde en iyilenmiş Tekrarlanabilir süreçler ve pratikler nasıl ortaya konuluyor ? Eylül 17, 2007

Agile süreç mantığında en iyi ve problemsiz bir süreç yapısına ulaşıp daha sonra değişmeksizin ayrı şekilde ilerlemek gibi bir mantık yok. Proje içindeki şartlar değiştikçe , ilerledikçe ve proje ekosistemi hakkında bilgi ve deneyim arttıkça her zaman daha iyi bir sürece ulaşmamızı sağlayacak olanaklar çıkıyor. Bu olanakları görüp değerlendirebilmek çok önemli. Bir sürecin tekrarlanabilir olması aslında bu iyileştirme olanaklarını göremediğimiz anlamına geliyor olabilir.

İyileştirmeleri yapabilmek amacıyla sürekli uygulanan süreç hakkında geri beslenim almak gerekiyor. Bu geri beslenim süreci uygulayanlardan alınıyor. Her yineleme(iteration) sonunda tüm ekibin katıldığı Retrospective adını verdiğimiz toplantılar yapılıyor. Bu toplantının ilk aşamasında yineleme performansı herkesle paylaşılıyor. . Kaç kart bitti, kartlar hayat döngüleri içinde en çok hangi aşamada bekledi, toplam story point olarak ne kadar iş çıktı , hızımız neydi gibi genel resim ortaya konuyor. Sonrasında ekip olarak 4 soruya karşılık 4 farklı liste hazırlıyoruz.

Neyi iyi yaptık?
Neyi daha iyi yapabilirdik?
Karışıklığa neden olan durumlar nelerdi?
Gelecek için neler öğrendik?

Bu soruların cevapları sonraki bölümde tartışılmaya başlanıyor. Muhtemel iyileştirmeler neler olabilir bunlar çıkarılıyor ve bir sonraki toplantıya kadar takip edilmesi amacıyla aksiyon maddeleri toplanıyor. Bu Retrospective toplantıları için uygulama kalıpları oluşmuş durumda. Farklı koşullarda farklı şekillerde bu toplantıları yapabiliyoruz. Ama temel olarak amaç bu 4 soruya karşılık bulabilmek ve problemleri farkedip çözebilmek ve iyi giden şeyleri daha iyi hale getirebilmek.

Brunch- Agile Ağustos 16, 2007

26.08.07 tarihinde sabah 10:00 – 13:00 arasi brunch esliginde Agile ve
XP pratikleri tanitimi yapmayi ve sizlerle tanismayi planliyoruz.

Katilim ucreti sadece brunch ucretinden ibarettir.

Ilgilenen arkadaslar lutfen info@mentor.com.tr adresine email atip
kayitlarini yaptirsinlar.

Katilim ucreti: 20-40 YTL arasinda
Yildiz Unv. Hisar Tesisleri

Hikaye kartlarının planlanması Ağustos 10, 2007

Bu yazıda kısaca yineleme kapsamında geliştirilecek kartlarla ilgili tahminlerin nasıl alındığını ve kartların nasıl seçildiğini anlatmaya çalışacağım.

Yineleme başlamadan 2 hafta önce bir ön toplantı yapılıyor. Bu toplantıya analistler ve müşteri katılıyor. Daha önce adı konan ve birkaç cümleyle ifade edilmiş halde duran kullanıcı hikayesinin bir sonraki yineleme kapsamına alınıp alınmayacağı belirleniyor. Müşteri öncelikleri ve yayım planlaması sırasında verilen tahmin kullanılarak kapsam belirleniyor.

Kartlar belirlendikten sonra analist bir hafta boyunca detay çalışmayı yapıyor ve kabul kriterleri , arayüz kesitleri gibi bilgileri topluyor. Bu haftanın sonunda tüm kartlar bir panoya asılıyor ve her geliştirici bir kart alarak kart için ne gibi geliştirme faaliyetlerinin gerekeceğini buluyor

Mevcut yineleme bitiminden sonraki yineleme için planlama toplantısı yapılıyor ve ön toplantıda belirlenen tüm kartlar analist tarafından tüm ekip üyelerine açıklanıyor. Sonraki adımda kartı geliştirme bakış açısından inceleyen kişi kart için ne gibi çalışmaların yapılması gerektiğini diğer ekip üyeleri ile paylaşıyor. Herkesin kafasında soru işaretleri giderildikten sonra planlama pokeri pratiği ile tahminler alınıyor.

Bu tahminler alındıktan sonra ekibin bir önceki yinelemede kaç puanlık iş bitirdiği ve sonraki yinelemede kaç kişinin kartlar üstünde çalışacaği gibi faktörler gözönüne alınarak ne kadarlık iş yapılabileceği tahmin ediliyor. Örneğin bir önceki yinelemede 20 puanlık iş bitmiş olsun ve tatile giden bir geliştirici dönüyor olsun, bu durumda 24 lük iş bitiririz gibi bir tahmin verilebilir.

Sonraki aşamada müşteri kartları öncelik sırasına koyuyor. Kritik öneme sahip olanları en başa koyuyor. Son olarak ekibe bu kartları yapabiliriz diyor musunuz diye bir soru soruluyor ve yineleme içeriği herkes rahat hissedecek şekilde değiştirilebiliyor. Toplantı sonunda kısa bir ara veriliyor ve yeni kartlar ile ilgili geliştirme çalışmaları ayakta yapılan bir toplantı sonucunda başlatılıyor.

Sürekli entegrasyon büyük bir projede uygulanması Ağustos 9, 2007

Bu yazıda kısaca sürekli entegrasyon sürecini büyük kod tabanına ve yaklaşık 80 yazılımcının çalıştığı bir projede nasıl uygulandığını aktarmaya çalışacağım.

Bu tür büyük projelerde entegrasyon problemlerinin ortaya çıkma riski daha fazla. Hergün yüzlerce satır yeni kod ekleniyor . Bu eklenen kodların mevcut özelliklerde hiçbirşeyi bozmadığını ve problemlerin ortaya çıkmadığını maliyetsiz biçimde doğrulamak gerekiyor. Bu nedenle sürekli entegrasyon süreci daha fazla önem kazanıyor. Fakat bu konuda yaşanan ana sıkıntılardan biri sürekli entegrasyon kurulumlarının kod tabanının büyüklüğünden dolayı uzun sürmesi. Prensip olarak bu kurulumun azami 10 dk sınırında tutulması gerekiyor. Aksi halde insanlar kurulumun durumuna bakmadan kodları versiyon kontrole ekleyip entegrasyon problemlerine neden olabiliyorlar. Bizim projede uyguladığımız yöntem şu şekilde işliyor.

Sürekli entegrasyon kurulumunu 3 seviyede yapıyoruz.

 

1. Hızlı kurulum
2. Entegrasyon kurulumu
3. Gecelik kurulum

Hızlı kurulum:

Herhangi bir kod değişikliği yapıp versiyon kontrole eklediğimizde bu değişiklik Hızlı kurulum sunucusu tarafından tespit ediliyor ve Ant script vasıtasıyla hızlı kurulum başlatılıyor. Bu kurulumun kapsamı tüm kodların derlenmesi, veritabanına değişikliklerin uygulanması(dbdeploy) ve yaklaşık 40 bin birim testinin çalıştırılması olarak özetlenebilir. Bu kurulum yaklaşık 7 dk sürüyor. Yeni bir Checkin işlemi yapmadan önce mutlaka son hızlı kurulumun sonucunun başarılı olmuş olması gerekiyor.

Eğer Hızlı kurulum başarısız olursa herkesin bilgisayarında Windows Taskbar da çalışan CCTray uygulamasındaki ikon kırmızıya dönüyor ve tüm ekip bir problem olduğunu anlıyor. Başarısız kuruluma neden olan checkin işlemini yapan kişi yaptığı değişikliği geri alıyor ve bir önceki başarılı kuruluma dönülüyor. Bu sayede diğer insanlarin checkin işlemlerini bloke etmekten kaçınılıyor.

Hızlı kurulum sonucu başarılı ise Entegrasyon kurulumu tetikleniyor.

Entegrasyon kurulumu:

Entegrasyon kurulumu Hızlı kurulumun başarılı olduğu durumda çalışmaya başlıyor.

Entegrasyon kurulumunun en büyük özelliği projenin uygulama sunucularına deploy edilmesi ve QA grubu tarafından hazırlanan bir listedeki Kabul Senaryosu testlerini çalıştırması. Bu kabul testleri uygulamayı Selenium aracını kullanarak arayüz düzeyinde test ediyor. Bu listede bulunan kabul senaryoları projenin önemli ve riskli bazı özelliklerini test ediyor.

Entegrasyon kurulumu başarısız ise buna neden olan kod değişikliği analiz edilip düzeltilmeye çalışılıyor . Hızlı kurulumdakinin aksine ekiptekiler checkin işlemi yapılabiliyor. Fakat checkin yapmadan önce başarısızlığı düzeltmeye çalışan kişilere gidip izin almak gerekiyor. Versiyon kontrole eklenecek kod değişikliğinin kurulumu bozan değişiklikten tamamen ayrı olması gerekiyor.

Gecelik kurulum

Her gece yarısı tüm ekip uyurken CruiseControl boş durmuyor. Bu kurulum tüm kodları sıfırdan derliyor, veritabanını sıfırdan oluşturuyor,birim testlerini çalıştırıyor ve uygulamayı deploy ederek binlerce kabul testi senaryosunu çalıştırıyor. Bu kurulum yaklaşık 40 dk kadar sürüyor. Kabul testlerinin çalışması sırasında arayüzde alınan hatalar o anda Desktop un resimlerini alarak kaydediliyor.

Buna ek olarak Sürekli performans denetimi için performans testleri çalıştırılıyor ve rapor oluşturuluyor. Bu sayede uygulamanın saniyede kaç sayfa sunabildiği gibi önemli metrikler güncelleniyor.

Bu pratiğin uygulanması sonucu baş ağrıtan ve çözülmesi zaman alan problemlerin önüne geçilmiş oluyor. Proje her an gerçek ortama kurulmaya hazır halde tutulabiliyor. Bu tür pratikleri uygulamayan projelerde gerçek ortama kurulumlar günler alabilirken , sürekli entegrasyon sayesinde bu süre dakikalarla ölçülüyor.

Konuya ilgi duyanlar için Martin Fowler ‘ in makalesi

http://www.martinfowler.com/articles/continuousIntegration.html

TDD Eğitimi Ağustos 6, 2007

TDD eğitiminin içeriğini aşağıda bulabilirsiniz. Eğitimin süresi 2 gündür. Daha detaylı bilgi için benimle bağlantıya geçebilirsiniz.

İçerik :

·Overview of TDD

o Theory

o Principles

o Mechanics

· xUnit tools

· Practice 1 : Stack implementation.

· Topdown TDD with Mock objects and Dependency Injection

o Improving testability of designs

o Mocks vs Stubs

o Dynamic Mock Libraries

· Practice 2: Sending emails to Overdraft accounts.

· Unit test quality

o Fine grained ,Simple, Isolated,Fast, Readable

· Unit Test patterns

o Naming conventions.

o Testing for behaviour.

o Using ObjectBuilders in test preparation.

o Custom Constraints for Assertions

o Testing abstract classes

o Testing with Database

· Common test smells

o Long tests

o Using mocks instead of stubs

o Testing implementation

o Too many assertions

o Intermittent failures

· Automating test suites.

o Ant integration

· Executing tests during continuous integration

o Sample CI implementation with CruiseControl

· Test Coverage and Analysis

o Configuring and executing Emma coverage tool.

· Levels of testing in Enterprise Projects

o Examples from Real World Projects

· Story test driven development using Fit

· Behaviour Driven Development(BDD)

o Example Specifications using Jbehave

· TDD approach in legacy applications

· Group exercise : TDD Coding Workshop

o Sales Tax problem

Yineleme iş akışı performansının değerlendirilmesi Haziran 18, 2007

Her yineleme sonunda kendimizi değerlendirdiğimiz ‘retrospective’ adı verilen bir gözden geçirme toplantısı yapıyoruz. Bu toplantının amacı neyi iyi yaptık, neleri daha iyi yapabiliriz tespit etmek. Bu konuyla ilgili daha önce ‘Geçmişe bakış’ adlı bir yazı yazmıştım.

Bu toplantılarda yineleme yöneticisi(iteration manager) tarafından hazırlanan bazı grafikler kullanıyoruz. Bir grafik bin kelimeye bedel. Bu grafiklerden birisi kartların yineleme içindeki süre boyunca hangi aşamalarda ne kadar zaman geçirdiklerini toplu gösteriyor. Yineleme yöneticisi bu grafiği hazırlamak için hergün kaç kartın hangi adımda olduğunu not ediyor. Kartlar yineleme içinde Geliştirme, Analist onayı, QA, testi, Bitti gibi aşamalardan geçiyor. Bu aşamalar içinde hangilerin dar boğaz oluşturduğu hazırlanan grafik sayesinde görülebiliyor. Örneğin geliştirme hızlı iken testçiler bu hıza yetişemiyorsa , grafikte test aşaması ile ilgili kart sayısı sürekli artıyor.

Bu grafiği temel alarak beklemelerin ve darboğazların nedenini sorguluyoruz. Verdiğim örnekten gidersek ; testçi sayısı yeterli değil mi ? Müşteriye erişemiyor muyuz? Geliştiricileri Testçilerle eşleştirerek darboğazı aşabilir miyiz? gibi soruları sorarak süreçte bazı değişiklikler yapmamız sözkonusu olabiliyor.

Projeye yeni katılan birinin alışma süreci Haziran 17, 2007

Diyelim ki uzunca süredir devam eden bir projeniz var ve bu ekibe yeni katılanlar oldu. Yeni katılan arkadaşların projede yararlı olmaya başlamaları için belli bir alışma sürecinden geçmeleri gerekiyor. Bu süreç içinde iş kurallarını, alan bilgisini, kullanılan araçları ve teknolojiyi öğrenmeleri gerekiyor. Proje büyüdükçe ve o ana kadar bitirilen yazılım fonksiyonları fazlaysa bu alışma süreci uzayabiliyor.

Şu an çalıştığım proje yaklaşık bir yıldır devam eden ve 80 e yakın kişinin çalıştığı bir proje. Ekibe yeni katılan olduğu zaman bu kişinin adaptasyonunu kolaylaştırmak için kullandığımız bazı yöntemler şöyle..

1. Yeni katılan ister geliştirici ister analist ister testçi olsun; ekibe katılımından sonraki 1-2 haftalık süre boyunca test ekibinde çalışıyor. Test ekibi bünyesinde uygulamayı son kullanıcı gözünden kullanarak, uygulamanın ne olduğunu, ne amaçla yazıldığını, nasıl kullanıldığını öğreniyor. Buna ek olarak hataları bularak projeye ilk günden yarar sağlamaya başlıyor. Hataları bulmaya çalışırken iş kuralları hakkında derinlemesi bilgi sahibi olabiliyor.
2. Sonrasında eğer yeni katılan geliştirici ise kısa bir süre hataları(bug) düzelten grubun içinde çalışıyor. Hataların kaynağını bulmaya çalışırken kodların yapısını çabuk kavramak mümkün oluyor. Değişik hatalarla uğraşırken sistemin birçok farklı kısmını görme imkanı buluyor.
3. Sonrasında eşli programlama(pair programming) pratiği ile projeye yeni katılan kişiye bir yandan sürekli bilgi transfer edilirken bir yandan gerçek iş üstünde çalışması sağlanıyor.
4. İşimizi kolaylaştıran bir başka özellik alan modelini projenin merkezine koymamız. Alan modelini oluşturan nesneler ve ilişkileri çalışma ortamımızın duvarında asılı. Tüm tartışmalar alan modelini kullanan bir dille yapıldığı için yeni katılan bir kişi bu modeli öğrendikçe müşteriyi, analistleri, testçileri kısaca tüm ekibin konuşmasını anlamaya başlıyor.

Planlama oyunu Haziran 7, 2007

XP ve Scrum ‘ da kullanım hikaye buyukluk tahminlerinin yapıldığı planlama oyunu ile ilgili bir yazı. Pratiği fotoğraflarla beraber güzel şekilde anlatmış.

http://www.crisp.se/planningpoker/

Test kapsam(coverage) in yüksek olması sistemin test edildiğini gösterir mi? Haziran 5, 2007

Diyelim ki Emma veya Clover gibi araçlarla birim testlerinizin kodunuzun yüzde kaçını test ettiğini öğrenmek için raporlar alıyorsunuz. Bu tür araçlar birim testlerinden önce koda özel semboller koyuyor ve testlerin çalışması esnasında bu sembollerin yüzde kaçının üstünde geçildiğini size raporluyor.

Peki test kapsamının yüzde 100 olması tüm kodlarınızın test edildiği anlamına gelir mi?

Kısa cevap HAYIR. Diyelim ki bütün test kodlarınızdaki doğrulama adımlarını ( Junit Assertion ları mesela) kaldırdınız. Test kapsam raporlarını tekrar aldığınız zaman test kapsam yüzdesinde bir değişiklik olmadığını görürsünüz. Testler Assertion lar olmadığı için hiçbir şeyi test etmediği halde test kapsamınız yüzde 100 olarak raporlanıyor olabilir. Bir başka deyişle test kalitesi yüzde 0 olduğu halde test kapsamınız yüzde 100 olabilir.

Bu nedenle test kapsam yüzdesi sistemin ne kadarının test edildiği ile ilgili metrik olamaz. Yazılan testlerin kalitesi test kapsamından daha önemlidir. Ancak kaliteli testlerin olduğu bir sistemde test kapsamı ölçümleri bir anlam ifade eder.

Primavera ‘ da Scrum başarı öyküsü Haziran 3, 2007

Primavera proje yönetimi yazılımları konusunda lider firmalardan biridir. Ürünleri inşaat, telekom, finans gibi sektörlerde kullanılmaktadır. Bu şirket 2003 yılında ürün geliştirme aşamalarında yaşadığı problemlerden kurtulmak amacıyla çevik süreçleri kullanmaya başlamıştır.

Primavera ‘ nın ürünlerine olan talep çok yüksekti ve farklı müşteri ihtiyaçlarına karşılık verebilmesi gerekiyordu. Geliştirme ekibi yeni sürümü yetiştirmek amacıyla fazla mesailer ve fedakarlıklarla dolu bir 2002 yılı geçirmişti. Çoğu projede olduğu gibi bu sürenin özellikle son birkaç ayı çok kötü geçmişti. Yeni gereksinimler haftasonları yapılan çalışmalar sonunda yetiştirilmeye çalışılıyordu.

Bütün bu fedakarlıklara rağmen birkaç hafta gecikmeyle de olsa çıkarılan sürüm üst düzey yönetim tarafından yetersiz bulunmuştu . Ayrıca yoğun bir dönem geçiren geliştirme ekibinin morali bozulmuştu.

Bu aksaklıkların sonucunda Primavera Scrum ve XP ile işe başlamaya karar verdi.

Scrum proje planlaması ve yönetimine ; XP ise analist, testci, geliştirici ve yönetici gibi rolleri barındıran bir ekibin etkin çalışabilmesi için gerekli yöntemlere odaklanıyor. İki sürecin birlikte kullanılması komple bir çözüm ortaya koyuyor.

Primavera işe ürün yönetimi için Scrum ‘ ı kullanarak başlar. Sonrasında ürün kalitesini ve ekip verimliliğini arttırmak için XP pratiklerini uygular.

Günümüzde Primavera halen çevik süreçleri kullanmaya devam ediyor ve müşterinin beğenisini kazanmiş yazılımlar üretiyor. Çevik süreçler aynı zamanda firma kültüründe de farklılıklar meydana getirir. Şu an yenilikçi fikirlerin ortaya çıktığı daha dinamik ve motive ürün geliştirme ekibine sahiptir.

Primavera daha iyi olmanın yollarını arıyor

Bob Schatz yazılım geliştirmeden sorumlu yöneticiliğe geldiğinde ilk önce küçük iyileştirmelerde bulunur. Motivasyonu arttırma amaçlı toplantılar, yeni ofis ortamı, primler gibi iyileştirmeler yapılır Fakat bu iyileştirmeler sonuçlara yansımaz.

Geliştirilen ürünün son sürümü çıktığı halde geliştirme ve pazarlama ekipleri ile üst düzey yöneticiler gidişattan memnun değildirler. Herkes gecikmelerden, ürün kalitesindeki sorunlardan ve yetiştirilemeyen özelliklerden dolayı birbirini suçlar.Hatta üst yöneticiler yazılım geliştirme ekibinin yıl sonu primlerini kaldırır.Daha ciddi bir değişikliğe ihtiyaç olduğuna karar verirler. Yazılım geliştirme konusunda mevcut yaklaşımları incelemeye başlarlar ve çevik süreçlerin kendi problemlerine en iyi ilaç olabileceğini düşünürler. Bunun nedeni şartların sürekli değiştiği kaotik ortamlarda çevik süreçlerin devamı sağlanabilir hızla , disiplinli ve kaliteli yazılım geliştirebilmenin yollarını göstermesidir.

O güne kadar Primavera ‘ nın yazılım geliştirme süreci tipik şelale(waterfall) süreci olmuştur. Pazarlama ekibi yeni sürümde görmek istedikleri özellikleri yazılım ekibine gereksinim dokümanı ile bildirmiştir. Yazılım ekibi ve yöneticiler bu dokümandan çıkardıkları işleri detaylı şekilde planlamaya çalışıp organize olmaya çalışmışlardır. İşler alt işlere bölünmüş ve planlar en ufak detaylara kadar yapılmaya çalışılmıştır. İşlerin bölünmesi sonucu oluşan alt kırılımlar analist, geliştirici ve testçi ekiplerine atanmıştır. Bu şekilde proje yönetimi cepheden çok uzaktaki komuta kontrol merkezinden savaşı yönetmeye benzer.

Müşteri portföyünün genişlemesi sonucu ihtiyaçlarda farklılıklar oluşur ve bu durum ürün geliştirme sürecini sekteye uğratır. Ürün teslimleri değişen gereksinimleri karşılayabilmek için sürekli erteleniyordu. Tüm bu durumlar ekibin üstünde baskı oluşturmuştur. Bu ortam şirketin müşterileri için kabul edilemez bir durum olarak ortaya çıkmıştı

Durum böyleyken Primavera, Scrum ve XP ye bir şans vermeye karar verir ve üst yönetimin desteğiyle Ken Schwaber gibi danışmanları şirkete davet eder.

Scrum ile başlarken

İlk önce yöneticilere ScrumMaster eğitimleri verilir. ScrumMaster proje yöneticisinin Scrum terminolojisinde karşılığıdır. ScrumMaster ‘ in ana görevi işbirliği ortamını güçlü tutmak, ekipler arasında kusursuz iş akışını mümkün kılmak ve aylık yinelemeler sonucu istenen özelliklerin yazılıma eklenmesini sağlamak olarak özetlenebilir.

Scrum sürüm 4.0 için denenmeye başlanır. Bu sürümün en kritik ve pazarlama ekibi için en fazla anlam ifade eden özelliği iş akışı ve işbirliği(collaboration) uygulamaları ile entegrasyonu sağlayabilmektir. Bu nedenle ilk yineleme için bu özellikle ilgili gereksinimler seçilir. Bir aylık yineleme sonunda amaç gereksinimleri mevcut yazılıma eklemek ve çalışan yazılımı teslim etmektir.

Ekip yapısı bu özelliğe odaklanılarak tekrar oluşturulur. Testci, analist, gelistirici gibi rolleri barındıran fonksiyonel bir ekip yapısı kurulur. Daha önce , ekipler roller bazında insanları gruplayarak oluşturulmuştu. Ekip bir aylık kısa süre boyunca belli bir alandaki özellikleri yazılıma eklemeye odaklanır. Hergün ayakta yapılan toplantılarla gidişat hakkında herkes bilgilendirilir.

Bir ayın sonunda yeni özellikler yazılıma eklenir ve yineleme sonunda yapılan toplantıyla yeni özelliklerin demosu yapılır. Pazarlama ekibi, üst düzey yöneticiler bir ay gibi kısa bir sürede önem verilen bir özelliğin yazılıma eklenmiş olmasından müthiş derecede memnundurlar. Artık eklenen özelliklerle ilgili kendileri de çalışmalar yapabilecekler ve stratejiler oluşturabileceklerdir. Bu iyi başlangıç tüm organizasyonun Scrum’ a geçişini hızlandırır.

Birlik olan ekipler

Çevik süreçlere geçişin dışardan farkedilen en büyük özelliği ofis düzenindeki değişikliklerdir. İnsanlarin çevresine bariyerler kuran kubik düzeninden daha açık , herkesin daha kolay iletişim kurabileceği açık ofis ortamına geçilir. İnsanlar birbirleri ile epostalar yollayarak iletişim kurmak yerine en etkili iletişim yöntemi olan yüzyüze iletişimi tercih etmeye başlar. Böylece ekibin içindeki bağlar kuvvetlenir ve bilgi paylaşımı artar.

Primavera ‘ nın doksan kişilik yazılım ekibi onar kişilik alt ekiplerden oluşmaktadır. Her alt ekibin çalıştığı bölgede herkesin görebileceği biçimde alt ekibin amacı, hedefi , duvara asılır. Bunun yanında ekip yineleme planları, farklı grafikler, testlerin kapsam raporları gibi bilgileri duvardaki panolara asarak paylaşır ve sabah toplantıları bu panoların önünde yapılır. Böylece son durum hakkında herkes bilgi sahibi olur.

İlk yayımdan sonra

Proje yönetimi ve planlaması Scrum ile yapılmaya başlandıktan sonra geliştirme, test, entegrasyon konularında farklı pratiklerin gerekliliği ortaya çıkar. Primavera klasik şelale sürecinden geldiği için testleri ve entegrasyonu yazılımı yayınlamadan kısa bir süre önce yapmıştır. Her yinelemeyi yeni özellikler eklenmiş ve kullanıma hazır biçimde bitirebilmek için test, entegrasyon gibi pratikleri baştan sona sürekli yapılır hale getirmek gereklidir Bunun için XP pratiklerinin hayata geçirilmesine karar verilir.

XP ‘ nin getirdiği kurala göre bir özelliğin bitmiş sayılabilmesi için birim ve kabul testlerinin tümünden geçmesi gereklidir. Primavera ‘ da XP pratiklerinin uygulanmaya başlanır. Geliştiriciler birim testlerini kodlarını yazmadan önce kodlamaya başlar. Pazarlama ve analistler kabul test senaryolarını vermeye başlarlar. Object Mentor ‘ dan alınan danışmanlıkla geliştirici ekibe Nesne tabanlı yazılım geliştirme, basit tasarım, test yönlendirmeli tasarım, refactoring gibi pratikler hakkında kabiliyetler kazandırılır. Sürekli entegrasyon pratiği ile yazılım geliştiriciler sık sık yazdıkları kodların versiyon kontrol sistemine eklenir. Bu değişiklikler o anda otomatik olarak kapsamlı testlerden geçerek entegrasyon problemleri anında tespit edilir.

Başarısız olma gibi bir seçenek yok

Primavera ‘ nin CTO’ su Dick Faris yazılım geliştirme sözkonusu olduğunda başarısız olma gibi bir seçeneklerinin olmadığını ve insanların kullanmak isteyecekleri yazılımı verebilmenin en önemli şey olduğuna dikkat çeker. Bu nedenle yazılım firmaları 18 ay önce aldıkları gereksinimleri değişmez olarak kabul edip yazılım geliştiremezler. Değişiklikleri kontrol etmeye ve önlemeye çalışan süreçler yerine bu değişiklikleri müşteriye daha iyi değer sağlayabileceğimiz fırsatlar olarak gören ve bunun için formüller öneren süreçleri kullanmak zorundayız.

Primavera ‘ nın uygulamasında yineleme sonlarındaki değerlendirme toplantılarında (Sprint Review meeting) ilgili herkese yeni eklenen özellikler tanıtılır ve fikirleri alınır. Bu fikirler somut çalışan yazılım üstünden sağlandığı için şirkete rekabet anlamında yararlı fikirlerin ortaya çıkması kolaylaşır.

Farkedilen değişikler

Primavera proje yöneticilerinden ve Scrum Master Jennifer Coyle şöyle diyor.

‘ Yinelemeler boyunca tek hedefe odaklanarak sürekli işbirliği içinde ve uyumla çalıştığımız için daha verimli oluyoruz. Bu verim herkesin eve saatinde gitmesi ve ailesine daha fazla zaman ayırabilmesi anlamına geliyor. Böylece bununda kişisel motivasyon üstünde olumlu etkileri oluyor. Herkes bir sonraki iş gününe daha fazla iş başaracağız diyerek geliyor ve yaptığı işlerden gurur duyuyor.

Scrum ‘ ın en tuttuğumuz başka bir yönü sürekli gözden geçirmelerin olması ve yeni isteklerle uyumu. Bu sayede müşterinin gerçekten ne istediğini somut şekilde anlayabiliyoruz. Uygulanan pratiklerle sürekli yazılım teslimine hazır şekilde durabiliyoruz.’

Bugün

Primavera Scrum ve XP pratiklerini kullanmaya başladıktan dokuz ay sonra hedefledikleri sürümü çıkarmayı başarır. Bu sürüm daha önce yapılan iki sürümün içeriğini oluşturan özelliklerin toplamından daha fazla özellik içermektedir. Pazarlama, ürün yöneticileri, geliştiriciler , yöneticiler ve testcilerin olduğu büyük bir ekibin işbirliği ile bu başarılı sonuç yaratılır.

Primavera çevik yaklaşımları öylesine başarılı bulur ki çevik proje yönetimi ile ilgili bir araç geliştirerek müşterilerine sunar.

En büyük zorluk

Primavera ‘ nın başarısı sonucunda her firma aynı yöntemleri uygulayabilmek isteyebilir. Fakat başarılı olabilmek için organizasyon olarak kültür değişikliği gerekir. Bu kültürü değişikliğini yapmaksızın sadece belli pratikleri kullanarak fayda sağlanması güçtür. Primavera bu başarısını yaptığı kültür değişikliğine borçludur.

Sürecin adı yok Haziran 2, 2007

Geçenlerde işe giderken aklıma takılan bir soru oldu. Acaba projede uyguladığımız sürecin adı var mı veya adının olması önemli mi?

Tüm çalıştığım ekiplerde çevik prensipleri temel alan süreçler kullanıyoruz. Sürekli entegrasyon, TDD, Refactoring, Yinelemeler, Planlama oyunları, Yayım planları -yönetimi, Kullanım hikayeleri(user story) gibi pratikler isim olarak ortak fakat detaylara baktığımda projeden projeye birçok farklılık göryorum..

Bu farklılığın nedeni süreçler projelere göre uyarlanıyor ve bu uyarlanma proje süresi boyunca son güne kadar devam ediyor.Proje süresi boyunca projeye başlangıcındaki şartlar aynı kalmıyor. Şartlar değiştikçe ortaya çıkan olumsuzlukları ortadan kaldırmak ve  daha etkin çalışma olanaklarını değerlendirmek gerekli. Projenin başından sonuna aynı süreç yapısını aynı şekilde hiç değişmeden uygulamaya çalışmak belki süreç denetim memurlarını mutlu edebilir fakat ekibin daha verimli çalışabilme olanaklarını ortadan kaldırıyor.

Çevik süreçler kendini değişikliklere nasıl adapte ediyor ? Öncelikle kültürel olarak bir fark var. Çevik ekipler kendi çalışma şekillerini seçme ve kendilerini organize etmeleri konusunda yetkili kılınıyor. Kısa sürelerle toplanıp projede neyi iyi yaptıklarını, neyin daha iyi olabileceğini tartışıyorlar. Bu toplantılara Retrospectives diyoruz. Bir nevi ekip çalışma şeklini kodların Refactor edilmesi gibi iyileştiriyor ve yola devam ediyor. Ekibi oluşturan tüm bireyler sürekli daha iyi nasıl çalışabiliriz sorusunu kendisine soruyor. İyileştirmeler tepeden değil tabandan yukarı yayılıyor. Bu konuyla ilgili daha önce yazdığım bir yazı http://cenkcivici.wordpress.com/2007/05/23/gecmise-bir-bakis/

Bu nedenle Scrum, XP vesaire gibi süreçleri kullanıyoruz demek bana çok anlamlı gelmiyor. Çevik(Agile) yapıda süreçler kullanıyoruz demek ve genellemek daha mantıklı. XP, Scrum başlangıç noktaları oluşturuyor. Sonrasında iş projeye en uygun yöntemi süzmeye kalıyor Sürecin adının ne olduğu hiç önemli değil…..

Tahminleri kim verir? Haziran 1, 2007

Diyelim ki kullanım hikayelerini(user story) leri çıkardınız. İşlerin ne kadar zamanda bitebileceğini kestirebilmek için bir tahmin yapmak şart.

Bu aşamada tahminleri kim verir? Tahminler ne olarak verilir?

Çok kısaca bizim projelerde uygulamalarımız nedenleriyle şu şekilde.

Tahminler tüm ekipçe planlama oyunu denilen pratikle verilir. Bu pratiğin detaylarını daha önceki bir yazıda anlatmıştım.Kısaca tekrarlamak gerekirse bu aktiviteye ekipteki tüm yazılım geliştiriciler katılır.  Her kullanım hikayesi teknik ve iş mantığı açısından Teknik lider ve Analist tarafından sırayla açıklanır. Bu konuda yazılımcıların soruları cevaplanır. Riskler , varsayımlar ortaya dökülür. Tahminlemeye geçmek için her ekip üyesinden onay alınır. İşin kapsamı hakkında bilgi sahibi değilseniz tahmin vermeyeceğim deyip kısa araştırma(spike) çalışması isteyebilir ve risklerin azaltabilirsiniz. Herkes tahminleme için evet diyorsa kart için herkesten aynı anda tahmin vermesi istenir.Tahminler ideal gün olabileceği gibi 1,2,3,5 gibi sayılar olarak verilebilir. Sonrasında eğer aşırı fazla veya az tahminler varsa bu tahminleri verenler neden az veya fazla verdiklerini açıklarlar ve ekip ortak bir değerde buluşur. Süreç diğer kartlarla devam eder. Bu tahminler daha sonra yayım ve yineleme planlamasında kullanılır. Özellikle projenin ilk safhalarında kartlar birbirlerine göre bağıl olarak tahmin edilir. X kartı 1 denir, ölçü olarak alınır ve Y kartının tahmini X e göre bağıl olarak verilir. Bunun nedeni projenin ilk aşamalarında zaman tahminlerinin verilmesinin zorluğudur.

Bazı ekiplerde tahminlerin sadece ekibin teknik lideri tarafından verildiğini görmek mümkün.Bunun yapılmasının nedeni tahminlerin doğruluğunu sağlayabilmek fakat işi yapacak kişi teknik lider olmayacağı için aslında tahminler doğru demek yanlış olur. Planlama oyunu aktivitesinde olduğu gibi tahminler tüm ekip tarafından verilmeli.

Peki tahminler tutmaz ise ne olur? Planlama oyununda tahminlerin birbirlerine bağıl olarak verildiğinden bahsetmiştim. Proje başladıktan bir süre sonra 1 , 2 ,3, 5 gibi ölçekte işlerin ne kadar sürdüğü ile ilgili cetveller oluşmaya başlayacaktır. 1 olan kart 0.5- 1.5 gün arası sürüyor gibi. Kartlara dair iş miktarı birbirlerine bağıl olarak tahmin edildiği için zaman tahminlerinde yaşanan problemler yaşanmayacaktır.

Ayrıca asıl olan tahminler değil ekibin birim zamanda yani yineleme(iteration) bazında ne kadar iş yapabildiğidir. Buna kısaca hız diyelim. Tahminlerin tek başına hiçbir anlamı yoktur ve işlerin ne kadar zamanda bitebileceğini hızı hesaba katmadan bulmak mümkün değildir. Eğer projenin şartları değişirse örneğin projeye yeni elemanlar eklenirse bu yineleme sonunda ölçülen hızı yükseltebilir . Bu sayede tahminlerinizi değiştirmeden projeyi süresindeki kısalma ile ilgili kestirim bulunabilirsiniz.

Özetlemek gerekirse tahminleri tüm ekip tarafından vermek gerekiyor.Tahminleri zaman olarak değil birbirlerine bağıl büyüklük değerleri ile vermek ve tahminlere TAHMIN gözüyle bakmak gerekli.  Hız ölçümü projenin süresi ile ilgili hesaplarda kullanılan asıl ölçümdür.

Çevik süreçler ve CMMI Mayıs 31, 2007

Genelde çevik süreçler ve CMMI modelinin iki farklı yaklaşımı temsil ettiği düşünülür fakat detaylı incelendiğinde CMMI ve çevik süreçler farklı seviyelerde incelenmesi gereken yaklaşımlardır.

CMMI süreç iyileştirme için kullanılabilecek bir modeldir ve modelin gereksinimlerini nasıl karşılayacağınız konusunda CMMI sizi belli bir yöntemle kısıtlamaz.

CMMI modeline uygun bir süreç uygulamasını çevik süreçleri etkin kullanarak yapabileceğiniz gibi reçete şeklinde oluşturulmuş, organizasyon yapınıza uygun olmayan ve etkinliği sınırlı bir süreçle de yapmak mümkündür. Aynı CMMI derecelendirmesine sahip iki şirketin iş yapış biçimleri, organizasyon yapıları, verimlilikleri ve proje teslim kabiliyetleri birbirlerinden çok farklı olabilir.

Çevik süreçlerin prensipleri ile çelişen durum CMMI modeli değil CMMI derecelendirmesi ile ilgili konularda şirketlerin çoğu zaman yaptıkları yanlış uygulamalar ve bu konuda yerleşmiş kültürdür.

CMMI modeline bağlı olarak süreç iyileştirmesi yapan organizasyonlarda modelin aradığı süreç alanlarına dair kanıtların çoğunlukla dokümantasyon olarak yorumlandığını ve uygulandığını görürüz. Sonuç olarak ağır dokümantasyon yükü altında organizasyon hantallaşır ve değer sağlayabilme niteliğini kaybeder. Süreç ekibin doğal çalışma ritmi olmaktan çıkar ve bürokratik bir hal alır ve organizasyona gerçek yarar sağlayamaz.

Çevik süreçler çalışan yazılımı kapsamlı dokümantasyona yeğ tutar ve sadece gerektiği kadar dokümantasyon oluşturmaya gayret eder. Çevik süreçler konusunda yanlış inanışlardan birisi hiç dokümantasyon oluşturmadan sadece yüzyüze iletişime dayandığıdır. Fakat herhangi bir çevik ekibin ofis ortamına girdiğinizde oluşturulan ve sürekli canlı tutulan dokümantasyonlar hemen gözünüze çarpacaktır.Günümüzde CMMI L4 ve L5 derecelerine çok kısa sürede gelen ve SEI yi bile bu konuda şaşırtan çevik süreçleri kullanmasıyla tanınan şirketler (Boldtech, British Aerospace Industries gibi) ortaya çıkmıştır.

Bir başka konu çevik süreçler dendiğinde sürekli Extreme Programming’in akla gelmesidir. Extreme Programming ekip olarak etkin yazılım geliştirme pratikleri sunar. Scrum ise proje yönetimine odaklanır. XP ve Scrum’ in sentezi bir süreç CMMI L3 ‘ ün gereksinimlerini karşılayabilmektir ve organizasyona en yararlı olan süreç alanları CMMI L3 seviyesine kadar olanlardır.

CMMI modelli süreç iyileştirme ile ilgili günümüzde şirketlerin en büyük yanlışlardan biri süreç iyileştirme çalışmaları sırasında süreç alanlarına ait detaylarına odaklanmaları ve büyük resmi gözden kaçırmalarıdır. Sürecin ana amacı CMMI ‘ a uygunluk değil yazılımı kullanmayı bekleyen müşteriye değer katabilmesidir. Optimize edilmiş süreç adımlarının entegrasyonu sonucu verimli bir süreç yapısına ulaşmak mümkün olmayabilir. Çevik süreçler bu konuda bütüne odaklanır ve ana amaç olarak müşteriye 2-4 hafta arası aralıklarla sürekli yazılım teslimleri yaparak değer katmayı amaçlar. Tüm pratikler bu ana amaca uygun olacak şekilde organize olur. Örneğin sürekli entegrasyon pratiği sayesinde proje her an teslime hazır halde tutulur.

Problemlere neden olan bir başka konu organizasyonların CMMI derecelendirmesine çabuk kavuşmak adına baştan belli hazır süreç paketleri ve araçları alıp uyarlama yoluna gitmeleridir. Bu yöntem maliyetleri arttırdığı gibi başarı şansı kullanılacak süreçlerin organizasyonla ne kadar örtüştüğü, ne kadar kolay adapte edilebileceği ile sınırlıdır.

Çevik süreçler ise disiplinli yazılım geliştirebilmek için elzem çekirdek pratiklerden başlayarak organizasyonun kültürüne ve projelere göre süreci sürekli geliştirerek ve iyileştirerek organik olarak oluşturmayı tercih eder. Extreme Programming pratiklerinden daha kompleks DSDM(Dynamic Systems Development Method) gibi süreçlere kadar bir evrim izlenebilir. Sonuç olarak organizasyon yapısıyla birebir uyumlu süreçlere ulaşılır.

CMMI ‘ in hedefi olan tekrarlanabilir ve sonuçları önceden tahmin edilebilir olgunlukta olan süreçler çevik süreçlerin uygulanması ile başarılabilir ve günümüzde bu konuda yaşanan problemlere çözüm olabilir .

Yalın yaklaşımlar ve çevik süreçler Mayıs 28, 2007

Çevik süreçler şu an bilişim sektörü en güçlü Amerika ve İngiltere gibi ülkelerde altın zamanını yaşıyor. 4-5 yıl öncesiyle karşılaştırdığımızda artık çok büyük şirketlerin çevik süreçlerden yarar sağlamak için çalışmalar yürüttüklerini görüyoruz. Şirketlerin ilgisindeki artış en büyük nedeni artan rekabet koşulları, şirketlerin IT projelerine yaptıkları yatırımların sonucu daha hızlı görmek istemeleri , çevik süreçlerin bu ihtiyaçlara cevap verebilmesi ve müşteriye katma değer sağlamaya odaklı olmasından kaynaklanıyor.

Çevik süreçlerin benimsediği ve Agile Manifesto(www.agilemanifesto.org) ile özetlenen prensipler ve değerler bütünü, yazılım geliştirme dünyası için yeni bir yaklaşım olarak görülüyor. Fakat benzer yaklaşımları başta üretim sektörü olmak üzere farklı sektörler uzun süredir başarıyla kullanıyor. Çevik süreçler bu yaklaşımların yazılım dünyasına izdüşümü olarak görülebilir. Bu yaklaşımın temelini Yalın Düşünce(Lean Thinking) oluşturuyor.

Yalın düşünce öncelikle hedefiniz nedir sorusunu sorar. Amaç her zaman bizi hedefe yaklaştıracak değerleri yaratmak olmalıdır. Yazılım bağlamında düşünüldüğünde hedef müşteri ihtiyaçlarını karşılayan kaliteli yazılımı hızla teslim etmektir. Yalın düşünce bu hedefe ulaşılırken kullanılan sürece ne kadar değer ürettiği, müşteriye ne sağladığı gözüyle bakar. Müşteriye değer sağlamayan süreç faaliyetleri zaman,kaynak ve para israfıdır ve sürecin etkinleşmesi için israfın yok edilmesi gerekir. Tüm faaliyetlerin ne kadar değer oluşturduğunun sürekli sorgulanması gerekir. Değer akışı bu sayede sürekli iyileştirmelerle müşteriye mükemmel değer sağlayacak şekilde ayakta tutulur. Bu sayede hem müşteriler ihtiyaçlarına daha kaliteli, hızlı ve ucuz şekilde ulaşırlar hem de firmalar rekabet güçlerini ve karlılıklarını arttırmış olurlar.

Yalın düşüncenin çıkışı Toyota Üretim Sistemi’dir(Toyota Production System). Bu sistemin temelinin atıldığı 1950′li yıllarda Henry Ford’un ortaya koyduğu kitle üretim(mass production) yaklaşımı kabul görüyordu. Fabrikalarda düşük vasıflı işçiler ve özel makinalar üretim hatlarında ucuz arabalar üretebiliyordu. Mevcut sistem üretime direk katkısı olmayan ve değer sağlamayan faaliyetleri beraberinde getiriyordu. Örneğin detaylı planlama, stok yönetimi, araç yatırımları gibi faaliyetler ve sistemin insan kaynağına özensiz bakış açısı ana problem kaynağıydı.

Savaş sonrası yıllarda Toyota kendi üretim süreçlerini kurarken Ford üretim sistemini inceledi. O yıllarda Toyota’nın zaman ve kaynak israf etmek gibi lüksleri yoktu, ayakta kalabilmek için çok verimli çalışarak müşteri ihtiyaçlarını karşılayan kaliteli ürünleri piyasaya hızlıca sürmesi gerekiyordu. Amaç üretimi tüketici istedikçe yapmak ve hızlıca tüketiciye ulaştırmaktı. Sistemde israfa yer yoktu. Stok, detaylı planlama aktiviteleri, kararlarının gecikmesi israf olarak algılanıyordu. Üretim büyük kitleler halinde değil müşterinin istediği kadar yapılıyordu. Çalışma düzeni olarak farklı makinelerin dizildiği düz bir üretim hattı yerine U şeklinde bir işçinin birden fazla makinenin sorumluluğunu aldığı bir yerleşim kullanıldı ve monotonluğu azalttığı için çalışanların iş tatmini arttı. Toyota Üretim Sistemi’nin en önemli özelliklerinden biri çalışanlara ve iş memnuniyetlerine verdiği önemdi.

Yalın yaklaşımın fabrikalarda yoketmeye çalıştığı israf 7 kategoride değerlendirilir.

İsraf 1 : Fazla üretim

Bir sipariş gelmeden malı üretmek. Örneğin yalın yaklaşımı benimseyen Dell Computer çok az bir stok tutup bilgisayarları müşteri siparişi geldiğinde özel olarak üretebilmesi ile ünlü.

İsraf 2 : Stok

Ham madde ve üretilen ara parçalar maliyetleri arttırır. Bunları üretim sırasında taşımak, saklamak gerekecektir.İdeal durum hiç stok yapma ihtiyacı olmadan ham maddenin nihai ürün olana kadar hızlı şekilde akıtılmasıdır.

İsraf 3 : Gereksiz iş adımları

Gereksiz iş adımları süreci kompleks hale sokabilir. Eğer bir iş adımı olmadan süreç işleyebiliyorsa o adım israftır.

İsraf 4 : Hareket

İşin yapılması için çok fazla efor sarfetmek gerekiyorsa bu israftır.

İsraf 5 : Hatalar

Hataları daha ortaya çıkmadan önlemek gerekir. Üründe farkedilen hatalar o ürünün üretilmesi için kullanılan kaynakların israfıdır.

İsraf 6 : Beklemeler

Bir iş adımı için başka iş adımlarının çıktıları bekleniyorsa bu bekleme israftır.

İsraf 7 : Taşıma

Bir parçayı bir yerden diğerine taşıma zorunluluğu maliyetleri arttırır ve israftır.

Amerikan firmaları Yalın yaklaşımı benimseyen ve yukarda anlatılan israfları önleyen Japon şirketleri karşısında pazar kaybetmeye başladılar. 1980′li yıllarda Toyota yeni bir araba modelini Amerikan şirketlerinin 3 de biri zamanda üretebiliyordu. Araç kalitesi ve tüketici memnuniyetinde de Japonlar açık ara önde gidiyordu.Günümüzde bile 10-15 yıldır saat gibi işleyen Japon arabalarını hala yollarda görmek mümkün. Amerikan arabalarının ise ilk 6 ay içinde dahi problemler çıkarması hatta arabaların geri çağrılması gibi problemler olağandı.

Zaman geçtikçe aynı verimi hedefleyen Amerikan ve Avrupa şirketleri yalın yaklaşımları benimsedi ve yalın yaklaşım üretim sistemleri dışında yazılım sektörü gibi birçok farklı alanda uygulanmaya başlandı. Yazılım geliştirme alanına baktığımızda Yalın yaklaşımın çevik süreçler olarak yorumlandığını söyleyebiliriz. Toyota ‘ nın ürün tasarımına bakışı çevik süreçlerin pratiklerine şaşırtıcı derecede benziyor.

İsrafı yazılım projelerine yorumlarsak aşağıdaki liste ortaya çıkıyor.

İsraf 1:Ekstra özellıklerin eklenmesi

Müşterinin sadece ihtiyaç duyduğu özelliklerin yazılıma eklenmesi gerekir. Çevik süreçler sadece günün gereksinimlerine odaklanır. Gelecekte bu gereksinim de ortaya çıkar diyerek müşterinin geri beslenimi olmadan yazılıma ek özellikler eklemez. Kodlama aşamalarında da aynı şekilde kodlar sadece günün ihtiyaçlarını karşılayacak şekilde basitçe tasarlanarak yazılır. Gelecekte ihtiyaç olacak diye sistemin kompleksliğini arttıracak özelliklerin yazılıma eklenmesinden kaçınılır.

İsraf 2: Gereksinimler

Baştan tüm gereksinimlerin detaylandırılması ve analiz dokümanlarının oluşturulması baştan hammadde stoğu oluşturmak gibi israftır. Gereksinimleri büyük yığın halinde stoklamak yerine çevik süreçler kısa adımlarla gereksinimleri alır ve bunları çalışan yazılıma dönüştürür. Bu teslimler sürekli yapılır ve analiz projenin başından son aşamalarına kadar devam eder. Teslimlerde yazılıma hangi özelliklerin ekleneceği müşterinin kendisi tarafından belirlenir.

İsraf 3:Gereksiz iş adımları

Gereksiz dokümantasyon, gözden geçirme çalışmaları , pratikte işlemeyen test süreci gibi ilk başta akla gelen iş adımları müşteriye yazılım teslimi hedefine katkıda bulunmaz. Aksine bu çalışmalar zamanla amaç haline gelir ve ekip asıl hedefi unutabilir. Çevik süreçler disiplinli şekilde yazılım geliştirilebilmek için gereken en temel pratikleri içerir ve çalışan yazılımı iş ürünleri oluşturmaktan yeğ tutar.

İsraf 4: Bilgiye ulaşırken harcanan efor

Ekibin bilgiye kolayca ulaşabilmesi ve paylaşabilmesi gereklidir. Örneğin analiste sorulacak bir soru için toplantılar düzenlemek gerekiyorsa, yazılım geliştirici işi ile ilgili kaynaklara zor ulaşabiliyorsa bu israftır. Çevik süreçlerde tüm ekip üyeleri açık bir ofis ortamında oturur ve sürekli iletişim halindedir. Ekiplerin oturma düzeni bilgi paylaşımını arttıracak şekilde düzenlenir. Ekip bilgiyi duvarlara asılan panolarda paylaşır. Örnek olarak alan modeli, projenin son performans ölçümleri, versiyon kontrol sistemi bağlantı özellikleri, önemli iletişim bilgileri, halen geliştirilmekte olan özellikler gibi bilgiler ekibin çalıştığı ortamda herkesin görebileceği şekilde paylaşılır.

İsraf 5:Hatalar

Yazılımda test aşamalarından sonra bulunan hatalar israf edilen kaynaktır. Çevik süreçlerden XP testleri birinci önceliğe koyar ve kodların yazılması için önce testler yazılır. Testler sayesinde mevcut yapının belli bir işlevi yerine getirmediği ispatlanır. Sonrasında bu işlev için gereken kodlar yazılır ve testler tekrar çalıştırılır. Test geçtiğinde işlev yazılıma eklenmiş demektir. Bu gerekenden fazla iş yapılmasınında önüne geçer.

İsraf 6:Beklemeler

Örneğin bir işin başlaması için onaylar bekleniyorsa bu israftır. SRS onayı bunun en güzel örneklerinden biridir. Testcilerinde teste başlamak için kodlamanın bitmesini beklemesi aynı şekilde israftır. Çevik süreçlerde beklemeler minimuma indirilmiştir. 2-4 haftalık sürelerle ihtiyaçlar hızlıca geliştirilip yazılıma eklenir ve müşteriye teslim edilir. Toplantılar dahi kısa zaman alması için ayakta yapılmaya çalışılır.

İsraf 7:Ekipler arası iş teslimi

Bu tür teslimleri azaltmak için Testçi, Analist, Yazılım geliştirici gibi rollerdeki ekip üyeleri hergün yazılıma yeni özellikler eklemek hedefiyle beraber çalışırlar. Örneğin gereksinimi belirten bir kullanım hikayesi(user story) ile ilgili kodlama çalışmaları başlamadan önce ekip üyeleri biraraya gelip kısaca kapsamı tartışabilir. Bu tür basit fakat etkili yöntemlerle dokümantasyon ihtiyaçları ve ek iş ürünlerinin getirdiği israf önlenmiş olur.

Çevik süreçler bu israfları önlemeye çalışırken Çevik Manifestoyu(Agile Manifesto) kullanır. Çevik manifesto tüm çevik süreçlerin kabul ettiği prensipleri ortaya koyar.

Aşağıdaki maddelerde soldakileri sağda yazılanlardan daha önemli tutar.

Bireyler ve iletişim > Kullanılan araçlar ve süreçler
Çalışan yazılım > Kapsamlı dokümantasyon
Müşteri ile işbirliği > İş sözleşmesi üstünde görüşmeler
Değişime hızlı adapte olabilmek > Bir planı takip etmek

‘den daha önemlidir. Bu sağda yazılanların önemsiz olduğu anlamına gelmez fakat solda yazanlar ilk önceliğe sahiptir.

Prensipler :
Çevik süreçlerin ilk önceliği yalın yaklaşımla örtüşecek biçimde kaliteli yazılımı müşteriye teslim edebilmektir. Bu projenin ilk aşamalarından itibaren sürekli teslimlerle yapılır ve müşterinin yazılımı çok önceden kullanmaya başlayarak değer sağlamasına olanak sağlanır. Günümüzde çevik süreçlere artan ilginin başlıca nedenlerden biri , yapılan yatırımların hızlı geri dönüşünün olmasıdır.

Çevik süreçler değişiklikleri projenin ilerki aşamalarında dahi olsa kabul eder. Amaç müşterinin ihtiyaçlarını karşılayan yazılım üretmektir ve ihtiyaçlarda meydana gelen değişiklikler projenin sonraki aşamalarında dahi yazılıma aksettirilmelidir. Test güdümlü tasarım, kapsamlı otomatik testler, sürekli entegrasyon, basit tasarım gibi pratikler sayesinde değişikliklerin getireceği maliyetler minimuma indirilir ve süreç değişikliklere çabuk adapte hale getirilir.

Çevik süreçler çok kısa aralıklarla yazılım teslimleri yapar. Bu aralıklar tipik olarak 2-4 hafta arasıdır. Bu sayede sürekli geri beslenim sağlanır ve müşterinin tam istediği şekilde yazılım evrimleşerek gelişir.

Alan uzmanları , yazılımcılar, testciler günlük olarak birlikte çalışırlar. Farklı roller arasında duvarlar örülmez. Rol bazlı ekipler yerine yazılım özelliklerine göre ekipler oluşturulur. Yazılımcı, analist, yazılım geliştirici aynı ekibin içinde çalışır ve sürekli iletişim halindedir.

Projeler motive bireyler çevresinde kurulur ve ekip üyelerine gereken kendileri ile ilgili alacakları kararlar konusunda güvenilir. Ekip kendi kendine organize olacak yetkiye sahiptir.

Yüzyüze iletişim diğer her türlü iletişim yönteminden önde tutulur.

Projedeki gelişmenin tek ölçüsü o ana kadar geliştirilmiş özellikler ve çalışan yazılımdır.

Çevik süreçler devam ettirilebilir bir hızı sağlamaya çalışır. Planlamaların sağlıklı olması için ekibin iş teslim hızının çok oynanaması gerekir. Örneğin fazla mesailer gibi yöntemlerle ekibin hızını geçiçi olarak arttırmak tercih edilen yöntemler değildir.

Teknik açıdan mükemmel , basit fakat sofistike çözümler oluşturulmasına özen gösterilir.

Çevik süreçlerin basitlik anlayışı akla gelen ilk baştan savma çözümü uygulamak yerine anlaşılması ve sonradan değiştirilmesi kolay , maliyeti en düşük ve o anki gereksinimleri karşılayan çözümü kullanmaktır.

En etkin çalışan ekipler kendilerini organize edebilen , bu konuda yetkin ekiplerdir. Ekip kendi çalışma yöntemlerini sorgulamakta ve gerekli değişiklikleri yapmakta özgürdür.

Bu yazıda kısaca yalın yaklaşımı ve yazılım sektöründe bu yaklaşımı temsil eden çevik süreçleri detaylara girmeden prensipleri çercevesinde aktarmaya çalıştım. Bu süreçlerin Türkiye gibi hızlı ve etkili çalışması gereken ve israfa tahammülü olmayan ülkelerde mutlaka uygulanması gerektiğini düşünüyorum.

Yazılım süreçleri nereye gidiyor? Mayıs 27, 2007

http://www.strategosinc.com/just_in_time.htm

adresinde sanayi üretiminde kullanılan süreçlerin nasıl evrimleştiği anlatılıyor. Her akımın yazılım geliştirme süreçlerinde izdüşümlerini görmek mümkün.

Örneğin Ford sistemi bürokratik , zaman ve kaynak israfının çok olduğu, düşük vasıflı işçilerin ve pahalı üretim hatlarının kullanıldığı bir yöntem.

Yalın(Lean) sistem ise yazılımda çevik süreçler olarak kendini gösteriyor. Sanayi üretimi konusundaki uzmanların çevik süreçlerle ilgili konferanslara katıldıklarında şaşırdıkları ve biz bu yöntemleri 20 yıl önce kullanmaya başladık, yazılım gibi yeni bir sektörün bunları tartışıyor olmasını ilginç buldukları söylenir.

Acaba hangi süreci uyguluyorlar? Mayıs 27, 2007

Çevik süreçlerin uygulandığı bir projeyi uzaktan nasıl tanırsınız?

http://www.flickr.com/photos/avlxyz/400455550/

Gecmise bir bakis Mayıs 23, 2007

 

Cevik surecleri kullanan ekiplerin uyguladigi pratiklerden birisi Retrospective adi verilen her yineleme sonunda(1 veya 2 haftalik
aralarla) yapilan gecmise ait gozden gecirme toplantilari.

Bu toplantilarin ana amaci

• Neleri iyi yapiyoruz?
• Neleri daha iyi yapabiliriz?

sorularina cevap bulmak ve bu cevaplari kullanip ekibi daha iyi isler haline getirebilmek ve nihayetinde projenin basarili olmasini saglamak.

Bu toplanti formatini biz asagidaki sekilde uyguluyoruz.

Her yineleme sonunda , bir sonraki yinelemenin planlama toplantisi oncesi tum ekip uyeleri bir odada toplaniyoruz. Herkese 15 dakika
veriliyor. Herkes elindeki postit lere bir onceki yinelemede ekibin neleri iyi yaptigini ve neleri daha iyi yapabilecegini yaziyor her
madde ayri kartlarda olacak sekilde yaziyor.

Neleri daha iyi yapabiliriz icin yazilan birkac karta ornek vermek gerekirse

• Bitirdigimiz kullanici hikayeleri ile ilgili QA den cok fazla bug donusu oluyor.
• Ekibe yeni katilanlar oldu, yineleme planlama toplantilarinda tahmin vermek yeni katilanlar icin oldukca zor.
• Esli programlama uygulanirken 2 gun ayni esle calistigimiz oluyor.
• Surekli entegrasyon sunucumuz arasira gercekten bir entegrasyon problemi olmadigi halde basarisiz oluyor.
• X modulundeki kodlar cok kotu kokular yayiyor.
• Spring MVC deki SimpleFormController yapisi gerektigi gibi kullanilmiyor.
• Yayim araliklari cok kisa, yayim oncesi yapmamiz gereken calismalar yinemeler icindeki dikkati dagitiyor.

Neleri iyi yapiyoruz kartlarina da birkac ornek ..

• Dev,QA,BA arasi iletisim iyi isliyor. Her kullanici hikayesinin gelistirilmesine baslanmadan once Dev,QA,BA uclu kisa bir toplanti cok ise yariyor.
• Kullanici hikayesi kartlarin arkasina kabul kriterlerinin yazilmasi cok iyi oldu.
• Ekibe yeni katilan arkadaslar hizli uyum sagliyor.
• Yinelemelerdeki hizimiz artmaya basladi.
• Ayakta yaptigimiz gunluk toplantilar cok iyi uygulaniyor.

Bu kartlarin her biri tahtaya yapistirildiktan sonra ayni konudan bahseden kartlar varsa bunlar gruplaniyor.

Gruplama sonrasi herkes eline bir kalem alip, tum kartlari inceleyip ayni fikirde oldugu kartlara bir tik atiyor. En fazla tik alan kartlar
grubun en cok konusulmasini istedigi konular oluyor. Bu konular sirasiyla grupca tartisiliyor ve cozum yollari tartisiliyor ve cozum
icin yapilacak isler, kimin bundan sorumlu oldugu not aliniyor ve Retrospective sonuclari olusturuluyor. Bu sonuclara bir sonraki
toplantida bakiliyor ve ekibe problemin halen surup surmedigi soruluyor.

Ekibin daha iyi calismasini engelleyen hicbir problem gizli kalmiyor…

Cevik surec deneyimi Mayıs 23, 2007

Cevik sureclerin kullanimi yayildikca gercek proje deneyimlerinin paylasildigi makalelerde artiyor.

Asagidaki makalede Amerika’da buyuk bir sirkette yapilan bir uygulama ile ilgili bilgiler var.

http://www.cio.com/article/109751

Standish den Jim Johnson su an bir sirketin cevik sureclere sirtini donmesi,basiniz agrirken aspirin almamaya benziyor diyor.

Yazılım geliştirme ve yalınlık Mayıs 23, 2007

Çevik süreçlerden ve temelindeki Yalın yaklaşımdan süreki bahsediyorum. Bu yaklaşımlar sadece yazılım geliştirme sektöründen çıkmış gibi görünebilir fakat diğer sektörler örneğin üretim sektörü bu tür yaklaşımları yıllardır kullanıyor.

Yazılım nispeten yeni bir sektör olduğu için konuşmalarda hep örnekler başka sektörlerden verilir. Yazılım geliştirme bina yapmaya , bir fabrikadan yeni bir arabanın çıkmasına benzetilir. Asıl sormamız gereken bu benzetmelerin yapıldığı sektörlerde şu an ne gibi yöntemlerin etkin olduğu.

Üretim sektörünü alırsak Toyota’nın Yalın yaklaşımı son 20 yıla damgasını vurmuş durumda ve Ford ‘un T1 üretim hattı ile başlayan kontrole ve detaylı planlamalaya dayanan süreci Toyota’nın Amerikan araba üreticilerini hezimete uğrattığı yıllar sonunda rafa kalkmış durumda.

Çevik süreçlerde bu yaklaşımların yazılıma iz düşümü. Toyota nın yeni bir arabayı nasıl tasarladığına incelediğinizde , çevik süreçlerle benzerlikleri görebiliyorsunuz.

Türkiye’ de bu konularda üretim sektörüne yol gösteren bir kurum var.

http://www.yalinenstitu.org.tr/yalin_yaklasim.asp

Yalın yaklaşımı , prensiplerini sitedeki kaynaklardan bulabilirsiniz.

Türkiye de çevik süreçler Mayıs 23, 2007

Çevik süreçler şu an bilişim sektörü en güçlü Amerika ve Ingiltere gibi ülkelerde altın zamanını yaşıyor. 4-5 yıl öncesiyle karşılaştırdığımda artık çok büyük şirketlerin çevik süreçlerden yarar sağlamak için çalışmalar yürüttüklerini görüyorum. Şirketlerin ilgisindeki artışın en büyük nedeni artan rekabet koşulları, şirketlerin IT projelerine yaptıkları yatırımların sonucu daha hızlı görmek istemeleri ve çevik süreçlerin bu ihtiyaçlara cevap verebilmesi , müşteriye katma değer sağlamaya odaklı olması.

Her yeni çıkan yaklaşımın patlama yaptığı uç noktaya çevik süreçlerde ulaşmış görünüyor. Bu konuda danışmanlık yapan, eğitimler veren şirketlerin sayısında büyük artış gözleniyor.

Türkiye’ye baktığımızda ise bu konudaki adaptasyonun çok yavaş ilerlediğini görüyoruz. Nedenleri bence şöyle…

• Çevik süreçler belli tecrübeler sonunda zamanın hakim bürokratik süreçlerine tepki olarak ortaya çıktı. Türkiye yazılım sektörü bu tepki aşamasına henüz gelmedi. Halen detaylı süreç ve araçların hakim olduğu bir süreç iyileştirme mantığı hakim.
• Rekabet koşulları çevik süreçleri mecburiyet haline getirmiyor. Kamu ve askeri ihaleler yıllarca sürebiliyor. Rekabet daha çok satış ekiplerinin arasında yaşanıyor.
• Bu konuda bilgi birikimi ve deneyimi yüksek seviyelerde değil. Gerçek projelerde bunları uygulayarak deneyim sahibi olan insan sayısı az. Yazılım geliştirme pratikleri ile ilgili bilgi seviyesi artıyor fakat proje yönetimi, planlama ile ilgili pratikler için aynı şeyi söylemek mümkün değil.
• CMMI ile ilgili çok büyük yatırımlar var.Şirketler bu çalışmalar sonucu kurdukları süreç yapılarının sonucunu görmeden yeni bir maceraya atılmak istemiyor. Yeni maceraya hazır olmaları için hali hazırda kullanılan yöntemlerin etkisiz olduğunu gerçek proje deneyimleri ile görmeleri gerekiyor.
• Türkiye yazılım pazarı özellikle büyük şirketler dış dünyaya kapalı. Aynı araçları kullanıyor olsalar bile yabancı şirketlerin kendi projelerinde nasıl yöntemlerle yazılım geliştirdiği konusunda bir paylaşım olmuyor. Kamu ve askeri ihaleler çevresinde tüm işler kümelenmiş durumda.
• Kamu ve askeri müşteriler bu süreçlerin kullanımı ile ne gibi yararlar sağlayabilecekleri konusunda bilgili değiller. Aslinda cevik süreçler sık yazılım teslimleri ve yatırımın kısa zamanda müşteriye geri dönebilmesi ile en çok müşteriye yarar sağlayan süreçler.
• Sektör şirketleri arasında bu süreçlerin uygulayan ve başarı hikayesi olabilecek örnek olmaması. Çevik süreçleri etkili kullanarak başarılı olan örnekler olması diğer şirketleri ateşleyebilirdi.

Süreç iyileştirirken dikkat edilmesi gereken en önemli şey Mayıs 22, 2007

Büyük resmi gözden kaçırmayın. Süreci oluşturan alt adımların etkin olması sürecin etkin olacağı anlamına gelmez. Alt adımların birbirleri arasındaki etkileşimi ve sürecin bir bütün olarak ne kadar etkin değer çıktısı sağlayabildiği alt adımların detaylarından daha önemlidir.

Süreçle ilgili aksaklıklar sözkonusu olduğunda yapılan en klasik hata bu büyük resimde değer akışını ve kayıpları analiz etmektense , süreci ek kontroller ve bürokrasi ekleyerek daha ağır ve işlemez hale getirmektir.Gereksinim dokümanları daha detaylı yazılmaya başlanır, yapılan her iş için izlenebilirlik oluşturulur, iş ürünlerinin bakımını kolaylaştırmak adına yeni araçlar alınır, herkes zaman çizelgeleri doldurmaya başlar fakat bunlar asıl problemi çözebilmek bir yana dursun, değer akışını ve zaman ve kaynak israflarını arttırır. Süreci müşteri önceliklerine göre işletmek giderek daha zor hale gelir. Zorluklar yaşandıkça hatalar tekrarlanır ve işler gittikçe kördüğüm halini alır.

Sistemin işlemezliğinin belirtilerini ortadan kaldırmak için uğraşırken, bu belirtilerin ana kaynağı problemle yüzleşmek zorlaşır. Asıl problemin kaynağına inmek için sürekli neden sorusunun sorulması gerekir. Bunu bir örnekle açıklayayım.

Örneğin Raporlama modülünün geliştirilmesi yavaş işliyor diyelim. İlk çözüm bu modüle yeni elemanlar eklemek olabilir. Fakat bu dediğim gibi problemin belirtilerinin üstünü örtmek olur. En az 5 kez neden sorusunu sormamız gerekir. Sorulara başlayalım…

5. Neden Raporlama modülünün geliştirilmesi yavaş işliyor?

Cevap : Bittiği sanılan işlerde çok fazla hata çıkıyor bu geri dönüşleri arttırıyor.

4.Neden çok fazla hata çıkıyor?

Cevap: Çok fazla test yazamadan işlere bitti diyoruz.

3. Neden testleri es geçiyorsunuz?

Cevap: Modülün teslim tarihleri itfaiye durumunda çalışmamızı gerektiriyor

2. Bu baskının nedeni ne?

Cevap: Bizim modülü kullanacak olan modüllerin zamanında yetişebilmesi için proje yöneticisi fazla aceleci davranıyor.

1. Neden proje yöneticisi çokkısıtlı bir zaman dilimi içinde bütün modülü bitirmeye çalışıyor?

Cevap: Projenin ilerki aşamalarında işlerin uzamasından çekiniyor ve bir an önce raporlama ile ilgili işleri bitirmek istiyor. Bu nedenle yazılımcıların önüne çok sıkı bir takvim koyup çok çalışmalarını sağlamak istiyor.

Bu 5 soru sonunda asıl problemin proje yöneticisinin korkuları olduğunu anlamış olduk. Bu soruları sormadan bu modüle eleman yığarak problemi çözdüğümüzü sanabilirdik fakat yeni elemanlar proje ekibini daha yavaşlatıp başka problemlere neden olacaklardı.

Sorunun temeline inerek problemle yüzyüze geldik. Bundan sonra yapılacak iş problemi kaynağında çözmek örneğin paralel bir geliştirme modeli geçmek olabilir. Raporlama modülü içinde iç yayımlar planlabilir ve her yayımla bu modüle bağlı olan modüllerin ihtiyaçlarını adım adım gerçekleştirilebilir. Eldeki raporlama fonksiyonalitesi ile diğer modüller geliştirme çalışmalarına başlayabilir.

Basit bir örnek fakat umarım anlatmak istediğimi göstermiştir.

Değer katmak Mayıs 22, 2007

CMMI ile ilgili literatüre baktığımda süreçlerin içindeki adımlara ve anahtar pratiklere fazla odaklanıldığını ve olgunluğun ağırlıkla anahtar pratiklerin olgunluğunun bütünü olarak ele alındığını görüyorum.

Örneğin CMMI-SW de şöyle bir tanım var.
“The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products”

Süreç içindeki adımlar belli iş ürünlerini girdi olarak alıyor ve çıktı olarak ve sonraki adımda girdi olarak kullanılmak üzere başka iş ürünleri üretiyor. Ayrica bu adimlarla ilgili detaylı planlama ve planların sürekli kontrol ve bakım altında olması olgunluğa yaklaştırır şeklinde bir düşünce yapısı mevcut.

Sormak istediğim sizce CMMI ın bu alt süreç alanlarına ve ilgili anahtar pratiklere olan odaklılığı bizi büyük resmi görmekten alıkoyuyor mu? Herhangi bir süreç içinde iş ürünleri bir adımdan diğerine sürekli transformasyonlarla değişerek son olarak müşterinin önüne yazılım olarak geliyor fakat CMMI bu adımlar ve bunların optimizasyonu ile daha ilgili.

Yalınlık prensiplerine göre ise iş önce büyük resmi görmeye çalışarak başlıyor. Gereksinimden müşterinin önüne konan yazılıma kadar işleyen süreç için Değer Akışı adı verilen bir diyagram çıkarılıyor. Değer bir işin yapılmasıyla müşteriye sağlanan katma değer anlamında kullanılıyor. Müşterinin istediği fonksiyonalitenin yazılıma eklenmesi ile değer katılmış oluyor. Değer akışı içinde müşteriye değer sağlamayan,müşterinin umrunda bile olmayan adımlar varsa bunlar Israf olarak görülüyor ve tüm süreç israfı önlemek için optimize ediliyor. Amaç değeri müşteriye en hızlı zamanda ulaştırabilmek ve süreci buna göre optimize etmek.

Örneğin bir organizasyon gereksinimler ile ilgili sayfalarca dokümanlar oluşturup onay için beklerken, bir başka şirket bu beklemeleri israf olarak görüp ilk aydan müşteriye kullanabileceği yazılım teslimlerine başlayabiliyor.

Bence CMMI bakış açısı , değer akışından çok alt adımlara odaklanmış durumda. Bu nedenle CMMI sertifikasına sahip olan şirketlerin zaman ve kaynak israfı ve müşteriye çok yavaş değer sağlaması çokca rastlanan durumlardan.

Ekip organizasyonu Mayıs 19, 2007

Zaman zaman calistigim projelerdeki deneyimlerimi paylasiyorum. Su an Ingiltere de gunluk gazetelerden biri icin yaklasik 70 kisilik bir ekiple ozel bir icerik yonetim sistemi hazirliyoruz. Bu 70 kisinin organizasyonu ve Agile pratikleri nasil kullandigimiz hakkinda kisaca
bilgiler vereyim.

 

Oncelikle 70 kisilik grupta bulunanlarin rolleri soyle

 

1. Proje yoneticisi
   Yazilim mimari
   Teknik liderler
   Yazilim gelistiriciler
   Arayuz tasarimcilari
   Testciler
   Yineleme yoneticileri
   Is analistleri
   Ekip ici musteri
   Veri tabani uzmanlari
   Kurulum sorumlusu

Bu 70 kisinin alt ekiplere nasil bolundugunu rolleri acikladiktan sonra
anlatiyorum.

 

Roller

 

1. Proje yoneticileri

 

2 proje yoneticimiz var. Bunlardan biri projenin gelistirilme faaliyetlerine, ekip icindeki islere odaklanmis durumda. Yayimlarin takibi, islerin plana gore yurudugu, butce vs bu yoneticinin kontrolunde.

 

Digeri ise organizasyonun geri kalaniyla proje arasinda iletisim vazifesi goruyor. Ofis organizasyonu, gerekli yazilimlarin zamaninda satin alinmasi, gereken insan kaynaginin saglanmasi vs gibi isler bu kisinin omuzlarinda.

 

2. Yazilim mimari
Bu kisi hem alan bilgisi olarak hemde teknik bilgi olarak ust duzeyde bilgiye ve deneyime sahip. Alt ekipler arasinda surekli mekik dokuyor
ve herkesin ayni mimari vizyonla ilerlemesine calisiyor. Fonksiyonel olmayan gereksinimlerde hedeflerin tutturulmasindan sorumlu. Surekli kod yaziyor UML diyagramlarini cizip sirca koskunde oturmuyor Bu gorevinde ona ekiplere dagilmis olan teknik liderler yardimci oluyor.

 

3. Teknik liderler
Her ekibin basinda deneyimli yazilim gelistiriciler bulunuyor. Kullanilan teknolojiler, mevcut yazilimin yapisi, altyapi faaliyetleri, yineleme kapsamindaki gereksinimlerin gelistirilmesi, planlama toplantilarinda hikaye kartlarinin teknik acidan ekibe anlatilmasi,ekipteki yazilim gelistiricilerle beraber kod yazma gibi calismalarda bulunuyorlar.

 

4. Yazilim gelistiriciler
TDD, Esli programlama(pair programming), Surekli entegrasyon gibi XP pratikleri ile kod yaziyorlar. QA den donen bug larin duzeltilmesi islemlerini yurutuyorlar.

 

5. Arayuz tasarimcilari
Kullanilabilirlik(usability) gibi kriterleri gozonunde tutup uygulamanin ve sitenin arayuzlerini sablonlar olarak hazirliyorlar.

 

6. Testciler
Hikaye kartlari ile ilgili kabul kriterlerini olusturuyorlar. Bitirilen hikaye kartlarinin testleri gerceklestiriyorlar ve bulunan
hatalari raporluyorlar. Selenium gibi araclarla fonksiyonel testleri yaziyorlar. Duzeltilen bug larin tekrar kontrolu, bug larin kritiklik seviyelerinin duzenlenmesi , buna gore yazilimin surumunun cikip cikmamasi ile ilgili kararlarda rol oynuyorlar.

 

7. Yineleme yoneticileri(Iteration manager)
Yineleme yoneticileri yinelemeler kapsaminda mikro yonetim islevini yerine getiriyor. Sabah aksam isler ne alemde diye alt ekibin basindalar. 2 haftalik yineleme sonunda amaclari mumkun olan maksimum miktarda is teslim edebilmek ve yineleme hedeflerini tutturabilmek.
Ayrica IM islerin yineleme kapsamindaki onceliginin takip ediyor ve bu onceliklere gore yazilim gelistiricilere islerin atiyor.

 

8. Is analistleri
Gereksinimlerin alinmasi, yazilim gelistirici,qa, im gibi diger ekip uyelerine gereksinimlerle ilgili bilgi verilmesi, planlama
toplantilarinda gereksinimlerin tahminlemelerden once aciklanmasi , biten fonksiyonalitenin musteriye demo edilmesi ve geri beslenimin toplanmasi gibi islemleri yurutuyor.

 

9.Ekip ici musteri
Ekip icinde calisan 3 kisilik bir grup var. Bunlar proje oncesi gazetede editorluk gorevlerinde bulunan insanlar. Projede gelistirilen kisimlarin gozden gecirilmesi, analistlerle konusup yeni gereksinimlerin belirlenmesi, bunlara musteri onceliklerinin atanmasi, organizasyonun geri kalaniyla kopru olma gibi sorumluluklara sahipler.

 

10.Veritabani uzmanlari
Veritabani modelinin hizli ve kaynaklari iyi kullanacak sekilde kurulmasindan sorumlu. Eski verilerin yeni modellere aktarimi gibi islerde bu kisilerin isi.

 

11.Kurulum sorumlusu(Build manager)
Surekli entegrasyon sunucularinin izlenmesi ,hizli islemesi, konfigurasyonu ve yonetiminden sorumlu. Deployment scriptlerinin hazirlanmasi, proje ciktilarinin versiyonlanmasi, Subversion,Trac,Twiki sunucularinin bakimi bu kisinin isi. Surekli entegrasyonu bozdugunuzda kafaniza birsey atan kisi ayni zamanda.

 

Bunlara ek olarak uygulamayi gercek ortaminda izleyen destek grubu gibi gruplarda var fakat ekibin icinde calismiyorlar.

 

Calisma ortamimiz buyukce bir ofis. Duvarlar projeyle ilgili bilgilerle kapli. Domain modelimiz, DbDeploy araci icin son versiyon numarasi, her ekibin hikaye kart panolari, son performans olcumlemeleri, ekibin hizi gibi..

 

Her sabah isteyen herkesin katildigi kisa bir toplanti yapiliyor. Bunda genelde proje yoneticileri bazi konular hakkinda bilgi veriyor. Ornegin yeni kurulum production ortaminda kuruldu gibi. Sizde tum ekibin bilmesini istediginiz birsey varsa bu toplantida soyluyorsunuz.
Bu toplanti yaklasik 5 dk kadar suruyor.

 

Sonra tum alt ekipler kendi aralarinda hikaye kartlarinin bulundugu panonun onunde toplaniyor. Herkes birgun once ne yaptigini, ne gibi problemler yasadigini, neler ogrendigini, o gun neler yapacagini anlatiyor. Yineleme yoneticisi o gun icin oncelikleri herkesle paylasiyor ve gunun plani ciziliyor ve pair programlama icin esler belirlenip is basliyor. Gun icinde esler degisebiliyor.

 

Tipik bir alt ekip organizasyonu soyle

 

1 Is analisti
1 Teknik lider
5-6 Yazilim gelistirici
1 Testci
1 Arayuz tasarimcisi
1 Yineleme yoneticisi

 

Proje icinde bu ekiplerden 5-6 tane bulunuyor. Analistler, testci baska ekiplerle paylasilabiliyor. Fakat yineleme yoneticisi, yazilim gelistiriciler, teknik lider ayni anda birden fazla ekipte calismiyor.

 

Bu alt ekipler projenin basindan sonuna ayni kalmiyor. Surekli yinelemeler sonunda diger alt ekiplerle eleman degis tokusu yapiliyor. Amac bir kisinin bir konuda uzmanlasmasi onlemek ve herkesin projenin her alanini gorup bilgiyi etkin sekilde paylasmasini saglamak. Ekip ici iletisim bu tur pratiklerle kuvvetli tutuluyor.

 

Yinelemeler 2 hafta suruyor.Her 2 hafta sonunda ic yayimlar yapilabiliyor. 2-3 aylik surelerle dis yayimlar yapiliyor ve
gelistirilen kisimlar gercek ortamda sunuluyor. Her 2 hafta sonunda yazilima yeni ozellikler ekleniyor ve musterilere sunulabiliyor.

 

Gereksinimler 2-3 cumlelik hikaye kartlari seklinde yaziliyor. Planlama oyunundaki yapilan toplantida tum ekibe kartlarla ilgili yapilacak isleri tahminler alinmadan once analist ve teknik liderler acikliyor. Sozkonusu kart icin tahmin aliniyor ve bunlara gore yineleme plani yapiliyor. Her yineleme sonunda daha once yolladigim gozden gecirmeler-Retrospective ler yapiliyor ve surec iyilestiriliyor.

 

Bir kartla ilgili gelistirme baslamadan once Story huddle dedigimiz bir pratik uygulaniyor.Analist, Testci ve isi yapacak olan 2 yazilim gelistirici max 15-20 dakika kafa kafaya verip kartla ilgili soru isaretlerini gideriyor. Kart bittigi zamanda once analist , sonra testci tamandir onayini veriyor. Gelistirme calismalari surerken surekli analiste danisiliyor. Oturma duzeni bile bu iletisimi kolaylastiracak sekilde duzenleniyor.

 

Hafta ici bazi oglenler herkes yemegini birlikte yiyip teknik bir konu hakkinda tartisiyor ve ekip ici sunumlar oluyor.

 

Domain modeli , nesnelerinin isimlendirilmesinde cok titiz davraniliyor. Domain modelinin sahibi musteridir,onun dilini yansitmak gerekir seklinde bakiliyor ve bir nesne isimlendirirken analiste danisiliyor. Daha once yolladigim sekilde surekli entegrasyon kapsaminda kod degisikliklerinde binlerce test calistiriliyor. Kurulum bozuldugunda uretim hatti duruyor ve kimse duzelene kadar kod eklemiyor.
Entegrasyon problemleri farkedildikleri an duzeltilmis oluyor. Uygulama her an deployment a hazir tutuluyor. Her basarili kurulumda otomatik olarak versiyon kontrol sistemindeki dosyalar etiketleniyor.

 

Yayimlar oncesi versiyon kontrol sisteminde branch ler aliniyor. Gercek ortamda farkedilen hatalar bu branch ustunde duzeltiliyor. Hata duzeltme calismalari yapmayan ekibin geri kalani Trunk ustunde gelistirmeye durmadan devam edebiliyor. Branch ler icin ayri cruise control sunuculari mevcut.

 

Her kod checkini hizli entegrasyon kurulumunu tetikliyor. Bunda yaklasik 40 bin birim testi 10 dk nin altinda bir surede
calistiriliyor. Bu kurulum basari olursa , cruise control yavas entegrasyon kurulumunu tetikliyor. Bu yaklasik 20 dk suruyor ve arayuz duzeyinde tum uygulama test ediliyor.

RUP uygulamalarinda yapılan bazi hatalar Mayıs 19, 2007

RUP uygulamalarında yapılan bazı hataları Craig Larman şu şekilde özetliyor.

1) Yinelemelerin(iteration) çok uzun sürmesi
2) Yinelemelerin zaman sınırlı(timeboxed) olmaması
3) Yinelemelerin tümleştirilmiş(integrated) ve test edilmiş bir yazılımla bitmemesi
4) Her yinelemenin üretim yayımı(production release) ile bittiğini düşünmek
5) Detaylandırma(elaboration) devresinin amacını geçiçi bir prototip geliştirmek olarak belirlemek.
6)Yazılım geliştirmeyi gereksizce iş ürünlerine(workproduct) boğmak
7)Baştan detaylı planlama
8)Modelleme, UML ve CASE araçları kullanmaya çok fazla odaklanmak
9)Rational in araçları olmadan UP nin uygulanamayacağını düşünmek

1) Yinelemelerin(iterations) çok uzun sürmesi

Yinelemelerin yararlarını daha önceki yazılarda tartışmıştık. Tekrar özetlemek gerekirse yinelemeler projeyi kısa devrelere bölerek riski azaltmayı, ekibin önüne kısa vadeli hedefler koyarak motivasyonu sürekli kılmayı ve müşteriyle iletişimi ve güven ortamını kurmayı amaçlar. Yinelemerin süresi uzadıkça bu amaçlara ulaşmak zorlaşır. UP’ de yinelemelerin süresi 2-6 hafta arası olmalıdır.

2) Yinelemelerin zaman sınırlı(timeboxed) olmaması

Yinelemeler zaman sınırlı olmalıdır. Eğer yineleme hedefleri gerçekleşemeyecek gibi görünüyorsa yapılacak şey yineleme kapsamında değişiklikler yaparak bazı özellikleri bu kapsamdan çıkarmaktır. Zaman sınırlı olan yinelemeler birim zamanda ne kadar iş yapabildiğinizi gösterdiği için geleceğe dair daha iyi tahminler yapmanızı sağlayacaktır.

3) Yinelemelerin tümleştirilmiş(integrated) ve test edilmiş bir sonuçla bitmemesi

Yineleme tümleştirilmiş(integrated) ve test edilmiş bir sonuçla bitmelidir. Eğer sorunlar varsa kapsam daraltılmalıdır ve yineleme sonucunda sistem dengesiz bir vaziyette bırakılmamalıdır.

4) Her yinelemenin üretim yayımı(production release) ile bittiğini düşünmek

Bunu yapmak zorunluluk değildir. Ekip içinde bir yayımda olabilir(Internal release)

5) Detaylandırma(elaboration) devresinin amacını geçiçi bir prototip geliştirmek olarak belirlemek.

Detaylandırma devresinin amacı geçiçi bir prototip oluşturmak değil tüm yazılımın işlevsel bir alt kümesini oluşturmak olmalıdır. Prototiple anlatılmak istenen geçiçi ve daha sonra çöpe atılacak kod oluşturmak değildir.

6)Yazılım geliştirmeyi gereksizce iş ürünlerine(workproduct) boğmak

Sadece gerekli olanlar seçilmeli ve uygulanmalıdır. Süreç gerekmeyecek iş ürünleri ile hantallaştırılmamalıdır.

7)Baştan detaylı planlama

Baştan detaylı planlar yapmaya çalışmak özyineli yazılım geliştirme prensiplerine aykırıdır.

8)Modelleme, UML ve CASE araçları kullanmaya çok fazla odaklanmak

Modeller ve araçlar asıl kodun önüne geçmemelidir. Sadece gerekli olan ve projeye yarar sağlayan modeller kullanılmalıdır. Gerekmediği halde UML diyagramlarının hazırlanmasını istemek projeyi yavaşlatacaktır.

9)Rational in araçları olmadan RUP nin uygulanamayacağını düşünmek

RUP nin çok araca ihtiyaç duyması yanlış anlamalardan biridir. Rational ürünlerine bağlı kalınmaksızın uygulanabilir.

Rational Unified Process in mimarlarından ve Use case kavramını ortaya atan Ivar Jacobson kısa süre önce Rational dan ayrılıp Essential UP adlı şirketi kurmuştur. Yukarda belirtilen araç bağımlı bürokratik süreç yapısından çıkmayı ve Essential UP yi Agile süreç yapısına oturtmaya çalışmaktadır.

Başarılı projelerin ortak yönleri Mayıs 19, 2007

Harvard Business School tarafından yapılan ve yaklaşık 2 yıl süren bir araştırma [MacCormack01] sonucu başarılı yazılım projelerinin aşağıdaki 4 özelliğe sahip oldukları görülmüştür.

1)Başarılı projeler yinelemeli (iterative) şekilde yazılım geliştirirler. Yazılımın müşteri için anlamlı bir parçası erken bir yayımla(release) teslim edilir ve yazılım teslimi diğer yinelemeler(iterations) ile devam eder. Müşteriden yayımlar(release) sonrası sürekli geri beslenim alınır. Yazılım bir evrim süreci sonucunda oluşur.
2)Yapılan değişiklikler sonrası günlük tümleştirme (daily integration) yapılır. Tümleştirme sonucu yazılımın durumu hakkında bağlanım(regression) testleri sayesinde hızlı bir şekilde geri beslenim alınır.
3)Yazılım geliştirme ekibi deneyimlidir.
4)Projenin başından itibaren yazılım mimarisine ve sistemin birbirinden bağımsız bileşenlerden oluşturulmasına dikkat edilir.

Buna benzer bir araştırmada Bell Labs tarafından yapılmış ve aşağıdaki özellikler saptanmıştır.

1)Yinelemeli(iterative) yazılım geliştirme ve yinelemelerin sonunda müşterinin geri beslenimi.
2)Basit organizasyon yapısı, rol tanımlarının gereksizce çoğaltılmaması.
3)Ekip içi iletişim.

Gördüğünüz gibi bu özellikler yinelemeli (iterative) yazılım süreçlerinin özelliklerine uyuyor. Özellikle çevik yazım süreçlerinin prensipleri ile birebir uygunluk sözkonuşu.

İlk araştırma sonuçlarının birinci maddesinde yinelemeli(iterative) şekilde yazılım geliştirmeden ve yazılımın çalışan bir parçasını erken teslim etmenin(early release) yararından bahsediliyor. Yazılımda çıkan hatalara hangi faktörlerin etki ettiği konusunda yapılan başka bir araştırmada birinci maddeyi doğrular nitelikte. Sonuçlara göre yazılımın %20 lik bölümünü erken teslim eden projenin ,yazılımın %40 ‘lık bölümünü daha geç teslim eden projeye oranla 10 faktör az hata içerdiği ortaya çıkıyor.

İkinci maddede günlük tümleştirme(daily integration) ve bağlanım(regression) testlerinden bahsediliyor. Hata faktörleri için yapılan araştırma bu pratiğin hataları 13 faktör azalttığını gösteriyor. 1 ve 2 numaralı özelliklerin projelere yüzde 50 ye yakın verimlilik kazandırdığı aynı araştırmada belirtiliyor.

Üçüncü madde ise insan kaynağının önemini vurguluyor. Çevik yazılım süreçleri bireyler ve ekip hayatına verdiği önemle bu özelliğe sahip durumda…

Dördüncü madde ise XP deki yüksek kalite hedefini ve tekrar tasarım(refactoring) ile yazılım tasarımının sürekli iyileştirilmesi pratiğini akla getiririyor

Burada yinelemeli(iteratıve) yazılım süreçlerinin başarılı olmasının nedenlerini kısaca bakalım.
1)Yinelemeli(iterative ) yazılım geliştirme süreçlerini kullanmak daha az risklidir.
2)Riskler önceden tespit edilebilir ve çözülebilir.
3)Proje süresince meydana gelebilecek değişikliklere çabuk tepki verebilir.
4)Projenin durumu hakkında daha fazla bilgi sağlar ve tekrarlar arttıkça tahminler
daha sağlıklı, kesin hale gelir.
5)Hatalar daha çabuk bulunur, kalite seviyesi yüksektir.
6)Sonuçta üretilen yazılım müşteri isteklerini daha iyi şekilde karşılar.
7)Erken ve sürekli süreç iyileştirmesine olanak verir.
8)İletişim ve koordinasyonu zorunlu kılar.
9)“Gördüğüm zaman anlarım” anlayışına ters düşmez.
Müşteriler ne istediklerini anlamak için bazen yazılımı görmeleri gerekir.
10)Tekrar kullanılabilirlik (reuse) için elverişli ortam yaratır.
11)Proje yöneticileri yerinde taktik kararlar alabilirler, insan kaynağı daha yerinde kullanılır.
12)Ekip üyeleri tekrarlar boyunca hatalarından dersler alır ve kendilerini geliştirir.

Standish grubunun 1998 de 23000 projeyi kapsayan yaptığı bir araştırmada [Standish98] projelerin başarısının en çok aşağıdaki 5 faktöre bağlı olduğu sonucuna varıyor. Faktörlerin ne kadar etkili olduğu yanlarında verilmiştir.

Kullanıcı/müşteri katılımı 20
Üst Yönetici desteği 15
Açık iş hedefleri(business objectives) 15
Deneyimli proje yöneticisi 15
Kısa aralıklı kilometre taşları 15

Bu faktörlerle çevik yazılım süreçleri arasında paralellik kurmak gene mümkün. Çevik yazılım süreçlerinde kullanıcı/müşteri yazılım geliştirme ekibinin aktif bir üyesi olarak çalışıyor ve sürekli geri beslenim sağlıyor. Yapılan kısa aralıklı teslimler ve demolar sayesinde üst yönetici desteği yüksek seviyede tutuluyor. Her yineleme plani(iteration plan) ve değişen öncelikler projenin gidişatının iş hedefleri doğrultusunda ilerlemesini sağlıyor. Son olarak kısa aralıklı yayımlar(release) ve sabit süreli yinelemeler(timeboxed iteration) kısa aralıklı kilometre taşları hedefini gerçekleştiriyor.

Cenk Çivici

Kaynaklar:
[Larman04]
Craig Larman, Agile and Iterative Development : A Manager’s guide , ISBN: 0-131-1115-8
[Standish98]
Jim Johnson et al. 1998. Chaos: A recipe for success, 1998. Published Report . The Standish Group
[MacCormack01]
MacCormack, A. 2001. “Product-Developmen t Practices that work.” MIT Sloan Management Review 42(2)

Yazılım projesinde rol dağılımı Mayıs 19, 2007

Bu yazımda küçük-orta ölçekli bir proje ekibindeki en temel rollere ve bu rollerin sorumluluk alanlarına değinmeye çalışacağım.

Rolleri aşağıdaki şekilde kısaca özetleyebiliriz.

1) Proje yöneticisi
2) Analist/Çözümleyici
3) Mimar- teknik lider
4)Yazılım geliştirici
5)Test/Kalite Kontrol

1) Proje yöneticisi

Proje yöneticisinin görevi projenin önüne çıkan engelleri ortadan kaldırmak ve ekibin verimli çalışması, projenin zamanında teslimi için gerekli ortamı sağlamak, önlemleri almaktır. Örneğin teknik bir konuda ekibe dışardan yardım gerekiyorsa bu yardımı sağlamak, bir danışman tutmak proje yöneticisinin işidir. Ekibin kullandığı bilgisayar, yazılım geliştirme ortamındaki sorunların hızlı şekilde çözülmesini saglamak gene proje yöneticisinin işlevine örnek gösterilebilir. Proje yöneticisi aynı zamanda kritik kararları almakta da öncu rol oynar. Yazılımda kritik bir hata varsa yayım(release) tarihinin ertelenmesi buna örnek gösterilebilir. Bu örneklerden anlaşılabileceği üzere herşeyin yolunda gittiği bir projede proje yöneticisinin işlevi çok görünür değildir.

Proje yöneticisinin görevi yapılacak işleri küçük parçalara ayırıp daha sonra bunların zamanında bitirildiğini takip etmek değildir(Micromanagement). Bu tür yönetim tarzının günümüzde artık yeri yoktur. Yönetici ekibine güvenmeli, ekipe kararlar alabilmesi ve durumlara adapte olabilmesi için gerekli yetkiyi tanımalıdır (Empowerement of the team).

2) Analist/Çözümleyici

Çözümleyicinin görevi kullanıcı/müşteri grubuyla görüşerek iş gereksinimlerini (business requirements) i almaktır. Çözümleyiciler kullanıcı/müşteri ile ekibin diğer rolleri arasında(proxy) görev yapar. Ekip içinde müşteriyi çözümleyiciler temsil eder. Çözümleyici müşteri ile iletişim içindedir yazılım geliştiricilerin gereksinimler hakkında sordukları soruları en hızlı şekilde cevaplamaya çalışır. Cevaplayamadığı soruların cevabını müşteriye giderek bulur. Müşteriden aldığı bilgileri yazılım geliştiricilerin anlayabileceği formata çevirmek gene çözümleyicinin işidir. Çözümleyicinin kullandığı format kullanılan sürece bağlı olarak değişebilir. Örneğin XP de bu format hikaye kartları, RUP gibi bir süreçte kullanım senaryosu(use case dokümani) , Şelale gibi bir süreçte ise uzun bir doküman şeklinde olabilir.

Günümüzde Çözümleyici/ tasarımcı (Analist/Tasarımcı) gibi tanımlamalara rastlamak mümkün. Böyle bir rol tanımı bence çok büyük bir hata olur. Çözümleyiciler yapılan işin alan(domain) bilgisine sahip olmalidir ve yapılan projeyi kullanıcı/müşteri bakış açısından görebilen bir kafa yapısı ve yetenek gerektirir. Tasarım ise uygulamaya , yazılan koda yakın olmayı ve yuksek teknik bilgi seviyesi gerektirir. Uygulamanın tasarımından çözümleyici rolü sorumlu olmamalıdır.

Çözümleyici grubu proje ekibi küçükse QA/Test, Proje yöneticisi gibi rolleri de üstüne alabilir fakat Tasarım,Teknik liderlik, Yazılım geliştirici gibi roller başka ekip uyeleri tarafından yerine getirilmelidir.

3) Mimar- teknik lider

Yazılım mimarisi kısaca yazılımı oluşturan önemli/büyük bileşenler ve bunların organizasyonu, birbirleri ile iletişimleri ile ilgilidir. Bu mimari üzerine yazılım iş gereksinimleri tatmin edecek şekilde bina edilir. Mimarı aynı zamanda operasyonel performans gibi gereksinimleri de tatmin etmelidir. Mimar/teknik lider tıpkı diğer yazılım geliştiriciler gibi kod yazar fakat ayni zamanda genel mimarı ile ilgili kararları almaktan, tasarım çalışmalarında liderlik yapmaktan sorumludur. Mimar/teknik lider teknik işlerin zamanında ilerlemesinden proje yöneticisine karşı sorumludur. Bu açılardan değerlendirildiğinde mimar/teknik lideri diğer yazılım geliştiriclere göre yüksek teknik bilgiye sahip ve bu işlerden yöneticiye karşı sorumlu bir rol olarak görmek mümkündür.

4)Yazılım geliştirici

Yazılım geliştirici kodun tasarlanması ve yazılmasından sorumludur. Burada dikkat edileceği üzere tasarım ve kodun yazılmasını birbirinden ayırıp ayrı rollere yüklemedim. Bunun nedeni kodun tasarımı hazırlayan insan tarafından yazılması gerektiğine inanmamdan kaynaklanıyor. Günümüzde her ne kadar modelleme dilleri geçerlilik kazanmış olursa olsun, kodun yazımı sırasında her zaman tasarımda öngörülemeyen noktalar ortaya çıkacaktir. Diğer bir deyişle kodlama tasarımı etkileyecektir. Tasarım yazılım geliştiricilerin ve mimarın içinde bulunduğu bir ekip aktivitesi haline getirilebilir fakat tasarımcı , programcı gibi bir ayrıma gidilmemelidir.

Bu tür ayrımlara gidilmesinin kaynağında programcılığı ucuz bir kaynak haline getirme çabaları olduğunu düşünüyorum. Tasarımcı ile programcının ayrı rollere bölündüğü durumlarda iyi bir tasarım olduktan sonra düşük seviyede bir programcıda olsa bu tasarımı koda çevirmek kolay gibi çok ama çok yanlış bir mantığa rastlamak mümkün Diğer bir nokta tasarımcılarla ilgili. Tasarım yapılırken yüksek teknik bilgiye sahip olmak gerekli fakat tasarımcı ile programcı rolleri birbirinden ayrılırsa tasarımcı zamanla teknik bilgi seviyesini kaybedecek ve kaliteli tasarımlar üretmekten uzaklaşacaktir.

Projenin gereksinimlerine bağlı olarak yazılım geliştiriciler UI, Veritabani, Uygulama,Rapor geliştiricisi gibi rollere ayrılabilir.

5)Test/Kalite Kontrol

Test/Kalite Kontrol rolü kullanıcının bakış açısıyla yazılımı test etmekten sorumludur. Küçük projelerde bu rolü Analistler üstlenebilir fakat Test/Kalite Kontrol rolü hiçbir şekilde yazılımı geliştiren insanlara yaptırılmamalıdır. Kodun o kodu yazan insan tarafından test edilmemesi ve kullanıcı bakış açısıyla test edilmesi çok önemlidir. Yazılım geliştirici
yazılımı bu bakış açısından görmekte zorlanacaktir. Test/Kalite Kontrol test senaryolarını hazırlar gerekirse Rational Robot, Fit gibi programlar yardımıyla bizzat kod yazarak otomatik fonksiyonel testleri gerçekleştirir. Kullanici kabul testlerini koordine eder.

Türkiye de çoğu projede QA/Test rolünün es geçildiğini söylemek yalan olmaz. Bu testleri son kullanıcıya yaptırmak sanırım en çok rastlanılan durumlardan biri. Bir diğer problemde zaman darlığına giren projelerin çoğunun test aşamalarından zaman kısmaları. Sonuç olarak hatalarla dolu yazılımlarla karşılaşıyoruz.

Test/Kalite Kontrol rolünü kısmen teknik bilgi gerektiren(programcının yapabileceği hataları tahmin etmek açısından faydalı olacaktir) ve iş gereksinimleri anlayan, kullanıcı/müşteri gibi düşünebilen bir rol olarak görüyorum ve en az yazılım geliştiriciler kadar önemli olduğunu düşünüyorum. Umarım verilen iş ilanlarında gelecekte Test/Kalite Kontrol gibi ayrımları daha fazla görebiliriz.

Proje büyüdükçe roller özelleşecektir ve proje özelliklerine göre yeni rol tanımları gerekecektir. Bunlara örnek vermek gerekirse

Yineleme yöneticisi(Iteration Manager)

Kullanıcı arayüzü(UI) tasarımcısı ,

Kullanılabilirlik (usability) testcisi

Teknik yazar (dokümantasyon, yardım dosyaları),

Kurulum/Yayım mühendisı( kurulum işlemleri, konfigürasyon/versiyon yönetimi)

Rapor tasarımcısı

Sistem mimarı (hardware mimarisi)

gibi yeni roller eklenebilir.

Iki farkli bakis acisi Mayıs 17, 2007

Gecmiste farkli projelerde farkli yoneticilerin “Scope Creep” ile
basacikabilmek adina soyledikleri iki soz…

1. Musteri ile yapilan toplantilarda konusulanlari tutanak altina alalim, her toplantinin sonunda musteri tutanagi imzalasin.
Tutanaklardan gereksinimlere kadar izlenebilirlik olusturalim. Bu sayede gelecekte kapsam disi birsey yapmamiz istendiginde bunu
engelleyebilmek icin elimizde belge olsun.

2. Onumuzdeki 6 haftalik sure sonunda cikacak ilk yayim(release) icin musterinin en cok onem verdigi gereksinim kumesini
belirleyelim. Yayim calismalari esnasinda bu gereksinimlerin disinda istekler geldikce ayri bir kumeye dahil edelim, maliyetlerini ve
onceliklerini surekli yineleme(iteration) sonlarinda degerlendirip bir sonraki adimin planini olusturalim. Ilk yayim icin onceligi
olmayanlari ilerki yayimlara planlayalim.

Bu konuya Agile ikinci bakis acisiyla yaklasiyor. Musteri ile cekismelerin yasanacagi durumlar yerine musteriyle birlikte calismak amaclaniyor. Yazilim ekibinin yapacagi islerin onceligi ile musterinin oncelikleri ortusturuluyor ve calismalar buna gore yapiliyor.

Cevik manzaralar Mayıs 17, 2007

Cevik sureclerin uygulandigi ortamlardan bazi manzaralar …

CruiseControl sunucusunun ne durumda oldugunu anlamak icin
http://www.flickr.com/photos/mchadwick/6373338/
http://www.flickr.com/photos/znachor/255143511/
http://www.flickr.com/photos/arje/96476883/

Kart Duvari(Story Wall)
http://www.flickr.com/photos/jnywong/117192781/

Basit bir uml araci
http://www.flickr.com/photos/jim/207638758/

Retrospective duvari
http://www.flickr.com/photos/jnywong/110438669/

Ofis ortamlari
http://www.flickr.com/photos/wukong/53824604/
http://www.flickr.com/photos/wukong/53825195/

Gelistirme sureci
http://www.flickr.com/photos/wukong/53825130/in/set-1167080/

Yineleme yoneticisi(Iteration Manager) Mayıs 17, 2007

Diyelim ki yineleme plani yapildi, yineleme kapsamina gelistirilmesi planlanan kartlar alindi ve gelistirme calismalari basladi. Yineleme
surerken bu kartlarin engellerle karsilasmadan zamaninda gelistirmesini nasil takip edersiniz? Yineleme icindeki calismalari
yurutmek yonlendirmek kimin gorevi olmali?

Bizde bu gorevi yineleme yoneticisi(Iteration manager) rolu tarafindan yurutuyor. Tek bir kisi proje suresince bu isi yapabilecegi gibi yinelemeler bazinda bu gorev degisik kisiler tarafindan yerine getirilebiliyor.

Yineleme yoneticisi gorevleri arasinda sunlar bulunuyor.

1. Kartlarin yineleme hayat dongusu sirasinda engellere takilmamasi,bu engellerin asilmasi
2. Ekibin yineleme icindeki hizinin takibi, geri kalan kartlari ne kadar zamanda bitirebileceginin takibi
3. Gelistirilmekte olan kartlarin durumlarinin kisa araliklarla gun icinde kontrolu, ne zaman bitebilecegi ile ilgili tahminlerin alinmasi
4. Yinelemenin mevcut durumu ile ilgili proje paydaslarina bilgi verilmesi
5. Yineleme sonuclarinin alinmasi, yineleme sonundaki “retrospective” calismasinin yapilmasi

XP de musteri Mayıs 15, 2007

XP deki musteri (“onsite customer”) pratigi ile genelde gercek musterinin birebir ekiple birlikte calismasi,ihtiyaclari araci olmadan
ekibe aktarmasi, oncelikleri belirlemesi, biten fonksiyonalitenin kabulunu yapmasi anlasilir.

Proje ekip buyuklugu, musterinin isteksizligi, calisma sekline alisik olmamasi gibi degisik nedenler gercek musterinin ekiple birebir
calismasini imkansiz kilabilir. Bu durumda musteriyi surecin disina tamamen itmeden , musteri ile surekli iletisimi mumkun kilarken ayni
zamanda XP nin uygulanabilmesini nasil saglariz?

Bizim calistigimiz projelerde analistler ekip icinde musteri rolunu oynuyor. “Onsite customer” bizim icin ekip icindeki analistler oluyor.
Fakat bu analistler insanin icinde kayboldugu gereksinim dokumanlariyla ugrasmaktansa musteri ile ekibin geri kalani arasinda
surekli mekik dokuyan tarzda cok ince bir katman icinde calisiyor.

Bu analistler genelde proje konusundaki alan bilgisi ust duzeyde olan insanlardan olusuyor. Cozulmeye calisilan problemleri iyi anlayip
anlatabilmek ve ekibin bu konulardaki sorularina onlarin anlayabilecegi dilde ifade edip her zaman cevaplamak bu analistin
sorumluluklari arasinda. Analist bizimle ayni ortamda calisiyor,oturduklari yer ideal olarak esli programlama yapilan
workstation larin cevresinde oluyor.

Hikaye kartlarini olusturmak(gerekli detayla), musteriyle konusup bu kartlarin oncelikleri belirlemek, bizim tahminlemelerimize ve
onceliklerimize gore yaptigimiz degisiklikleri musteriyle paylasmak gene analistin gorevi. Planlama oyunu sirasinda tahminler verilirken
kartlari aciklamak, sorulari cevaplamak cevaplayamadiginda gidip bu sorulara cevap bulmak(hizlica) gene bu analistin gorevi.

Analist kartlarin yinelemenin hayat sureci asamalari (Bekliyor,Gelistiriliyor, Analist gozden gecirmesi, QA testi,Gercek
musteri gozden gecirmesi, Bitis) sirasinda gerekli oldugu durumlarda devreye giriyor. Ornegin bir yazilim gelistirici hikaye kartiyla
ilgili isleri bitirdigini dusunuyorsa analistin fonksiyonaliteyi gozden gecirmesi icin karti Analist gozden gecirmesi safhasina
aktariyor(pano ustunde karti diger bolume zimbaliyor). Analist fonksiyonalitenin musterinin istedigi sekilde gerceklestirildigi
dogrulayip QA in testi icin QA Testi asamasina aktariyor. Bu asamalar arasi gecislere Analist – DEveloper , QA – Developer voleybolu diyoruz.
Degisen oncelikler hakkinda bizi bilgilendiriyor. Ornegin Bekliyor durumdaki kartlardan hangisini once yapalim dedigimizde bu soruyu
cevaplayan analist oluyor.

QA ile birlikte es(pair) olup test senaryolarinin olusturulmasi icin calisabiliyor ve kabul testlerinin hazirlanmasina yardimci oluyor,
senaryolari QA e aktariyor. Sonrasinda gercek musteri ile beraber kabul testlerinin yapilmasini koordine ediyor.

Bunun ana yararlari bence yazilim analistin yorumu ile degilmusterinin gereksinimleri uyarinca gelistiriliyor, dogru urunun ortaya
cikmasi kolaylasiyor. Gercek musteri yazilimin gelisimini surekligorebiliyor. Analist ekibin onundeki engelleri surekli kaldirarak
hizini arttiriyor.

Kodun versiyon kontrol sistemine eklenmesi Mayıs 15, 2007

XP nin sloganlarini kullanan makalelerden veya elestirilerden biraz siyrilip bu pratiklerin nasil uygulandigi konusunda konusalim istiyorum. Asagida bizim kod check in islemlerini nasil yaptigimizi kisaca ozetlemeye calistim.

Yazilimcilar yaptiklari kod degisikliklerini belli asamalara geldikleri zaman versiyon sistemine eklerler(check in islemi). Bu ekibin geri kalaninin yaptigi degisikliklerden geri kalmamak icin cok kisa surelerle yapilir. Her check in islemi icin programcinin takip etmesi gereken su islemler vardir.

1.Diger programcilarin kod degisikliklerini gormek(conflict durumlarini mesela) icin versiyon kontrol sisteminden son
degisiklikleri kontrol eder(eclipse synchronize islemi)

2.Gelen giden degisiklikler gozden gecirilir. Herhangi bir problem gorunmuyorsa yerel kopya guncellenir(update islemi)

3.Son gelen degisiklikler, yerel merge islemleri ile kurulum islemi (ant, maven gibi bi aracla) yapilir. Bu yerel kurulum derleme,testlerin calistirilmasi gibi islemleri icerir..

4. Eger derleme, testler basarili ise ve siz derleme yaparken herhangi baska bir degisiklik yapilmamissa(son bir synchronization kontrolu) check in islemi gerceklestirilir.

5.CruiseControl gibi bir entegrasyon sunucusu bu yeni degisiklikleri alarak entegrasyon kurulumunu baslatir. Eger kurulum entegrasyon sunucusunda basarisiz olursa en son checkin yapan entegrasyondaki problemi duzeltir. Basarisiz kurulum sirasinda check in islemleri yapilmaz.

Bu islemi ayni anda sadece tek kisi(veya pair) yapabilir. Bir problem oldugunda entegrasyonun neden bozuldugunun kolay
anlasilabilmesi icin ayni anda birden fazla checkin yapilmamasina dikkat edilir. Bizim projede yukarda anlatilan surece baslamadan once checkin onceligini belirtmek amaciyla kucuk bir oyuncak(kucuk bi fil) kullaniliyor. O an checkin yapmak isteyen fili alip laptopin ustune yapistiriyor ve sureci uygulamaya basliyor. Fil baskasinda iken check in yapamiyorsunuz. Bu surec en fazla 10-15 dk civarinda suruyor ve 2-3 saatlik calismaya dogal bir ara verme olanagi sunuyor.

Bunun ne avantaji var derseniz entegrasyon icin ayri bir caba harcamiyoruz. Entegrasyon problemleri ekip halinde yazilim
gelistirirken en cok bas agritan seylerden biri olabiliyor. Projenin son hali surekli calisir halde entegrasyon sunucusunda hazir haldetutuluyor.Her basarili kurulum sonrasinda Subversion da kodlar kurulumun versiyonu ile etiketleniyor. Her basarili kuruluma aitkodlara sonradan ulasmak incelemek mumkun olabiliyor.

Bu tur bir pratik ister XP ister baska bir surec kullaniyor olsun, herkesin uygulamasi gereken bir pratik bence.

Plan degil planlama onemli Mayıs 15, 2007

Burokratik sureclerdekfal bakmaktan oteye gitmeyen ve hicbir zaman takip edilemeyen kutsal proje planlarinin aksine cevik sureclerde planlama surekli yapiliyor. Aktivite bazinda degil yazilima eklenecek ozellikler(features) bazinda yapiliyor.

Yineleme(iteration) ve yayim(release) planlarini yapabilmek icin ekipten planlama pokeri adi verilen bir pratikle tahminler aliyoruz.

Planlama pokerine tum gelistiriciler katiliyor. Tipik olarak bu oyuna 5-6 gelistirici katiliyor, daha fazlasi pratigin uzun
surmesine neden olabiliyor.Tahminleri sadece gelistiriciler veriyor, proje yoneticisi veya analistler tahminlere katilmiyor. Toplanti salonunda herkes oturduktan sonra poker kartlari dagitiliyor.

Kartlarda tshirt bedenleri S, M, L, XL, XXL ,XXXL veya sayilar 1,2,3,5,8,15,25,45,100 oluyor, tahmin birimi zaman degil zaman tahmini yapmak cok daha zor ozellikle projenin ilk asamalarinda.
Kartlari buyuklukleri acisindan degerlendirip tahminleri veriyoruz.

Surec su sekilde isliyor.

1. Genellikle Analist veya proje yoneticisi hikaye kartinda(story card) yazili gereksinimi okuyor.

2. Gelistiriciler gereksinimle ilgili sorularini yoneltiyor. Sorular bittikten sonra herkes kabul ederse tahminlemeye geciliyor.

3. Gelistirici tahminini dagitilan kartlardan birini secerek yapiyor ve secili kart kapali kalacak sekilde ortaya konuyor.

4. Herkes kart secimini yaptiktan sonra tum kartlar ayni anda aciliyor. Bunun sirayla yapilmamasinin nedeni tahminleri yaparken
birbirimizden etkilenmemizi onlemek.

5. Haliyle cok buyuk veya cok kucuk tahminler gelebiliyor. Uc tahminler yapanlar birbirleri ile tartisiyor. Neden cok az veya cok
fazla tahmin yaptiklarini birkac dakika suresince tartisiyor.

6. Bu tartisma bittikten sonra kartlar cevriliyor ve bir onceki asama tekrarlaniyor. Herkes tekrar karti secip ayni anda aciyor.

7. Ortak degerlere dogru bir yakinsama yoksa gene ayni adim tekrarlaniyor. En kotu ihtimalle 3-4 raund da tahminler tartismalar sonunda
birbirine yaklasiyor.

8. Birbirine cok yakin tahminlerin oldugu durumda cogunlugun tahmini seciliyor. 8,8,5,8 durumunda 5 veren kisiye 8 in ok olup olmadigi
konusunda onayi aliniyor.

Baslangic analizinin sonunda bulunan bircok hikaye karti icin tahminler bu pratikle aliniyor ve yayim ve yineleme planlari
yapiliyor.

Gelecekte bir hikaye kartinin buyuklugunu degistirecek bir gelisme oldugu zaman veya yeni hikaye kartlari geldigi zaman bu pratik
tekrarlaniyor. Bu tekrarlar yineleme bitisinde yapilan “retrospective” toplantisinin hemen arkasindan yapilabiliyor.

Hiz tahmini Mayıs 15, 2007

Yinelemeli,arttirimli(iterative,incremental) sureclerde ilk yinelemeye oncesi(henuz elde dunun hava durumu olmadan) Hiz(velocity) tahmini nasil yapilmali?

Bir projede bizim uygulamamiz su sekilde isledi.
1. Kullanici hikayeleri analizler sonucu olusturuldu.

2. Tum hikaye kartlari icin planlama pokeri pratigi ile tahminler alindi.Tahminler icin 1,2,3,5,8 olcegi kullanildi. Bu tahminler secilen ve olcekte 1
olan basit bir kullanici hikayesine gore bagil olacak bicimde verildi.

3. Tum tahminler verildikten sonra kisa bir gozden gecirme yapildi. Cok buyuk
oldugu dusunulen kartlar ikiye bolundu. Bazi kartlar icin tekrar tahminler
alindi.
4. Olcekte 1 olan bir kartin ne kadar surebilecegini kestirebilmek icin , kartin
gelistirilmesi icin yapilacak islemler cikarildi. Veritabaninda tablolarin
olusturulmasi, dao, servislerin yazimi, ajax isleri gibi ve her birinin ne kadar
surebilecegi tahmin edildi.

5.Haftalik calisma saati bir onceki adimda cikan toplam saate(olcekte 1 olan
kart icin) bolunerek kac puanlik kartin bitirilebilecegi yani ilk hiz tahmini
cikarildi.

6.Cikan hiz tahminine uyacak sekilde kullanici hikayelerini secmesi icin
musteriyle toplanti ayarlandi

Surekli entegrasyon ortami Mayıs 15, 2007

Surekli entegrasyon (Continuous Integration) pratiginde bilindigi gibi yazilim gelistiriciler cok kisa araliklarla yaptiklari
degisiklikleri versiyon kontrol sistemine eklerler. Surekli entegrasyon sunucusu(CruiseControl gibi) bu degisiklikleri izler ve
bir degisiklik oldugunu gordugu an tum degisiklikleri alarak entegrasyon kurulumunu gerceklestirir. Bu kurulum basitce kodlarin
derlenmesi, testlerin gerceklestirilmesi, standartlarin kontrol edilmesi gibi adimlari icerir ve sonuclari raporlar. Bir problem
ciktiginda problemin kaynagi son yapilan degisiklikler olacagi icin problemi bulup duzeltmek kolaylasir ve yazilim gelistirirken
basimizi en cok agritan entegrasyon problemlerinin onune gecilmis olur.

Bu pratikle ilgili dikkat edilmesi gereken noktalardan biri bence entegrasyon ortaminin projenin gelecekte kurulacagi “production”
ortamina mumkun oldugu kadar benzemesi gerekliligi.

Ornegin gelistirme ortaminda appserver olarak Jetty , veritabani olarak Hqldb, isletim sistemi olarak windows kullaniyor
olabilirsiniz. Bu sayede daha verimli calisiyor olabilirsiniz. Fakat projenin calisacagi ortam appserver WebSphere, db olarak Oracle ve
isletim sistemi olarak Linux ise entegrasyon sunucunuzunda bu platformu kullanmasi gerekir diye dusunuyorum.

Bu sayede su anki projemizde normalde yazilim gelistirme ortaminda ortaya cikmayan fakat entegrasyon sirasinda tespit ettigimiz bircok
problemi tespit edebildik. Ornegin chart bilesenleri icin linux da java yi headless baslatmak gerekti, linux icin gereken ek guvenlik ayarlari
yapmak gerekti.
Entegrasyon sunucusu yazilim gelistirme ortaminin kopyasi seklinde olsaydi bu tur problemleri tespit etmemiz gecikebilir ve ilerde basagrisi olabilecek problemler ortaya cikabilirdi.

Tasarim borcu(Design debt) Mayıs 15, 2007

Kimse borcla birlikte yasamak istemez  fakat proje gelistirme sureci icinde binbir turlu baski altindayken , yazilim gelistiriciler olarak
problemlere bazen kestirme  cozumler uretebiliyoruz. Tekrar kodlar bunun en cok rastlanan kestirmelerden birisi…

Bazende daha kalici ve isleri basitlestirecek cozum yollarini proje ilerledikce farkediyoruz fakat zaman kisiti gibi nedenlerle bu
cozumleri uygulamamiz mumkun olmayabiliyor.

Proje ilerledikce bu borclarin ustune faiz biniyor ve isler icinden cikilmaz hale gelebiliyor. Tasarimdan kotu kokular yukseliyor, basit
bir degisikligi yapmak bile uzun arge calismalari gerektirebiliyor.

Iyilestirilmesi gereken bu tur noktalari biz tasarim borcu adiyla ayri kartlar(farkli bir renk kart kullanarak) olarak takip ediyoruz. Bunlar
planlama sureci icine girmiyor fakat hikayelerin asili oldugu panoya (story wall) konuyor.

Tasarim borcunu minimumda tutmaya ozen gosteriyoruz. Ornegin tasarim borcunu tespit edildikten 1-2 yineleme sonrasinda odemeye calisiyoruz. Eger borclar artiyorsa, alacaklilar kapimiza dayanmaya basliyorsa bu panodaki kartlarin fazlaligindan anlasilabiliyor

Konuyla ilgili olarak
http://www.jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Design%20Debt.html

Kullanici hikayesi(user story) formati Mayıs 15, 2007

Cevik sureclerde gereksinimler kullanici hikayeleri seklinde yakalaniyor.

Asagidaki yazi genelde kullanilan kullanici hikayesi formatini
ve yapisini anlatiyor.

http://dannorth.net/whats-in-a-story/

Hiz(Velocity) Gelisimi Mayıs 15, 2007

Bilindigi gibi XP de yineleme kapsaminda biten is miktari Hiz(Velocity) adiyla takip edilir. Bir onceki yinelemenin hizi bir
sonraki yinelemenin planlanmasinda kullanilir. Proje yoneticiside hizi kullanarak toplamda projenin ne kadar surede bitebilecegini kestirmeye
calisir.

Bizim projede hizda soyle bir gelisim izledik. Projenin ilk iki haftasi kucuk bir ekiple(1 analist, 2 dev) prototip calismasi yaptik.
Bir yineleme kadar suren bu calismada bazi kartlari gelistirdik ve mimari acidan belirsizlikleri ortadan kaldiracak spike adi verilen
calismalari yaptik. Bu calisma sonunda tum kartlar icin tahminleri(1,2,4 olceginde) verdik her yinelemede toplam 10 puanlik
kart bitirebilecegimizi tahmin ettik.
Daha sonra proje ekibi buyudu ve ilk yayim kapsamindaki yinelemelere basladik fakat gorduk ki ilk bir haftalik yineleme sonunda hizimiz
sadece 6 cikti. Tatil donusu olmasi,bazi teknolojilerin ekip uyeleri tarafindan ilk defa kullaniyor olmasi, ekibin birbirine uyumunun henuz
saglanmamis olmasi, riskli ve gelistirilmesi zor olan kartlarin secilmesi gibi nedenlerle bu ilk hiz dusuk cikti.
Sonraki yinelemede son hizimizi gozonune alarak 6 yi hedefledik. Yineleme sonunda hizimizin 8 oldugunu gorduk. Daha onceki problemlerin
ortaya kalkmaya basladigini gorduk.

Sonraki yineleme hizi 10 olarak cikti. En son hizimiz ise 8 olarak olculdu. Ekibe yeni birinin katilmasi ve bir hikayenin edilenden fazla
is icermesi hizdaki dusuklugun nedenleriydi.

Ozetle hizin 6-8-10-8 seklinde bir grafik olusturdugunu goruyoruz. Bir sonraki yineleme kapsamina icin 10 puanlik is almayi dusunuyoruz.
Hizin proje ilerledikce artmasi ve belli degerlere yakinsamasi acisindan iyi bir grafik sayilabilir.
Proje yoneticisi ekibin hizi olarak bu somut degerleri kullanip ne kadar zamanda tum kartlarin bitirebilecegini tahmin edebiliyor. Hiz
yeterli degilse hangi degere cikmamiz gerektigini olcebiliyor.

Hikaye kartlari(user story) hayat dongusu Mayıs 15, 2007

Panodaki
http://www.flickr.com/photos/karthikc/333796870/
Kartlarin hayat dongusu

1. Kartlar yinelemeye Gelistirilmeye hazir (Read to play) durumunda basliyor.

2. Yazilim gelistiricilerin ustunde calismaya basladigi kartlar gelistirilmekte(In Development) duruma aliniyor. Kartin ustune o an
kart ustunde calisan gelistricilerin isimleri yapistiriliyor.

3. Gelistirilmesi bittigi zaman kart BA gozden gecirmesine hazir hale geliyor(Ready for BA Review). Is analisti(BA) gelip kartin
gereksinimleri karsilayip karsilamadigini uygulamayi kisa bir testten gecirerek deniyor.

4. BA gozden gecirmesi basarili ise QA gozden gecirmesine hazir(Ready for QA review) asamasina geliyor. QA hata bulmak icin elinden geleni
ardina koymuyor BA gozden gecirmesi basarisiz olursa kart Yazilim gelistirme asamasina geri donuyor.

5. QA gozden gecirmesi basarili olursa Musteri gozden gecirmesine hazir(Ready for Customer review) asamasina geliyor ve musteriye demosu
yapiliyor. Bu demo hergun saat 5 de eger gun icinde biten kartlar varsa gerceklesiyor.

Bir yayim(release) biterken Mayıs 15, 2007

Agile surecleri kullandigimiz projelerdeki deneyimlerimi,uyguladigimiz pratikleri zaman zaman paylasiyorum. Asagidaki yazi bu konuyu anlattigim bir emailden alinti.

5 haftalik gelistirme suresinin(5 1 haftalik yinelemeler(iteration) ve 2 haftalik proje baslangic asamasi) sonunda ilk kullanici yayimini gerceklestirdik. Proje daha en az 6 ay kadar surecek fakat musteri bu Pazartesi’nden itibaren kritik ihtiyaclari olan bazi ozellikleri
barindiran yazilimi kullanmaya basliyor.

Sistem 5 haftanin (+2 haftalik inception asamasi) sonucunda yaklasik 710 birim testi ve 120 ye yakin kullanici senaryo testi(Selenium RC
ile yazilan) ile teslim ediliyor. QA bu 5 hafta icinde ikinci haftadan itibaren yinelemelerde biten hikaye kartlari icin surekli testler
gerceklestirdi.Bug veritabaninda kritik olmayan 7 bug acik kaldi.Cogu renk, alignment gibi problemler. Bug lar icin bir pair programciyi
gorevlendirdigimiz bazi yineleme(iteration) lar oldu.

Kapsamli testler sayesinde projenin sonlarinda Charting kutuphanesinin degistirilmesi, Sitemesh in kullanima alimi, Ajax inplace editing ve
autocomplete combo larinda degisik implementasyonlarin kullanimi gibi buyuk degisiklikleri gerceklestirebildik.

Projenin tum paydaslarina(stakeholder) yineleme sonlarinda demolar yapildi. Musteri tarafinda projenin sorumlusu kisiye(onsite customer)
ise hergun aksam o gun gelistirilen kisimlarla ilgili kucuk demolar gerceklestirildi.

Sonuc musteri sirket icindeki diger projelerde de Agile surecleri hayata gecirmek icin calismalar yapmaya basladi Surekli yapilan
demolar ve erken teslim ile proje hakkinda cekinceleri olanlarin bu cekinceleri giderildi.

Bu surenin sonunda musteriye calisan yazilim yerine imzalamalari icin bir gereksinim analiz dokumani, use case diyagramlari vs verseydik
acaba reaksiyonlari ne olurdu

Surekli entegrasyon Mayıs 15, 2007

Daha once calistigim projelerden birinde Surekli entegrasyon surecimiz asagidaki gibiydi.

Surekli entegrasyonu orneklemek acisindan CruiseControl surekli entegrasyon sunucusuna bagli calisan bir Ant build script imiz var.
En son kurulum 5 dakika 20 saniye surdu. Bu sure icinde yapilanlar sirayla

1. Son degisikliklerin versiyon kontrol sisteminden alinmasi
2. Veritabani script lerinin calistirilmasi
3. Veritabanina production data larinin yuklenmesi
4. Kodlarin compile edilmesi
5. 700 kusur Birim testinin calistirilmasi
6. Uygulamanin entegrasyon sunucusuna deploy edilmesi
7. 100 den fazla Selenium ile yazilmis kullanici kabubl testlerinin calistirilmasi.
8. DbSchemaSpy ile veritabani modeli ile ilgili dokumantasyonun olusturulmasi
9. Artifact lerin olusturulmasi(war dosyalari gibi) ve CruiseControl web uygulamasi araciligi ile yayinlanmasi

Bu islemler her kod degisikliginde tekrarlaniyor. Entegrasyon problemleri ile ilgili riskler problem ortaya ciktigi an farkedilip duzeltilebiliyor.

Basitlik var basitlik var… Mayıs 15, 2007

Agile sureclerin basitlige verdigi onem elestirilerin ana noktalarindan birisi. Konuyu acmak icin KISS prensibini iki farkli sekilde
yorumlayalim ve basitlik anlayislarini asagidaki kod ornekleri ile karsilastiralim.

Basit bir ornek secelim. Problem bir String deki bos karakterlerin kaldirilmasi olsun.Basitligi KISS(Keep it simple stupid) olarak, akla ilk gelen bastan savma cozum yorumlarsak , probleme asagidaki gibi bir cozum bulunabilir. Metod string i karakter karakter gezip, gezilen karakter bos karakter mi diye bakiyor. Bos olan karakteri atlayip bos olmayanlardan yeni bir string olusturarak devam ediyor

Private Function RemoveSpace(ByVal strFldName As String) As String
Try
Dim i As Integer
RemoveSpace = ""
For i = 1 To strFldName.Length
If Mid(strFldName, i, 1).Equals(" ") Then
Else
RemoveSpace = RemoveSpace & Mid(strFldName, i, 1)
End If
Next
Catch ex As Exception
End Try
End Function

KISS prensibini Agile in savundugu anlamda (Keep it Simple Sophisticated) diye yorumlarsak ayni probleme asagidaki gibi bir cozum bulunabilir. Ruby String class inin gsub metodu ile butun bos karakterleri(tab,whitespace vs) tanimlayan
bir regular expression kullanilip bos karakterler kaldirilabilir.

stringWithSpaces.gsub!(/^\s*/,”")

Basit tasarimlar yapmak,problemlere Agile in anlattigi anlamda basit cozumler bulabilmek bence gunumuzde daha fazla yetenek istiyor.

Degisiklik yonetimi Mayıs 15, 2007

Degisiklik yonetimi projenin hangi safhasinda uygulanmali seklindeki soruya soyle bir cevap vermistim…

Degisiklik yazilim projelerinin dogasi, proje suresince yeni isteklerin gelmesi, daha once alinan gereksinimlerin degismesi dogal.
Degisiklikleri kontrol altina alip onlemeye calismaktansa(ornegin srs onaylari ile) degisimlere adapte olacak ve riskleri azaltacak surec
pratikleri(Ornegin Agile planlama ve gereksinim yonetimi ve degisim maliyetini azaltici TDD,Refactoring, Continuous Integration gibi
pratikler) kullanmak gerekli.

Gelen her istek ister degisiklik olsun, ister sifirdan bir ozelligin eklenmesi olsun uyguladigimiz surecler acisindan yeni bir bir istek
huviyetini tasiyor. Istekle ilgili bir User Story hazirlanip yazilimcilardan isin maliyetinin tahmini alindiktan sonra musteriden
onceliklendirmesi isteniyor ve gelistirilme icin sirasini bekliyor. Gereksinimler,SRS->Tasarim->Gelistirme->Test->Bakim seklinde giden
waterfall tarzi calismanin en buyuk dezavantaji degisime ayak uydurmayi imkansiz hale getirmesi. Sonuc musteri ile cekismeler ve
musteri ihtiyaclarini karsilamayan yazilimlar oluyor. Gecmis boyle biten proje sonuclari ile dolu. Isin sasirtici tarafi basarisiz
projelerden sonra sirketler bir sonraki projelerinde kendilerini garanti altina almak ve onceki problemleri yasamamak durtusuyle
kullanilan surecleri daha fazla kontrollu ve agir isleyecek hale getiriyor. Ek onay adimlari, degisiklikler icin burokratik is
akislari, daha fazla arac gerec , bol bol toplanti, israf edilen zaman…

Bir baska onemli nokta bence musteriden projenin gelistirilmis kisimlariyla ilgili ne kadar sik bilgi aldiginiz, biten kisimlari ne
kadar cabuk teslim edebildiginiz. Eger cok kisa surelerle teslimler yapiyorsaniz ve ornegin haftalik iteration lar sonunda o haftanin
biten isleri ile ilgili demolar yapiyorsaniz .

Buyuk bir projeden Agile manzaralari Mayıs 15, 2007

Gectigimiz aylarda yaklasik 70 kisilik ekibin calistigi bir projede(buyuk bir gazetenin online yayin sistemi) basladim. Agile pratiklerin buyuk ekibe olceklenmesi, Domain Driven Design yontemlerinin kullanimi gibi konular acisindan iyi bir proje.

Projede uyguladigimiz bazi pratikler su sekilde.

Ekip Ozellik(Feature) lar bazinda alt ekiplere bolundu. Gazetenin organizasyon yapisini taklit edip A modulu B modulu seklinde bir yapidan ziyade, ana ozellik listesinden yola cikilarak ornegiz yazi dizileri, icerige ozgu reklamlar, ozel icerik olusturma vs gibi konularda alt ekipler olusturuldu. Bu ekiplerin yasam sureleri feature in gelistirilmesi ve teslimiyle sinirli.

2. Yinelemeler sonunda ekipler arasinda surekli eleman degisimi oluyor. Alan modeli Domain Driven Design kitabinda tanimlanan
Boundary Context lere gore bolumlenmis.

3. CruiseControl kurulumlari hizli ve yavas seklinde ikiye ayriliyor. Hizli kurulum ekipten herhangi biri checkin islemi
yaptiginda calistiriliyor. Bu kurulum yaklasik 10 dk suruyor ve hizli calisan ve birkac selenium testi bu kapsamda calistiriliyor.
Bu kapsamda yaklasik 22 bin birim testi her checkin de calistiriliyor. Yavas calisan yaklasik 20 dk suren kurulum hizli
kurulumun basarili olmasi durumunda calistiriliyor. Cruise hizli kurulumun olusturdugu artifact leri izliyor. Bir war un olustugunu
gordugu an yavas kurulum tetikleniyor.

4. Testlerin bolunlenmesi su sekilde

• Controller, Servis ler gibi katmanli yapida ustlerde yeralan nesnelerin sorumluluklarinin testleri.
• Javascript lerin Jsunit ile testleri
• Hibernate mapping dosyalarinin testleri. Her map edilen obje icin
  bir HbmTest yaziliyor.
• Veri erisiminden sorumlu Repository lerin gercek veritabanlari ile testleri.
• Performans testleri.
• Selenium ile yazilmis uygulamayi on yuzunden test eden kabul testleri

5. XP deki klasik gunluk ayakta yapilan toplantilar ekip buyuklugu yuzunden farkli uygulaniyor. Her sabah herkes toplaniyor fakat sadece tum ekiple birles paylasmak isteyen konusuyor. Sonra ekipler kendileri 7-8 kisilik ekipler icinde ayni toplantilarini yapiyorlar. Teknik liderlerde sik sik kendi aralarinda bu toplantilari yapiyor.

6.Gun icinde en az bir kere Pair degisimi oluyor. Yineleme yoneticisi (iteration manager) rolu ekip icinde dolasiyor. Yineleme yoneticisi
rolunu oynayan kisi o yineleme kapsamindaki hikayelerin gelistirilmesinde engelleri ortadan kaldirmaya ve bos kalmamaniza calisiyor

7. 2 haftada bir production ortamina biten isler yayimlaniyor. Musteri sirket bu biten ozelliklerden surekli gelir elde ettigi icin
bu kritik oneme sahip.

8. Gereksinimler musteriye cok yakin oldugumuz icin en az detayla yaziliyor. Gereksinimleri Twiki aracinda tutuyoruz. Izlenebilirlik
icin kullanici hikayelerinin arkasina test, bug vs kartlari yapistiriyoruz

9. Ekibin calisma ortaminda duvarlar ekibin ihtiyac duyacagi bilgilerle kapli. XP Story Wall, degisik grafikler, kritik bug lar vs

10. Her ekip icin Testci, Analist, UI tasarimcisi gibi roller var. Kullanici hikayeleri fazla detay icermedigi icin bir hikayeyi gelistirmeye baslamadan once QA,BA ve Dev bir araya gelip kisa bir gorusme yapiyor.

Simdilik aklima gelen bunlar…