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)

• İç dinamikler: üst yönetim belirli kaynak, zaman, kapsam içerisinde projenin planlanmasını ister ve takımın verdiği tahminler yerine, en yüksek maaşı alan (HIPPO (Highest Paid Person’s Opinion)) kişinin dediği yapılır
• Tahminleme pazarlığı: Takım tahminleri verir ve muhtemel sürüm gününü hesaplar ve sonra diğer paydaşlar tarafından tahminlerin değiştirtilmesi yönünde bir baskı yaşanır
• Expert görüşü: Projede yer almayacak olan bir expert tahminlemeyi yapar ve daha sonra takım üyeleri bu tahminlemeyi gerçekleştiremedi diye suçlanır
• Son dakika değişiklikleri: Tahminleme pazarlığının bir başka türüdür, değişiklikler projeye eklenir ancak plan bir şekilde değiştirilmez.

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:

• Dedike takımlar: Kişileri takımlar arasında sürekli değiştirmek veya bölüştürmek stabilliği ve tahminlemeyi bozabilir, bu nedenle dış etkenlerden kaynaklanan kontrol dışı çoklu-iş (multi-tasking) olabildiğince azaltılmaya çalışılmalıdır.
• Çapraz fonksiyonlu takımlar: Her takımın kullanıcı değerini en hızlı şekilde yaratmasını sağlayacak ekspertize sahip olmasını amaçlar. Bu sayede diğer takımlardan destek almadan veya diğer takımların yapacağı işi beklemeden bağımsız bir şekilde takım ilerleyebilir
• Bütünsel kalite odağı: Tüm ürün süreçlerini kapsayacak şekilde bir kalite alt yapısı hazırlayarak, maksimum verim sağlanabilir. Böylece sadece test anlamında değil; kodlama, entegrasyon, aktarım gibi noktalarda da onaylama, manuel yapılan süreçler nedeni ile kuyruk oluşturma gibi bekleme yaratan işlemlerin hızlı akışı sağlanabilir. Bütünsel kalite odağı ana başlıkları ile test öncelikli yazılım, kod iyileştirme, eşli programlama, kolektif kod sahiplenme, otomasyon, sık entegrasyon gibi kavramlardır [5].
• Kapsam dondurma: Bir iterasyon içerisinde önem derecesi en yüksek olan ve söz verilen işe odaklanmak ve bu işi iterasyon içerisinde değiştirmemek; geçmiş dönem verisini korumak ve değişkenleri azaltmak adına yapılabilecek en önemli işlemlerden biridir.

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:

• Kullanıcı hikayerini bölmek: Kullanıcı hikayeleri farklı şekillerde bölünebilir. Burada temel amaç kullanıcı değeri yaratacak şekilde hikayeleri alt hikayelere bölebilmektir. Diğer bir değişle, kullanıcı hikayelerini modüller halinde katman katman bölmek yerine, böldüğümüz her parçanın kullanıcı değerini kaybetmeden, birbirini beklemeyecek şekilde, kendi başına çalışabilen paydalara bölmek ve her bir öykünün tek başına deliver edilmesini sağlamaktır. (Tablo7)

Tablo 7: Kullanıcı hikayelerini bölmek

• İlerlemeyi görünür hale getirmek: İlerlemeyi sadece veriler kullanarak göstermek yeterli değildir. Kullanıcı değeri müşteriye gösterilmediği sürece hiç bir değer taşımamaktadır. Çünkü aktarılmayan her değer müşteri tarafında sabırsızlık ve sonrasında gittikçe büyüyen güven eksikliği yaratacaktır. Bu nedenle kullanıcı değeri yaratacak şekilde bölmüş olduğumuz öykülerimizin sadece birbirinden olabildiğince bağımsız çalışmasına değil aynı zamanda her an yüklenebilir veya görünebilir olmasına özen gösterilmelidir. Böylece hem rakamsal hem de fiziksel olarak görünür olunabilir. (Tablo8)

Tablo 8: İlerlemeyi gösterebilmek

• Kullanıcı hikayeleri için sadece hikaye puanlaması (SP) kullanmak ve birkaç SP opsiyonunu elemek: Alt tasklara verilmiş olan saat bazında zaman planlamasının çeşitli nedenlerden dolayı çok fazla değişime uğradığına yazının üst kısımlarında bolca değindik. Bu nedenle alt tasklara saat tahminlemesi yapmayı bırakıp sadece hikayelere puanlama vererek işe başlayabilirsiniz. Eğer bunu yapıp başarıya ulaştıysanız sonraki aşama kullandığınız öykü puanlaması değerlerini azaltmak olacaktır. Böylece tüm işleri küçük, orta, büyük, çok büyük şeklinde sınıflamaya başlayabilirsiniz. Bu da hikayelerin 2 veya 3 mü olduğu ile ilgili tartışmaları azaltır ve sınıflandırmayı çabuklaştırır.(Tablo9)

Tablo 9: Poker kartlarını azaltma

• Hikayelerin takvim zamanlarını kısıtlamak ve histogram oluşturmak: Hikayelerin genel uygulama süresini kısıtlayarak, en öncelikli işe odaklanmayı ve kullanıcı değerini maximize etmeyi amaçlar. Böylece daha küçük hikayeler yaratılmaya başlanır ve belirli bir süre içerisinde hikayenin ne kadarının başarılabileceğine dair bir his edinilmiş olur. Zamanla hikayelerin büyüklükleri benzer boyutlara gelmeye başlar. Bu sayede Pakinson yasasının (“Bir iş, daima, bitirilmesi için kendisine ayrılan sürenin hepsini kapsıyacak şekilde uzar”) söylemiş olduğu duruma düşmemiş oluruz.

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

• Öykü puanlaması yerine sadece öyküleri saymaya başlamak:

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

• Yuvarlanan dalga tahminlemesi (Rolling wave planning) yapmak: Artık geçmiş iterasyonlarınıza bakarak, sonraki iterasyonlarda deliver edebilceğiniz hikaye sayısını ve ürünün tahmini çıkış zamanını öngörebilirsiniz. (Tablo11)

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