Günlerden birgün……

Çevik süreçler konusundaki önyargılardan biri bu süreçlerin disiplinle ters düştüğü şeklinde. Boehm in yazdığı , içeriği iyi olmakla beraber Balancing Agility and Discipline gibi yanlış başlıklı  kitaplar bile var.

Çevik süreçler disiplinli mi sorusuna  Kent Beck in güzel bir cevabı var.’Bir atlete çevik misiniz yoksa disiplinli mi gibi absürt bir soru sorabilir misiniz? Her atlet disiplinli olabildiği ölçüde çevik olabilir. Disiplinle çalışması çevikliği ve başarıyı getirir.’

Çevik süreçlerde çevik olabilmek için disiplin gerekir. TDD, Sürekli entegrasyon, refactoring gibi geliştirme pratiklerinin titizlikle uygulanması, sürekli iyileştirmeye, ekip hayatına ve iletişime verilen aşırı önem bu disiplinin parçalarıdır.

Çeviklik kullanılan Xp,Scrum gibi süreçlerden öte yazılım geliştirme projelerine yönelik bir bakış açısını ifade eder. Bu bakış açısı Çevik manifesto ve prensipler olarak özetlenir.

Manifesto

Aşağıdaki maddelerde soldakileri sağda yazılanlardan daha önde 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

• İlk önceliğimiz 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.

• Değişiklikler projenin ilerki aşamalarında dahi olsa kabul edilir. Amaç müşterinin ihtiyaçlarını karşılayan,onlara yarar sağlayacak , gerçek değer katacak 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.

• Çok kısa aralıklarla yazılım teslimleri yapılır. 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, testçiler günlük olarak birlikte çalışırlar. Farklı roller arasında duvarlar örülmez. Rol bazlı ekipler yerine yazılım özelliklerine(features) 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.

• Sadelik 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.

• Ekip kısa sürelerle toplanır, çalışma yöntemlerini gözden geçirir ve daha etkin ve etkili çalışmak için kendini retrospective formatında yapılan toplantılarla gözden geçirir.

Zaman zaman su an calistigim projedeki tecrubelerimi paylasiyorum. Proje yaklasik yuz kisiye yakin bir ekip tarafindan gelistirilen ve
ekibin ayni fiziksel ortami paylastigi en buyuk Agile projelerden biri. Guardian gazetesi icin akilli bir icerik yonetim sistemi hazirliyoruz.
Proje Agile sureclerin buyuk ekiplere olceklenmesi ve basarisi acisindan onemli bir uygulama.

Projede yaklasik 70 gelistirici calisiyor ve gunde ortalama versiyon kontrole checkin yapilan changeset sayisi 50 civari.

Her checkin islemi icin gelistirici checkin dansi dedigimiz sureci uyguluyor. Once versiyon kontrolden baskalarinin yaptigi
degisiklikleri cekiyor ve kendi dosyalarini guncelliyor. Sonra kendi bilgisayarinda checkin icin kullanilan scripti calistiriyor. Bu script
kodlari derleyip testleri calistiriyor. Testler basarili ise gelistirici kendi degisikliklerini versiyon kontrole ekliyor. Sonrasi
bildiginiz gibi CruiseControl tarafindan yapilan otomatik entegrasyon kurulumu. Bu kurulum icin 2 asamali bir surec kullaniliyor. Ilk
asamada hizli Cruise sunucusu birim ve entegrasyon testlerini calistiriyor. Bu basarili olursa yavas calisan senaryo testlerini
calistiran bir baska Cruise sunucusu tetikleniyor ve kritik fonksiyonaliteler icin bu testler calistiriliyor. Buna ek olarak her
gece yarisi tum senaryo test suitelerini calistirdigimiz bir asama var. Kodlarda bir nokta bile degisse , degisiklik bu entegrasyon
surecinden otomatik geciyor.

Cruise kurulumlari basarisiz olursa kurulumlari takip eden gelistirici basarisizliga neden olan checkin i yapan kisinin masasina proje
ofisinin heryerinden gorulebilen sisme bir palmiye agacini koyuyor.Amac kurulumu kim kirdi, kim duzeltiyor gorebilmek. Kurulum kirilmis
durumda iken kimse checkin yapamiyor , uretim hatti duruyor. Kurulumu kiran gelistirici ya problemi duzeltiyor ya da insanlari bekletmemek
icin degisikligini geri aliyor. Bu duzeltme suresi 5-10 dk ile sinirli. Cruise kurulumunu bozmak oldukca stresli olabiliyor, 70
kisinin baskisini ustunuzde hissedebiliyorsunuz.

Gunde kurulumun kirilma sayisi su aralar 2-3 gibi. Bu kadar kisinin calistigi bir projede insanlarin birbirinin ayagina basmamasi
olanaksiz ve entegrasyonun kirilmamasi olanaksiz, bu entegrasyonun sagliksiz oldugunu ve testlerin yetersizligi gosterir. Arada bir
kirilmasi gerekli fakat minimumda tutmak gerekiyor. Her 50 checkin de 2-3 problem katlanilabilir duzeyde.

Proje icinde bilgi paylasimini etkin kilabilmek icin yazdigimiz kucuk bir Ruby on Rails uygulamasi var. Bu uygulama Cruise sunucularinin o
an ne yaptiklarini, hangi durumda olduklarini, Test, Demo vs gibi ortamlara yapilan deployment larin hangi versiyon kontrol etiketiyle
yapildigini, Trac de bulunan mevcut bug sayilarini, bunlarin seviyelerini, uygulamanin production da calisan son halinin screenshot
larini, siteye gelen hit sayilarini , hiz olcumlerini ve gunun mesaji dedigimiz duyurular icin kullanilan ekranlari proje ortamindaki LCD tv den sirayla gosteriyor.

CruiseControl yazilimda da yaptigimiz degisikliklerle Ant in verdigi ciktiyi anlik gosterebiliyor. O an Cruise un hangi asamada oldugunu
izlemek mumkun oluyor. Yazilan Ruby script leriyle bu log lar incelenip yavas calisan kurulum asamalari bulunmaya calisiliyor.
Ornegin biri cok yavas calisan bir test yazdiysa bu raporlarda ortaya cikiyor. Amac bu problemlerin onune gecip hizli kurulumu 10 dk, yavasi
ise 20 dk civarinda tutabilmek.

Yazilimlar sonucu editorler gazetenin gunluk internet sitesini hazirliyor. Gunluk ayri ziyaretci sayisi yaklasik 2 milyon civari,
aylik hit sayisi 170 milyon. Sistem bundan daha fazlasini kaldirabilecek gucte, saniyede 400 sayfa gosterimi gibi kriterleri
mevcut. Proje kullandigimiz open source teknolojiler olan Spring,Hibernate, Resin vs ile ilgili performans konusunda iyi bir
case study olusturdu.

Projenin yonetiminde Agile surecler kullaniliyor. Bu sayede sayesinde projenin 3. ayindan itibaren teslimler yapilmaya baslandi ve gazete
editorleri yazilimi seyahat gibi kisimlar icin kullanmaya basladi. Sitenin diger kisimlari icin Legacy sistem kullanilmaya devam etti.
Sonraki aylarda asama asama baska bolumler teslim edildi. Bu degerin cabuk verilmesi sayesinde reklam gelirleri artmaya ve proje kendi
maliyetini cikarmaya basladi. Su an site sayesinde Ingiltere de en cok okunan internet gazete sitesi durumuna yukseldi. Bu Agile in IT ile
is hedefleri arasinda paralellik kurabilmesine guzel bir ornek.

Cache implementasyonunu gerceklestirmek icin yazacagim testleri
ekledim. Testler CacheImpl a ozel ve izole, CachePolicy / CacheLoader
implementasyonlarina bagli degil…

Test edilen davranislar
-Cache ilk olusturuldugunda bos olmali.
-Cache den key ile bir istek yapildiginda CacheLoader i kullanarak
istenen objeyi dondurmeli.
-Mevcut cache lenen bir element varsa, ayni element istendiginde
CacheLoader cagrilmadan istek Cache den saglanmali.
-Birden fazla element cachelenebilmeli.
-CacheLoader istenen element i bulamazsa ve exception firlatilsa Cache
null dondurmeli.
-Cache Policy o anda cache in temizlenmesi gerekiyor derse cache
temizlenmeli ve element tekrar yuklenip cache e eklenmeli.

TEST

public class CacheImplTest {

public boolean shouldRefreshCache = false;

@Test
public void cacheIsEmpty() {
CacheImpl vodafoneCache = new CacheImpl(null,null);
assertThat(vodafoneCache.isEmpty(),is(equalTo(true)));
}

@Test
public void
testShouldLoadFromCacheLoaderIfItemWithGivenKeyIsNotCached() throws
Exception {
CacheLoader cacheLoader = EasyMock.createMock(CacheLoader.class);
CacheImpl cacheImpl = new CacheImpl(cacheLoader,new CachePolicyStub());

Object KEY = new Integer(1);
Object VALUE = new String(”A”);

EasyMock.expect(cacheLoader.load(KEY)).andReturn(VALUE);
EasyMock.replay(cacheLoader);

Object loadedObject = cacheImpl.load(KEY);

EasyMock.verify(cacheLoader);
assertThat(loadedObject,is(sameInstance(VALUE)));
}

@Test
public void
testShouldNotLoadFromCacheLoaderIfItemWithGivenKeyIsCached() {
CacheLoader cacheLoader = EasyMock.createMock(CacheLoader.class);
CacheImpl cacheImpl = new CacheImpl(cacheLoader,new CachePolicyStub());

Object KEY = new Integer(1);
Object VALUE = new String(”A”);

EasyMock.expect(cacheLoader.load(KEY)).andReturn(VALUE);
EasyMock.replay(cacheLoader);

cacheImpl.load(KEY);
cacheImpl.load(KEY);

EasyMock.verify(cacheLoader);
}

@Test
public void testShouldCacheMultipleItems() {
CacheLoader cacheLoader = EasyMock.createMock(CacheLoader.class);
CacheImpl cacheImpl = new CacheImpl(cacheLoader, new CachePolicyStub());

Object KEY1 = new Integer(1);
Object VALUE1 = new String(”A”);
Object KEY2 = new Integer(2);
Object VALUE2 = new String(”B”);

EasyMock.expect(cacheLoader.load(KEY2)).andReturn(VALUE2);
EasyMock.expect(cacheLoader.load(KEY1)).andReturn(VALUE1);
EasyMock.replay(cacheLoader);

Object loadedObject1 = cacheImpl.load(KEY1);
Object loadedObject2 = cacheImpl.load(KEY2);

EasyMock.verify(cacheLoader);

assertThat(loadedObject1, is(sameInstance(VALUE1)));
assertThat(loadedObject2, is(sameInstance(VALUE2)));
}

@Test
public void testShouldLoadFromCacheLoaderIfCachePolicyIsTrue() {
CacheLoader cacheLoader = EasyMock.createMock(CacheLoader.class);
CachePolicy cachePolicy = new CachePolicyStub();
CacheImpl cacheImpl = new CacheImpl(cacheLoader, this);

shouldRefreshCache = true;
Object KEY1 = new Integer(1);
Object VALUE1 = new String(”A”);

EasyMock.expect(cacheLoader.load(KEY1)).andReturn(VALUE1).times(2);
EasyMock.replay(cacheLoader);

cacheImpl.load(KEY1);
cacheImpl.load(KEY1);

EasyMock.verify(cacheLoader);
}

@Test
public void shouldReturnNullIfCacheLoaderThrowsItemNotFoundException() {
CacheLoader cacheLoader = EasyMock.createNiceMock(CacheLoader.class);
CacheImpl cacheImpl = new CacheImpl(cacheLoader, this);

EasyMock.expect(cacheLoader.load(EasyMock.anyObject())).andStubThrow(new
ItemNotFoundException());
EasyMock.replay(cacheLoader);

Object loadedObject = cacheImpl.load(”A”);
assertThat(loadedObject,is(equalTo(null)));

}

private class CachePolicyStub implements CachePolicy {

public boolean shouldRefreshCache() {
return shouldRefreshCache;
}
}

public boolean shouldRefreshCache() {
return shouldRefreshCache;
}
}

Implementasyon

public class CacheImpl {

private final CacheLoader cacheLoader;
private Map cachedElements = new HashMap();
private final CachePolicy cachePolicy;

public CacheImpl(CacheLoader cacheLoader, CachePolicy cachePolicy) {
this.cacheLoader = cacheLoader;
this.cachePolicy = cachePolicy;
}

public Boolean isEmpty() {
return true;
}

public Object load(Object key) {

if (cachePolicy.shouldRefreshCache()) {
cachedElements.clear();
}

Object cachedElement;
if (!cachedElements.containsKey(key)) {
try {
cachedElement = cacheLoader.load(key);
} catch (ItemNotFoundException ex) {
return null;
}
cachedElements.put(key, cachedElement);
}

return cachedElements.get(key);
}
}

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.

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.

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.

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/

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.

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.

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

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ç 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.

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.

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ğ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

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.

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.

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/

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 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.

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…..

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.

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 .

Ç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.

Ç