Scrum Yöntemi Yapı Elemanlarının CMMI Seviye 2 Gereklerine Eşlenmesi: Bir Vaka Çalışması

Abstract

This paper presents the gap analysis stage of the software process improvement effort of a technology company developing remote monitoring systems and embedded software for heavy machinery exports. The company had to determine whether they can meet the requirements of CMMI Level 2 practically to satisfy their main contractor's software quality requirements without investing in building a new CMMI-based quality management system from scratch. The mapping study and gap analysis results proved that the Scrum-based software development processes of a software organization could satisfy most requirements of the CMMI Level 2 practically.

Keywords

• Software Engineering
• Software Process Improvements
• Agile Methodologies
• Scrum
• CMMI
• Small Software Development Organizations

Giriş

Entegre Yetenek Olgunluk Modeli (ing, CMMI – Capability Maturity Model Integration), müşteri memnuniyetini ve ürün kalitesini arttırmak, düzeltme maliyetlerini azaltmak ve proje planlarındaki gecikmeleri önlemek amacıyla özellikle ana yüklenici rolünü oynayan büyük yazılım organizasyonları tarafından yaygın olarak benimsenmiş referans modellerden birisidir. CMMI, ürün yaşam döngüsünü içeren hangi geliştirme ve bakım aktivitelerinin uygulanacağını gösteren en iyi pratiklerden oluşur [1]. Ancak, küçük yazılım organizasyonlarının CMMI gereklerini sağlaması maliyet ve zaman açısından ciddi yatırım gerektirmektedir. Bu tür organizasyonlar, geliştirmekte oldukları yazılım projelerinin açığa çıkan değişikliklere hızla adapte olabilme yeteneklerini, proje kalitesini, proje üretkenliğini ve rekabetçi ortamda geliştirdikleri yazılım uygulamalarının pazara çıkma hızını arttırmak amacıyla çevik yazılım geliştirme yöntemlerini benimsemektedirler.

Küçük ve orta ölçekli yazılım organizasyonlarının büyük çaplı ana entegratör şirketlere alt yüklenici olarak global pazarlarda yer alabilmeleri için, CMMI gereksinimlerini karşılayan ayrı bir kalite sistemi kurmak yerine, çevik yazılım geliştirme yöntemleri arasında daha yapısal ve disiplinli kabul edilen ve aynı zamanda kullanımı en yaygın olan [ 2 ] Scrum’ın eksiklerini tamamlamaları birçok açıdan avantaj sağlayacaktır.

Bu bildiride, yurtdışına ihraç edilen iş makinaları için gömülü yazılımlar ve uzaktan takip yazılımları geliştiren bir teknoloji şirketi içerisinde küçük organizasyon özelliklerini barındıran bir yazılım grubunun süreç iyileştirme çabasının boşluk analizi aşaması takdim edilmektedir. CMMI Seviye 2’ye ait yedi süreç alanının gereksinimleri ile Scrum çerçevesini oluşturan öğeler arasında bir eşleştirme oluşturarak ve boşluk analizi yaparak, Scrum kullanan bir organizasyonun tanımlı süreçlerinin CMMI Seviye 2 gereksinimlerini pratik bir şekilde sağlayabileceği gösterilmektedir.

Bildirinin bundan sonraki bölümleri şu şekilde düzenlenmiştir. Bölüm 2’de bu alanda yapılan diğer çalışmalardan bahsedilmiştir. Bölüm 3’de vaka çalışmasının metodolojisi tanıtılmıştır. Bölüm 4’de Scrum yöntemini oluşturan öğeler ile CMMI Seviye 2 Süreç Alanlarının gereksinimleri arasında oluşturulan eşleştirme ve boşluk analizi sonuçları verilmiştir. Son bölümde sonuçlar özetlenerek değerlendirilmiştir. 2

İLGİLİ ÇALIŞMALAR Literatürde çevik yöntemlerden ve Scrum’dan başlayarak CMMI gereklerinin karşılanabileceğine yönelik teorik ve pratik çalışmalar mevcuttur. Bu çalışmalar, bizim bu konudaki öngörümüzü destekler niteliktedir.

Vriens [ 3 ] yazılım geliştirme sürecinde XP ve Scrum çevik yöntemleri birlikte kullanıldığında CMM Seviye 2 gereksinimlerinin karşılanabileceğini göstermiştir. Kahkönen ve Abrahamsson [ 4 ] yapmış oldukları çalışmada XP çevik yönteminin pratikleri kullanılarak gerçekleştirilen yazılım geliştirme süreçlerinin CMMI yazılım süreç iyileştirme metodunun gereksinimlerini karşıladığını deneysel olarak kanıtlamışlardır. Pikkarainen ve Mantyniemi [ 5 ] CMMI çerçevesinin Proje Planlama ve Gereksinim Yönetimi süreç alanlarındaki özel amaçlar ( ing, Specific Goals - SG) ile çevik yöntemler arasındaki ilişkiyi göstermek amacıyla bir eşleştirme çalışması yapmışlar ve çalışmalarını da deneysel olarak desteklemişlerdir.

Scrum alanında yapılan çalışmalardan, Sutherland ve arkadaşları [ 6 ] ile Jakobsen ve arkadaşları [ 7,8 ] tarafından yapılan çalışmalarda Scrum çevik yöntemi ile CMMI 5 gereksinimleri arasındaki ilişkiler gösterilmektedir. Machic ve Zabkar [ 9 ] CMMI ölçüm ve analiz pratiklerinin Scrum tabanlı yazılım geliştirme süreciyle birlikte nasıl uygulanabileceğini gösteren bir çalışma yapmışlardır. Pikkarainen ve Mantyniemi [ 5 ] tarafından yapılan eşleştirme çalışmasından yola çıkan Marcal ve arkadaşları [ 10 ], CMMI Proje Yönetimi süreç alanları ve Scrum pratikleri arasında daha detaylı bir eşleştirme çalışması yapmışlardır. Ancak bu çalışma deneysel olarak desteklenmemektedir. CMMI olgunluk seviyesi 2 ve 3’de tanımlı süreç alanlarının özel pratikleri için CMMI süreç alanları ile Scrum arasındaki ilişkileri belirleyen diğer bir çalışma ise Potter ve Sakry [ 11 ] tarafından yapılmıştır. 3

METODOLOJİ

Hedef organizasyon için mümkün olan en kısa süre içerisinde ve yazılım organizasyonu içerisinde geliştirilmekte olan mevcut projeleri sekteye uğratmadan CMMI Seviye 2 gereklerinin sağlanması hedeflemiştir. Bu çalışmada kullanılan metodoloji Brereton [ 12 ] tarafından tanımlanan kılavuz yönergelere uygun olarak tasarlanmıştır (Şekil 3.1).

Şekil 3.1. Çalışma Metodolojisi 3.1

Analiz Çalışması Öncelikle CMMI Seviye 2’de tanımlı süreç alanlarına ait en iyi pratikler ve Scrum yöntemi yapı elemanları arasında bir eşleştirme oluşturmak için detaylı bir analiz çalışması gerçekleştirilmiştir. Aşağıda belirtilen araştırma sorusu oluşturulmuş ve bu araştırma sorusun çerçevesinde CMMI Seviye 2 ile Scrum arasındaki ilişki araştırılmıştır.

Araştırma Sorusu: Scrum öğeleri CMMI Seviye 2 gereksinimlerine nasıl eşlenir? Yazılım organizasyonunda tanımlı süreçlerin mevcut durumunu ve yol haritasını belirlemek amacıyla öncelikle yaklaşık iki ay süren detaylı bir mevcut durum/boşluk analizi gerçekleştirilmiştir. 3.2

Alan Prosedürü ve Veri Toplama Mevcut durum/boşluk analizi çalışmaları sırasında gerekli olan veri mülakat yöntemi kullanılarak toplanmıştır. Bu bulgulardan yola çıkılarak CMMI Seviye 2 süreç alanlarına ilişkin gereksinimlerin Scrum pratikleri ile nasıl karşılanacağı ve uygulanacağına dair süreç iyileştirme ekibiyle beyin fırtınası yapılarak eşleştirme tabloları çıkarılmıştır. 3.3

Mevcut Durum/Boşluk Analizi Yazılım organizasyonunda yer alan üst yönetim, kalite yöneticisi ve teknik yöneticilerle yapılan toplantılar sırasında SCAMPI C [ 13 ] yöntemi referans alınarak ve mülakat yöntemi ile gerçekleştirilen mevcut durum/boşluk analizinde CMMI Seviye 2’de tanımlı her bir süreç alanı için aşağıda belirtilen üç kriterin olup olmadığı kontrol edilmiştir: • Yazılım süreci dokümante edilmiş mi? • Dokümante edilmiş olmasına bakılmaksızın belli bir yazılım süreci tutarlı olarak uygulanıyor mu? • Yazılı olan veya olmayan yazılım sürecinin çıktıları kayıt altına alınmış mı? Tablo 3.1. CMMI Seviye 2’de Tanımlı Süreç Alanlarına Ait Özel Pratikler için Elde Edilen Ortalamalar

Süreç Alanı

Proje Planlama Proje İzleme ve Kontrol Konfigürasyon Yönetimi Gereksinim Yönetimi Süreç ve Ürün Kalite Güvence Ölçüm ve Analiz

Uygulanan Süreçler %21 %39 %61 %56 %38 %3

Belgelenen Süreçler %0 %4 %0 %18 %0 %0

Nesnel Kanıt %4 %38 %50 %68 %28 %0

Her bir süreç alanı için elde edilen sonuçların yüzdeleri Tablo 3.1’de özetlenmiştir. Elde edilen sonuçlara göre CMMI Seviye 2’de tanımlı süreç alanlarına karşılık gelen kurumsal süreçlerin genelde tam dokümante edilmediği halde pratikte uygulandığı, ancak uygulamalardan beklenen ara çıktıların genelde üretilmediği belirlenmiştir. 4

CMMI SEVİYE 2 SÜREÇ ALANLARININ SCRUM

PRATİKLERİ İLE EŞLEŞTİRİLMESİ CMMI-DEV versiyon 1.3 [ 14 ]’ de tanımlanan basamaklı gösterim göz önünde bulundurularak Scrum’ da tanımlı öğelerin CMMI Seviye 2’de tanımlı her bir süreç alanındaki özel pratikleri ne derece karşıladığını belirlemek için bir karşılama derecesi (Tablo 4.1) oluşturulmuş ve bu kriterlere göre özel pratiklerin ne derece karşılandığı belirlenmiştir.

Karşılama Derecesi

TK Tamamen Karşılanmıştır KK Kısmen Karşılanmıştır HK

Hiç Karşılanamamıştır

Tablo 4.1. Pratiklerin Derecelendirme Kriterleri

Kriter

Pratik, Scrum ile tamamen ele alınmış Pratiği yerine getirmek için Scrum’ da bazı tanımlamalar yapılmış Ancak pratik, Scrum ile tam olarak karşılanmamaktadır.

Pratik, Scrum’da hiç ele alınmamış

Derecelendirme aşaması tamamlandıktan sonra, CMMI Seviye 2’de tanımlanan her bir süreç alanı için o süreç alanında tanımlı pratiklerin karşılanma yüzdeleri aşağıdaki formül kullanılarak hesaplanmıştır:

Karşılanma yüzdeleri hesaplandıktan sonra her bir süreç alanına ait karşılanma yüzdeleri için bir grafik oluşturulmuş, sonuçlar gruplanmış ve CMMI Seviye 2 süreç alanlarının Scrum pratikleri ile eşleştirilmesini gösteren bir genel görüş oluşturulmuştur. Proje Planlama Süreç Alanı’nda üç adet özel amaç ve bu özel amaçları yerine getirmek amacıyla tanımlanan on dört özel pratik mevcuttur. Bu pratiklerin her birinin Scrum pratikleri ile nasıl karşılandığını gösteren eşleştirme çalışması Tablo 4.2’de, değerlendirme sonuçları ise Şekil 4.1’de verilmiştir.

Oyun öncesi fazı, ürün iş listesi, Sprint iş listesi, hikâye puanları, Sprint planlama, tişört bedeni Hikâye puanları, kullanıcı hikâyeleri, Sprint planlama, sürüm planlama Oyun öncesi fazı, Scrum süreci Hikâye puanları, Sprint planlama, tişört bedeni KO TK TK TK KK KK KK HK TK TK Sprint iş listesi, Sprint planlama Sprint iş listesi, kullanıcı hikayeleri, Sprint planlama TK TK 3.3. Plan Taahhüttü Edinilmesi 3.2. İş ve Kaynak Seviyelerinin

Mutabık Kılınması 3.1. Projeyi Etkileyen Planlarının

Gözden Geçirilmesi 2.7. Proje Planının Oluşturulması 2.6. Paydaş Katılımının

Planlanması 2.5. Gerekli Bilgi ve Yetkinliklerin

Planlanması 1.1 Proje Kapsamının Tahmin

Edilmesi 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 2.4. Proje Kaynaklarının

Planlanması

1.2. İş Ürünü ve Görev Özniteliklerinin Tahmin Edilmesi 1.3. Proje Yaşam Döngüsü'nün

Tanımlanması 1.4. Efor ve Maliyet Tahminlerinin Belirlenmesi 2.1. Bütçe ve Takvimin

Oluşturulması 2.2. Proje Risklerinin

Belirlenmesi 2.3. Veri Yönetiminin

Planlanması Şekil 4.1. Proje Planlama Süreç Alanı’na ait Değerlendirme Sonuçları 4.2

Proje İzleme ve Kontrol Süreç Alanının Eşleştirilmesi Proje İzleme ve Kontrol Süreç Alanı’nda iki adet özel amaç ve bu amaçları gerçekleştirmek için tanımlanmış on özel pratik mevcuttur. Bunların Scrum pratikleri ile nasıl karşılandığını gösteren eşleştirme çalışması Tablo 4.3’de, değerlendirme sonuçları ise Şekil 4.2’de verilmiştir.

Tablo 4.3. CMMI-SCRUM Proje İzleme ve Kontrol Süreç Alanı Eşleştirme Tablosu

CMMI SCRUM Özel Özel Pratikler Karşılayan Pratikler Amaçlar

e m e l z İ e r ö G a n a l P i y e j o r P . 1 1.1. Proje Planlama Parametrelerinin İzlenmesi 1.2. Taahhütlerin İzlenmesi 1.3. Proje Risklerinin İzlenmesi 1.4. Veri Yönetiminin İzlenmesi 1.5. Paydaş Katılımının İzlenmesi 1.6. İlerleme Gözden Geçirmelerinin Yapılması Ürün iş listesi, Günlük Scrum, Sprint değerlendirme, Sprint retrospektif, aşağı-tüketim grafikleri Ürün iş listesi, Sprint iş listesi, Günlük Scrum, Sprint planlama, Sprint değerlendirme, Sprint retrospektif, aşağı-tüketim grafikleri Günlük Scrum, Sprint planlama, Sprint retrospektif, engel günlüğü/listesi, beyaz tahtalar, sunumda kullanılan büyük yazı kâğıtları

Günlük Scrum, Sprint planlama Günlük Scrum, Sprint planlama, Sprint değerlendirme, Sprint retrospektif, sürüm planlama, aşağıtüketim grafikleri, görev tahtası

KO KK TK KK HK TK TK 2.3. Düzeltici Eylemlerin

Yönetilmesi 2.2. Düzeltici Eylemlerin

Alınması 1.2. Taahhütlerin İzlenmesi

1.3. Proje Risklerinin İzlenmesi 2.1. Sorunların Analiz Edilmesi

1.4. Veri Yönetiminin İzlenmesi 1.7. Kilometre-taşı Gözden Geçirmelerinin Yapılması 1.5. Paydaş Katılımının İzlenmesi e k m li t e e n n ö ö aY iY y em am ly t E a i ap i c t K l

e .2 zü

D 1.7. Kilometre-taşı Gözden Geçirmelerinin Yapılması 2.1. Sorunların Analiz Edilmesi 2.2. Düzeltici Eylemlerin Alınması 2.3. Düzeltici Eylemlerin Yönetilmesi

Sprint değerlendirme, sürüm gözden geçirme Günlük Scrum, Sprint retrospektif, engel günlüğü/listesi, beyaz tahtalar, sunumda kullanılan büyük yazı kâğıtları Günlük Scrum, Sprint retrospektif, görev tahtası, engel günlüğü/listesi, beyaz tahtalar, sunumda kullanılan büyük yazı kâğıtları Günlük Scrum, Sprint retrospektif, görev tahtası, engel günlüğü/listesi, beyaz tahtalar, sunumda kullanılan büyük yazı kâğıtları 1.1. Proje Planlama Parametrelerinin İzlenmesi 1 0,8 0,6 0,4 0,2 0 1.6. İlerleme Gözden

Geçirmelerinin Yapılması Tablo 4.4. CMMI-SCRUM Konfigürasyon Yönetimi Süreç Alanı Eş leştirme Tablosu TK KK KK

KO HK KK KK TK TK HK KK pratikleri ile nasıl karşılandığını gösteren eşleştirme çalışması Tablo 4.5’de, değerlendirme sonuçları ise Şekil 4.4’de verilmiştir.

Tablo 4.5. CMMI-SCRUM Gereksinim Yönetimi Süreç Alanı Eşleştirme Tablosu

CMMI Özel Amaçlar

1.4. Gereksinimlerin Çift Yönlü İzlenebilirliğinin Sağlanması 1.3. Gereksinim Değişikliklerinin

Yönetilmesi Şekil 4.4. Gereksinim Yönetimi Süreç Alanı’na ait Değerlendirme Sonuçları 4.5

Ölçüm ve Analiz Süreç Alanının Eşleştirilmesi Ölçüm ve Analiz Süreç Alanı’nda tanımlı iki adet özel amaç ve bu özel amaçları yerine getirmek için tanımlanmış sekiz adet özel pratik mevcuttur. Bu özel pratiklerin Scrum pratikleri ile nasıl eşleştiği Tablo 4.6’da, detaylı sonuçlar ise Şekil 4.5’de verilmiştir.

Tablo 4.6. CMMI-SCRUM Ölçüm ve Analiz Süreç Alanı Eşleştirme Tablosu

CMMI Özel Amaçlar

2.1. Ölçüm Verilerinin Edinilmesi 2.2. Ölçüm Verilerinin Analiz Edilmesi ması 2.3. Verilerin ve Sonuçların Saklan2.4. Sonuçların İletilmesi

SCRUM

Karşılayan Pratikler

Ürün iş listesi, Sprint iş listesi, hikâye puanları, kullanıcı hikâyeleri, aşağı-tüketim grafikleri, hız grafiği Günlük Scrum, Sprint planlama, Sprint değerlendirme, Sprint retrospektif Günlük Scrum, Sprint planlama, Sprint değerlendirme, Sprint retrospektif, aşağı-tüketim grafikleri, hız grafiği Günlük Scrum, Sprint planlama, Sprint değerlendirme, Sprint retrospektif, aşağı-tüketim grafikleri, hız grafiği KO HK KK HK KK KK KK HK

KK 1.1. Ölçüm Hedeflerinin

Oluşturulması 1 0,5

0 2.4. Sonuçların İletilmesi

1.2 Ölçümlerin Belirlenmesi 2.3. Verilerin ve Sonuçların

Saklanması 1.3. Veri Toplama ve Saklama

Prosedürlerinin Belirlenmesi 2.2. Ölçüm Verilerinin Analiz

Edilmesi 1.4. Analiz Prosedürlerinin

Belirlenmesi 2.1. Ölçüm Verilerinin Edinilmesi Şekil 4.5. Ölçüm ve Analiz Süreç Alanı’na ait Değerlendirme Sonuçları 4.6

Süreç ve Ürün Kalite Güvence Süreç Alanının Eşleştirilmesi Süreç ve Ürün Kalite Güvence Süreç Alanı’nda tanımlı iki adet özel amaç ve bu özel amaçları yerine getirmek için tanımlanmış dört adet özel pratik mevcuttur. Bu pratiklerin nasıl karşılandığını gösteren eşleştirme çalışması Tablo 4.7’de, değerlendirme sonuçları ise Şekil 4.6’da verilmiştir.

Tablo 4.7. CMMI-SCRUM Süreç ve Ürün Kalite Güvence Süreç Alanı Eşleştirme Tablosu

CMMI Özel Amaçlar

SONUÇLAR VE DEĞERLENDİRME Gerçekleştirmiş olduğumuz boşluk analizi ve eşleştirme çalışması sonucunda CMMI Seviye 2’de tanımlı süreç alanlarının her biri için tanımlanmış özel pratiklere ait alt pratiklerin Scrum ile karşılanma yüzdeleri Tablo 7.1’de özetlenmektedir.

Tablo 5.1. CMMI Seviye 2 Süreç Alanlarının Karşılanma Yüzdeleri KO TK KK HK

Proje

Planlama

%71,43 %21,46 %7,14

Proje İzleme ve

Kontrol

%50,00 %40,00 %10,00

Gereksinim

Yönetimi

%100,00 %0,00 %0,00

Konfigürasyon

Yönetimi

Ölçüm ve

Analiz

Süreç ve Kalite Güvence

%28,57 %42,86 %28,57 %0,00 %62,5 %37,5 %25,00 %50,00 %25,00

SCAMPI C yöntemiyle gerçekleştirilen durum/gap analizinden elde edilen bulgulara ve yapılan eşleştirmelere göre göre, CMMI Seviye 2’de tanımlı süreç alanlarında tanımlanmış özel pratiklerin çoğunun Scrum pratikleri ile karşılandığı gözlemlenmiştir.

Kaynaklar

References

2.2. Proje Risklerinin Belirlenmesi 2.3. Veri Yönetiminin Planlanması 2.4. Proje Kaynaklarının Planlanması 2.5. Gerekli Bilgi ve Yetkinliklerin Planlanması 2.6. Paydaş Katılımının Planlanması 2.7. Proje Planının Oluşturulması 1 . CMMI Product Team, CMMI for Development (CMMI-DEV) . Version 1 .3, Technical Report , CMU/SEI-2010 - TR- 033 , Software Engineering Institute, 2010 .

2. Highsmith , J., “Agile Project Management: Creating Innovative Products“, Pearson Education, e-book, 2009 .

3. Vriens , C. , “ Certifying for CMM Level 2 and IS09001 with XP@ Scrum” , In Proceedings of the Agile Development Conference, sf. 120-124 , 2003 .

4. Kähkönen , T. , Abrahamsson , P. , “ Achieving CMMI level 2 with enhanced extreme programming approach” , In International Conference on Product Focused Software Process Improvement, sf. 378-39 , Berlin, 2004 .

5. Pikkarainen , A . Mantyniemi, “ An Approach for Using CMMI in Agile Software Development Assessments: Experiences from Three Case Studies” , In Proceedings of SPICE Conference , 2006 .

6. Sutherland , J. , Jakobsen , C. R. , ve Johnson, K., “ Scrum and CMMI Level 5: The magic potion for code warriors” , In Proceedings of the 41st Annual Hawaii International Conference on System Sciences, sf. 466-466 , 2008 .

7. Jakobsen , C. R. , ve Johnson, K. A., “ Mature Agile with a twist of CMMI” , In Agile Conference, sf. 212 - 217 , 2008 .

8. Jakobsen , C. R. , Sutherland , J. , “ Scrum and CMMI going from good to great” , In Agile Conference, sf. 333 - 337 , 2009 .

9. Mahnic , V. , Zabkar , N. , “Introducing CMMI measurement and analysis practices into Scrum-based software development process” , In International Journal of Mathematics and Computers in Simulation, sf. 65-72 , 2007 .

10. Marcal , A.S.C. , Soares , F.S.F. , ve Belchior , A.D., “ Mapping CMMI Project Management Process Areas to SCRUM Practices. ” In: SEW2007: Proceedings of the 31st IEEE Software Engineering Workshop , Washington, DC, USA, sf. 13 - 22 . IEEE Computer Society, Los Alamitos, 2007 .

11. Potter , N. , Sakry , M. , “ Implementing SCRUM (agile) and CMMI together”, The Process Group-Post Newsletter , vol. 16 , no. 2, sf . 1- 6 , 2009

12. Brereton , B. , Kitchenman , B. , Budgen , L. Z. , “ Using a protocol template for case study planning” , In Proceedings of EASE , vol. 8 , sf. 41 - 48 , 2008 .

13. SCAMPI Upgrade Team, Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A, Version 1 .3: Method Definition Document , Pittsburgh, Pennsylvania: Software Engineering Institute, Carnegie Mellon University, 2011 .

14. CMMI Product Team, CMMI for Development (CMMI-DEV) . Version 1 .3, Technical Report , CMU/SEI-2010 - TR- 033 , Software Engineering Institute, 2010 .