Efor Tahmini Nasıl Yapılır?
Yakın zamanda katıldığım eğitimlerde katılımcılardan efor tahmini ile ilgili çok fazla soru geldiğini gözlemledim. Bu sebeple bir işe taahhüt etmeden önce nasıl efor tahmini yapılır konusuna değinmek istiyorum.
Öncelikle efor tahmini neden yapılır, neden buna ihtiyaç duyarız? Bu konunun bireyler, takımlar ve yöneticiler tarafından iyi anlaşılması gerekir. Anlaşılmadığı zaman tahmin edemeyeceğimiz kadar büyük karmaşaya, hatta problemlere sebep olabilir.
Neden Efor Tahmini Yaparız?
Scrum değerlerinden bir tanesi taahhüttür (Commitment). Scrum takımları her sprint onları ürün hedefine götürecek bir sprint hedefine taahhüt ederler. Birbirlerine de o hedefe ulaşmak için destek olacaklarına dair taahhütte bulunurlar. Hatta sadece destek olmak için değil, birbirlerini bu taahhütten sorumlu tutmak için de taahhütte bulunurlar. Görüldüğü üzere Scrum ne kadar basit bir çerçeve olsa da değerlerini yaşatmak konusunda takımlara ve takımları oluşturan bireylere bazı sorumluluklar yüklüyor. Sprint sonunda sprint hedefine ulaşabilmeliyiz ki potansiyel olarak yayınlanabilir bir iş parçası (increment) yani değer üretebilelim. Bu küçük hedefler de bizi büyük hedefimize ulaştırsın. (Product Goal)
Takımlar bu kadar şeye taahhüt ederken gerçekçi olmaya ihtiyaç duyarlar. Product Owner’ın sprint planlamada getirdiği iş fikri ve takımın yarattığı sprint hedefine ulaşabilirler mi, buna taahhüt edebilirler mi bilmek isterler. Bunun için de önceki sprintlerde elde ettikleri deneyimlerinden oluşan verileri kullanarak yeni sprint için planlanan işlere tahmini efor belirlerler.
Görüyoruz ki efor tahmin etmenin amacı takımın daha gerçekçi ve ulaşılabilir tahhütlerde bulunmasına yardımcı olmaktır. Yani eforalama bir amaç değil bir araç. Uzun süredir aynı işi yapan, aynı ürünü geliştiren, aynı hizmeti veren, uzun süredir birlikte çalışan bireylerden oluşan takımlar, efor tahmini yapmadan da taahhüt de bulunabilir. Çünkü belirsizlikleri daha az, bilinenleri daha fazla olabilir. Fakat özellikle de yeni kurulmuş takımlar, yeni bir fikri hayata geçirmeye çalışıyorsa kapasitesini öngörebilmek için faydalı olabilecek bir araçtır efor tahmini.
Neden Efor Tahmini Yapmayız?
Efor tahminleri performans değerlendirmek için kullanılmaz. Bazı organizasyonlarda büyük bir yanlış anlaşılma olarak efor tahmini takımların ya da bireylerin performansını değerlendirmek için kullanılıyor. Bu yöntem birçok risk barındırmakla birlikte en önemli gördüğüm risk, motivasyonun değer üretmekten çok, story point (detaylarına birazdan aşağıda değineceğiz, bir çeşit efor tahmini aracı) tüketmeye kaymasıdır. Takımların hedefleri organizasyonca belirlenen story point miktarlarına göre belirlendiğinde, takımlar da yaptıkları işin ne olduğundan çok ne kadar story point tükettiğine odaklanır. Bu durumun bazı riskleri vardır. İlk risk değer ortadan kalkar. Yani müşteri için yaratılan fayda düşünülmez, dolayısı ile ihtiyaç olan şey değil, herhangi birşey yapılmış olur. Takımın müşteri odaklı yaklaşımı zedelenir. Bir diğer risk, planlamalarda en değerli iş yerine en çok story point gerektiren işi alma eğilimi olabilir. Bu da doğru önceliklendirme yapmayı engellediğinden fırsatların kaçırılmasına sebep olabilir. Ayrıca Product Owner’ın önceliklendirmesine müdahale olduğundan takım içi saygı değeri zedelenebilir. Product Owner ve takım aynı amaç için çaba göstermez. Başka bir risk, performans story point üzerinden değerlendirildiğinden işlere verilen efor manipüle edilebilir. Bu da şeffaflığı ortadan kaldırır.
Nasıl Efor Tahmini Yaparız?
Scrum’da efor tahmini aşağıdaki şekilde tariflenmektedir.
“İşi yapacak olan Developers işlerin büyüklüğünü belirlemekten sorumludur. Product Owner, detaylarda nelerin yapılıp nelerden vazgeçilebileceğini anlamalarına yardımcı olarak Developers’ı etkileyebilir.”
Scrum’da da tariflendiği üzere işlerin büyüklüğünü belirlemekten Developers sorumludur. Product Owner ya da Scrum Master aynı zamanda Developers şapkası takmıyor ise işlerin eforlanmasına müdahale etmez. Sadece Developers’ın ihtiyacı olan desteği sağlar. İşlerin eforlanması genelde refinement (backlogdaki işlerin takım tarafından incelendiği ve mümkün olduğunca sprinte almaya hazır hale getirmeye çalıştığı çalışma) sırasında ya da sprint planning etkinliğinde yapılır.
Takımların işlere efor tahmini yapabilmesi için bazı yöntemler bulunur. Bunun için Planning Poker, T-Shirt Sizing, Dot Voting, “Big, uncertain, small” yöntemlerini örnek verebiliriz. Daha çok takımlarda “Planning Poker” dediğimiz göreceli bir efor tahmin etme yöntemi kullanılmaktadır. “Planning Poker” Fibonacci serisinde bulunan sayılar (1,2,3,5,8,13,21,34,55…) kullanılarak işlere puan verme şeklinde yapılır. Fibonacci serisi kendisinden önceki iki sayının toplamı olacak şekilde ilerler, bu da işlerin büyüdükçe karmaşıklığının üstel bir şekilde arttığını ifade edebilmek için kolaylık sağlamaktadır.
Takımlar işleri birbiri ile kıyaslayarak puanlar. Kıyaslamayı başlatabilmek için bir işi baz olarak alıp, o işe Fibonacci serisindeki bir sayıyı puan olarak verirler. (Ben genelde 5 veya 8 öneriyorum ki kendisinden daha büyük ve daha küçük işleri puanlamak kolay olsun.) Baz iş diğer işler puanlanırken kıyaslama yapılacağından herkesin nasıl yapılacağı hakkında fikrinin olduğu, uçtan uca çözüm sunan, ortalama zorlukta bir iş olabilir. Daha sonra takımlar diğer işleri bu baz işe göre daha zor, daha büyük, daha küçük, daha karmaşık, daha riskli, daha belirgin gibi kriterlere göre kıyaslayarak puanlar. Sprintler tamamlanıp, planning poker ile efor tahmini yapmaya alışıldıkça baz puandan ziyade sprint planlamadaki işler kendi içlerinde kıyaslama yapılmaya başlanır.
Yukarıdaki işlemleri bir örnek ile açıklayacak olursak, önümüzde bir sepet dolusu ütüsüz giysi var. Hedefimiz bu sepetteki tüm giysileri ütülemek ve katlamak. Her bir giysinin ütüleme ve katlama işlemlerinin bittiğinden emin olmak için aşağıdaki kriterlerin sağlanmış olması gerekmektedir. Bu kriterlere “definition of done” (“bitti”) kriterleri diyebiliriz.
Kırışıksız bir şekilde ütülenmiş olması
Giysinin herhangi bir yerinde üst üste ütü izi çizgisi olmaması
Ütü sonrası giysilerde parlama, yanma, yamulma, tutuşma gibi deformasyon olmaması
Kabin boy valize sığacak büyüklükte katlanması
Sepetin içerisinde 1 adet pamuklu gömlek, 1 adet pamuklu t-shirt, 1 adet kumaş pantolon, 1 adet keten pantolon, 1 adet pamuklu mendil, 1 adet ipek eşarp var.
Burada görece en belirgin ve orta zorluktaki iş pamuklu t-shirt olduğundan onu baz puan seçebiliriz.
Pamuklu t-shirt : 5 story point (sp)
Pamuklu mendil t-shirt ile aynı zorluk, karmaşıklık ve riskte, fakat biraz daha az emek gerektiriyor bu sebeple,
Pamuklu mendil : 2 sp
Pamuklu gömlekte kollar, düğme araları gibi yerleri ütülemek ve katlamak zor, hem karmaşıklık, hem zorluk, açısından daha büyük olduğundan,
Pamuklu gömlek : 13 sp
Kumaş pantolonda üst üste ütü izi bırakmadan ütülemek ve katlamak zor. Kumaş ayarı yapmak gerek ki parlamasın, belki ekstra iş olarak üzerine ütülerken parlamasın diye ıslak tülbent koymak gerekecek, karmaşıklık da var.
Kumaş pantolon : 34 sp
Keten pantolonun kırışıklığını açmak daha zor ama ütü çizgisi izi bırakma ihtimali az. Katlamak da daha kolay.
Keten pantolon : 21 sp
İpek eşarpta yanma ya da buhar izi bırakma riski yüksek. Doğru ısı ve buhar ayarını ayarlamak gerekecek. Katlama ve ütü işlemleri daha az karmaşık.
İpek eşarp: 8 sp
Görüldüğü üzere puanlama yaparken “definition of done” (DOD) dediğimiz kalite kriterleri doğrultusunda karmaşıklık, zorluk(büyüklük), belirsizlik, risk faktörleri ele alınır.
Takımlar da DOD, geçmiş tecrübeleri, yetkinlik ve deneyimleri doğrultusunda işleri birbiri ile kıyaslayarak efor tahmini yapar. Planning Poker ile efor tahmini, taahhüt edilecek işleri takım olarak inceleyip herkesin yapılacak iş konusunda ve harcanacak efor konusunda ortak bir anlayış geliştirmesini sağlayan bir takım oyunudur diyebiliriz.
Bunu da sadece bir işe taahhüt ederken kendilerine yardımcı olacak bir araç olarak ya da iyileşme ile ilgili takım olarak takip ettikleri metriklerde veri elde etmek için kullanılar.
Yorumlar