=Paper=
{{Paper
|id=Vol-1980/UYMS17_paper_37
|storemode=property
|title=Cevik Yontemlerde Cosmic Islev Puani ve Hikaye Puaninin Birlikte Kullanimi (Using Cosmic Funcion Points and Story Points Together in Agile Frameworks)
|pdfUrl=https://ceur-ws.org/Vol-1980/UYMS17_paper_37.pdf
|volume=Vol-1980
|authors=Cihangir Ertaban,Serhat Gezgin,Selami Bagriyanik,Erinc Albey,Adem Karahoca
|dblpUrl=https://dblp.org/rec/conf/uyms/ErtabanGBAK17
}}
==Cevik Yontemlerde Cosmic Islev Puani ve Hikaye Puaninin Birlikte Kullanimi (Using Cosmic Funcion Points and Story Points Together in Agile Frameworks)==
https://ceur-ws.org/Vol-1980/UYMS17_paper_37.pdf
Çevik Yöntemlerde Cosmic İşlev Puanı ve Hikaye
Puanının Birlikte Kullanımı
Cihangir Ertaban1[0000-0001-9492-8413], Serhat Gezgin1[0000-0002-2548-7578], Selami Bağrıya-
nık1, Erinç Albey2[0000-0001-5004-0578], and Adem Karahoca3
1 TURKCELL, İstanbul, Türkiye
cihangir.ertaban@turkcell.com.tr, serhat.gezgin@turkcell.com.tr,
selami.bagriyanik@turkcell.com.tr
2 Özyeğin Üniversitesi, İstanbul, Türkiye
erinc.albey@ozyegin.edu.tr
3 Bahçeşehir Üniversitesi, İstanbul, Türkiye
adem.karahoca@eng.bau.edu.tr
Özet. Hikaye Puanı (SP: Story Point), Scrum ve Kanban gibi çevik yöntemlerde
kullanılan en yaygın metriklerden birisidir. Subjektif bir metrik olsa da kullanışlı
ve basit olması nedeniyle çevik ekiplerin birikim listelerinde bulunan kullanıcı
hikayelerinin uygun bölümlere ayrılmasında, maliyet tahminlemesinde ve ekip-
lerin hız ve kapasitelerinin hesaplanmasında yaygın bir şekilde kullanılmaktadır.
Cosmic işlev puanı (CFP: Cosmic Function Point) ise yazılım işlevsel kapsam
büyüklüğünün ölçümünde kullanılan ve aynı zamanda bir ISO standardı da (ISO
19761) olan objektif bir metriktir. Bu çalışmada Türkiye’nin en büyük teknoloji
ve iletişim hizmetleri sağlayıcı firmalarından birinin çevik yazılım geliştirme
prensiplerine göre çalışırken hem Hikaye Puanı hem de CFP metriklerini birlikte
kullanım deneyimleri paylaşılmış; iki metriğin benzerlikleri ve farklılıkları irde-
lenmiştir. Sonuç olarak SP metriğinin kapsam boyutlandırma toplantıları sıra-
sında kullanıcı hikayelerinin çevik mantıkla uygun kapsam büyüklüğüne bölün-
mesinde daha etkin bir araç olduğu, CFP’nin ise çevik ekiplerin ürettiği çıktıların
miktarının ve kalitesinin zaman içindeki trendinin ölçülmesinde ve yine çevik
ortamlarda dış kaynak hak edişlerinin belirlenmesinde daha başarılı sonuçlar ver-
diği sonucuna varılmıştır. Ek olarak CFP’nin Efor tahminlemesinde kullanılıp
kullanılamayacağı yönünde bir doğrusal regresyon modeli için ön analiz yapılmış
ve ilk sonuçlar paylaşılmıştır.
Anahtar Kelimeler: Hikaye Puanı, SP, FSM, COSMIC İşlev Puanı, CFP, ISO
19761, Çevik Yöntemler, Scrum, Kanban, Efor Tahminleme.
378
Using Cosmic Funcion Points and Story Points Together
in Agile Frameworks
Abstract. Story Point (SP) is one of the most common metric in agile frameworks
such as Scrum and Kanban. Although being subjective, story point is very useful
for grooming and sizing of the backlog items, cost, squad velocity and capacity
estimation. Cosmic Functional Points (CFP) is an objective metric used for esti-
mating the functional scope of the software and it is an ISO standard (ISO 19761).
This study investigates the use, similarities and differences of boh SP and CFP
in agile software development practices in the largest technology and communi-
cations provider of Turkey. As a result, SP is an effective tool for grooming the
user stories whereas CFP provides successful results for measuring output of the
squad, quality trend and outsource contracts. Also, a preanalysis for a linear reg-
ression model of CFP versus effort estimation is conducted in this paper and the
initial results are shared.
Keywords: Story Point, SP, FSM, COSMIC Functional Point, CFP, ISO 19761,
Agile Frameworks, Scrum, Kanban, Effort Estimation.
1 Giriş
Çevik Çerçeveler günümüzde yazılım sektöründe yaygın olarak kullanılmaktadır. Çe-
vik Çerçeveler arasında da en çok Scrum [1] ve Kanban [2] öne çıkmaktadır [3]. Her
iki yöntemde de yapılan işin iyileştirilebilmesi için mevcut durumun değerlendirilebil-
mesi gerekir. Bu değerlendirmenin yapılabilmesi için de mevcut durumun metriklerle
ölçülmesi gerekir. Ölçülecek temel unsur geliştirilen yazılım olduğunda ise iki ana met-
rik bulunur: Hikaye Puanı ve CFP.
Hikaye Puanı ve CFP metriklerinin ikisi de yazılımı rakamsal bir büyüklükle ifade
ettiğinden sıklıkla karşılaştırılmışlardır. Hikaye Puanının bir standart olmaması ve sez-
gisel olarak hesaplanması nedeni ile uygulayıcılar arasında yanlış anlamalara ve nice-
liksel olarak farklılıklara yol açabilmesi göz önünde bulundurularak, karşılaştırmalarda
CFP’nin Scrum ile birlikte kullanılan Hikaye Puanı’nı ikame edip edemeyeceği tartı-
şılmaktadır [17][18][19].
Bu çalışmada Hikaye ve CFP metriklerinin birbirini ikame ederek Çevik Yazılım
Geliştirme metodunda yalnızca birinin kullanıldığı örneklerin aksine sürecin farklı nok-
talarında faydalar sağlayarak iki metriğin birlikte kullanılabileceği bir örnek deneyim
paylaşılmaktadır. Hikaye Puanı ve CFP metriklerinin kullanıldığı yerler, benzerlikler
ve farklılıklar incelenmiş ve Hikaye Puanı ile efor tahminlemesinin nasıl yapılabilece-
ğine dair bir ön çalışma yapılmıştır.
Çalışmanın yapıldığı takım Çevik Çerçevelerden Genişletilmiş Kanban (Extended
Kanban) uygulamaktadır. Kanban’ın temel prensiplerini ve bu prensiplere ek olarak
Scrum’da yer alan rolleri ve toplantıları (Günlük Toplantı, Kapsam Boyutlandırma
Toplantıları) almıştır.
379
Takımın benimsediği prensipler, roller ve CFP hakkında genel bilgiler aşağıda ve-
rilmiştir:
1.1 Kanban
Kanban üretim alanında 1950’lerde ortaya çıkan [6], yalın üretim felsefesi ile birlikte
[7] kaliteyi artırmayı ve Ürün Tamamlanma Süresi’ni (Lead Time) kısaltmayı hedefle-
yen bir metoddur. 2000’li yıllardan itibaren Teknoloji üretim süreçlerinde de çevik çer-
çevelerden biri olarak uygulanmaya başlanmıştır [8]. Kanban’ın zorunlu kıldığı çok az
sayıda kuralı vardır. Sürecin diğer tüm detaylarına ilişkin uygulamaların hemen hemen
tamamı takım insiyatifine bırakılmıştır.
Ürün Tamamlanma Süresi Ölçümü
Kanban’ın diğer çevik metodlarda olduğu gibi dayandığı temel ilkeler deneyimlemek,
ölçmek ve sürekli iyileşmedir. Ürün Tamamlanma Süresi işlerin takım tarafından ele
alınmasıyla başlayarak daha önce anlaşılan Tamamlanma Kriterleri’nin hepsinin ger-
çekleştirilmesiyle biter. Kanban çerçevesinde Ürün Tamamlanma Süresinin kısalması
beklenir [2].
Görselleştirme
Kanbanda işin tamamlanana kadar geçeceği aşamaları ve her aşamada ne kadar iş bu-
lunduğunu görselleştiren bir tahta kullanılır. Bu tahta plastik, karatahta ya da dijital bir
ekran olabilir [2].
İş Çekme Prensibi ve Aktif İş (WIP) kısıtı
Kanban’ın üçünü kuralı ise bir istasyonda tamamlanan işin bir sonraki istasyonun üye-
lerince doğru zamanda kendileri tarafından çekilmesidir. Bu kurala göre işler kimseye
atanmaz, herkes kendisi çeker. Bir kişinin işi çekebilmesi için gerekli ön koşul ise o
kişinin üzerindeki işlerin Aktif İş kısıtında belirtilen sayıdan daha az olmasıdır. Genel-
likle herkesin aynı anda tek bir iş yapacağı ön görülür ve kişilerin iş kısıtları 1 olarak
belirlenir. Bir istasyonda görevli kaç kişi varsa o istasyonda en fazla o kadar iş buluna-
bilir. Bu prensibin temel nedeni ise bir kişinin üzerine alacağı birden fazla iş olsa bile
en fazla biriyle ilgileneceği ve diğer işlerini beklemeye alacağıdır. Kanban’da da bu
durum görsel hale getirilir, beklemeye alınan işler tahta üzerinde de gösterilir [5].
1.2 Roller
Scrum’da çevik ekip Ürün Sahibi (Product Owner), bir Scrum Yöneticisi (Scrum Mas-
ter) ve Geliştirme Takımı’ndan oluşmaktadır [1].
Kanban Ekibi’nde Scrum’da olduğu şekilde belirlenen roller yoktur. Yine de çevik
takımlardaki gibi Ürün Sahibi, Kanban Yöneticisi ve Geliştirme Takımı’nın birlikte
Kanban Takımı’nı oluşturması yaygındır [5].
380
1.3 Toplantılar
Scrum çerçevesine göre çevik takımın gerçekleştirmesi gereken tekrarlayan toplantılar
bulunur. Bu toplantılar; Sprint Planlama Toplantısı, Günlük Toplantı (Daily), Sprint
Değerlendirme Toplantısı (Review) ve Sprint İyileştirme Toplantısı’dır (Retrospec-
tive). Çerçevede zorunlu kılınmamakla birlikte Kapsam Boyutlandırma (Grooming &
Sizing / Refining) toplantıları da yapılabilmektedir [4].
Scrum yaklaşımında yazılım geliştirme sürecinde işler birikim listesinde öncelikleri
belli bir şekilde bekler. İşler bu listeden Geliştirme Takımı tarafından çekilir, “Sprint”e
dahil edilir. “Sprint” boyunca “Tamamlanma Kriterleri”ne (Definiton of Done) göre
işlerin anlaşılan tüm adımları tamamlanır. İşlerin bir sprint içerisinde tamamlanabil-
mesi için işlerin yaratacağı değere göre küçük parçalara ayrılması ve önceliklerine göre
sıralanması gerekir. Bu sebeple Scrum için işlerin küçük parçalar haline getirilmesi son
derece önemlidir [5].
Günlük Toplantı
Çevik çerçevelerin önemli bir özelliği iş yapan kişiler arasındaki iletişimi artırmasıdır.
Bunu sağlamanın en Pratik yolu ise Günlük toplantılardır. 15 dakikayı geçmeyen bu
toplantılarda her üye tek tek söz alarak o gün yapacağı işleri ve varsa karşılaştığı engel-
leri tüm takıma iletir. Bu sayede tüm takım her üyenin yapacağı işlerden ve karşılaştığı
engellerden en hızlı şekilde haberdar olur [1].
Kapsam Boyutlandırma Toplantıları
İşlerin küçültülmesi için yaygın olarak uygulanan metot “Kapsam Boyutlandırma”
(“Refining”) toplantılarıdır (Eski adıyla “Grooming & Sizing”). Bu toplantılarda Biri-
kim Listesi’ndeki işlerin bir Sprint’e sığacak kadar küçük hale getirilmesi sağlanır [4].
Kapsam Boyutlandırma toplantılarında yaygın olarak kullanılan yöntem ise “Poker
Planlama” (Planning Poker) metodu ve Hikaye Puanı’dır. Hikaye Puanları genellikle
Fibonacci dizisindeki sayılardan seçilir [9]. Asıl amaç Sprint içinde tamamlanmak
üzere birikim listesinden alınacak işlerin belirli bir büyüklüğün üzerinde olmamasının
sağlanmasıdır. İşin belirli bir büyüklüğün üzerinde olması durumunda ise iş daha küçük
parçalara küçültülür.
Kapsam Boyutlandırma toplantılarında tüm takım yer alır [4]. Takımın adım adım
yaptığı oylama sonrasında ortak bir noktada işin Hikaye Puanı cinsinden büyüklüğü
belirlenmiş olur [4].
1.4 Yazılım Büyüklük Ölçümü ve CFP
Fonksiyonel boyut ölçümü (FSM) bir yazılım sisteminin işlevselliğinin ölçümü olarak
tanımlanabilir. Veri tabanı sistemlerinde bilgi getirme, kaydetme veya arayüzler aracı-
lığı ile harici sistemlerde bilgi yayınlanması bu bahsedilen işlevselliğe örnek olabilir.
FSM Yazılım endüstrisinde Albrecht'in FPA yöntemi ile ilk tanıtımından bu yana kul-
lanılmaktadır. Son 30 yılda orijinal yöntemden başka birçok yöntem de türetilmiştir
[10][11].
381
FSM yöntemlerinden biri olan COSMIC diğer FSM yöntemlerine göre yeni bir yön-
temdir. İlk sürümü 1998 yılında yayınlanmıştır [12].
COSMIC kısaca bir ölçüm sürecidir. Bu süreç üç temel aşamadan oluşur. Bunlar
sırasıyla Ölçüm Stratejisi, Eşleme ve Ölçme aşamalarıdır. Birinci aşamadaki amaç,
kapsam, ayrıntı düzeyi ve işlevsel kullanıcıların belirlenmesidir. Eşleme aşamasındaki
amaç, işlevsel süreçler, veri grupları ve veri özniteliklerinin tanımlanmasıdır. Son aşa-
madaki amaç ise veri hareketlerini tanımlanması ve bir önceki aşamada tanımlanan tüm
fonksiyonel süreçlere ölçüm fonksiyonunun uygulamasıdır [10]. Son aşamanın çıktısı
da CFP (Cosmic Function Point) biriminde kapsamın fonksiyonel büyüklüğüdür [10].
2 Vaka Çalışması
Türkiye’nin en büyük Teknoloji ve İletişim Hizmetleri sağlayıcısı firmalarından biri
yazılım geliştirme süreçlerini çevik yaklaşımlara göre yeniden şekillendirmektedir Bu
çalışma kapsamında ise bu şirketin Dijital Öğrenim Çözümleri üzerinde çalışan bir ürün
geliştirme ekibinin çevik dönüşüm sırasında Hikaye Puanı ve Cosmic İşlev Puan met-
riklerini nasıl kullandığı irdelenmektedir.
2.1 Dijital Öğrenim Çözümleri Ekibi
Dijital Öğrenim Çözümleri alanında yazılım geliştiren takım çevik çerçeveler arasında
Scrum ve Kanban’ı inceledikten Scrum’daki bazı prensipleri de uygulamakla birlikte
Kanban’a karar vermiştir.
Kanban takımı bir Ürün Sahibi, bir Kanban Yöneticisi ve Geliştirme Takımı’ndan
oluşmaktadır.
Geliştirme Takımı üyeleri arasında Teknoloji ve İletişim Hizmet sağlayıcısı şirket per-
soneli analistler, yazılımcılar, şirkete yazılım geliştirme hizmeti sağlayan bir firmanın
çalışanı olan analistler, yazılımcılar ve test uzmanları bulunmaktadır.
Çevik Ekibin bu dönüşüm ile temel hedefleri kaliteyi artırmak, işlerin tamamlanma
süresini düşürmek, yaratılan değeri en yüksek seviyeye çıkarmak ve aynı zamanda ekip
motivasyonunu da üst seviyeye çıkarmaktır. Takım Scrum çerçevesinde bulunan rollere
göre ekibi oluşturmuş, Günlük Rutinleri, Kapsam Boyutlandırma toplantılarını almış,
Kanban’ın Ürün Tamamlanma Süresi Ölçümü, Görselleştirme ve Aktif İş Kısıtı’nı be-
nimsemiştir.
Yapılacak işler önce Ürün Sahibi tarafından Kapsam Boyutlandırma toplantılarına
getirilmekte, bu toplantıda belirlenen seviyenin altında bir küçüklüğü varsa birikim lis-
tesine alınmaktadır. İstasyonların her birinde Aktif İş Kısıtları bulunur. İstasyonlardaki
işler biterek Aktif İş Kısıtında bir boşluk olduğunda ise yeni iş çekilmektedir. Ekibin
istasyonları “Analiz”, “Geliştirme”, “Test”, Kabul Testi” ve “Devreye Alım”dır. Tüm
bu istasyonların ardından işler “Canlı” istasyonuna alınır.
Hikaye Puanı Kullanımı
Takım, Hikaye Puanını Kapsam Boyutlandırma toplantı’larında kullanarak gelen işleri
kısa sürelerde tamamlanabilecek şekilde küçük parçalara ayırmayı hedefler. Bu yüzden
382
takımın belirlediği eşik “20 Hikaye Puanı”dır. 20 Hikaye Puanı’nın üzerindeki işlerin
senaryoları yeniden değerlendirilmeli ve küçültülmelidir.
CFP Kullanımı
Üretim
Takım CFP’yi işin büyüklüğünün ölçümünde kullanmaktadır. CFP işin fonksiyonel bü-
yüklüğünün değerlendirilmesinde uluslararası bir standart olması ile de kendini kanıt-
lamış bir metot olarak üstündür [13]. Çevik ekipler için ise performansın takibinde üre-
tim değeri önemli bir yere sahiptir. Dijital Öğrenim Çözümleri Ekibi de üretimi takip
etmek için CFP değerini kullanır.
Analiz sırasında istenen fonksiyonlar birer kullanım senaryosu halinde tek tek dokü-
mante edilir [14]. Bu sırada fonksiyonel değişiklikler de yazılır ve her senaryonun her
adımı için CFP değerleri belirlenir. Senaryoların CFP değerlerinin toplamı da işin top-
lam CFP değerini gösterir. İşlerin büyüklüğü bu şekilde hesaplanır. Ekip dikkate aldığı
dönem için (bu bir yinelemede takvim ayı da olabilir) canlıya alınan işlerin toplam CFP
değerini toplam üretim miktarı olarak kabul eder.
CFP – Problem Yoğunluk
CFP’nin bir başka kullanım noktası ile kalitenin takibi için CFP – Problem Yoğunluk
metriğidir. Bu metrik, canlı uygulamada geliştirilen üründe bir periyodda ortaya çıkan
problem sayısının üretilen CFP’ye bölünmesidir. Örneğin bir aylık bir sürede ortaya 10
problem çıkıyor ve bu süre içinde 100 CFP’lik bir üretim canlıya alınıyorsa CFP –
Problem Yoğunluk Metriği %10’dur. Bu metriğin en önemli avantajı yapılan işin bü-
yüklüğünü dikkate almasıdır. Üzerinde çalışılan iş ne kadar büyükse o kod parçasından
ortaya çıkacak problem sayısı da o kadar fazla olması beklenir. Üzerinde çalışılan işin
büyüklüğünün belirlenmesinde ise canlıya alınan iş sayısı, kod satır sayısı gibi metrik-
lerdense CFP daha objektif ve geçerlidir. CFP – Problem Yoğunluk metriğinin olumsuz
yanı ise dikkate alınan dönem içerisinde tesadüfen üretim yapılması ya da problem sa-
yısına bağlı olarak metriğin çok düşük ya da çok yüksek değerler alma ihtimalidir. Bu
riski de ortadan kaldırmak için Kümülatif CFP – Problem Yoğunluk metriği dikkate
alınabilir. Bu yeni metriğin tek farkı bir dönem için değil, geçmişten başlayarak (son 6
ay gibi) daha uzun bir dönemi değerlendirmektir. Aylık dalgalanmalar görülmeyecek,
kalitenin gidişatı daha iyi takip edilebilecektir.
Yazılım Geliştirme Hizmet Ödemeleri
Yazılım geliştirme süreçlerinde danışmanlık hak ediş ödemeleri anahtar bir noktadır.
Danışmanlara işe ayırdıkları zamana bağlı olarak ödeme yapılması çok yaygındır ancak
kişilerin fatura kesilen saat boyunca işe ne derece odaklı şekilde çalıştığı her ne kadar
yeni teknolojiler kullanılsa da kesin olarak tespit edilemez. Özellikle danışmanların
uzaktan çalıştığı durumlarda bu konu daha büyük bir sorundur. Çevik yazılım geliş-
tirme ilkeleri güven, iletişim, kalite ve ölçüm gibi değerlere dayanırken uzaktan çalışan
yazılım danışmanlarının ekranlarını izleme ve daha fazla kontrol çabaları bu değerlerle
çelişir. Bu konuda kalıcı çözüm ise danışmana ayırdığı saat cinsinden değil, üretilen
383
çıktı, kalite gibi değerler üzerinden ödeme yapılması olabilir [14]. Üzerinde çalıştığı-
mız Dijital Öğrenim Çözümleri Ekibi de danışmanlara her ay sonunda o ay içerisinde
canlıya alınan işlerin toplam CFP değeri kadar ödeme yapmaktadır. Danışmanlık hiz-
meti içerisinde analiz, geliştirme ve test işlerinde her CFP değerine karşılık gelecek
toplam tutarlar belirlenmiş ve sözleşme ile kayıt altına alınmıştır. Bu sayede danışman
firmada bu konuda çalışan kişi sayısı ve çalışma süresinin yerine yalnızca üretim mik-
tarı dikkate alınmaktadır. Bununla birlikte aşağıda daha detaylı değinilecek olan CFP –
Problem Yoğunluk metriğinin de sözleşmeye bir ceza unsuru olarak dahil edilmesi sa-
yesinde üretimin kalitesi de dikkate alınmıştır.
3 CFP – Hikaye Puanı Karşılaştırması
Hikaye Puanı yazılımın büyüklüğünün ölçümünde nicel bir değer taşıması açısından
CFP ile ortak noktalar barındırmaktadır ve bu yüzden CFP ile Hikaye Puanı karşılaştı-
rılabilir. Hikaye Puanı ve CFP araçlarının faydalı olduğu ve tercih edilebileceği nokta-
lar aşağıdaki tabloda belirtilmiştir:
Tablo 1. CFP – Hikaye Puanı Karşılaştırması
Amaç Hikaye Puanı CFP Açıklama
İş Parçalama Uygun Kısmi Uy- Hikaye Puanı, işin anlık büyüklüğü-
ve Küçültme gun nün belirlenmesinde CFP’ye göre
daha hızlıdır. Ancak kullanıcı hika-
yelerinden CFP olarak tahmini bü-
yüklük öngörülebileceği için anlık
büyüklük belirlemede CFP de kulla-
nılabilir [20].
Planlama Uygun Kısmi Uy- Hikaye Puanı ile kesinlik içermeyen
gun ön tahminleme yapılabilir, CFP’ye
göre Planlama daha fazla zaman ge-
rektirir.
Büyüklük Öl- Kısmi Uygun Uygun İşin büyüklük ölçümünde CFP daha
çümü net ve objektif bir metriktir
İşlerin Karşı- Uygun Değil Uygun Hikaye Puanı öznel ve ekibe özel-
laştırılması dir. Farklı ekiplerin karşılaştırılması
için ancak CFP kullanılabilir.
Yazılım Ge- Uygun Değil Uygun Ekiplerin hikaye puanı üretimler
liştirme Hiz- hem öznel hem de zaman içinde de-
met Satın Al- ğişkendir, CFP ise işin büyüklü-
ması ğünde daha kesindir
Kalite Uygun Değil Uygun CFP aracı kullanılarak CFP – Prob-
lem Yoğunluk değeri hesaplanabilir
ve kalite bu yolla takip edilebilir.
384
4 CFP ile Efor Tahmini
İşin büyüklüğünün ölçümünde ve ekibin üretim miktarının takibinde CFP objektif ve
daha üstün bir metoddur. CFP metodu; işin büyüklüğünü daha iyi tarif ettiğinden işin
yapılması için gerekli zamanı daha iyi tahminleyebilir [16].
Bu bölümde Dijital Öğrenim Çözümleri ekibinin kısıtlı sayıda verisiyile CFP’nin işe
harcanan eforu ne kadar iyi tahmin edebildiğini inceleyeceğiz.
4.1 Örnek Veriler
Tablo 2. İşlerin CFP ve Harcanan Toplam Efor Değerleri
İş CFP Efor (Gün)
1 49 42.7
2 23 34.8
3 10 5.3
4 9 3.4
5 8 18.7
6 7 3.8
7 7 3.3
8 6 12.8
9 6 12.0
10 4 3.5
11 4 2.4
12 3 4.2
Dijital Öğrenim Çözümleri ekibinin 12 örnek işinin CFP büyüklüğü ve tamamlanmış
olan bu işlerin “Tamamlanma Kriterleri”nde Yazan tüm işlerin tamamlanmasının
(Adam Gün) cinsinden Efor karşılığı Tablo 1’de belirtilmiştir. Burada yazılı olan “Gün”
mesai gününü ve her gün için 8 saati ifade etmektedir.
Buna göre listede yer alan en küçük iş 3 CFP büyüklüğündedir ve yapılması gereken
tüm işlemlerin tamamlanması 4.2 adam gün efor almıştır. En büyük iş ise 49 CFP bü-
yüklüğünde bir iştir ve 42.7 adam günlük bir efor harcanmıştır.
4.2 Basit Doğrusal Regresyon Modeli
Dijital Öğrenim Çözümleri ekibinin verilerine dayanarak CFP bilgisiyle Efor tahmini
yapılması için Basit Doğrusal Regresyon Modeli [15] denenmiştir. Basit Doğrusal Reg-
resyon Modeli Efor tahminlenirken her iş için geçerli olan sabit maliyetleri tarif eden
bir β0 değerinden ve CFP arttıkça artan β1 değerinden oluşmaktadır:
Efor = β0 + (β1 * CFP) (1)
385
Eldeki veriler modele uygulandığında β0 = 1.8 ve β1 = 0.92 olarak hesaplanmış ve
eğim, yani β1 ile ilgili p-değeri 0.00014 olarak bulunmuştur . Bu değerler kullanılarak
eldeki veriler tahmin edilmeye çalışıldığında tahminler Tablo 2’de iletilmiştir:
Tablo 3. İşlerin CFP, Harcanan Toplam Efor ve Tahmin Edilen Toplam Efor Değerleri
İş CFP Efor (Gün) Tahmin
1 49 42,7 46,8
2 23 34,8 22,9
3 10 5,3 11,0
4 9 3,4 10,1
5 8 18,7 9,2
6 7 3,8 8,2
7 7 3,3 8,2
8 6 12,8 7,3
9 6 12,0 7,3
10 4 3,5 5,5
11 4 2,4 5,5
12 3 4,2 4,6
Modelin R2 [15] değeri 0,7809 olarak gerçekleşmiştir. Yalnızca bu verilere bakıldı-
ğında CFP’nin efor tahminlemesini gösteren modelin gücünün yüksek olduğu görül-
mektedir.
Dijital Öğrenim Çözümleri CFP ve Efor Bilgileri
60,0
40,0
20,0
0,0
1 2 3 4 5 6 7 8 9 10 11 12
Efor (Gün) CFP
Şekil. 1. Dijital Öğrenim Çözümleri CFP ve Efor Bilgileri Görseli
4.3 Basit Doğrusal Regresyon Modelinin Değerlendirmesi
Model R Square değeriyle güçlü görünmekle birlikte veriler bir grafiğe yansıtıldığında
verilerin farklı açılardan da incelenmesi gerektiği görülmektedir.
386
Dijital Öğrenim Çözümleri
50
40
Efor (Gün)
30
20
10
0
0 10 20 30 40 50 60
CFP
Şekil. 2. İşlerin Efor ve CFP Eksenlerinde Dağılımı
Bu grafikte Dijital Öğrenim Çözümleri ekibinin verileri Efor ve CFP değerleriyle
görünmektedir. Grafik, doğrusal bir regresyon modelinin tam olarak uygun olmadığı
şeklinde yorumlanabilir. Bunun yerine iki ayrı veri grubu ve dolayısıyla iki ayrı mode-
lin bulunması grafikle daha fazla örtüşmektedir.
Veriler grafikteki çizgilerine göre gruplandıklarında aşağıdaki şekilde 2 ayrı mo-
delde görselleştirilebilir.
Gruplanmış Veriler
50
Grup 2
40
Efor (Gün)
30
20
10 Grup 1
0
0 10 20 30 40 50
CFP
Şekil. 3. Veriler gruplandığında iki ayrı tahmin modelinin geçerli olma ihtimali ortaya çıkıyor
Verilerin gruplanması halinde iki ayrı modele daha fazla uyduğu tespit edilmiştir.
İlk grup basit doğrusal bir modele uymaktadır.
Efor = β0 + (β1 * CFP) (2)
β0 = 1.7 ve β1 = 0.2795; β1 için p-değeri 0.09 olarak bulunmuştur.
İkinci grup ise doğrusal olmayan bir regresyon modeli ile uyumluluk göstermektedir.
Burada test edilen model:
Efor = (β0 * CFP) /(β1 + CFP) (3)
β0 = 64.2943 ve β1 = 22.6662; β0 ve β1 için p-değerleri sırasıyla 0.0009 ve 0.012
olarak bulunmuştur.
387
Bununla beraber verilerin bu şekilde gruplanmasına yol açabilecek bir özellik tespit
edilmemiştir. Ancak bu iki modelden ilki CFP değeri ile eforun doğrusal bir ilişki içinde
olduğu, yani her birim CFP için eforun aynı oranda arttığı işlere (örneğin dair eforu
tahmin etmek için daha uygun olabilecekken ikinci model CFP değeri arttıkça karşılık
gelen eforun azalarak arttığı (adeta bir öğrenme etkisinin olduğu) işler (örneğin yazı-
lımcının daha önce üzerinde çalışmadığı bir teknoloji) için gerekli eforu tahmin etmekte
daha başarılı olabileceğini göstermektedir. Ancak veri sayısı çok az olduğu için, mo-
dellerin yeterliliği hakkında kesin yargılara varmak pek mümkün değildir. Veri azlığı,
analizlerimizde iki önemli açık nokta bulunmasına yol açmıştır. Öncelikle modeller ve-
riye en iyi uyan modeller olarak seçilmiş, tahmin performansları test edilememiştir.
İkinci olarak da olası tüm CFP-efor ilişkilerinin sadece yukarıda öne sürülen iki tip
modelle açıklanması mümkün olmayabilir. Veriler arttıkça belki üçüncü (hatta daha da
fazla) tipte CFP-efor ilişkisinin de ortaya çıkması olasıdır. Özetle, yapılması gereken
daha fazla CFP-efor ikilisi değerine ulaşmak ve öne sürülen bu iki modeli kulanarak,
elde edilen yeni veri ikililerinin CFP değeri ile değerlendirip, karşılık gelen efor değe-
rini tahminlemektir. Bu sayede modellerin tahmin performansları da test edilmiş ola-
caktır. Ayrıca artan veri ile birlikte üçüncü (ya da daha fazla) CFP-efor ilişki tipinin
ortaya çıkıp çıkmayacağı da gözlemlenebilecektir.
Sonuçta Dijital Öğrenim Çözümleri ekibinin 12 adet verisinin CFP bilgisiyle Efor iliş-
kisi basit doğrusal regresyon modeliyle matematiksel olarak güçlü bir şekilde ifade
edilse deŞekil. 2 ve Şekil. 3’e bakıldığında, henüz ortaya konmamış başka parametre-
lerle incelemelerin devam etmesi gerekliliği ortaya çıkmaktadır.
5 Sonuç
Çevik prensiplerle çalışan ekipler için işlerin büyüklüklerini ölçebilmek hem işleri kü-
çültebilmek hem de yapılan işi değerlendirmek ve iyileştirme noktalarını görebilmek
için oldukça önemlidir. İki amaç için de Hikaye Puanı ve CFP bazı açılardan benzeyen
ve bu yüzden kıyaslanan metriklerdir. Sıklıkla CFP’nin Hikaye Puanı’nı ikame edeceği
ve yalnızca CFP’ye yer verilecek örnekler üzerinden değerlendirmeler yapılır.
Bu çalışmada Türkiye’nin en büyük teknoloji ve iletişim hizmetleri sağlayıcı firmala-
rından birinin Scrum ve Kanban’ın önemli ilkelerini benimseyerek uyguladığı yazılım
geliştirme sürecinde hem Hikaye Puanı hem de CFP kullanımının olumlu bir örneği
incelenmiştir. Çevik takım, Hikaye Puanını özellikle çok hızlı bir araç olması sebebiyle
işleri parçalayıp küçültürken; CFP’yi ise işin büyüklüğünün tespitinde, kalite takibinde
ve dış kaynak ödemelerinde kullanmaktadır. Özetle, çevik çerçeve ile çalışan takımla-
rın hem Hikaye Puanı hem de CFP ile çalışması mümkündür.
Çevik yazılım geliştirirken hem planlama hem de maliyet yönetimi açılarından bir
işe ne kadar efor harcanacağı ve işin ne zaman tamamlanacağı bilgilerine ihtiyaç du-
yulmaktadır. CFP işin büyüklüğünü net şekilde ortaya koysa da CFP ile maliyet ve
tamamlanma süreleri arasında bir ilişki kurulması gerekmektedir.
Bu ilişkinin incelenmesi için Dijital Öğrenim Çözümleri Ekibi’nin 12 adet verisin-
deki CFP değeri ve işe harcanan toplam efor kullanılarak basit doğrusal regresyon mo-
deli kurgulanmış; doğrusal model matematiksel olarak güçlü görünse de, iyi bir tahmine
388
ulaşmak için daha fazla veriye ve belki daha fazla indikatöre (kullanılan teknoloji türü
gibi) ihtiyaç duyulduğu ortaya çıkmıştır.
Yazılım geliştirme süreçlerinde; yapılacak çalışmanın yeni olup olmaması, çalış-
mayı yapacak kişilerin uzmanlık seviyesi, kullanılan teknolojiler, işin tamamlanana ka-
dar ekip içi veya ekip dışı sebeplerle ne kadar bloklandığı, Kanban gibi bir çerçeve
kullanılıyorsa kuyrukta bekleyen iş sayısı ve kuyruk yönetimi, işin önceliği gibi pek
çok sayıda etken hem işe harcanan toplam efor hem de işin tamamlanma süresini
önemli ölçüde etkilemektedir. Daha fazla veri ve bu etkenlerin de dikkate alınmasıyla
büyüklüğü belirlenmiş işler için hem toplam eforun hem de toplam tamamlanma süre-
lerinin daha güçlü modellerle tahminlenmesi mümkündür. Gelecekte veri kümesi bü-
yüdüğünde daha ileri modeller oluşturulup test edilmesi planlanmaktadır.
Kaynaklar
1. Scrum Page, https://www.agilealliance.org/glossary/scrum/, erişim tarihi 2017/08/10.
2. Kanban Page, https://www.agilealliance.org/glossary/kanban/, erişim tarihi 2017/08/10.
3. VersionOne 11th annual state of agile development survey results, https://explore.versio-
none.com/state-of-agile/versionone-11th-annual-state-of-agile-report-2, erişim tarihi
2017/08/10.
4. Scrum Page, http://www.scrumguides.org/scrum-guide.html, erişim tarihi 2017/08/10.
5. Kniberg, H., Skarin, M.: Kanban and Scrum making the most of both. Managing Editor:
Diana Plesa. Enterprise software development series. InfoQ. USA (2010) ISBN 978–0–557–
13832–6.
6. Sugimori, Y., Kusunoki, K., Cho, F., Uchikawa, S.: Toyota Production system and Kanban
system: Materialisation of just-in-time and respect-for-human system. Int. J. Prod. Res.
15(6), 553-564 (1977).
7. Christopher, M.: The Agile Supply Chain: Competing in Volatile Markets. Industrial Mar-
keting Management. 29(1), 37-44 (2000).
8. Anderson, D.: Kanban: Successful Evolutionary Change for Your Technology Business.
Sequim, Washington: Blue Hole Press (2010).
9. Tamrakar, R., Jorgensen, M.: Does the use of Fibonacci numbers in planning poker affect
effort estimates?. In Proceedings of 16th International Conference on Evaluation and As-
sessment in Software Engineering, pp. 228-232. (2012).
10. Bağrıyanık, S., Karahoca, A., Ersoy, E.: Selection of a functional sizing methodology: A
telecommunications company case study. Global Journal on Technology 7, 98–108 (2015).
11. Albrecht, A., J., Gaffney, J., E.: Software Function, Source Lines of Code, and Development
Effort Prediction: A Software Science Validation. IEEE Transactions on Software Enginee-
ring, SE-9(6), 639 – 648 (1983).
12. Common Software Measurement International Consortium. The COSMIC Functional Size
Measurement Method Version 4.0.1 Measurement Manual, https://cosmic-sizing.org/publi-
cations/measurement-manual-401/, erişim tarihi 2017/08/09.
13. Bağrıyanık, S., Karahoca, A.: Automated COSMIC Function Point measurement using a
requirements engineering ontology. Information & Software Technology 72, 189-203
(2016).
14. Salmanoğlu, M., Öztürk, K., Bağrıyanık, S., Ungan, E., Demirörs, O.: Benefits and Challen-
ges of Measuring Software Size: Early Results in a Large Organization. IWSM MENSURA
(2015).
389
15. Freedman, David A.: Statistical models: theory and practice. Cambridge University Press
(2009).
16. Commeyne, C., Abran, A., Djouab, R.: Effort Estimation with Story Points and COSMIC
Function Points – An Industry Case Study (2016).
17. Fehlmann, T., Santillo, L.: From Story Points to COSMIC Function Points in Agile Software
Development – A Six Sigma perspective (2010).
18. Ungan, E., Çizmeli, N., Demirörs, O.: Comparison of Functional Size Based Estimation and
Story Points, Based on Effort Estimation Effectiveness in Scrum Projects. (2014).
19. Desharnais, J., Kocaturk, B., Buglione, L.: Improving Agile Software Projects Planning
Using the COSMIC Method. (2011).
20. Common Software Measurement International Consortium. The COSMIC Functional Size
Measurement Method Version 3.0.1 Guideline for the use of COSMIC FSM to manage
Agile projects, http://www.cosmicon.com/portal/pub-
lic/COSMIC_Agile_Projects_Guideline_v10.pdf , erişim tarihi 2017/09/09.
390