Neden Süre Tahmini Yapmıyoruz ve Deadline Vermiyoruz?

Neden süre tahmini yapmadığımızı anlamak için “süre” kavramını iki farklı alt başlığa toplamamız gerekir. 1- İdeal Süre: Bir işin ideal şartlar altında (her şey yolunda iken, işi bölen engelleyen hiçbir şey yokken ve full time iş üzerinde çalışırken) tamamlanabileceği süre 2- Toplam Gerekli Süre (duration) : İşin tamamlanması için gerekli toplam/kesin süre.

Bir örnek vermek gerekirse, Bir basketbol maçı 40 dakikadır. 4 çeyrek üzerinden oynanır. Her bir çeyrek 10 dakikadır. Ama maçın bitimine kadar geçen toplam süre 2-2.5 saat kadardır. Toplam 40 dakikalık süre ideal süredir ama maçın tamamlanması için geçen süre 2-2.5 saat aralığıdır.

İdeal süreyi tahmin etmek göreceli kolaydır ama işi tamamlamak için geçmesi gerekli total süreyi tahmin etmek zordur hatta çoğu durumda kesin olarak geçmesi gerekli süreyi söylemek imkânsızdır.

Toplam Gerekli Süre = “İdeal Süre” + bağımlılıklar + engeller + beklenmedik problemler + değişiklik gereklilikleri vb iş süresini etkileyecek faktörler olarak tanımlanabilir.

Bir iş için gerekli toplam süreyi hesaplayabilmek için o iş üzerinde çalışan kişilerin de hızlarını bilmek gerekir. Bir Word dokümanına belirli bir metni yazma hızı nasıl ki kişiden kişiye değişirse kod yazma hızı da aynı şekilde yazılımcıdan yazılımcıya değişir. Dolayısıyla toplam gerekli süreyi tahmin edebilmeniz için yazım hızını da bilmeniz gerekir. Farklı tecrübe ve özellikteki takım üyelerinden hangisine göre süre tahmini yapacağımız da süre tahmini yapmamızı zorlaştıran bir faktördür.

Yazılım dünyasına geri gelecek olursak, diyelim ki bir ekran ve backend işini geliştireceksiniz. Gereksinimler ve tasarım belirli olsun. Ve sizden süre tahmini verilmesi istensin, bu tahmini nasıl vereceksiniz? Bu iş için ne kadar süreye ihtiyaç olduğunu anlamak için yapılacak işleri düşüneceksiniz. Bu iş devam ederken sizi bölecek işleri hesaplamanız gerekecek, o ana kadar ön görülememiş değişiklik taleplerini sizin ön görmeniz gerekecek, çıkacak problemler için de bir tahmininizin olması gerekli, belki siz bu ekranı geliştirirken yazılımın içinde etkilediğiniz başka alanlar olacak ve onların varlığını geliştirme yaparken fark edebileceksiniz. Gerekli toplam süreyi tahmin ederken tüm bu faktörleri hesaplamanız gerekecek ki çoğu önceden görmeniz neredeyse olanaksız.

Buraya kadar ki tüm nedenlerden dolayı işleri büyüklük olarak tahmin ediyoruz.
Büyüklük bir birim, tıpkı cm,km,kg,ml gibi. Büyüklük birimi olarak Story Point, T-shirt size (s-m-l-xl) , zoo metodu ya da büyüklük sırasını kullanabiliriz. Bunların tamamı büyüklüğü ifade eder ve büyüklük işin karmaşıklığını, riskini, gerekli eforu içerisinde barındırır. Karmaşıklık, risk, efor arttıkça büyüklük de artar.

Yazılım geliştirme çalışmalarında kesin bir süre vermek oldukça zor olduğundan bir işin kesin olarak biteceği tarihi doğru olarak tahmin etmek için ya çok şanslı olmanız gerekir ya da hiç de gerçekçi olmayan çok uzun süreler vermeniz gerekir ki tahmin ettiğiniz sürede işi tamamlayabilesiniz.

Deadline ya da kesin bitim tarihi üst yönetimlerin sevdiği ve kendileri için gerekli olduğunu düşündüğü bir kavram olmak ile birlikte gerçek hayatta bu sürelere kesin uyum saplanması için çok uzun süre tahminleri yapılması gerekir. Sadece süre tahmini vermiş olmak ve bu süreyi tutturmak için uzun süreler vermek mi daha iyidir yoksa daha gerçekçi öngörülerde bulunmak mı?

İşlere büyüklük cinsinden tahminler vermemizin nedeni, product backlogda bekleyen işlerin büyüklüklerini öngörebilmek ve takımın hızına göre uzun vadeli planlar yapmaya elverişli bir ortam oluşturmaktır. Bu sayede ürün ile ilgili verilecek pazarlama, lansman, ürün özellikleri, yatırım oranı vb. stratejik kararlarda üretim miktarının öngörülebilmesine imkan sağlanır.

Süre tahmini verse idik, bunlar çok uzun olacaktı fakat büyüklük tahmini yapmamızın da içerisinde belirli zorlukları yok değildir. Takımın hızını ölçmek ve bu ürün iş listesinde yer alan işleri büyüklük olarak tahmin etmek gerekir.

“size” –> “velocity” –> “duration”

Ancak bu iş her zaman çok da kolay değildir. Takımın hızını, o ana kadar tüm sprintlerin aritmetik ortalamasını alarak hesaplamak yanıltıcı olabilir, burada önemli olan (Monte Carlo simülasyonları gibi) istatistiki hesaplamalar ile belirli bir güven aralığında bir hız tahmini oluşturmaktır.

Örneğin takımın hızı son 12 sprintte, ortalama 50 story point olsun, bu size bir sonraki 12 sprintte de 50 story point olabileceği çıkarımı yaptırtabilir bu çıkarım yanlış olmamak ile birlikte daha gerçekçi bir hesap yapmak için istatistiki çıkarımlar yapabileceğiniz bir hesaplamaya ihtiyacınız vardır.

Bu tip roadmap çalışmaları yaparken hesaplamalarınızda kullanacağınız tool’lara özellikle dikkat etmenizde büyük fayda vardır, önerim bu işi olabildiğince sizin kontrolünüzde ilerletmektir. Kontrolü uygulamalara bırakmayın çünkü tool’lar bizim için sadece birer araçtır, onların esiri olmamak gerekir.

Tüm bunları düzgün yaptığınızı var saysak bile işimiz halen bitmedi, ürün iş listesinde bekleyen tüm kalemlerin büyüklük tahminini yapmanız gerekli.

Büyüklükleri belirli olan işleri bu hızla gidersek ne kadar sürede bitiririz size gideceğiniz yol ile ilgili daha tutarlı bir öngörü verecektir. Ama unutmamak gerekir ki bunlar bir deadline değildir. Çünkü işin içeriğinde, pazarda, rakiplerde, stratejimizde özetle her şeyde çok hızlı değişiklikler olan bir dünyada bizim de işimizin içeriği her zaman değişebilir ve biz bu değişikliklere adapte olabilme becerimizi herhangi bir deadline’a uymaktan daha önemli ve öncelikli görüyoruz.

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir