Yapılacak olan işlerin önceden maliyetlendirilmesi yazılım
geliştirme sektöründeki kritik işlerden birisidir ve bu konuda function point, uzman
görüşü(expert judgement), story point kullanımı vb. çeşitli
yöntemler günümüzde kullanılmaktadır. Her yöntemin olumlu olumsuz yönleri
olduğu için tek bir standart model yok(yazılım dünyasının en büyük derdi
standartlar yoktur çok fazla).
Agile dünyada maliyet hesabı için kullanılan yöntemlerden
birisi de story point kavramı ile maliyetlendirmedir. Burada kritik
kavramlar ekip, büyüklük, hız, süre ve takvimdir. Kısaca story pointler
kullanılarak maliyetlendirmenin nasıl yapılacağından bahsetmeye çalışacağım.
Agile yöntemlerde maliyetlendirme ile ilgili önemli
kurallardan birisi, “İşi kim yapacak ise en iyi maliyeti o verir” mantığıdır. Yazılım
geliştiriyorsak da geliştirme ekibi ya da scrum takımı(developer, testci, DBA,
mimar vs. takımda kim var ise hepsi dahildir) maliyeti verir.
İşlere örnek olarak şu gözle bakılır;
İş: Ankara’dan
İstanbula otomobil ile Ankara-İstanbul otobanı kullanılarak gidilecek
Büyüklük:
400km
Hız:
100km/h(ortalama)
Süre:
4Saat
Takvim:
08:00–12:00
Bu kavramların özellikleri ve aralarındaki ilişkiler;
büyüklük herkese göre aynıdır, değişen bir bilgi degildir, hız aractan araca
veya kişiden kişiye değişir, süre hıza bağlıdır, takvim de süreye bağlıdır. Dolayısı
ile bu kavramlardan büyüklük ve hız asıl belirleyici olanlardır.
Bu kavramlar kullanılarak maliyetlendirme yapılacak ise büyüklük
hesabı yapılacak olan işin anlamlı bir büyüklükte olması gerekir. Anlamlı bir
büyüklükten kasıt ekibin o işi anlayıp, o işi gerçekleştirmek için yapılması
gerekenleri kafasında kabaca canlandırabilmesi gerekir. Çok fazla belirsizlik
içermemesine dikkat edilir.
Scrum’da işlerin belirlenmesinden sorumlu kişi product
owner rolünü üstlenen kişidir, bu kişi müşteridir veya müşteriyi temsil
eden kişidir, yapılacak olan işin/projenin user story olarak maddelere
bölünmüş halinden oluşan product backlog olarak adlandırılan gereksinim
listesini yönetir. Scrum takımı product backlog’daki user story’lere
büyüklük maliyeti verir. Örnek bir user story “Kullanıcı olarak
kullanıcı adı ve şifremle sisteme login olmak istiyorum” şeklindedir. User
story’ler maliyet vermek için çok büyük ise(epic, theme) çeşitli
yöntemlerle maliyet verilebilecek daha küçük parçalara bölünürler veya maliyet
vermek için küçük user story’ler var ise bunlardan bazıları
birleştirilebilir.
Product backlog hazır ve büyüklük maliyeti verilmesi
gerekiyor, product owner ve scrum takımının olduğu bir toplantı
düzenlenir. Bu toplantıda poker planning denilen bir yöntemle scrum
takımı product backlog maddelerine(user story) maliyet verirler.
Açık olmayan noktalar hakkında product owner’dan bilgi alırlar, user
story’ler parçalanıp, birleştirilebilir.
Büyüklük maliyeti verilirken birim olarak story points
denilen bir birim kullanılır ve işler göreceli büyüklüklerine göre puanlanır.
Bunu büyüklüklerine göre t-shirt’lerin S, M, L, XL gibi işaretlenmesi olarak da
düşünebilirsiniz. Story point olarak genellikle fibonacci serisine
benzer 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 gibi rakamlar kullanılır, aradaki
sayılar kullanılmaz. Bunun iki önemli nedeni var birincisi aradaki sayılar
olursa çok fazla karmaşa olur, 5 mi yoksa 6 mı şeklinde, bunun yerine 5 mi 8 mi
ayırımı daha kolay karar verilebilir bir durumdur. Diğer bir neden işlerin
büyüklükleri ile o işteki belirsizlik veya belirsizlik çıkma olasılığı da doğrusal
olarak artar o yüzden sayılar arasındaki farklar da giderek artıyor, mesela 40
ile 100 arasında ciddi bir fark var. Bu büyüklükteki sayılar genelde
belirsizlik içeren ve bölünemeyen user story’ler için kullanılır.
Göreceli büyüklük kavramı için referans noktası veya
noktaları olması gerekir, ilk defa poker planning yapmıyorsanız zaten
daha önceden verdiğiniz büyüklük maliyetleri sizin için referanstır ancak ilk
defa yapıyorsanız kendinize referans orta seviye bir iş seçip ona orta seviye
bir puan vermelisiniz(3,5 gibi), sonraki işlerinizin maliyetlerini hep o
referans işle karşılaştırarak vermelisiniz. Örneğin referans işe 5puan dedik,
sonraki iş bu referans işten çok az daha büyük bir iş o zaman bu işe de 8puan
diyorsunuz, ya da sonraki iş referans işten küçük bir iş o zaman bu işe 3puan
yada 2puan diyorsunuz şeklinde ilerleniyor.
Poker planning şu şekilde yapılır; user story
puanları (0,1,2,3,5,8 vb) poker kartlarına bastırılmış şekilde her scrum takımı
üyesinin elinde bir deste puan kartı olur. Product backlog’daki maliyet
verilecek iş her ekip üyesi maliyet verebilecek hale gelinceye kadar kabaca
irdelenir. Sonra her ekip üyesi ilgili iş için belirlediği puan kartını ters
bir şekilde masaya kapatır, herkes kartını koyduktan sonra kartlar açılır. Yani
maliyet verirken ekip üyeleri bir birinden etkilenmesin diye ilk önce kimse
kimsenin verdiği maliyeti görmez. Kartlar açıldıktan sonra çok farklı puanlar
var ise en küçük puan veren ekip üyesi ile en büyük puanı veren ekip üyelerine
neden bu puanı verdikleri sorulur. Bu noktada diğer ekip üyelerinin gözünden
kaçan bir nokta var mı yok mu bu anlaşılmaya çalışılır. Gerekli tartışmalar
yapıldıktan sonra ekip benzer bir puan üzerinde anlaşıncaya kadar bu seans
devam eder. Ekip ortak bir puan üzerinde anlaştığında o işin büyüklük maliyeti
verilmiş olur. Takım bu şekilde product backlog’daki tüm maddeleri puanlar.
Elimizde büyüklükleri puan olarak belirlenmiş bir product
backlog var, bu product backlog’daki işlerin ilgili ekip tarafından
ne kadar sürede yapılabileceğini bulmamız gerekiyor ki süre ve takvim olarak
müşterimiz ile anlaşalım. Süre için bize hız bilgisi gerekli. Buradaki hız scrum
takımının birim zamanda ne kadar puanlık iş yapabildiğidir. Örneğin product
backlog’daki işler 1000puan çıktı bizim scrum takımımız 15günde 50puanlık
iş yapabiliyor, o zaman product backlog’daki işlerin bu scrum takımı
tarafından tamamlanması ((1000/50)*15)= 300gün
sürer, şeklinde bir hesap yapılır. Buradaki kritik nokta bu hız bilgisinin
nasıl elde edildiği eğer ilk defa story point’lerle maliyet verip iş
yapmıyorsanız hız bilgisi için ekibin tarihsel verileri kullanılabilir,
geçmişte kac puanlık işler ekip tarafından ne kadar sürede yapıldı şeklinde
ortalama bir hesap yapılıp hız bilgisi elde edilebilir. Ancak geçmiş
verileriniz yok ise hız bulmak veya tahmin etmek için farklı yöntemler
kullanmanız gerekiyor, bunlardan birisi müşteriniz ile anlaşabiliyorsanız bir
iterasyon yapıldıktan sonra hız bilgisi elde edilip müşteriye bu hız bilgisi üzerinden
maliyet dönülür. Müşteri ile bu konuda anlaşamıyorsanız tahmini bir hız
seçmeniz gerekir başlangıç için.
Agile yöntemlerde gereksinimler, süreler, maliyetler vs. bir
defada alınan ya da başlangıcta kesin rakamlarla belirlenen şeyler olarak kabul
edilmez. Aslında tüm yöntemlerde bu böyle olmalıdır, çünkü belirsizliklerin en
fazla olduğu projenin başlangıç aşamasında verilen süre, maliyet gibi bilgiler
çok büyük oranda projenin ortasında, sonunda sapar, projenin başlangıcında
gereksinimleri sabit olarak almak, süreleri, maliyeti sabit olarak vermek çoğu
zaman gerçekçi bir yaklaşım olmamakla birlikte firmalar kendilerini garanti
altına almak için bu sabit kapsam, sabit fiyat, sabit süre yöntemini tercih
ediyorlar.
Agile yöntemlerde süre, maliyet gibi sayılarla ifade edilen
kavramlar için aralık kullanılması da tercih edilen bir yöntem. Aynı şey scrum
takımının hız bilgisi için de geçerlidir. Hız ile verimlilik bir birine paralel
kavramlar değildirler, bir takım ne kadar hızlıysa o kadar verimlidir
diyemeyiz. Hızları düşük diye eleştirdiğiniz bir takımın hiç bir extra efor
sarfetmeden hızını arttırması gayet kolay, story point’leri daha fazla
verirler. O yüzden bu kavramlara doğru yaklaşmak çok önemlidir. Hızın artması
değil sağlıklı bir aralıkta olması önemlidir. Bazen artar, bazen azalır.
Burada yazılım maliyetlendirmesinde çok kullanılan adam gün,
adam ay vb. içinde zaman bilgisi barındıran kavramlardan hiç bahsetmedik. Bir
ekip bir projeye maliyet verirken ekipden zaman bazlı maliyet almak sizin o
işin gerçek büyüklüğünü bilmemenize neden olur. Aynı işi bir ekip elamanı 1günde
yapar, başka bir ekip elemanı 3günde yapar ancak sonucta yaptıkları iş aynıdır.
Peki bu 1günlük bir iş midir, 3günlük bir iş midir? Neye göre, kime göre? Bu
yüzden kişiden kişiye çok fazla değişiklik göstermeyen büyüklük kavramı ile
maliyetlendirmek daha sağlıklı bir yaklaşımdır.
Agile maliyetlendirme ile ilgili Mike Cohn’un Agile
Estimating and Planning kitabı okunabilecek güzel bir kaynak.