Valla blog yazisi yazmayalı çok uzun zaman oldu. Onun icin yazıma başlarken çok heyecanlandım. Bundan 20 önce de aynen bu şekilde blog yazısı yazıyordum, sonra yazılar seyrekleşmeye başladı, sonra sayfam hackendi yazılar bozuldu. Herşeyi geri yükleyecek enerjiyi de bulamayınca sıfırdan başlamaya karar verdim. O da olmadı. Neyse, bir de bunun yanında uzun zaman sonra klavyemi Türkçe’ye çevirdim ve Türkçe yazmaya çalışıyorum.
İlk yazı olduğu için biraz kendimden bahsedeyim mi bilmiyorum ama yaklaşık 7 yıldır Amerikada yaşıyorum. 25 yıldan uzun süredir yazılım işleri ile uğraşıyorum. Bu sene de kendi youtube kanalımı açtım. Buraya linkini koyarım.
Agile development benim gençliğimde çok konuşulan konulardan biriydi. Konuyu bilmeyen veya kullanmayan şirketler geri kafalı olarak görülüyordu. Zaman geçti ve bir şekilde büyük umutlarla bel bağlanılan sistem döndü dolaştı ve yeni bir sömürü sistemine döndü.
Ben lisedeyken (sene 1990-98) yazılım projelerini yönetecek düzgün bir yöntem olmadığı için inşaat projelerine benzer bir şekilde yönetmeye karar vermişler. O zamanlar hep şöyle sözler söyleniyordu; ”Yazılım projelerinin %90’ı zamanında tamamlanamıyor ve %70’ı başarısız oluyor.” Tabi ben bunu ilk duyduğum zaman lisede tubitak için yazılım projesi hazırlıyordum. O zamanlar çözüm olarak waterfall denen bir yöntemden bahsediliyordu. Yani çok detaylı analiz yap, sonra çok detaylı döküman yaz, sonra işleri modüllere ayır, ekip belirle, ekipleri işlere ata, işlerin birbiri ile olan bağlarını belirle ve nihayet otur kodu yaz.
Bu yöntemle birden fazla ekip birbiri ile bağlantılı olarak çalışması gerekiyor ve her ekip kendinden önce gelen ekibin işini bitirmesini bekliyor. Aynı zamanda işler kötü gittiğinde her ekip kendinden önce gelen ekibi suçlayabiliyordu. Bu yöntemi biraz daha düzeltmek için önce işleri daha küçük parçalara ayırmaya başladılar. Bu durumda mesela çok büyük bir yazılım projesinde modüller şu şekilde oluyordu. Kullanıcı işlemleri, finans işlemleri, raporlama işlemleri, … Sonrasında da bizim şelale yöntemini her biri için çalıştırmaya başladılar. Bu durumda Analizciler birinci modülü bitirdiğinde hemen ikinci modül için çalışmaya başlayabiliyor. Diğer ekipler de biten işlerin devamındaki işleri hemen yapmaya başlıyorlardı. Çok güzel, kimse boşta kalmıyor.
Bu aşamada çok basit bir soru sorayım. İstanbul’dan Ankara’ya araba ile gitmek ne kadar sürer. Veya daha basit birşey sorayım İstanbul’da Kadıköy’den SultanAhmet’e gitmek ne kadar sürer. Bunlar çok basit sorular olarak görülebilir ama doğru cevabı verebilmek için bir sürü bilgiye ihtiyacınız var. Hangi gün, hangi saatte, hangi yoldan, hangi taşıtla gidilecek gibi bilgileri bilmeden cevap vermek zor. Bu bile bu kadar zorken insanların 6-12 aylık işler hakkında tahminde bulunması neredeyse imkansız. Ama hayatında doğru tahmin yapmamış kişiler, uzman diye işe aldıkları kişilere zorla bu tahmini yaptırmaya çalıştılar ve tahminler tutmayınca da kendileri dışında bir suçlu aradılar.
Bu dönemde herşey analizcilerin suçuydu. Adama görmediği, detaylarını bilmediği şeyleri dizayn etmesini isteyip sonra suçlamak çok kolaydı. Analizcilerin de bahaneleri olduğu için hayat çok güzeldi. Ama patronlar huzursuzdu. Herşeyi görmek istiyorlar ve eğer proje başarısız olacaksa 4 ay önceden görüp daha fazla para kaybetmek istemiyorlardı. Bir yandan da sorunları zamanında görüp başarıya da ulaşmak istiyorlardı elbet.
Parçalı waterfall sistemi nispeten bir sürü sorunu çözüyordu ama analiz bittikten sonra kodlama aşamasında analizde görülen hataları düzeltmek ona göre plan değiştirmek çok zordu. Analizi yapılmış, geliştirilmesi yapılan ürünün gerçekten istenen ürün olup olmadığını anlamak için 4-5 ay geçmesi gerekiyordu.
Yukarıdaki resim güzel bir örnek. Müşteri ne istedi, karşılığında ne dizayn edildi ve ne geliştirildi. Bir de bunu 6 ay sonra görüp şok olmak da cabası.
Bu sırada devreye Agile Development diye birşey atıldı. Denildi ki kardeşim biz bunları fazlara böldük ama olmadı daha da ufak parçalara bölelim kimse boş kalmasın ve sürekli geliştirme olsun. Agile development aslında bir konsept bir de bunun yöntemleri var. Bunlardan en meşhuru Scrum.
Agile Development geçmişteki sorunlar çözmek için belli değerler ile geldi. Bu değerler insani biraz daha ön plana çıkartıp insani sorunların da planlamaya katılmasını istiyordu, bunun dışında çalışan bir sistemi çok güzel yazılmış dökümanlardan üstün tutuyordu. Bu zaman içinde daha az döküman yazın gibi de algılandı. Müşteriyi sistemin içinde tutarak sürekli geri bildirim almayı hedefledi ve en önemlisi değişlere anında cevap verebilecek bir sistem olması isteniyordu.
Bu sistemde 6 ay beklemek yerine 1-2 ay içinde herşeyden biraz olan ve hataları bile olsa çalışan bir sistem oluşturmak, müşteriye bunu gösterip ondan geri bildirimler almak ve bu geri bildirimlere göre bir sonraki versiyonu geliştirmek hedefleniyordu. Müşterilerin ne istediğini bilmediği durumlarda çok güzel bir sistem. Kerval yolda düzülürün yazılıma uyarlanmış hali.
Scrum’a gelirsek işleri burada biraz daha karışıyor. Wiki sayfasına göre scrum itişip kakışma demekmiş. Ben hucum etme gibi birşey diye biliyordum. Neyse bu yöntem agile development yapmak için kullanılan bir yöntem. Başka yöntemler de var ama nedense bu çok tuttu. Benze ismi japonca’ya benzediği için insanlar bu adamlar çok disiplinli kesin güzel birşeydir diye üzerine atladı. Ama atlaması ile öpmeye başlaması bir oldu 🙂
Scrum ile birlikte hayatımıza scrum master diye bir rol girdi. Project manager gibi ama değil. Ekipte değil ama dışında da değil. Sorunları çözüyor ama detaylarını bilmek istemiyor. Aslında müdürün adamı. Herşeyi takip ediyor. Bunun dışında ürünün sahibi ve herşeyi yapan yazılım geliştirme ekipleri bulunuyor. Ürün sahibi de ekibin bir parçası ve yazılım ekipleri direkt ürün sahibi ile konuşabiliyor.
Scrum bürokrasiyi azaltmayı, yüzyüze iletişim kurmayı, şeffaflığı ve sürekli gelişmeyi vaat ediyordu. Gelişim hem ekibin yeteneklerinde hem de sürecin kendinde olacaktı. Ne demek bu? Ekip içinde kimsenin rolu olmayacak ve ekip üyeleri o gün hangi işi yapmak istiyorlarsa onu yapacaklar. Yani bir gün analiz yapayım, öbür gün test yapayım. Yapılacak ne iş varsa herkes yapsın ve böylece gelişsinler. Bunun yanında da işler bitip teslim edildikten sonra neleri güzel yaptık, neleri yapamadık tartışıp bir sonraki işte daha düzgün iş yapmak isteniyordu. Kulağa hoş geliyor ama davulun sesi yakından o şekilde değil. Az sabredin anlatıcam.
Scrum işleri 2-4 haftalık periyodlara bölüp, bu periodların sonunda birşeyler üretmeyi ön görüyor. Bu periodlara sprint deniyor. Ben 1 haftalık sprint yapan yerler gördüm. Bu ekibi ne kadar zorlamak isteyeceğiniz ile ilgili bir durum. Ekibe güvenmiyorsaniz 1 haftalık sprintler yazılımcılara acı çektirmek için güzel bir yöntem.
Scrum bir dizi toplantıların yapılmasını istiyor. Ürün sahibi yapılmasını istediği işleri yarım yamalak bir şekilde yazıyor ve backlog denen yapılacak işler listesine koyuyor. Sonra ürün sahibi ile bir toplantı yapılarak hangi işler ne kadar acil ve işlerin detayları konuşuluyor. Buna göre işlere bir puan veriliyor. Bu puanlamaya velocity diyorlar ve havalı olsun diye fibonacci sayıları ile hesaplanıyor. Verilen örnek de her zaman ”Bu bardağı buradan buraya taşımak 1 velocity ise, alıp biraz ileriye koymak 2 velocity”. Keşke bütün işler bu şekilde karşılaştırılabiliyor olsaydı. Gün geliyor şifremi unuttum özelliği ile database güncellemesini karşılaştırmak zorunda kalıyorsunuz. Buna 5 velocity demişiz o zaman bu 7 olur diyorsun. Bunu da adil bir şekilde yapmak için ekipteki herkese 1,2,3,5,8,13,21,34,50,100 yazan kartlar veriliyor ve yeni gelen işlerin detayları verildikten sonra ekipteki herkesin bir sayı seçip aynı anda göstermesi isteniyor. Bu sayılar genelde oldugundan büyük seçilmeye başlayınca hemen ürün sahibi veya yönetici neden böyle dediniz bu çok basit bir iş diye müdahele edebiliyor ve sonra tekrar oylama yapılmasını istiyor. Aynı zarf içindeki bazı oyların geçersiz sayılması gibi birşey. Sonrasında herkes seve seve yöneticinin istediği sayılara düşürüyor. Bazen de yazılımcılara neden bu rakamı verdin diye soruluyor. Çok soru sorulmasın isteyen yazılımcılar her işe 21 verip geçiyor. Ne az ne çok. Velocity olayı günün sonunda yapılacak işin gün bazında süresine bağlanıyor ve bu iş 1 gündü 13 dedik, bu iş de benzer 13 diyelim. Bu iş iki gün sürer 26 dememiz lazım ama mecbur 21 diyoruz.
İkinci büyük topantı sprint toplantısı. Her sprint bitiminde bir sonraki sprint için toplantı yapılıyor. Bunu sprint’in sonunda yapan da var başında yapan da var. Bu toplantıda ekibin sprint başına yapabileceği velocity değerine göre işler backlog’dan sprint planına alınıyor. Bazen büyük işler 2’ye bölünüyor ve yarısı plan içine alınıyor.
Scrum’ın sorun yaratan noktalarından biri olan toplantının adı Daily standup toplantısı. Bu toplantı genelde herkesin zamanında işe gelebilmesini sağlamak için sabah 9’da veya mesai kaçta başlıyorsa ondan 15-20 dk sonra yapılıyor. Akşam çıkarken yapmak bana daha mantıklı geliyor ama böyle yapanı gormedim. Tavsiye edilen yöntem duvara post-itlerle taskları yapıştırmak ve onları toplantıda ben bunu bitirdim diye bir sonraki adıma geçirmek. Bu duvar aynı zamanda yöneticinin yemeğe giderken bakıp bu sprint işler yetişmeyecek daha çok çalışmamız lazım diyebileceği yerde olması gerekir. İyi niyetle yapılan bu toplantı kim ne yapıyor, nerede sorun yaşamış onu öğrenmek için güzel bir fırsat. Scrum master, herkese tek tek ne yaptın, sorun var mı diye soruyor ve eğer sorunu varsa nasıl çözülecekse ilgili kişiyi bulup haber veriyor.
Standup Meeting
Scrum Task
Yine yönetici işler nasıl gidiyor diye görebilsin diye burn-down chart denilen birşey var. Bu toplam velocity’in sprint içinde azalma hızını gösteriyor. Bu hızla gidersek yetiştiremeceğiz denilen nokta burası.
Bir de son olarak retrospective gibi bir ismi olan son toplantı var. Genelde her 2 sprint’den sonra dönüp geriye bakıp nerde patladık nasıl düzeltirip denilen yer bu toplantı. Eğer güzel birşey yapıldıysa ve işe yaradıysa bundan sonra hep yapılsın diye notlar alınır ve bu notlar bir yerde saklanır ve herkesle paylaşılır. Buna göre ekip çalışma düzenini iyileştirir.
Kötü yanları
Bu iyi niyetle geliştirilmiş yöntemin en kötü yanı kafanıza göre değiştirilebiliyor olması. Cehenneme giden yollar iyi niyet taşları ile döşenmiştir derler. Scrum’ın çekilmez yapan şeyler de yöneticilerin ”iyi niyetli” adımları ile ortaya çıkmış.
Scrum içindeki ekiplerin her istedikleri işleri yapabilmeleri gerekirken bir yerden sonra kişilerin rolleri olmaya başlıyor. Sen adamı developer diye işe almışsın, gerekirse manual test yapacaksın diyemiyorsun. Aynı şekilde tester’a hadi bugün de sen yaz abisi diyemiyorsun. Oyle olunca ekip içinde analiz yapan, kod yazan ve test yapan ayrı kişiler oluyor. Oldu mu sana waterfall.
Sonra günlük toplantı, sprint toplantısı, önceliklendirme toplantısı, iyileştirme toplantısı derken 2 haftalık sprint’in yarım gününden fazlası toplantılarda geçiyor. Bir yere kadar verimli olan toplantılar hem çok uzaması hem de gereksiz konuşmalar yüzünden toplu olarak vakit kaybına dönüşüyor.
Velocity hesabı zor ve sprint başına tamamlanan velocity sayısının her sprint’te biraz daha artması hedefleniyor. Bu da her hafta bir öncekinden daha fazla iş yapmak anlamına geliyor ki bu imkansız. Ayrıca işlerin velocity’sini azaltmaya yönelik girişimler sprint planlamasının hatalı olmasın ve günün sonra sprint’in başarısız olarak kapanmasına neden oluyor.
Kısa sprintler ve günlük kontrol bir süre sonra mikro management denilen ”boş durmayın çalışın” diye müdürlerin çaktırmadan ekranlara bakmak yerine burn-down grafiğine bakıp yeterince çalışmıyorsunuz demesine olanak sağlıyor. Bu söylemler performans değerlendirmesinde burn-down’lar neden hep sabit demek ki çalışmıyorsunuz. Utanmadan bir de zam mı istiyorsun demeye kadar varıyor.
Bir de işin kalitesi ile ilgili soru işaretleri var. Agile aslında bunu da düşünmüş ve demiş ki sen yapıldı diyorsun ama bir şeyin yapıldı olarak işaretlenmesi için kurallar var ve bunlar dokümante ediliyor. Eğer senin yaptığın şey buna uymuyorsa yapıldı diyemezsin. Eğer bir iş sprint içinde yapılamadıysa o işin puanı sprint’e yazılamaz. Bir örnek vermek gerekirse bardak buradan şuraya taşınacak. Bu durumda işin yapıldığını garantilemek için senden bardağın yeni yerinin fotografını, eski yerini de içine alacak şekilde bir fotografı ve belki yeni yerinin GPS koordinatlarını isterim. Bunlar olmadan iş yapıldı diyemezsin. Zaten bunlar varsa da iş doğru yapılmıştır. Aynı şekilde yazılım için, unit testler yazılmış olması lazım, hepsinin başarılı olarak bitiyor olması lazım ve yazılan testlerin yapılan işi tam kapsiyor olması lazım. Tabi bunu da birinin kontrol ediyor olması lazım. Kontrol edenin de bunun için harcadıgı eforu bir yere yazıyor olması lazım. O zaman bu da işin bir parçası olması lazım. Velocity planlamasına ekleniyor olması lazım. Lazım da lazım. Scrum bir yerde kod review yapmayın da diyor. Patlaya patlaya öğreneceksiniz diyor ama insanların ne kadar ileri gidebileceklerini çok dikkate almamış tabi. O patlamalar bir sonraki sprint’e velocity olarak ekleniyor bu sayede 13 puanlık iş 100 puan olmuş ama kimsenin haberi yok. Bakiyorsun sprint bazlı velocity artmış o durumda işler yolunda.
Günün sonunda eğer düzgün yönetilmezse Agile denilen şey verimsiz, insanların gerektiğinden fazla yoran ve işe yaramayan bir yöntem olacak. Agile’ın sorunlarını gideren Agile 2.0 çıkar mı, çıkarsa içine edilmesi ne kadar sürer bilmiyorum ama artık gereksiz iş yükünden kurtulup AI Scrum Masterların birebir toplantılar yaptığı, sorunlara hızlıca cevaplar bulunduğu hatta kodun içinde daha fazla yer alan sistemlerin olması gereksiz angaryaların bu sistemler sayesinde en aza indirilmesi gerekiyor. İlk yazım bu şekilde olsun. Kendinize iyi bakın.