Çevik Yöntemlerde Cosmic İşlev Puanı ve Hikaye Puanının Birlikte Kullanımı

Abstract

Ö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 ekiplerin 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ı irdelenmiştir. Sonuç olarak SP metriğinin kapsam boyutlandırma toplantıları sırasında kullanıcı hikayelerinin çevik mantıkla uygun kapsam büyüklüğüne bölünmesinde 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 verdiğ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.

-

Using Cosmic Funcion Points and Story Points Together in Agile Frameworks 1

Giriş Çevik Çerçeveler günümüzde yazılım sektöründe yaygın olarak kullanılmaktadır. Çevik Ç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ğerlendirilebilmesi 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 metrik 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 sezgisel olarak hesaplanması nedeni ile uygulayıcılar arasında yanlış anlamalara ve niceliksel 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ı noktaları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.

Takımın benimsediği prensipler, roller ve CFP hakkında genel bilgiler aşağıda verilmiş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ı hedefleyen 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ş bulunduğ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 üyelerince 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. Genellikle 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ş bulunabilir. 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 Master) 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 ]. 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 (Retrospective). Ç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 tamamlanabilmesi 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ığı engelleri 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 Birikim 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 kullanılmaktadır. Son 30 yılda orijinal yöntemden başka birçok yöntem de türetilmiştir [ 10 ][ 11 ].

FSM yöntemlerinden biri olan COSMIC diğer FSM yöntemlerine göre yeni bir yöntemdir. İ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şamadaki 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 metriklerini 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 personeli 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ı benimsemiş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 listesine 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

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ıtlamış bir metot olarak üstündür [ 13 ]. Çevik ekipler için ise performansın takibinde üretim 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 toplam 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 metriklerdense 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 sayı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 çı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 hizmeti 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 miktarı 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 sayesinde ü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 noktalar aşağıdaki tabloda belirtilmiştir:

Tablo 1. CFP – Hikaye Puanı Karşılaştırması Amaç İş Parçalama ve Küçültme

Hikaye Puanı CFP

Açıklama

Uygun

Kısmi Uygun Kısmi Uygun

Hikaye Puanı, işin anlık büyüklüğünün belirlenmesinde CFP’ye göre daha hızlıdır. Ancak kullanıcı hikayelerinden CFP olarak tahmini büyüklük öngörülebileceği için anlık büyüklük belirlemede CFP de kullanılabilir [20].

Hikaye Puanı ile kesinlik içermeyen ön tahminleme yapılabilir, CFP’ye göre Planlama daha fazla zaman gerektirir. İşin büyüklük ölçümünde CFP daha net ve objektif bir metriktir Hikaye Puanı öznel ve ekibe özeldir. Farklı ekiplerin karşılaştırılması için ancak CFP kullanılabilir. Ekiplerin hikaye puanı üretimler hem öznel hem de zaman içinde değişkendir, CFP ise işin büyüklüğünde daha kesindir CFP aracı kullanılarak CFP – Problem Yoğunluk değeri hesaplanabilir ve kalite bu yolla takip edilebilir. Planlama

Uygun

Büyüklük Ölçümü İşlerin Karşılaştırılması Yazılım Geliştirme Hizmet Satın Alması Kalite

Kısmi Uygun

Uygun Değil

Uygun

Uygun

Uygun Değil

Uygun

Uygun Değil

Uygun

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 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 Regresyon 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)

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

Dijital Öğrenim Çözümleri CFP ve Efor Bilgileri 1 2 3 4 5 6 Efor (Gün) 7

8 CFP 9 10 11 12 Ş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. Grup 2 Grup 1

Dijital Öğrenim Çözümleri 0 10 20 40 50

60 30

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ı modelin bulunması grafikle daha fazla örtüşmektedir.

Veriler grafikteki çizgilerine göre gruplandıklarında aşağıdaki şekilde 2 ayrı modelde görselleştirilebilir.

Gruplanmış Veriler 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. 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, modellerin 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 veriye 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ğerini tahminlemektir. Bu sayede modellerin tahmin performansları da test edilmiş olacaktı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 parametrelerle 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ı firmaları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ımları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ç duyulmaktadı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 verisindeki CFP değeri ve işe harcanan toplam efor kullanılarak basit doğrusal regresyon modeli kurgulanmış; doğrusal model matematiksel olarak güçlü görünse de, iyi bir tahmine 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 kadar 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ürelerinin 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 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/public/COSMIC_Agile_Projects_Guideline_v10.pdf , erişim tarihi 2017/09/09.

References

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.versionone. 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 Marketing 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 Assessment 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 Engineering , 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/publications/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 Challenges of Measuring Software Size: Early Results in a Large Organization . IWSM MENSURA ( 2015 ).