Zaman tahminlemesi yapmak aslında temelinde bağımlılıktır. Psikolojik olarak, belirsizliği giderme ve sonucu bilme isteği insanın doğasında bulunmaktadır. Hayatımızda nasıl sonucu belli olmayan bir olay bizde uykusuzluk ve stres yaratıyorsa, bu durum da aynı şekilde; üst yöneticinizin veya müşterinizin farklı nedenlerden dolayı projenin olası sonuçlarını bilmemesi sabırsızlık, stres ve güvensizlik gibi birçok nedene sebebiyet verebilir.
Zaman tahminlemesi ile kaynak planı çıkarma, satış önerisi belirleme, finansal rapor oluşturma gibi farklı departmanların kullanacağı ve rahat alanda hissedeceği veriler elde edilebilir. Ancak bu verilerin hiç biri kullanıcı değeri yaratan veriler değildir. Lean yönetim prensiplerini düşündüğümüzde kullanıcı değeri yaratmayan her iş atık (waste) olarak kabul edilmekte ve devamlı iyileştirme yöntemleri ile minimuma getirilmesi amaçlanmaktadır. Bu durumda tahminlemeye harcanan zaman atık olarak kabul edilebilir ve iyileştirilmesi ve minimuma indirilmesi gerekmektedir.
Bu gereklilik sadece zaman kaybını minimuma indirmek için değildir. Aynı zamanda 2011-2015 yıllarındaki CHAOS raporlarına bakıldığında projelerin sadece ortalama %29’u zaman, bütçe ve kalite anlamında başarılı sonuçlanabilmiştir (Tablo1).
Tablo 1: Yıllara göre CHAOS raporu
Projelerin küçüklüğü veya çevik proje yönetim tekniklerinin uygulanması bu durumu biraz iyileştirmiş olsa bile (Tablo2), projenin başlangıcında verilmiş olan zaman tahminlemelerinin projenin ilerleyen safhalarında değiştiğini göstermektedir.
Tablo 2: Büyüklük ve metoda dayalı CHAOS raporu
Peki, bu değişkenlik neden kaynaklanmaktadır?
Öncelikle yazılım sistemleri kişilerin rolünün ve etkisinin yüksek olduğu sistemlerdir. İnsan etkileşiminden yüksek derecede etkilenebilecek ve değişebilecek durumdadır (Tablo3). İnsan etkileşimi için örnek verecek olursak; onayların alınması, organizasyonel yapı ve süreçler ve tabii ki insanların mükemmel olmaması ve bunun sonucunda doğacak gecikmeler ve değişiklikler düşünülebilir. J.B. Rainsberger 2013 yılında bu durumu betimleyen Tesadüfi Zorluk (“Accidental Complication”) terimini ortaya atmıştır.
Bu terime göre Zorunlu Zorluklar (“Essential Complication”) insanların tahminleyebildiği yazılım ile ilgili problemlerden oluşurken; Tesadüfi Zorluklar, insan etkileşiminden ve kişi durum ve koşullarından kaynaklandığı için tahminlenemeyen durumlar olarak nitelendirilmektedir.
Tablo 3: Sosyal komplex sistemlerde insan faktörü
Bu durumda en iyi ihtimalle bizim vereceğimiz zaman tahminleri mükemmel yazılımcı gününü düşünerek yapılmaktadır. En iyi ihtimal ile diyorum çünkü aşağıda bulunan durumların en az biri zaman tahminlemesi sırasında oluşmakta ve tahminlemenin daha yanlış noktalara gitmesine katkıda bulunmaktadır J (Tablo4)
Tablo 4: Estimes Dysfunctions
Zaman tahminleme serüvenimizin sonuna geldikten sonra takım çalışmaya başlar. Ve ürün-market değeri, hız ve kalite gibi metrikler yerine zaman ve bütçeye odaklanılır. Takımın bütün odağı zamanında tamamlama üzerine gittikçe baskının artışı ile devam eder. İşte bu tam anlamı ile proje öncelikli geliştirmenin (Project Driven Development) (Tablo5) tanımıdır. Bu tip bir yönetimin en kötü etkisi suçlamanın proje hayatı boyunca tüm departmanlara yayılarak artması ve gerçek hatanın görülememesi veya ilgilenilmemesidir.
Tablo 5: Proje Öncelikli Geliştirme (Project Driven Development )
İşe yarayan yöntem nedir ve nasıl ilerlenir?
Asıl odaklanılması gereken geçmiş iş tamamlanma sonuçlarına bakarak, tahminleme eforunu azaltırken, kullanıcı değerlerini stabil bir şekilde arttırmaktır (Tablo6).
Tablo 6: Tahminlemeyi geçmiş verilere bakarak gerçekleştirme
Değişkenlik arttıkça tahminleme yapmak zorlaşır. Takımın güvenirliğini ve tahminlemesini iyi hale getirebilecek her türlü yatırım değerlidir. Bu nedenle geçmiş verilerde bulunan değişkenleri azaltmak için öncelikle kurum içi dinamiklerde birkaç değişikliğe gitmek gerekebilir:
Değişkenlerimizi biraz daha kontrol altına almaya başladıktan sonra adım adım #NOESTIMATION aşamalarından geçmeye hazırız demektir. Bu aşamalar:
Tablo 7: Kullanıcı hikayelerini bölmek
Tablo 8: İlerlemeyi gösterebilmek
Tablo 9: Poker kartlarını azaltma
Bir diğer yapılması gereken de deliver edilen hikayelerin puanlamalarını bir histogram üzerinde kontrol etmektir. Bu sayede iterasyonlarda bulunan puanlama dalgalanması takip edilerek düzeltilme aksiyonları alınabilir. (Tablo10)
Tablo 10: histogram oluşturmak
Eğer histogram üzerinde dalgalanmaları minimize hale getirmiş iseniz, artık puanlamayı bırakıp hikayeleri saymaya başlayabilirsiniz. Bu nokta #noestimation yöntemini uygulamaya başladığınız noktadır J
Tablo 11: Rolling wave planning
#Noestimation ile verim arttırmak için hikaye boyutlarını daha da küçültebilir ve sürekli bir gelişime doğru ilerleyebilirsiniz. Sprint Planlamaları’na artık ihtiyaç duymadığınızı düşünüyorsanız, onları kullanmayı bırakabilirsiniz. Tek yapmanız gereken kullanıcı değeri üreten işlemlere yoğunlaşmak…
Bu aşamaların ayrıntılarını öğrenmek isterseniz Vasco Duarte’nin NoEstimation [2] kitabını okumanızı tavsiye ederim
Semen Cirit, Agile Turkey