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.
