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.