Merhaba
Bu hafta calistigim sirketce yazilim gelistirmede yeni bir yaklasima gectik. Pilot calismasi yapildiginda herkesin mutlu oldugu bu modeli sirketce benimseme karari aldik.
Simdiye kadarki sistemde, proje sahibi ihtiyaclarini ve taleplerini bir panel'e onem derecesi vererek yapistiriyordu (bunun fiziksel post-it veya index card yapilari da mevcut, bilgisayar ortaminda olanlari da)
Sonra "İş Analist"i (Business Analyst) toplanti organize edip isin detaylarini ogreniyor ve bu isi iligli yazilim biriminin tahtasina ihtiyaclar, beklentiler, kabul kriterleri, etkilenecek yerler gibi detaylarini da kapsayacak sekilde yazip asiyordu.
Yine analisr proje sahibi ile konusarak oncelik sirasina gore bu "ticket"'i siraliyordu
Ilgili yazilim birimi elindeki is yogunluguna bakarak Ticket'i ele aliyor ve uzerinde calisip bitirince test kolonuna asiyordu. Test onay verdikten sonra proje sahibi isi gorup is acisindan test ediyor ve kabul verince is hayata geciriliyor ve sonuclaniyordu.
Cok da duzgun isleyen bu sistemin bir handikapi bazen oncelikler bazen isin geregi olarak bekleyen "ticket"lar guncelligini yitirebiliyor veya buyuk parcalar halinde yazilim yapimasi gereginden dolayi uzun zaman alabiliyordu. Yazilimcinin gorusu pek alinmadigi icin yazilim sirasinda ortaya cikan uyumsuzluklar bircok toplantiya ve analizlerde revizyona ihtiyac duyabiliyordu.
Yine de bu yapinin tum bu aksayan yanlara ragmen oldukca akici bir sistem oldugunu da kabul etmemiz gerekiyor. Bu sistem icin Agile Zen kullaniyorken sonra oylama ile Trello'ya gectigimizi de dipnot olarak vereyim.
Bu sistem ocellikle BDD ve TDD yapilari ile son derece uyumlu oldugu icin genelde cok de benimseniyordu.
Bu hafta calistigim sirketce yazilim gelistirmede yeni bir yaklasima gectik. Pilot calismasi yapildiginda herkesin mutlu oldugu bu modeli sirketce benimseme karari aldik.
Önce
Yazilimda simdiye kadar Agile metodolojisi kullaniyorduk, en modern, kullanisli ve ise uygun yapilari uygulamayi seven bir sirkette calismak gercekten cok hos bir tecrube.Simdiye kadarki sistemde, proje sahibi ihtiyaclarini ve taleplerini bir panel'e onem derecesi vererek yapistiriyordu (bunun fiziksel post-it veya index card yapilari da mevcut, bilgisayar ortaminda olanlari da)
Sonra "İş Analist"i (Business Analyst) toplanti organize edip isin detaylarini ogreniyor ve bu isi iligli yazilim biriminin tahtasina ihtiyaclar, beklentiler, kabul kriterleri, etkilenecek yerler gibi detaylarini da kapsayacak sekilde yazip asiyordu.
Yine analisr proje sahibi ile konusarak oncelik sirasina gore bu "ticket"'i siraliyordu
Ilgili yazilim birimi elindeki is yogunluguna bakarak Ticket'i ele aliyor ve uzerinde calisip bitirince test kolonuna asiyordu. Test onay verdikten sonra proje sahibi isi gorup is acisindan test ediyor ve kabul verince is hayata geciriliyor ve sonuclaniyordu.
Cok da duzgun isleyen bu sistemin bir handikapi bazen oncelikler bazen isin geregi olarak bekleyen "ticket"lar guncelligini yitirebiliyor veya buyuk parcalar halinde yazilim yapimasi gereginden dolayi uzun zaman alabiliyordu. Yazilimcinin gorusu pek alinmadigi icin yazilim sirasinda ortaya cikan uyumsuzluklar bircok toplantiya ve analizlerde revizyona ihtiyac duyabiliyordu.
Yine de bu yapinin tum bu aksayan yanlara ragmen oldukca akici bir sistem oldugunu da kabul etmemiz gerekiyor. Bu sistem icin Agile Zen kullaniyorken sonra oylama ile Trello'ya gectigimizi de dipnot olarak vereyim.
Bu sistem ocellikle BDD ve TDD yapilari ile son derece uyumlu oldugu icin genelde cok de benimseniyordu.
Sonra
Simdi ise neredeyse tum bunlari cope attigimiz yeni bir sistem ile karsi karsiyayiz. Dun dagitilan dokumana gore prensipleri asagida yazacagim . Orjinal dokumana buraya tiklayarak ulasabilirsiniz (Ingilizce)- Analiz onceden yapilmayacak, ise baslandiginda aninda yapilacak
- Buyuk is parcalari tanimlandiginda, kucuk bitirilip test edilebilir parcalara bolunecekler
- Analist, yazilimci, proje sahibi ve testci proje boyunca birarada calisacak
- Analist maestro gibi calisacak, tikanikliklarin hizla cozulmesine katki saglayacak
- Proje sahibi gunluk 5-10 dakikalik hizli durum degerlendirmesi toplantilarina katilacak
- "Ticket" lar kisa ve hemen halledilebilir boyutlarda olacak
- "Ticket" lar kabul kriteri kivaminda olacak (onceden yazilan 15 - 20 maddelik kabul kriterlerinin her biri bir "ticket" olacak
- isler "minimum teslim edilebilir is" olarak degerlendirilecek ve biten her kucuk parca dagitilacak (deploy) (Benim bu konuda ciddi endiselerim var mesela )
- Hangi "ticket"larin "minimum teslim edilebilir is" oldugu tespit edilecek ve oncelik sirasina sokulacak
- Kucuk dagitimlar ile Ana projenin fonsiyonelligi artirilacak
- Guclu bir iletisim esas olacak
- Haftalik olarak "ne yapildi ne yapilacak" toplantilari duzenlenecek
- Oncelik proje sahibince belirlenecek (teknik oncelik yoksa)
Beklenen Faydalar
- Proje sahibi isin daha fazla icine girerek isin yuruyusu hakkinda canli bilgi sahibi olabilir
- Sorunlara ve sorulara cok daha hizli cevaplar uretilecek
- Degisen ihtiyaclara daha esnek cozum uretilecek
- Programcilarin yaraticiliginin onu acilacak (is hakkinda fikir uretip tartismasinin onu acilacak)
- Daha cabuk dagitimlar (deploy) saglanacak
- Daha kucuk "ticket"lar olacagi icin daha kisa test zamanlari olaacak = daha az hata cikacak
Evet mevzu bu sekilde ozetlendi.
Bu yaklasima uygun olarak proje tahtalarinin bu sisteme uyumlu hale getirilmesi de dusunuluyor elbet. Eskiden tek bir tahta vardi ve Next Up kolonundan once bir kuyruk ile yapilacak isler siralanirdi. Simdi bir yazilim tahtasi ve buna ticket getiren diger tahtalar su sekilde duzenlendi
Hangi tahtalardan is geldigina bakacak olursak
1 - Features : yapmak istenilen ama henuz kucuk parcalara bolunmemis isler
2 - Tech : sistem upgrade'leri, database bakimlari vs
3 - Bugs : hatalar
4 - Current : bolunmus ve yyapilmaya hazir isler
Bu sistemde benim birkac yorumum ve cekincem var. Bu konu aslinda biraz da yazilim gelistirme dili ile de ilgili. Yani yukaridaki prensipleri hazirlayan ve pilot uygulamasini yapan ekipler Ruby ile calisiyorlar. Yani kodlar acik halde deploy ediliyor ve interpreter araciligi ile yorumlanip calisiyor. Bu da onlara kucuk parcalarin dagitiminda esneklik sagliyor. Halbuki benim kullandigim yapi .NET ve compile edilerek deploy edildigi icin bu esneklige sahip degilim. (Klasik ASP'nin gozunu seveyim)
Benim calistigim proje .NET 1.0 da baslayip senelerce bu sekilde devam etmis yani yapi olarak eski ve hantal. TDD ve BDD ile uyumlu degil. yani kucuk, test ve teslim edilebilir parcalar icin uygun ortami saglamiyor. Projenin .NET uzerinde yeniden yazilmasi zaten konu disi yani yeniden yazilacaksa Ruby'de yazilacak ve bu cok ust duzey bir karar gerektirdiginden bu konuda adim atilamiyor.
Genel olarak yapklasim bana Turkiye'deki "Ati kosarken nallayalim", "kervan yolda duzulur" yaklasimlarini hatirlatti. Dolayisiyla bence Turkiye bu yaklasima daha yatkin bir ulke. Ne dersiniz ?
