Alt Yüklenici Yönetiminde Çevik Bir Yaklaşım Deneyimi
Gonca Hülya SELÇUK, Hakime KOÇASELSAN A.Ş., Ankara ghselcuk@aselsan.com.tr
unsal@aselsan.com.tr
Özet. Günümüzde yazılım geliştirme projelerinde yaygın olarak kullanılan çevik
yöntemler, ihtiyaçları sık değişen projelerdeki başarı oranını artırmaktadır. Yazı-lım geliştirme projelerinde kullanılan çevik yaklaşımlar, ihtiyaçlar doğrultusunda tek başına veya birden fazla yaklaşımın harmanlanması ile bir arada kullanılabil-mektedir. Alt yükleniciler tarafından geliştirilen yazılımlar ya da yazılım bileşen-leri kapsamındaki alt yüklenici yönetimi faaliyetbileşen-lerinin de yazılım geliştirme fa-aliyetlerini destekleyerek proje başarısına katkı sağlayacağı öngörülmektedir. Çevik yazılım geliştirme faaliyetlerinin çevik alt yüklenici yönetimi ile destekle-nebilmesi adına; bu çalışmada alt yüklenici yönetimi için çevik bir yaklaşım öne-rilmektedir. Tecrübelerin de paylaşılacağı bu çalışmada, önerilen çevik yaklaşı-mın uygulanmasının projeye katkıları ve geleceğe dair çalışma önerileri sunul-maktadır.
Anahtar Kelimeler: Alt Yüklenici Yönetimi, Çevik Yaklaşımlar, Çevik
Yazı-lım Geliştirme.
Experience with Agile Approach in the Subcontractor
Management
Gonca Hülya SELÇUK, Hakime KOÇ
ASELSAN A.Ş., Ankara ghselcuk@aselsan.com.tr
unsal@aselsan.com.tr
Abstract. Nowadays, agile methods, which are widely used in the software
de-velopment projects, increase the success rate of projects, where requirements are changing very frequently. Agile approaches used in the software development projects can be used alone or in combination with multiple approaches according to needs. It is also expected that subcontractor management activities will cont-ribute to the success of projects in which all software or some components of
software developed by subcontractors. In this study, an agile approach for sub-contractor management is proposed to support all agile development activities. Moreover, this study presents the application of this agile approach in a specific industrial context with its benefits to all stakeholders in subcontractor activities.
Keywords: Subcontractor Management, Agile Approaches, Agile Software
De-velopment.
1
Giriş
Yazılım geliştirme projelerinde çevik yaklaşımlar günümüzde yaygın olarak kullanıl-maktadır. Çevik yaklaşımlar, detaylandırılamamış gereksinimler içeren projelerde za-man içerisinde iterasyonlar halinde çalışılabilmesine imkan tanımakta, dağıtık çalışan takımların çalışmalarını desteklemektedir. Belirsizliklerin yönetimine ve etkileşimin artmasına katkı sağlayan çevik pratikler projelerin başarısını da etkilemektedir. Stan-dish Group International’ın 2015 yılında 10.000’i aşan proje ile yapmış olduğu çalış-mada, çevik süreçler kullanılan projeler ile şelale modeli kullanılan projelerdeki başarı oranı karşılaştırılmıştır [1]. Çalışma sonuçlarına göre, çevik süreç kullanılan projelerin başarı oranı şelale modeli kullanılan projelerin başarı oranının dört katıdır.
Şirketler yazılım geliştirme faaliyetlerini kendi bünyelerinde gerçekleştirebildikleri gibi tedarik etmeyi de farklı nedenlerle yoğun olarak tercih etmektedir. Savunma sek-törü projelerinde de alt yüklenici kullanımı önemli bir paya sahiptir. Türk Silahlı Kuv-vetlerini Güçlendirme Vakfı Bağlı Ortaklıkları tarafından 2014 yılsonu itibarıyla 3.230 alt yüklenici ile çalışılmaktadır [2]. Yazılım geliştirme projelerinin sözleşmeler kapsa-mında tedarik edildiği ve alt yükleniciler tarafından gerçekleştirildiği durumlarda, proje yönetim faaliyetleri yanı sıra alt yüklenici yönetim faaliyetleri de projenin başarısını etkileyen önemli unsurlardan biri olmaktadır. Farklı ihtiyaçlara sahip projelerde farklı yönetim yaklaşımları öne çıkmaktadır [3]. Bu doğrultuda, çevik süreçlerle geliştirilen ve yönetilen projelerde alt yüklenici yönetiminin de çevik yaklaşımlara uyum sağlaması önem taşımaktadır [4].
ASELSAN Radar ve Elektronik Harp Sistemleri Sektör Başkanlığı (REHİS) bünye-sinde alt yükleniciler tarafından çevik süreçler kullanılarak geliştirilmekte olan projeler yürütülmektedir. İlgili projeler kapsamında ASELSAN REHİS tarafından gerçekleşti-rilen alt yüklenici yönetimi faaliyetleri için çevik bir yaklaşım tanımlanmıştır. Bu bil-diride, alt yüklenici yönetimi için tanımlanan çevik yaklaşıma yer verilmektedir. Bölüm 2’de çevik yaklaşımlar üzerine genel bilgi verilmektedir. Bölüm 3 önerilen çevik yak-laşımı tanımlamakta; Bölüm 4 ise tanımlanan modelin bir ürün hattı yazılım geliştirme projesindeki uygulamasını özetlemektedir. Bölüm 5; sonuçları, öğrenilen dersleri ve gelecek çalışmalar için önerileri içermektedir.
2
Çevik Yaklaşımlar
Günümüzde yazılım geliştirme faaliyetlerinde yoğunlukla tercih edilen çevik yaklaşım-lar farklı şekillerde kullanılabilmektedir. Bu yaklaşımyaklaşım-ların odağındaki “çevik”lik;
Bireyler ve etkileşim Çalışan yazılım üretme
Müşteri ile işbirliği içinde çalışma Değişime cevap verme
değerlerini öne çıkarmaktadır [5].
Çevik kavramını hayata geçiren yaklaşımlardan biri olan Scrum, ilk defa 1995 yı-lında tanıtılmıştır. Scrum, karmaşık ürünlerin geliştirilmesini, teslim edilmesini ve sür-dürülebilir olmasını bir çerçeve (framework) olarak tanımlamaktadır [6]. Bu çerçeve yinelemeli ve artırımlı bir şekilde, kullanılabilir ürün geliştirmeyi desteklemektedir. Özünde Scrum takımı olarak adladırılan, küçük takımlar yer almaktadır. Scrum takımı; bir ürün sahibi (product owner), geliştirme takımı ve Scrum Master’dan oluşmaktadır. Scrum takımının rol ve sorumlulukları aşağıdaki tabloda yer almaktadır.
Tablo 1. Scrum Takımı Rolleri
Rol Sorumluluk
Ürün Sahibi Ürünün veya projenin iş listesini (product backlog) yönetmekten so-rumludur.
Geliştirme Takımı Her bir iterasyonda (sprint) “Bitti (Done)” tanımına uyan ve yayınla-nabilir bir iş parçasını teslim etmekten sorumludur.
Scrum Master Scrum’ın tanımlanmış çerçeveye uyumlu yürütüldüğünü garanti et-mekten sorumludur.
Scrum kapsamında “çevik”liğin desteklenmesine yönelik olarak İterasyon (Sprint), İterasyon Planlama, Günlük Değerlendirme, İterasyon Değerlendirme, İterasyon Ret-rospektifi etkinlikleri de tanımlanmıştır. Roller ve etkinliklerin yanı sıra aşağıdaki un-surlar da tanımlanmıştır:
İş Listesi (Product Backlog): Üründe ihtiyaç duyulan her şeyi içeren bir liste-dir.
İterasyon İş Listesi (Sprint Backlog): İterasyon kapsamında yapılmasına karar verilen ve “Ürün İş Listesi”nden seçilen bir listedir.
Ürün Parçası: İterasyon sonucunda, mevcutta gerçekleştirilen tüm iterasyon-lardaki işlerin “Bitti (Done)” kavramına eriştiği, ürünün belirli özelliklerle ça-lışan bir parçasıdır.
“Bitti (Done)” Kavramı: Scrum takımında şeffaflığın sağlanarak işin hangi durumda bitti sayılabileceğinin tanımını içermektedir.
Scrum çerçevesinin yanında Kanban yaklaşımı da yazılım geliştirmede 2000li yılla-rın başından itibaren öne çıkan yaklaşımlardan biridir. Kanban, ilk defa 1940lı yıllarda Japonya’da yalın üretim (lean production) ilkesiyle ortaya çıkmıştır. Kelime anlamı ile “görsel sinyal” veya “kart” demek olan Kanban, üretimde her aşamada kullanılan kart-lara karşılık gelmektedir. Yalın üretim ilkesinden yola çıkıkart-larak modellenen Kanban 2000li yıllarda yazılım geliştirme alanında da kullanılmaya başlanmıştır [7]. Kanban’ın çıkış noktasında süreç iyileştirme yer alırken yazılım geliştirme alanında;
İş akışının görselleştirilmesi ve yönetilmesi Aynı anda gerçekleştirilen iş sayısının limitlenmesi Süreçlerin açık hale getirilmesi
olarak özetlenebilecek üç temel prensibi benimsemektedir. İş akışının görselleştirilmesi ve tüm takımın erişebilmesi sonucunda, bir takım üyesi bir işi bitirdiğinde sıradaki bir sonraki işe geçmesi hedeflenmektedir.
Scrum ile Kanban yaklaşımları, temel olarak işlerin çevik bir şekilde tamamlanma-sını hedeflemektedir. Farklılık taşıdıkları noktalar Tablo 2’de özetlenmektedir. Scrum çerçevesindeki tanımlı kurallar (roller, etkinlikler) yerine Kanban kullanımının verim-liliği artırdığını savunan örnekler [8] bulunduğu gibi; farklılıkların yanı sıra Scrum ve Kanban yaklaşımlarının beraber kullanıldığı “Scrumban” gibi yaklaşımlar da bulun-maktadır [9].
Tablo 2. Scrum ve Kanban Farklılıkları
Scrum Kanban
Geliştirme zaman limiti dahilinde, iterasyon-larla yapılır.
Geliştirme süreklidir, zaman limiti konulması zorunlu değildir.
Süreç iyileştirme aktiviteleri tanımlıdır. Süreç iyileştirme aktiviteleri için belirli bir ta-nım yoktur.
Roller tanımlıdır. Herhangi bir rol tanımlı değildir. İterasyon iş listesi her iterasyon başında
oluş-turulur. İş listesi sürekli güncellenerek kullanılır. İşlerin tamamlanmasındaki temel hedef, kısa
aralıklar dahilinde gerçekleştirilmesidir.
İşlerin tamamlanmasındaki temel hedef, bir akış içerisinde gerçekleştirilmesidir.
3
Alt Yüklenici Yönetiminde Çevik Yaklaşım İhtiyaçları
Alt yüklenici yönetimi kapsamında, savunma sektöründe bir ürün hattı yazılım geliş-tirme projesindeki çeşitli ihtiyaçlardan yola çıkılarak çevik bir yaklaşım önerisi oluştu-rulmuştur. Çevik yaklaşımın oluşturulma motivasyonu aşağıdaki konu başlıklarında özetlenmektedir. Bu kapsamda, yazılım geliştirme projelerini gerçekleştiren proje ekibi “Alt Yüklenici”, projeye ihtiyaç duyarak alt yüklenici aracılığıyla tedariğini sağlayan ve yöneten ekip de “Alt Yüklenici Sorumlusu” olarak adlandırılmaktadır.
3.1 Gereksinim Mühendisliği / Ürün Sahipliği
Alt Yüklenici tarafından geliştirilmekte olan projede çevik bir yaklaşım olan Scrum [6] kullanılmaktadır. Scrum pratikleri kapsamında, yazılım geliştirme faaliyetlerinin içeri-ğini belirlemek için “iş listesi (product backlog)” Alt Yüklenici ve Alt Yüklenici So-rumlusu tarafından tanımlanmaktadır. İş listesinde, detaylı yazılım gereksinimlerini oluşturabilecek seviyede işler bulunabildiği gibi detaylandırılma ihtiyacı bulunan ge-reksinimler de yer almaktadır. İhtiyaç sahibi firmada gereksinim mühendisliği faaliyet-lerinin gerçekleştirilerek kullanım senaryolarının detaylandırılması veya oluşturulma-sına ihtiyaç duyulmaktadır. Kullanım senaryoları, iş listesine girdi sağlamakta ve iş lis-tesinin detaylandırılmasını sağlamaktadır. Alt Yüklenici tarafından kullanılan Scrum pratikleri kapsamındaki “ürün sahibi (product owner)” rolü gereksinim mühendisliği faaliyetleri açısından yeterli olamamaktadır. Bu noktada ürün sahibinin;
ihtiyaç sahibi firmadaki matris yapılanma nedeniyle birden fazla bölümden bil-ginin toplanması,
proje kapsamındaki ihtiyaçların sık değişmesi,
projenin entegre edileceği birim veya proje sayısının fazla olması, diğer projelerin gereksinimlerinin proje ihtiyaçlarında etkili olması
gibi faktörleri yönetmesi gerekmektedir. Proje için belirtilen bu faktörler ve yapılmış çalışmalar doğrultusunda, Alt Yüklenici Sorumlusu tarafından da ihtiyaç sahibi firma içerisindeki “ürün sahibi (product owner)” rolünün üstlenilmesi gerekliliği ortaya çık-maktadır.
3.2 İşlerin Planlanması ve Takibi
Alt Yüklenici tarafından yazılım geliştirme faaliyetleri iterasyonlar bazında gerçekleş-tirilmektedir. Her bir iterasyon öncesinde Alt Yüklenici tarafından gereksinim mühen-disliği / ürün sahipliği faaliyetleri sonucu elde edilen detaylı senaryolar, gereksinimler veya faaliyetler değerlendirilmekte; yeterli detayı içeren ve öncelikli olan işler seçilerek iterasyon kapsamına alınmaktadır. Alt Yüklenici tanımladığı iterasyonlar kapsamın-daki faaliyetlerini üç haftalık zaman dilimleri içerisinde tamamlamayı hedeflemektedir. Bu kapsamda; Alt Yüklenici Sorumlusu faaliyetlerinin niteliği ise Alt Yüklenici faali-yetlerine göre farklılık göstermekte, işler Alt Yüklenici’ye göre daha genel çerçeveden ve detay içermeden takip edilmektedir. Alt Yüklenici Sorumlusu tarafından takip edilen işler ve yürütülen faaliyetler proje açısından zaman kısıtı taşısa da, belirlenen bir zaman limiti içerisinde başlayıp bitirmek mümkün olamamaktadır. Bu nedenle Alt Yüklenici Sorumlusu iş ve faaliyetlerinin zaman limitinden veya iterasyonlardan bağımsız olarak takip edilmesi ihtiyacı bulunmaktadır.
3.3 Entegrasyon Ortamı
Alt Yüklenici ile Alt Yüklenici Sorumlusu fiziksel olarak farklı lokasyonlarda çalış-maktadır. Geliştirilen projenin gizlilik seviyesi nedeniyle geliştirme Alt Yüklenici lo-kasyonunda, kapalı ağ ortamında gerçekleştirilmektedir. Bu doğrultuda, proje konfigü-rasyon ortamına fiziksel olarak Alt Yüklenici Sorumlusu tarafından erişilememektedir. Ancak, alt yüklenici faaliyetlerinin eş zamanlı ve etkileşimli yönetilebilmesi açısından, Alt Yüklenici ve Alt Yüklenici Sorumlusu arasında sürekli bir iletişim ve entegrasyon ortamının kurulabilmesi önem taşımaktadır. Projenin gizlilik kısıtları entegrasyon orta-mını da etkilemekte Alt Yüklenici tarafından kullanılan çevik proje yönetimi ortamına (iş listesini, tanımlanan işleri, faaliyetleri, değişiklik isteklerini, hataları içeren ortam) erişilememektedir. Çevik yaklaşımların farklı lokasyonlarda uygulanmaya çalışıldığı durumlarda yüzyüze iletişim kurulamadığından, proje ile ilgili tüm bilgilerin (mevcut durum, planlama, gereksinimler, kullanım senaryosu vb.) dokümantasyonun iyi bir şe-kilde yapılması ve yazılı iletişimin sağlanması önem kazanmaktadır [10, 11]. Bu ne-denle, Alt Yüklenici Sorumlusu ortamında da tüm bilgilerin dokümante edilebilmesi ve Alt Yüklenici yönetim faaliyetlerinin üst seviye takip edilebilmesi için çevik bir proje yönetim ortamının kurulması önemli hale gelmektedir.
3.4 Doğrulama
Doğrulama (verification) faaliyetleri Alt Yüklenici bünyesinde gerçekleştirilmekte olan iç bir süreçtir. Alt Yüklenici tarafından uygulanan çevik süreçler kapsamında yazılım geliştirme faaliyetleri için “Bitti (Done)” kavramı tanımlanmıştır. “Bitti” kriterlerinden biri de gerçekleştirilmiş olan faaliyetin doğrulanmasıdır. Alt Yüklenici Sorumlusu ta-rafından iterasyon sonu tanıtımlarına katılım sağlanmakta ancak geçerlileme (valida-tion) faaliyetleri birden fazla iterasyon sonucunda oluşturulan sürüm kabul faaliyetleri sonucunda yapılmaktadır. Hataların daha erken bir aşamada yakalanabilmesi için Alt Yüklenici Sorumlusu’nun geçerlileme faaliyetlerinden önceki bir aşamada doğrulama faaliyetlerine katkıda bulunması ihtiyacı bulunmaktadır.
4
Alt Yüklenici Yönetiminde Çevik Bir Yaklaşım
İhtiyaçlardan yola çıkılarak, Kanban ve Scrum yaklaşımları özelliklerinden faydalanı-larak alt yüklenici yönetimi faaliyetleri için çevik bir yaklaşım modellenmiştir (Şekil 1). Bu modelde; alt yüklenici yönetimi iş ve faaliyetlerinin gerçekleştirilmesinde iterasyon tanımlaması yapılmadan Kanban tahtası kullanılması önerilmektedir. İterasyon tanım-lanmasa da planlamayı kolaylaştırması açısından tahtada son iki ayın iş ve faaliyetlerine odaklanılmaktadır.
Birden fazla alt yüklenicideki Scrum takımını yöneten bir firmada, tüm Scrum ta-kımlarına bilgi aktarımının yapılması için “Alan Ürün Sahibi (Area Product Owner)” rolünün oluşturulması önerilmektedir [12]. Birden fazla projenin yürütülebileceği ön-görülerek Kanban tahtası birden fazla projeye ait iş maddesi içerebilmektedir. Gereksi-nim mühendisliği faaliyetleri ihtiyaç sahibi firmada da gerçekleştirilerek, Alt Yüklenici Sorumlusu’nun “ürün sahipliği” rolünü de üstlenmesi önerilmektedir. Bu noktada, Alt Yüklenici Sorumlusu’nda “ürün sahibi”nin, güncel kullanım senaryolarını Alt Yükle-nici’deki “ürün sahibi”ne aktarması planlanmaktadır.
Alt yüklenici yönetimi kapsamında yapılması gereken iş maddelerinin bulunabile-ceği dört farklı durum tanımlanmaktadır: Planlanan, Devam Eden, Alt Yüklenicide De-vam Eden, Tamamlanan. “Planlanan” durumdaki işler henüz başlamamış ancak iki ay içerisinde başlaması öngörülen işlerdir. “Devam Eden” durumdaki işler Alt Yüklenici Sorumlusu tarafından planlanmış ve üzerinde çalışılmaya başlamış olan işlerdir. “Alt Yüklenicide Devam Eden” durumdaki işler Alt Yüklenici Sorumlusu tarafından detay-landırılan kullanım senaryoları kapsamında Alt Yüklenici’ye aktarılmış olan işlerdir. “Tamamlanan” durumdaki işler ise Alt Yüklenici veya Alt Yüklenici Sorumlusu tara-fından bitirilmiş olan işlerdir. Tamamlanan bir iş Alt Yüklenici taratara-fından gerçekleşti-rilmiş ise Alt Yüklenici Sorumlusu tarafından resmi olmayan bir doğrulama işlemi de gerçekleştirilmektedir.
Bir iş maddesinin durumlarına göre ilerleyebileceği üç farklı iş akışı tanımlanmak-tadır:
1. Planlanan, Devam Eden, Alt Yüklenicide Devam Eden, Tamamlanan 2. Planlanan, Alt Yüklenicide Devam Eden, Tamamlanan
Şekil 1. Çevik Yaklaşım Önerisi Modeli
5
Alt Yüklenici Yönetiminde Çevik Yaklaşım Deneyimleri
Alt yüklenici yönetimi için modellenen çevik yaklaşım savunma sektöründeki bir ürün hattı yazılım geliştirme projesinde uygulamaya alınmıştır. Mevcut durumda, projede yazılım geliştirme faaliyetlerine devam edilmektedir. Ürün hattı projesinin çıktısı iki farklı projede kullanılmaktadır. Ürün hattı yazılım geliştirme projesi ile ürün hattını kullanan iki projenin yazılım geliştirme faaliyetleri eş zamanlı olarak Alt Yüklenici Sorumlusu tarafından takip edilmektedir.Çevik yaklaşım önerisi, projelerin yazılım geliştirme süreci devam ederken hayata geçirilmiştir. Alt Yüklenici Sorumlusu tarafından gerçekleştirilen iş ve faaliyetler çevik bir proje yönetimi ortamında takip edilmeye başlanmıştır. Kullanılan çevik proje
yöne-İş Listesi Alt Yüklenici Ürün Sahipliği Faaliyetleri İterasyon İş Listesi İterasyon 1 .. n Kabul Sürümü 1 .. n
Alt Yüklenici Sorumlusu Alt Yüklenici
Alt Yüklenici Sorumlusu
Ürün Sahipliği Faaliyetleri Planlanan Devam Eden
Alt Yüklenicide Devam Eden Tamamlanan 1 2 3
tim ortamında halihazırda yürütülen işler ve planlanan işler tanımlanmıştır. İşlerin kap-samı, Alt Yüklenici işlerini kapsayacak şekilde kurgulanarak entegrasyon ortamı Alt Yüklenici Sorumlusu’nda da oluşturulmuştur. Öneri doğrultusunda çevik proje yöne-timi aracı üzerinde iki aylık işleri gösteren bir filtre tanımı yapılmıştır. Alt Yüklenici Sorumlusu “ürün sahibi” rolünü de üstlenerek, ihtiyaç sahibi firma içerisindeki gerek-sinim mühendisliği faaliyetlerini gerçekleştirmekte ve kullanım senaryolarını oluştur-maktadır. Çevik proje yönetim aracında, işler için önerilen durumlar (Planlanan, De-vam Eden, Alt Yüklenicide DeDe-vam Eden, Tamamlanan) ve iş akışları hayata geçiril-miştir.
Çevik yaklaşım önerisi, proje kapsamında hayata geçirilerek iki aylık bir dönem kap-samında uygulanmıştır. Uygulama dönemi içerisinde sayısal kıyaslama gerçekleştirile-cek düzeyde veri toplanamamıştır; ancak alt yüklenici yönetimindeki çevik yaklaşımın projeye şu katkıları sağladığı görülmüştür:
Projedeki işlerin tüm ilgililere görünürlüğü artmıştır. Proje geçmişinin ve hafızasının kayıtlı olması sağlanmıştır.
Alt Yüklenici Sorumlusu tarafından yürütülen işler tanımlı hale gelmiştir. Ürün sahipliği faaliyetleri kapsamında projelerin birbirine olan etkisi kayıt
al-tına alınmıştır.
Kullanım senaryoları daha kısa sürede netleşmiştir.
Çevik proje yönetim ortamı ile aynı anda birden fazla proje için alt yüklenici yönetimi faaliyetleri gerçekleştirilmiştir.
Alt Yüklenici tarafından gerçekleştirilen iterasyonlardaki kapsam daha net planlanmıştır.
6
Sonuçlar ve Gelecek İçin Planlar
Alt yüklenici yönetimi için modellenen çevik yaklaşım ASELSAN REHİS bünyesinde birden fazla projeye çıktı veren bir yazılım ürün hattı projesinde hayata geçirilmiştir. Yaklaşımın çevik bir proje yönetimi ortamında hayata geçirilmesi, alt yüklenici yöne-timi faaliyetlerinin Alt Yüklenici Sorumlusu kapsamındaki tüm ilgililere görünürlü-ğünü artırmış ve faaliyetlere ilişkin geçmişin kayıtlı olmasını sağlamıştır.
Ürün sahipliğine ilişkin faaliyetlerin öncelikli olarak Alt Yüklenici Sorumlusu tara-fından gerçekleştirilmesi sonucunda kullanım senaryolarının netleşmesi çalışmalarının süresinin kısaldığı görülmektedir. Gelecek dönemde, senaryo çalışmalarındaki süre kı-salmasının projenin toplam süresine etkisi ölçülerek değerlendirilecektir. Bu kapsamda senaryo değişikliklerinin de ele alınması faydalı görülmektedir. Doğrulama kapsa-mında da gelecek dönemde; resmi süreçler öncesinde Alt Yüklenici faaliyetlerinin çe-vik süreçler kapsamında doğrulanmasının kabul faaliyetlerindeki hata sayısına etkisi değerlendirilecektir.
Kaynakça
1. Standish Grup Ana Sayfası, https://www.standishgroup.com/sample_research_files/ CHAOSReport2015-Final.pdf, Erişim Tarihi 2019/06/20.
2. D. Sağlam, Alt Yüklenici Seçimi, Yönetimi, Yaşanan Sorunlar, Çözüm Süreçleri Ve Eko-sistem Geliştirilmesi Hakkında Bir Çalışma, https://www.tskgv.org.tr/contents/makale-ler/599, Erişim Tarihi 2019/06/20.
3. C. Gencer, A. Kayacan, “Yazılım Proje Yönetimi: Şelale Modeli ve Çevik Yöntemlerin Karşılaştırılması”, Bilişim Teknolojileri Dergisi, 335-352, 2017.
4. L. Thorup and B. Jensen, “Collaborative Agile Contracts”, 2009 Agile Conference, Chi-cago, IL, pp. 195-200, 2009.
5. M. Fowler and J. Highsmith, “The agile manifesto”, Softw. Dev., vol. 9, pp. 28–35, 2001. 6. K. Schwaber and J. Sutherland, “The Scrum Guide”, November 2017,
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf, Erişim Tarihi 2019/06/20.
7. D.J. Anderson, “Kanban: Successful Evolutionary Change for Your Technology Busi-ness”, Blue Hole Press, ISBN 9780984521401, 2010.
8. D. I. K. Sjøberg, A. Johnsen and J. Solberg, "Quantifying the Effect of Using Kanban ver-sus Scrum: A Case Study," in IEEE Software, vol. 29, no. 5, pp. 47-53, Sept.-Oct. 2012. 9. M. Stoica, B. Ghilic-Micu, M. Mircea, C. Uscatu, “Analyzing Agile Development – from
Waterfall Style to Scrumban”, Informatica Economica. 20, pp.5-14, 2016.
10. D. Turk, et al., “Limitations of Agile Software Processes,” Proc. The 3rd International Con-ference on eXtreme Programming and Agile Processes in Software Engineering, Springer-Verlag, pp. 43-46, 2002.
11. M. Paasivaara and C. Lassenius, "Could Global Software Development Benefit from Agile Methods?," 2006 IEEE International Conference on Global Software Engineering (ICGSE'06), Florianopolis, pp. 109-113, 2006.
12. M. Penttinen and T. Mikkonen, “Subcontracting for Scrum Teams: Experiences and Gui-delines from a Large Development Organization”, 2012 IEEE Seventh International Con-ference on Global Software Engineering, Porto Alegre, pp. 195-199, 2012.
