Çevik Yaklaşımlarda İşin Maliyetini Belirleme 2

Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Maliyet Belirleme Teknikleri

Çevik Yaklaşımlarda İşin Maliyetini Belirleme yazı serisinin bu bölümünde farklı maliyet belirleme tekniklerine değineceğim. Bu teknikler, uzman görüşü, benzeşim(karşılaştırma), küçük parçalara bölme teknikleridir. Yapılan araştırmalardan ve araştırmaların sonuçlarından bahsedeceğim.

Uzman Görüşü

Uzman görüşüyle anlatılmak istenen yıllarca çalışarak elde edilen tecrübeden kaynaklanan uzmanlık değildir. İşi geliştiren kişinin uzmanlığıdır. Yazı serisinin ilk bölümündeki örneği hatırlarsanız, evet takım lideri, geliştiriciden çok daha tecrübeli biri fakat geliştirici, geliştirdiği konuyla ilgili yaşanan sıkıntıları, karşılaşılabilecek problemleri, önüne çıkabilecek engelleri en iyi bilen kişidir. Kendi hızını da en iyi geliştirici bilir dolayısıyla doğruya en yakın tahmini yapabilecek uzman kişi işi yapan kişidir.

Benzeşim

Diğer bir yaklaşım ise benzeşim ya da karşılaştırma da diyebileceğimiz tekniktir. Bu teknikte tahmini yapacak kişi kullanıcı hikayelerini karşılaştırarak şunu söyler:

  • A kullanıcı hikayesi B kullanıcı hikayesinden biraz daha büyüktür.

Kullanıcı hikayelerini karşılaştırarak büyüklüklerini belirleme tekniğidir. Steven Vicinanza, Tridas Mukhopadhyay, Michael Prietula, “Software-Effort Estimation: An Exploratory Study of Expert Performance” adlı çalışmaları ile yazılım geliştirme maliyetlerini belirlerken göreceli tahminler yaparak doğruya en yakın tahminleri gerçekleştirebildiğimizi ispatlamışlardır. Yapılan çalışmada benzeşim yöntemini kullanarak uzmanların, yazılım geliştirme eforunu hesaplayan algoritmik modellerden daha başarılı tahminlerde bulunduğu anlatılır.[1] Tabi bu çalışmadaki uzman görüşünün biraz evvel anlattığım takım lideri örneğiyle uzaktan yakından ilgisi yoktur. Uzman kişiler geliştirilecek ürünü, modül modül ya da işlev bazında inceleyerek projenin geliştirilebilmesi için gerekli eforu tahmin eder.

Yazılım geliştirme projelerinde mutlak ve göreceli tahmin üzerine gerçekleştirilen bir başka ilginç çalışma 2006 yılında Simula Araştırma Laboratuar’ında, Norveç’te gerçekleştirilmiştir.[2] Magne Jorgensen ve Stein Grimstad tarafından gerçekleştirilen çalışmada üç farklı bölümde katılımcılara verilen özelliklerin geliştirme eforlarının mutlak tahminlerini yapmaları istenmiştir. Buna göre;

İlk bölümde iki farklı gruptaki katılımcılara aynı özelliği anlatan dokümanlar verilmiştir. Birinci gruba verilen doküman bir sayfa iken ikinci gruba verilen doküman yedi sayfanın üzerindedir. Deneyin sonunda ikinci gruptaki katılımcılar, birinci gruptaki katılımcıların verdiği eforun % 48’i kadar fazla efor tahmininde bulunmuştur.

Çevik Yaklaşımlarda İşin Maliyetini Belirleme
Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Deneyin ikinci bölümünde iki tahmin grubundan aynı işlevsellik için tahminde bulunmaları istenmiştir.  Fakat ikinci gruba işlevsellikle ilgisi olmayan –son kullanıcının masaüstünde hangi yazılımların bulunduğu gibi- fazladan bilgiler de verilmiştir. İkinci grup birinci grubun neredeyse iki katı kadar yüksek bir tahmin yapmıştır.

Çevik Yaklaşımlarda İşin Maliyetini Belirleme
Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Deneyin üçüncü bölümünde ise üç farklı gruptan aynı özellik için tahminde bulunmaları istenmiştir. Birinci grup, kontrol grubu, sadece sağlanan bilgiler ile tahmin yapması istenmiştir. İkinci gruba müşterinin yazılım geliştirme ya da yazılım geliştirmeye nasıl efor verildiği hakkında bilgisi olmadığı fakat projenin 50 saatte geliştirilebileceğini düşündüğü söylenmiştir. Üçüncü gruba da müşterinin yazılım geliştirme ya da bunun için gerekli eforun nasıl verildiğine dair bilgisi olmadığı söylenmiş ikinci gruptan farklı olarak müşteri tahmininin 1000 saat olduğu söylenmiştir.

Buna göre kontrol grubu olan birinci grup istenen ürünün 456 saatte geliştirilebileceğini tahmin ederken, müşterinin 50 saat tahminde bulunduğu söylenen ikinci grup 99 saatlik bir tahminde bulunmuştur. Müşterinin 1000 saatlik tahminde bulunduğu söylenen üçüncü grup ise 555 saatlik bir efor tahmininde bulunmuştur.

Araştırma şu noktaya vurgu yapar; mutlak tahmine güvenemeyiz ve tahmini yapacak kişilere hangi bilgileri verdiğimize dikkat etmeliyiz.

Göreceli tahmin ile mutlak tahmin arasındaki farkı daha iyi anlamak için şu örneği düşünebilirsiniz; Göreceli tahminde su dolu iki bardak yan yana koyulduğunda hangisinin daha dolu olduğunu ya da hangisinin diğerine oranla ne kadar dolu olduğunu tahmin edebilirsiniz. Mutlak tahmin ise bu bardaklarda kaç mililitre su olduğunu tahmin etmektir. Tabi ki bir bardaktaki suyun miktarını mililitre cinsinden ve kesin olarak tahmin etmek çok zor bir iştir. Bu tahminin gerçeğe yakın olma ihtimali düşüktür.

 

Küçük Parçalara Bölme

Küçük parçalara bölme tekniği, büyük projelerin ya da kullanıcı hikayelerinin efor tahmini yapılırken daha doğru tahminler yapabilmek için küçük parçalara bölünmesidir.

2-3 günlük işleri doğru sonuca daha yakın bir şekilde tahmin etmek kolaydır. 90 – 100 günlük işlerin eforunu doğruya yakın şekilde tahmin etmek zordur. Çünkü efor fazladır, karmaşıklık fazladır, bağımlılık fazladır. İş büyüdükçe bilinmeyenler artacaktır. 90 – 100 günlük proje ya da kullanıcı hikayesini 2 – 3 günlük eforlara sahip işlere bölmek bu işlerin eforunu doğruya daha yakın tahmin etmemizi kolaylaştırır.

Ayrıca kullanıcı hikayelerini karşılaştırırken B hikayesi A hikayesinin 2 katıdır demekle B hikayesi A hikayesinin 50 katıdır demek arasında büyük fark vardır. 90 – 100 günlük işe verilen efor ile bu işi küçük parçalara ayırıp ve her bir küçük işi eforlayıp sonunda toplam efor çıkarıldığında çok büyük bir ihtimalle ulaşılan sonuç 90 – 100 günlük bir efor olmayacaktır. Ayrıca 100 günlük bir işin bilinmeyenlerinin fazla olduğunu söylemiştim. 2-3 günlük işlerin bilinmeyenleri ise daha azdır. Dolayısıyla küçük parçalara ayırma bilinmeyenlerin sayısını azaltacak ve görülmeyen şeylerin görünür olmalarını kolaylaştıracaktır.

Genelde parçalama işlemi sonrasında küçük parçalara verilen toplam efor büyük parçaya verilen efordan daha küçük olur. Çünkü tahmini yapan kişi neyin tahminini yaptığını daha iyi anlar. Deneyciliğin ilk sütunu olan şeffaflığın oluşması için bir adım atmış oluruz. Tabi bir de küçük parçaların toplam eforunun büyük parçaya verilen ilk efordan fazla olması ihtimali var. Yine buradan da anlaşılabileceği gibi aslında bilinmeyenler-görünmeyenler, akla gelmeyenler- bulunduğunu gösterir. Parçalara ayırdığınız için artık bunları daha rahat görebiliyorsunuz ve dolayısıyla yaptığınız tahmin daha doğru oluyor.

Yazılım geliştirme eforunu belirlerken doğruya yakın tahmin yapabilmek için gerekli tekniklerden bahsettim. Şimdi ise bu teknikleri nasıl aktivitelere dönüştürebileceğimize ve hangi yollarla kullanabileceğimize değineceğim. Bu aktivitelerin başında James Grenning’in oyunlaştırarak hem eğlenmemizi sağladığı hem de ilgili kullanıcı hikayesinin etkilerini tartıştığımız Planning Poker geliyor.[3] Sonrasında birçok takımın kullandığı T-Shirt Size’ı anlatacağım, zayıf ve güçlü yönlerinden bahsedeceğim. T-Shirt Size sonrasında ise Göreceli Toplu Değerlendirme(Relative Mass Valuation) tekniğinden bahsedeceğim.

 

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.3125&rep=rep1&type=pdf

[2] http://www.blackpepper.co.uk/agile-vs-waterfall-estimating-planning-tracking/

[3] https://renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf

 

Serinin tüm yazılarına erişmek için bağlantıya tıklayabilirsiniz.

Leave a Reply

Your email address will not be published. Required fields are marked *