Süre Tahmini
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.
“İdeal süre” maçın oynanma süresidir (40 dakika). Geçen süre ise maçın başından sonuna kadar geçen süredir.
“İdeal süreyi” tahminlemek kolaydır. 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) ne kadar sürede tamamlanabileceğini söylemek kolaydır.
Fakat işin tamamlanması için “geçen sürenin” tahmin edilmesi zordur çünkü işin tamamlanmasını etkileyen bütün faktörlerin öngörülüp hesaba katılması gerekir.
Geçen Süre = “İdeal Süre” + bağımlılıklar + engeller + beklenmedik problemler + vb iş süresini etkileyecek faktörler.
Bir iş için gerçekçi süre tahmini verebilmenin zorluğu geçen süreyi tahmin edebilmenin zor olmasından kaynaklanır.
Geçen süreyi tahmin edebilmek için o iş üzerinde çalışan takım üyelerinin de o işi ne kadar sürede tamamladığını bilmek gerekir.
Bir word dokümanına verili bir metni yazma hızı nasıl ki kişiden kişiye, kullanılan klavye tipine, kullanılan bilgisayara vb. faktörlere göre değişiklik gösterirse, takım üyelerine göre de kod yazma ve bir işi tamamlama hızı değişiklik gösterir.
İki kişinin bir sahil koşusuna çıktığını varsayalım. Diğerine oranla daha hızlı koşan kişi sahilin 10 dakika mesafede olduğunu söylesin. Diğer kişi ise parkuru biliyor ve bu sürenin kedisi için 30 dakika olduğu karşılığını versin. Birlikte sahil koşusu ile ilgili tahmin yapacaklar ve 10 ile 30 arasında bir tartışamaya gideceklerdir. Aritmetik ortalamasını alsalar ve 20 dakika tahmin etseler bu durum ikisi için de uygun olmayacak. Bu süre tahmininde hiçbir sonuca varmayacak. Oysa uzunluk üzerinden konuşsalar ve tahmini olarak yaklaşık 3 km koşacaklarını söyleseler durum farklı olacak.
Farklı tecrübe ve özellikteki takım üyelerinin hangisine göre süre tahmini yapacağımızı bilemeyiz bu nedenle, işin büyüklüğünü tahminlemek ve takımın hızını hesaplamak uzun vadede takımın ne kadar iş çıkaracağını bize gösteren gerçekçi bir metrik olmalıdır.
Büyüklük Tahmini (Story Point, Tshirt Size, Zoo Method, büyüklük sırası 1-10) Nedir?
Story point bir işin büyüklüğünün değerlendirilmesidir. Büyüklük içerisinde zorluk, risk, bilinmezlik ve karmaşıklık vardır. Büyüklüğün değerlendirilmesi amacıyla başka yöntemler de kullanılabilir (Tshirt Size, Zoo Method, büyüklük sırası 1-10 gibi).
Story point büyüklüğü ifade eder derken bunun sadece işin karmaşıklığından bahsetmiyoruz. Toplam büyüklüğünden bahsediyoruz. Ve bu işi gerçekleştirmek amacıyla sarf edeceğimiz zaman tabii ki buna dahil oluyor. Bu süreyi uzatan etkenler arttıkça büyüklük de artacaktır. Söz gelimi, 1 satırlık bir kod parçasının çok sayıda test implemente edilip koşturulmasına ihtiyacı var ise bu işi sadece yazılacak kod olarak düşünüp büyüklük tahmininde bulunmak hatalı olacaktır. Ya da yazılan kodun öngörülmesi zor ve sadece geliştirme esnasında olacabileceği düşünülen fonksiyonel etkileri var ise bu durum da bir bilinmez olarak risk teşkil etmekte ve işin büyüklüğünü arttırmaktadır. Dolayısıyla Story Point harcanacak efor ile ilgilidir ve sadece karmaşıklığı ifade etmez. Karmaşıklık büyüklüğü arttırır ama tek başına Story Point’i ifade etmez.
Story point zaman birimi değildir çünkü zamanın göreceli ve zor tahmin edilebilir olduğunu bunun yerine herkes için aynı olan bir ölçüm aracına ihtiyacımız olduğunu görmüştük. Dolayısıyla story point kişilerden,kişilerin bilgi,tecrübe ve yetenek düzeylerinden bağımsızdır.
Neden Tahminleme Yapıyoruz ?
“size” –> “velocity” –> “duration”
Tahminleme yapmamızın nedeni product backlogda bekleyen işlerin büyüklüklerini öngörebilmek ve takımın hızına göre uzun vadeli planlamalar yapmaya elverişli bir ortam oluşturmak.
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.
Bu amaçla, product backlogda bekleyen itemlar ne kadar önce tahminlenirse o kadar iyidir. Grooming toplantılarının temel amacı backlogda bekleyen itemların varsa risk ve bilinmezliklerini belirlemek ve yeterli detaylı bilgiye sahip itemların da Story Point tahminini yapmaktır.
Product owner da büyüklükleri takım tarafından tahmin edilmiş backlog itemlarının önceliklerini belirlerken, büyüklük ve velocityye göre öncelikleri değiştirebilecektir. Backlog yönetimi kolaylaşacak ve işe eklenecek değeri arttırabilecek öncelik kararı product owner tarafından daha verimli hale gelebilecek optimum önceliği belirlenmesine imkan sağlanacaktır.
Söz gelimi, ürüne yeni bir özellik eklemek isteyen product owner bu özelliğin tahmin edilmesi sonucunda X story point olduğunu görür ve takımın hızına göre bu işin bitmesinin yaklaşık 4 sprint alacağı sonucuna varır ise, bu özelliği bölmek daha küçük bir parçasını 1 sprint içerisinde bitirip lansmanını yapmak isteyebilir. Story point ve hız bilinmediği durumda bu yeni özelliğin bitişini ön görmek mümkün olamayacak, büyüklüğü kestirilemeyecek ve ürüne bu özelliğin eklenmesi için büyük olasılıkla 4 sprint süresi kadar beklemek gerekecektir.
Velocity ne için kullanılır ? Sprint planlamaya etkisi nasıl olmalıdır?
Bir basketbol takımının bir sezonda toplam 30 maç yaptığını düşünelim. Sezon ortasında (15. maçta) istatistiğe göre maç başına ortalama 60 sayı atıyor olsunlar. Bu takımın velocity’si 60 dır. Sezonun geri kalanında ortalama 60 sayıyla oynamaları muhtemeldir. Ama bir sonraki maç 60 sayı atacaklar gibi bir tahmin yapılamaz. Yani velocity uzun dönem planlamalar için kullanılır. Kısa dönem planlar için kullanılmaz. Dolayısıyla scrum takımları, sprint başında plan yaparlarken velocitylerine odaklanmak yerine, backlogdaki (iş listesindeki) storylerinden hangilerini tamamlayacaklarına odaklanmalıdırlar. Velocity sprint planlamasında bir fikir vermek ile birlikte takım sadece velocityye odaklanmamalıdır. Takım tecrübelendikçe, takımın önündeki engeller ortadan kalktıkça velocityleri artacaktır. Bu nedenle hep velocityye odaklanarak sprint planlaması yapmak takım açısından yanıltıcı ve yanlış olacaktır.
