COCOMO, Wideband Delphi, Planning Poker ve Story Points

Yazılım Kestirim Yöntemleri

Bu yazıda yazılım geliştirme projelerinde yaygın olarak bilinen ve efor (maliyet) ve takvim kestirimi için kullanılan aşağıdaki yazılım kestirim (software estimation) yöntemlerini göreceğiz. Bunları beraber inceleyerek (her ne kadar COCOMO diğerlerinden ayrı olsa da) aralarındaki ilişkileri de vurgulamış olacağız:

• COCOMO: Model tabanlı (formüle dayalı)
• Wideband Delphi: Uzman görüşüne dayalı
• Planning Poker: Uzman görüşüne dayalı
• Story Points: Uzman görüşüne dayalı

Yazılım projelerinde kestirim (software estimation) çalışmalarının neden yapıldığını Yazılımda Kestirim ve Yazılım Büyüklük Ölçümü yazısında detaylı incelemiştik. Özetle yazılımda kestirim; yazılım projelerinde daha iyi kaliteyi yakalayabilmek için, yazılım projelerinde makul planlamalar yapabilmek için ve kontrolü sağlayabilmek için yapılır. Yazılım büyüklüğünü, ne kadar geliştirme eforu gerekeceğini, ne kadar geliştirme zamanı gerekeceğini tahmin etmek için yapılır. Yazılım projelerini yönetmek için önemli bir yere sahiptir. 

Kestirim yöntemleri fiziksel yazılım nesneleri üzerinden ve yazılımın işlevsel özellikleri üzerinden olmak üzere temelde 2 farklı tekniğe ayrılmaktadır (detayları Yazılımda Kestirim ve Yazılım Büyüklük Ölçümü yazısında bulabilirsiniz). Ayrıca yazıda ayrıca LOC ile yazılım büyüklüğü kestirimini fiziksel yazılım özelliği ile işlemiştik. İşlevsel özelliğini kullanarak yazılım büyüklük kestirimini de COSMIC FSM yazısında ayrıntılı COSMIC açıklamalarıyla görmüştük. Şimdi bahsettiğimiz yazılım kestirim yöntemlerini ayrı başlıklarda görelim. 

COCOMO Yöntemi

COCOMO Nedir?

COnstructive COst MOdel ifadesinin kısaltması olan COCOMO 1981 yılında Barry Boehm tarafından geliştirilen bir kestirim modelidir. Software Engineering Economics kitabı ile tanıtmıştır. Bu model genel olarak COCOMO 81 olarak adlandırılmaktadır. Yazılım projelerinin maliyetini, eforunu ve takvimini tahmin etme süreci için kullanılan bir tekniktir. Yazılımda Kestirim ve Yazılım Büyüklük Ölçümü yazısında belirttiğimiz yukarıdan aşağıya (top-down) yaklaşıma sahip olan bir yöntemdir. Dünyada çok yaygın olarak kullanılan kestirim yöntemlerinden biridir.

COCOMO’da ölçüm LOC cinsinden yazılım büyüklüğüne ve maliyet faktörlerine dayanır. Maliyet faktörleri olarak proje nitelikleri, donanım, üretimin değerlendirilmesi vb. hususları da dikkate almıştır. Yani bunlar girdi olarak kullanılır. LOC ve bununla yapılan yazılım büyüklük ölçümünü aynı şekilde Yazılımda Kestirim ve Yazılım Büyüklük Ölçümü yazısında inceleyebilirsiniz.

COCOMO’da kestirimi hesaplamanın öncesinde bazı varsayımlar bulunmaktadır. Birincisi, COCOMO tahminlerinin projenin hem geliştirici hem de müşteri tarafından iyi yönetileceği varsayılır. İkinci varsayım, “Delivered Source Instructions (DSI)” ya da “Delivered Line Of Code” olarak ifade edilen teslim edilmiş talimatlar yani kaynak kodların COCOMO hesaplamasında birincil ana maliyet faktörü olduğudur. Yani kaynak kod sayısı her zaman hesaplamada girdi (input) olarak kullanılır. Delivered Source Instructions (DSI) ne demek biraz daha açalım. DSI bir proje tarafından geliştirilen bir satır kaynak kodun birim olarak ifadesidir. Yazılım maliyet/efor tahminlerinde kullanılır. Özetle; COCOMO’da efor/maliyet kestiriminde LOC cinsinden yazılım büyüklüğü ana girdi olarak kullanılır.

COCOMO’da hesaplamalar projenin büyüklüğüne ve karmaşıklığına göre yapılmaktadır. COCOMO seviyeleri yazılımın karmaşıklığına göre 3’e ayrılmıştır. Yazılım hangi seviyeye dahilse ona göre hesaplama yapılır. Bu seviyeler şunlardır:

1. Basit Proje: Sadece küçük yenilikler gerektiren küçük projeler bu kategoriye girer. Yazılım geliştirme ekibi uygulamaya, dile ve ilgili araçlara aşinadır. Genellikle 2-50 KLOC boyutlarındaki uygulamalardır. Basit iş sistemlerini, envanter yönetim sistemleri veya veri işleme sistemleri gibi uygulamaları örnek olarak verebiliriz.
2. Orta Karmaşıklıkta Proje: İlk kategoriye göre uygulama nispeten daha az tanıdık ve geliştirilmesi zordur. Ortalama yazılım ve ortalama ekibe sahiptir. Tipik olarak 50-250 KLOC boyutlarındaki uygulamalardır. Bu kategoriye derleyicileri veya bazı gömülü sistemleri örnek olarak verebiliriz.
3. Karmaşık Proje: İkinci kategoriye göre nispeten daha büyük projelerdir. Gereksinimleri katıdır. Daha fazla deneyime, daha büyük ekibe ve yenilikçi tasarıma ihtiyaç vardır. Gerçek zamanlı sistemleri örnek olarak verebiliriz.

Öte yandan yazılım maliyet / efor tahmini için uygulanan COCOMO modeli temel, orta düzey ve detaylı olmak üzere 3 aşamada yapılır. Aslında efor bir maliyet kalemidir, burada eforu bularak geliştirme maliyetini buluyoruz. Bu aşamalar da şunlardır:

• Temel Seviye: Genelde hızlı ve kabaca bir kestirim ortaya koymak için kullanılır.
• Orta Düzey: Orta seviye COCOMO’da düzeltme sağlayan 15 farklı maliyet faktörü bulunmaktadır. Temel COCOMO seviyesinde bu faktörlerin tümünün değeri 1 olarak alınmaktadır.
• Detaylı: Detaylı COCOMO’da ise gereksinim fazı, sistem tasarımı, kodlama ve birim testi, entegrasyon ve entegrasyon testi ve ayrıca bakım fazlarına bağlı ayrı çarpanlara sahiptir.

Temel COCOMO

Temel seviye (basic) COCOMO’da sadece yazılım büyüklüğü hesaplamaya dahil edilir. Diğer maliyet faktörleri 1 olarak düşünülür (yani hesaplamaya dahil edilmez.)

Efor hesaplaması için kullanılan formül şudur:

Efor = A * Boyut^B

Eforun birimi ise adam-ay’dır. Bir adam-ay, bir kişinin bir ay boyunca yazılım geliştirme projesi üzerinde çalışarak geçirdiği süredir.

Eforu kestirebilmek için öncelikle yazılım boyutu kestiriminde bulunmak gerekmektedir. Yazılım boyutu COCOMO için ana maliyet girdisidir. Formüldeki boyut değeri bu hesaplama öncesinde ortaya çıkardığımız yazılım büyüklüğünün KLOC cinsinden değeridir. COCOMO’da birim olarak KLOC (kilo lines of code) kullanılır. Yani 1000 satır kod 1 KLOC olarak formülde kullanılır.

A ve B ise projenin türüne göre tanımlanan sabitlerdir. Proje, başlangıçta belirttiğimiz hangi kategoriye giriyorsa ona göre A ve B sabitlerinin tablodaki değerleri alınır ve formülde kullanılır:

Proje Karmaşıklığı	A	B
Basit	2,4	1,05
Orta	3,0	1,12
Karmaşık	3,6	1,20

Tekrar belirtmek gerekirse kestirim yapacağınız yazılımın hangi seviyeye gireceğini öncelikle LOC büyüklük ölçümü yaparak belirliyoruz.

Efor = A * Boyut^B  formülünde eforun birimi belirttiğimiz gibi adam-ay’dır. Eforu bulduktan sonra artık geliştirme zamanını da bulabiliriz. Bunun için de formül şudur:

Zaman = C * Efor^D

Zaman ay cinsinden geliştirme zamanını göstermektedir. Efor belirttiğimiz gibi adam-ay olarak bir önceki formülde bulduğumuz değerdir. Buradaki C ve D sabitlerinin değerleri de şu şekildedir:

Proje Karmaşıklığı	A	B
Basit	2,5	0,38
Orta	2,5	0,35
Karmaşık	2,5	0,32

Örnek:

Boyutunu 40000 LOC = 40 KLOC olarak çıkardığımız bir yazılım için;

Proje tipi = Basit proje

Efor = 2,4*40^1,05 = 115 adam-ay

(Bu formülde bir ayda 152 çalışma saati ya da 19 çalışma günü baz alınmaktadır.)

Geliştirme süresi = 2,5*115^0,38 = 15 ay

Ortalama personel = 115 / 15 = 7,6 kişi

Son olarak verimliliği de hesaplayalım. Yazılımda Kestirim ve Yazılım Büyüklük Ölçümü  yazısında efor kestirimi bölümünde Efor = Boyut / Verimlilik (Productivity) formülünden bahsetmiştik. Üretkenlik ya da verimlilik formülü DSI/adam-ay şeklinde de gösterilir. Efor ve boyutu hesapladığımıza göre verimliliği de bu formülden çıkarabiliriz:

Ortalama verimlilik = 40000 / 115 = 348 LOC / adam-ay.

Bu hesaplamaları yorumlayacak olursak; LOC olarak büyüklüğünü kestirdiğimiz basit seviyedeki bu proje için 115 adam-ay’lık bir efor olacağını ön görüyoruz. Teorik olarak 7,6 geliştirici olduğu takdirde geliştirme 15 ayda tamamlanacaktır. Buna göre mevcut geliştirici sayısına göre geliştirici zamanını da ay olarak ortaya çıkarabiliriz.

Bu yöntemle bazı çıkarımlarda da bulunabiliriz. Aşağıdaki grafik yazılım boyutu arttıkça tahmin edilen geliştirme eforunu COCOMO seviyeleri bazında göstermektedir. Yazılım karmaşık bir yazılımsa efor diğer seviyelere göre daha fazla olacaktır. Ayrıca boyut arttıkça tahmin edilen efor doğrusal değerin daha üzerinde yer alacaktır:

Aşağıdaki grafik de yazılım boyutu arttıkça tahmin edilen geliştirme zamanının logaritmik değişimini göstermektedir. Bundan şunu anlayabiliriz; yazılım boyutu ile geliştirme zamanı aynı oranda artmamaktadır. Bunun sebebi olarak büyük yazılımlarda eş zamanlı yapılabilecek işlerin olmasını söyleyebiliriz:

Orta Düzey COCOMO

Orta düzey (intermediate) COCOMO modeli, yazılım boyutuna ek olarak yazılım hayatındaki bazı gerçekleri de hesaplamaya dahil eden temel COCOMO’nun uzantısıdır. Belirli maliyet faktörlerini çarpan olarak formüle dahil eder. Bu şekilde gerçeğe biraz yakınsamak hedeflenmektedir. Bu seviyede 15 maliyet faktörü kullanılmaktadır.

4 ayrı başlıkta toplanan bu maliyet etkenleri şunlardır:

1. Ürün Özellikleri: Geliştirilmekte olan yazılımın gerekli özellikleri:
   1. Güvenilirlik (reliability)
   2. Ürün karmaşıklığı (product complexity)
   3. Veri tabanı boyutu (database size)
2. Sistem Özellikleri: Donanımın yazılım üzerinde oluşturduğu kısıtlamalar:
   
   1. Yürütme süresi (execution time)
   2. Depolama (storage)
   3. Sanal makine değişkenliği (virtual machine volatility)
   4. Sistemin yanıt süresi (Computer response time)
3. Personel Özellikleri: Bireylerin deneyim ve yetenekleri
   
   1. Analist yetkinliği (analyst capability)
   2. Uygulama tecrübesi (application experience)
   3. Geliştirici yetkinliği (programmer capability)
   4. Sanal makine tecrübesi (virtual machine experience)
   5. Programlama dili yetkinliği (programming language experience)
4. Proje Özellikleri: Modern araçların ve uygulamaların kullanımı
   
   1. Modern programlama uygulamaları (modern programming practices)
   2. Modern yazılım geliştirme araçları (modern software development tools)
   3. Gerekli yazılım takvimi (required software schedule)

Bu seviyede efor hesaplaması için kullanılan formül şudur:

Efor = A * Boyut^B * c1 * c2 * c3 * c4 ….. c15

Formülde her bir maliyet etkeni ayrı bir çarpan olarak formüle eklenmiştir. A ve B değerleri için aynı şekilde temel seviyede belirttiğimiz tablodaki değerler kullanılır:

Proje Karmaşıklığı	A	B
Basit	2,4	1,05
Orta	3,0	1,12
Karmaşık	3,6	1,20

Maliyet faktörleri için de aşağıdaki tabloda bulunan değerler belirlenmiştir:

Maliyet Faktörü	Çok Düşük	Düşük	Nominal	Yüksek	Çok Yüksek	Fazlasıyla Yüksek
Güvenilirlik (reliability)	0,75	0,88	1,00	1,15	1,40	1,40
Ürün karmaşıklığı (product complexity)	0,70	0,85	1,00	1,15	1,30	1,65
Veritabanı boyutu (database size)	0,94	0,94	1,00	1,08	1,16	1,16
Yürütme süresi (execution time)	1,00	1,00	1,00	1,11	1,30	1,66
Depolama (storage)	1,00	1,00	1,00	1,06	1,21	1,56
Sanal makine değişkenliği (virtual machine volatility)	0,87	0,87	1,00	1,15	1,30	1,30
Sistemin yanıt süresi (Computer response time)	0,87	0,87	1,00	1,07	1,15	1,15
Analist yetkinliği (analyst capability)	1,46	1,19	1,00	0,86	0,71	0,71
Uygulama tecrübesi (application experience)	1,29	1,13	1,00	0,91	0,82	0,82
Geliştirici yetkinliği (programmer capability)	1,42	1,17	1,00	0,86	0,70	0,70
Sanal makine tecrübesi (virtual machine experience)	1,21	1,10	1,00	0,90	0,90	0,90
Programlama dili yetkinliği (programming language experience)	1,14	1,07	1,00	0,95	0,95	0,95
Modern programlama uygulamaları (modern programming practices)	1,24	1,10	1,00	0,91	0,82	0,82
Modern yazılım geliştirme araçları (modern software development tools)	1,24	1,10	1,00	0,91	0,83	0,83
Gerekli yazılım takvimi (required software schedule)	1,23	1,08	1,00	1,04	1,10	1,10

Örnek:

Boyutunu 40000 LOC = 40 KLOC olarak çıkardığımız bir yazılım için aşağıdaki faktörler olduğu takdirde;

Yüksek uygulama deneyimine sahip bir geliştirici faktörü: 0,82

Düşük seviye için programlama dili yetkinliği: 1,07

Efor = 2,4*40^1,05 * 0,82 *1,07 = 101 adam-ay

Görüldüğü üzere bu faktörlerden dolayı öngörülen efor (ve geliştirme süresi) temel COCOMO’ya göre değişmiştir.

Detaylı COCOMO

Bu seviye ilk iki seviyenin tüm stratejilerini içerir. Detaylı COCOMO’da gereksinim fazı, sistem tasarımı, kodlama ve birim testi, entegrasyon ve entegrasyon testi ve ayrıca bakım fazlarına bağlı toplamda 6 çarpana sahiptir. Yazılım projelerini etkileyen daha fazla faktör içerir ve daha doğru tahmin verir.

Detaylı COCOMO’da orta düzeydeki COCOMO’da olduğu gibi projenin bu her aşaması için ayrı hesaplama yapılır. Her bir alt birimin maliyeti ayrı ayrı tahmin edilir ve çıkan sonuçlar toplanır. Bu yaklaşım nihai tahmindeki hata payını azaltır.

Ayrıca web üzerinden COCOMO Calculation adresindeki araçla bu faktörleri de kullanarak hesaplama yapabilirsiniz.

COCOMO 2

1997 yılında COCOMO 1’in revize edilerek yeni yazılım geliştirme uygulamalarına uyum sağlaması için ortaya çıkarılmıştır. COCOMO 81 (ve 85) şelale (waterfall) yazılım geliştirme modeli düşünülerek geliştirilmiştir. Hesaplamaya takım deneyimi, geliştirici becerileri ve dağıtık geliştirme ile başa çıkabilmek için yeni maliyet faktörleri eklenmiştir ve COCOMO 81’deki bazı faktörler çıkarılmıştır:

• Emsalsiz Olma Durumu (Precedentedness)
• Mimari / Risk Çözümü (Architecture / Risk Resolution)
• Geliştirme Esnekliği (Development Flexibility)
• Takım Uyumu (Team Cohesion)
• Süreç Olgunluğu (Process Maturity)

COCOMO 2 daha ayrıntılı tahminler üreten çeşitli alt modeller içerir. Bu modeller şunlardır:

1. Uygulama kompozisyon modeli: Sistemlerin yeniden kullanılabilir bileşenler, komut dosyası veya veri tabanı programlamasından oluşturulduğunu varsayar. Prototip geliştirme tahminleri yapmak için tasarlanmıştır. Yazılım boyutu tahminleri uygulama noktalarına dayanır ve gerekli çabayı tahmin etmek için basit bir boyut/verimlilik formülü kullanılır.
2. Erken tasarım modeli. Bu model, gereksinimler belirlendikten sonra sistem tasarımının ilk aşamalarında kullanılır. Tahminler, daha sonra kaynak kod satır sayısına dönüştürülen işlev noktalarına dayanır. Formül, yedi çarpan kümesini dikkate alır.
3. Yeniden kullanım modeli. Bu model, tasarım veya program çeviri araçları tarafından otomatik olarak oluşturulan yeniden kullanılabilir bileşenleri ve/veya program kodunu entegre etmek için gereken eforu hesaplamak için kullanılır. Genellikle mimari sonrası model ile birlikte kullanılır.
4. Mimari sonrası model. Sistem mimarisi tasarlandıktan sonra, yazılım boyutuna ilişkin daha doğru bir tahmin yapılabilir. Bununla birlikte, personel kapasitesini, ürün ve proje özelliklerini yansıtan daha kapsamlı bir 17 çarpan seti içerir.

COCOMO’nun Avantajları ve Dezavantajları

Avantajları:

» Hızlı ve genel geçer proje maliyeti tahmini sağlar.

» Nasıl çalıştığını kolayca anlayabiliriz. Projenin toplam maliyetinin kestirimi kolaydır.

» İyi bilinen geliştirme ortamında küçük projelerde iyi sonuçlar verir.

» Geçmiş veriler üzerinde çalıştığı takdirde daha doğru ayrıntılar sağlar. Bunun için kuruluşunuza göre bir dizi COCOMO sabitleri veya başka ayarlama faktörleri de belirleyip kullanabilirsiniz.

» Yeni projelerin boyutları, karmaşıklığı, süreçleri çok farklı olmadığı sürece COCOMO bir tahmin aracı olarak oldukça değerli olabilir.

Dezavantajları:

» Yazılım maliyetlerinin doğruluğunu sınırlar.

» Etkileyen faktörleri belirlemek için ayrı bir değerlendirme çalışması yapmak gerekir.

» Gereksinimlerin değişkenliğini, müşteri niteliklerini, yazılım geliştirme ortamını, yazılım güvenliği konularını, çalışan değişimini göz ardı eder.

» Verileriniz COCOMO’yu geliştirmek için kullanılan verilerle eşleşmeyebilir Eşleşmiyorsa modeli ilişkilendirmek için gereken veriler toplanmalıdır.

» Deneyimler tahmin sonuçlarının gerçek efora göre sapma olabileceğini göstermektedir.

Wideband Delphi Yöntemi

Wideband Delphi Yöntemi Nedir?

Bu model ekip olarak bir tahmin oluşturmak için kullanılan bir yöntemdir. Katılımcıların fikir birliğine dayalı proje iş yükünü tahmin etmeye yönelik bir tekniktir. Geçmişi 1950’lere dayanmaktadır. Bu tarihlerde geliştirilen Delphi yöntemine dayanmaktadır. Delphi yöntemi kısaca uzmanlardan ve bir tahmin organizasyonundan oluşan bir grubunun ilgili konu hakkında uzmanlardan arka arkaya görüş ve yargıları alınarak tahmin yapmak için takip ettikleri bir yöntemdir.

1970’lerde Barry Boehm ve John A. Farquhar bu yöntemi genişleterek Wideband Delphi adını vermişlerdir. Yazılım geliştirme projelerinde Delphi yöntemine göre daha fazla etkileşim olduğu için bu isim kullanılmaktadır. Wideband Delphi’nin popüler olmasının sebebi ve en göze çarpan avantajları uygulama kolaylığı, düşük maliyet ve geçmiş verilere ihtiyaç duymamasıdır.

Wideband Delphi tekniğinde proje yöneticisi bir tahmin ekibi seçer. Ekip arasında sonuçlar arasında fikir birliği sağlanana kadar her bir tahmin için tartışma yapılır. Yani Wideband Delphi konu üzerinde tartışmayı (münazarayı) teşvik eder. Tekrarlanabilir bir tahmin sürecidir. Çevik (agile) proje yönetiminde (özellikle yazılım geliştirme projelerinde) başarıyla kullanılmaktadır. Basit bir dizi adımdan oluşur.

Wideband Delphi Adımları

Wideband Delphi adımları şu şekildedir:

Adım 1: Takımı Belirleme

Öncelikle proje yöneticisi nitelikli bir takım ve bir moderatör belirler. Ekip 3 ila 7 kişi arasında oluşmalıdır. Moderatör bu sürece aşina olmalıdır ancak sürecin sonucuna bir katkısı olmamalıdır. Proje yöneticisi idealde ekibin bir parçası olmalıdır dolayısıyla mümkünse moderatör olmamalıdır. Değerlendirme ekibi içerisinde yöneticiler, geliştiriciler, analistler, tasarımcılar veya başka katkıda bulunanlar olabilir.

Adım 2: Başlangıç Toplantısı

Bu adımda sorunla ilgili detaylı bilgiler, görev listesi, varsayımlar ve proje kısıtlamaları sunulur. Bu adımda ekip beyin fırtınası yapar ve varsayımları yazar. Ekip varsa sorun ve tahmin konular üzerinde tartışır. Ekip bu toplantı sonunda bir tahmin birimi üzerinde uzlaşmaya varır.

Bu adımda 10-20 ana görevden (WBS, Work Breakdown Structure yani iş kırılım yapısı) oluşan bir görev listesi oluşturulur. Yani bu görevler üst seviye olarak ortaya çıkarılır. WBS, proje hedeflerine ulaşmak ve gerekli çıktıları oluşturmak için proje ekibi tarafından yürütülecek toplam iş kapsamının hiyerarşik olarak gösterildiği bir yapıdır. WBS’te seviye azaldıkça proje çalışmasının daha ayrıntılı tanımları görülür.

Moderatör tüm tartışmaya rehberlik eder, zamanı izler ve başlangıç toplantısından sonra problem detayını, üst düzey görev listesini, varsayımları ve kararlaştırılan tahmin birimini içeren bir belge hazırlar. Daha sonra bu belgeyi bir sonraki adım için iletir.

Proje yöneticisi, her ekip üyesinin Delphi sürecini anladığından, vizyon ve kapsam belgesini ve diğer belgeleri okuduğundan, projenin geçmişi ve ihtiyaçları hakkında bilgi sahibi olduğundan emin olmalıdır. Kısaca bu adım ön hazırlık ve gözden geçirme aşamasıdır.

Adım 3: Bireysel Hazırlıklar

Bu adımda her bir görev için, takım üyeleri görevi tamamlamak için gereken eforu tahmin eder ve bu kestirimi yapabilmek için yapması gereken ek varsayımları yazar. Ekip tarafından oluşturulan varsayımları ve görevleri ekipte facilitator olarak adlandırılan kişi yapar. Bu adımdan sonraki aşama her bir tahmin ekibi üyesinin grup tartışmasına dayalı olarak tahminlerini gözden geçirdiği turlara ayrılır.

Adım 4: Tahmin Bölümü

Her ekip üyesi tahminlerini içerdiği bir tahmin formu doldurur. Moderatör tahmin formlarını toplar ve her bir formdan gelen eforun toplamını bir çizgi üzerinde işaretler:

Ekip, gündeme gelen her türlü sorunu veya ihtilafı çözer. Bireysel tahmin süreleri tartışılmaz. Bu ihtilaflar genellikle görevlerin kendileriyle ilgilidir. Anlaşmazlıklar genellikle varsayımlar eklenerek çözülür.

Tüm tahminciler bireysel tahminlerini gözden geçirir. Moderatör grafiği yeni toplam ile günceller:

Moderatör tahminler üzerinde fikir birliği sağlayana kadar ekibi birkaç tur boyunca yönlendirir. Bu tahmin oturumu tahminler yakınsayana kadar veya ekip tahminleri revize etmeye isteksiz olana kadar devam eder.

Adım 5: Görevleri Birleştirme

Proje yöneticisi, toplantı sonunda ekiple birlikte çalışarak nihai görev listesini, tahminleri ve varsayımları derler.

Adım 6: Sonuçları Gözden Geçirme

Son adımda proje yöneticisi nihai görev listesini tüm ekiple birlikte gözden geçirir. Bu gözden geçirme toplantısının amacı tahminlerin kabul edilebilir olup olmadığını, daha iyi planlama için yeterli olup olmadığını veya iyileştirme gereken bir yer olup olmadığını belirlemektir.

Planning Poker Yöntemi

Planning Poker ya da Türkçe ifadeyle planlama pokeri çevik (agile) geliştirmede kullanılan fikir birliğine dayalı kestirim ve planlama tekniğidir. Model tabanlı değil uzman görüşüne dayalı bir tekniktir. Yazılım geliştirme çalışmaların göreceli tahmininde popüler bir yöntem haline gelmiştir. Aşağıdan yukarıya (bottom up) yaklaşıma sahip olan bir yöntemdir. Bottom up yaklaşım için Yazılımda Kestirim ve Yazılım Büyüklük Ölçümü yazısında ilgili kısmı inceleyebilirsiniz.

Planlama pokerine ekipteki tüm geliştiricileri içerir. Çevik bir projede bu sayı genellikle on kişiyi geçmez. Eğer geçerse, genellikle iki ekibe ayrılır. Ekipte ürün sahibi (product owner) çalışmaya katılır ama tahmin yapmaz.

Planlama pokerinin başlangıcında tahmin yapacak her bir kişiye 0, 1, 2, 3, 5, 8, 13, 20, 40 ve 100 gibi değerlere sahip Planning Poker kartları verilir. Bu sayılar esasen önerilen değerlerdir. Bunun yerine Fibonacci serisi de seçilirse kartlarda 1, 2, 3, 5, 8, 13, 21, 34 … sayıları olacaktır. Fibonacci dizisi story points için kullanılmaktadır.

Planning Poker ile tahmin çalışmasına başlamak için bir moderatör bir kullanıcı öyküsü (user story) ya da bir ürün özelliği aktarır. Moderatör müşteri, analist ya da ürün sahibi (product owner) olabilir.

Konuşulan özelliğin tartışılıp netleştirilmesi için ürün sahibi tahmin yapacak her bir kişinin sorularını yanıtlar. Konu netleştikten sonra tahmin yapacak her bir kişi bir kart seçer ve kartlar aynı anda açıklanır. Herkes aynı değeri seçmişse bu tahmin olarak not edilir. Değilse, tahminlerini tartışır. Özellikle yüksek ve düşük değerler verenler nedenlerini paylaşmalıdır. Bu değerlendirme ve tartışmadan sonra her bir tahminci kartını yeniden seçer ve tüm kartlar yeniden açılır. Bu süreç fikir birliği sağlanana kadar devam eder. Bazen de ek bilgi gerekebileceğinden ertelenmesine karar verebilirler. Amaç, tahmin eden kişilerin hikâye için kullanılabilecek tek bir tahminde birleşmesidir. Bu nadiren üç turdan fazla sürer.

Bu yöntem çevik (agile) geliştirmede kullanılan araçlardan sadece bir tanesidir. Planning Poker başta da belirttiğimiz gibi uzman görüşüne dayalı (expert based) bir tekniktir.

Poker planlaması yaptığımızda eforu değil öykülerin göreceli boyutunu ekip olarak tahmin etmiş oluyoruz. Mutabık kalınan sayılarda örneğin 8 puanlık öykünün 5 puanlık öyküden daha büyük olacağını görüyoruz. Bu tür bir süreç başta zaman alacaktır ancak ekip birlikte çalıştıkça fikir birliğine daha kolay varacaktır. Poker Planlama, Wideband Delphi yönteminin bir varyasyonudur.

Story Points Yöntemi

User Story

Story points estimation (öykü puanları ile kestirim) konusuna geçmeden önce user story nedir bunu açıklayalım. User story yani kullanıcı öyküsü ya da kullanıcı hikayesi bir sistemin kullanıcısı veya müşterisinin istediği yeni özelliği kendi bakış açısından anlattığı net, basit, kısa tanımlardır. Bir sistemin veya yazılımın kullanıcısı için değerli olacak işlevselliği tanımlar. Kullanıcı öyküsü müşteri perspektifinden resmî olmayan bir şekilde konuyu aktarır. Hangi bilginin, kararın veya eylemin gerçekleştirileceğine dair bilgi verir.

Kullanıcı öyküleri özellikle çevik yazılım geliştirmede bir ürün özelliğinin ne değer katabileceğini ifade eder. Kullanıcıların belirli bir işlevi neden istediklerini daha iyi anlamaya yardımcı olur. Geliştirme ve ürün yönetimi bu kullanıcı hikayelerini dizin kartlarına veya yapışkan notlara yazıp bunları geliştirme aşamasında yapacakları tartışmaların bir parçası olarak kullanacaktır. Bu tartışmalar, ekibin daha iyi bir ürün ve kullanıcı deneyimi ortaya çıkarmak için kullanıcıya odaklanmasına yardımcı olur.

Kullanıcı öyküsü için Mike Cohn’un User Stories Applied ile belirttiği aşağıdaki gibi genel bir şablonu mevcuttur:

As a <type of user>, I want <some goal> so that <some reason>

Bazı user story örnekleri:

Bir işletme sahibi olarak kredi kartı kabul edebilmek istiyorum bu sayede yaygın bir ödeme kanalı ile ödeme alabileceğim.

Bir editör olarak, içeriği yayınlanmadan önce gözden geçirmek istiyorum, böylece doğru dilbilgisiyle optimize edildiğinden emin olabilirim.

Bir veri tabanı yöneticisi olarak, farklı kaynaklardan gelen veri kümelerini otomatik olarak birleştirmek istiyorum, böylece dahili müşteriler için raporları daha kolay derleyebilirim.

Story Points Nedir?

Peki user story points nedir? Story point yani öykü puanı BT geliştirici ekiplerinin bir kullanıcı öyküsünün (user story) uygulanmasının zorluğunu belirtmek ve tahmin etmek için kullandığı bir metriktir. Kullanıcı öyküsünü uygulamak için gereken eforun soyut bir ölçüsüdür. Story point; zorluk, karmaşıklık, riskler veya harcanan efora tekabül edebilir. Scrum, Agile-Kanban ve Extreme Programming (XP) çevik proje yöntemlerinde tavsiye edilir.

Öykü puanlarının işlevi her bir görev veya öykünün gerektireceği tahmini çalışma miktarını tutarlı bir şekilde yansıtmasıdır. Bu sayede ekibin hızını ölçmesini sağlar.

Story point ekibin görevin/öykünün ne kadar süreceğini tahmin ettiği adam-saat sayısı olabileceği gibi, başka herhangi bir iş/zaman birimi de olabilir. Bu nedenle kesin uygulama yöntemi iyi tanımlanmamıştır. Farklı projeler ve ekipler arasında farklılık gösterebilir.

Story Points İle Kestirim

Kullanıcı öyküsünün boyutunu tanımlamak için spesifik bir formül yoktur. Daha ziyade, tahmin aşağıdaki unsurların değerlendirilmesiyle ortaya çıkar. Bunların karmaşıklığı, ne kadar efor gerekeceği, riskleri, tekrarlar ve benzeri konular göz önüne alınarak tahmin yapılır. Bu unsurlar şunlardır:

» Kullanıcı Öyküsü (User Story): Öykü ne anlatıyor?

» Tasarım (Design): Yeni bir tasarım mı yoksa küçük değişiklikler mi gerekiyor?

» Kodlama (Coding): Çok sayıda sınıf oluşturmalı mıyız? Kullanıcı ara yüzüne ihtiyaç var mı? Veri dönüşümü karmaşık mı?

» Birim Testi (Unit Testing): Kaç tane test senaryosu yazılmalı? Mevcut test çerçevesi yeterli mi?

» Sistem Entegrasyon Testi (System Integration Testing): Ara yüz veriyle birlikte hazır mı? Zamanında dış ekiplerden yardım alabilecek miyiz?

» (User Acceptance Testing) Kullanıcı Kabul Testi: Kullanıcılar test için hazır mı? Kabul kriterleri öykü için açıkça yazılmış mı?

» Devreye Alım (Deployment): Bir CI/CD ( Continuous Integration and Continuous Delivery and Deployment – Sürekli Entegrasyon ve Sürekli Teslimat ve Devreye Alım) hattı mevcut mu? Manuel yapılacaksa ne kadar zaman harcamalıyız?

» Beceri ve Bilgi (Skills and Knowledge): Bu tür bir çalışma daha önce yapıldı mı? Ekipte doğru ve yetenekli insanlar var mı? Dışardan yardım almalı mıyız?

Story Points yani öykü puanlarıyla tahmin çalışması şu şekilde olur: Kullanıcı öyküleri story cards adı verilen kartlara yazılır. Burada kullanıcı açısından değerli işlevselliğin kısa açıklaması olmalıdır. Her ekip üyesi öykü için makul bir puan vererek Planning Poker yöntemini uygular!

Puan verme işleminde yaygın olarak Fibonacci dizisi (1, 2, 3, 5, 8, 13, 21…) kullanılır. Tişört boyutu olarak adlandırılan harfler de kullanılabilir (S, M, L, XL …). Puan verme işleminde bahsettiğimiz gibi sadece ne kadar efor alacağı değil; riskleri, karmaşıklığı gibi unsurlar da göz önüne alınır. Uzaktan çalışan ekipler için de puanlama için web üzerinde çevrim içi birçok uygulama bulunmaktadır.

Tahmin etmek için temel öykülerden de faydalanılır. Sonrasında her ekip üyesi verdiği puanın nedenini açıklar. Bir önceki adımda herkes nedenini açıkladıktan sonra fikir birliğine varılana kadar tartışılır (puanların ortalaması alınmaz). Eğer beklenmedik şekilde değer yüksek çıkarsa öykü ikiye veya daha fazla sayıya bölünebilir.