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…
