<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="tr">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Uluslararası, C ¸oklu Bileşenli C ¸evik Yazılım Geliştirme Projelerinde 3. Partilerle C ¸alışma Deneyimleri</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">S</forename><surname>¸enay Demirel</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Netaş Telekomünikasyon A.S ¸</orgName>
								<address>
									<settlement>İstanbul</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author role="corresp">
							<persName><forename type="first">Yagmur</forename><surname>Kırkagaç</surname></persName>
							<email>yagmur@netas.com.tr</email>
							<affiliation key="aff0">
								<orgName type="institution">Netaş Telekomünikasyon A.S ¸</orgName>
								<address>
									<settlement>İstanbul</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Uluslararası, C ¸oklu Bileşenli C ¸evik Yazılım Geliştirme Projelerinde 3. Partilerle C ¸alışma Deneyimleri</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">77EBD7A0E41CB5407C5FFD7C43D8BFB8</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-23T19:45+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Agile Software Development</term>
					<term>Multi-Components</term>
					<term>Software Solutions Development with 3rd Parties</term>
					<term>Software Project Management</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>İnternet ekonomisinin hızlı degişimi yazılım mühendisligindeki belirli kuralları da aynı hızla degiştirmektedir. C ¸evik yazılım geliştirme süreçleri, projede üretilen degerin hızlı ve etkin bir şekilde gerçeklenebilmesi için gelişmiş bir sistemdir. C ¸evik yazılım geliştirme süreçleri, yazılım projelerinin yaşamsal döngülerinin verimli bir şekilde tamamlanmasını saglamayı amaçlamaktadır. Netaş Telekomünikasyon A.S ¸. çevik yazılım geliştirme süreçlerinin projelerde uygulanmasının uzun yıllardır bilgi birikimine ve tecrübesine sahiptir. Netaş, büyük ölçekli, uluslararası ve çoklu bileşenli projelerini, 3. partilerle ortaklaşa çalışarak yürütebilmektedir. Bu bildiride, uluslararası, büyük ölçekli ve 3.partiler ile birlikte yürütülen çevik yazılım projelerinin yönetiminde edinilen deneyimlerin paylaşılması amaçlanmış, karşılaşılan sorunlar ve bu sorunlara getirilen çözümler çevik yazılım geliştirme prensipleri ışıgında incelenmiştir.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="tr">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Giriş</head><p>Günümüzde yazılım, birçok endüstrinin işleri için gerekli olmakla beraber, yazılım süreçlerinin başarı ile yürütülmesi için farklı yazılım disiplinleri uygulanmaktadır. Buna ragmen, birçok araştırma yazılım geliştirme projelerinin başarısını ölçebilecek bir formül ortaya koyulamadıgını göstermektedir. Özellikle, çevik yazılım projelerinde birçok degişkene baglı olmak, başarı ölçütlerinin formül ile ifadesini daha da zorlaştırmaktadır.</p><p>Standish Grup 1994'ten itibaren her yıl yazılım geliştirme endüstrisinin anlık durum görüntüsünü "CHAOS Raporu" isimli raporları ile yayınlamaktadır <ref type="bibr">[1]</ref>. 2015 yılında yayınlanan CHAOS Raporu, çeşitli ülkelerde farklı yapıda projelerin oluşturdugu 50000 projenin analizlerini içermektedir <ref type="bibr" target="#b0">[2]</ref>. Standish Grup 2015 yılı CHAOS Raporu'nda, son 5 yılda analiz edilen projelerin zaman, bütçe ve kalite degişkenleri ile tanımlanan proje başarı oranlarını CHAOS Manifestosu'nda tanımlandıgı şekilde analiz etmişlerdir. Projelerin, başarı sonuçları Tablo 1'de özetlenmiştir <ref type="bibr" target="#b0">[2]</ref>. Tablo 1'de görüldügü üzere, son 5 yılda geliştirilen yazılım projelerinin yaklaşık %70'i hala üstesinden gelmesi zor veya başarısız olmuştur <ref type="bibr" target="#b0">[2]</ref>. Araştırmacılar, yazılım projelerinin başarı oranlarını etkileyen faktörleri belirlemeye ve başarı oranlarını iyileştirecek yöntemleri araştırmaya odaklanmışlardır. Bu alanda yapılan araştırmalarda, çevik yazılım geliştirme disiplini diger yazılım geliştirme disiplinleri arasında en popüler olanlardan biridir.</p><p>C ¸eviklik, hızlı ve kolay hareket etmenin gücü anlamına gelmektedir. Yazılım projelerinde çeviklik; hızlı, hafif,verimli ve kaliteli yaşam döngüsü saglayarak, müşteri isteklerini olabildigince sade fazlar ve hızlı geri dönüşler ile mümkün kılmayı amaçlar. Yazılım geliştirmede uygulanan çevik metodolojiler, esnek bir güç oluşturmayı, hızlı hareket etmeyi ve zamanla oluşan degişikliklere kolay adapte olmayı hedeflemektedir. C ¸evik yazılım geliştirme metodolojisinin en temel özelligi, dagıtılabilir birimler ile başlayıp, zaman içerisinde ürünün tamamen işlevsel ve ölçeklenebilir birimlerden oluşturulmasını saglamasıdır. C ¸evik metodolojisinin döngüsel yapısı, geliştirilecek yazılımın kısa zamanda teslim edilebilir olmasını ve periyotlar halinde geliştirilmelerin tamamlanmasını saglar.</p><p>CHAOS 2015 raporu sonuçlarına göre, şelale (waterfall) ve çevik (agile) yazılım projeleri başarı oranlarının karşılaştırma tablosu Tablo 2'deki gibi su-nulmuştur. Tablo 2'de de görüldügü üzere, çevik projeler her proje büyüklügüne göre geleneksel proje yöntemlerinden daha başarılıdır <ref type="bibr" target="#b0">[2]</ref>. Yazılım geliştirme işlerindeki faktörler, yazılım mühendisligi ile ilişkili oldugu kadar iş ve proje yönetimi metodolojilerinin de birleşimidir. 3.partilerle yazılım geliştirme genel olarak yazılım geliştirme aktivitelerinin tedarikçiden yazılım geliştiricilerin saglanması olarak tanımlanabilir. Gelişen internet tabanlı işbirligi servisleri sayesinde Hindistan, C ¸in, Latin Amerika gibi ülkelerdeki yazılım geliştirme görevleri için tedarikçilerin kullanımı da artmaktadır <ref type="bibr" target="#b1">[3]</ref>. Takımlar farklı kültürel altyapılara sahip, dünyanın farklı lokasyonlarında bulunan takım üyelerinden oluşmaktadır. Büyük ölçekli uluslararası projelerde 3. partilerle çalışmanın yeni iş fırsatları oluşturma, pazara daha kolay giriş yapma gibi avantajlarının yanında bazı zorlukları da mevcuttur. Ekip kontrolü, koordinasyon, teknoloji ve insanların birbirleri ile etkileşimi farklı kültürel yapılara sahip, farklı dilleri konuşan, farklı çalışma prensipleri olan insanların bir arada çalışmalarını saglamak büyük ölçekli, uluslararası projelerde 3. partilerle çalışmanın güçlüklerinden bazıları olarak sayılabilir.</p><p>CMMI-Dev v1.3 seviye 3 sertifikasyonuna sahip olan Netaş, yıllardır uluslararası projeler geliştirerek müşterilerine kaliteli yazılım projeleri sunmaktadır. Netaş, uluslararası, çoklu bileşenli, 3.partilerle ortaklaşa geliştirdigi yazılım projelerinde de çevik yazılım metodolojilerini uygulamaktadır.</p><p>Bu bildiride, uluslararası çoklu bileşenli çevik yazılım projelerinde 3.partilerle çalışmanın avantaj ve dezavantajları ele alınmış, çevik yazılım geliştirme süreçlerindeki deneyimler sorunlara getirilen çözümler ile paylaşılmıştır. 2. kısımda Scrum modelinden ve Scrum of Scrum pratiginden bahsedilmiş, Netaş projelerinden bir örnek uygulama üzerinde açıklanmıştır. 3. kısımda söz konusu olan örnek uygulama sırasında karşılaşılan zorluklardan, 4. kısımda ise bu zorluklar karşısında çevik yazılım geliştirme metodolojilerinden faydalanılarak geliştirilen çözüm yöntemleri açıklanmıştır. 5. kısımda, proje kapsamında çıkarılan sonuçlar degerlendirilmiştir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Uluslararası, C ¸oklu Bileşenli C ¸evik Yazılım Geliştirme Projeleri</head><p>C ¸oklu bileşenlerden oluşan sistemler, modüler yapısının yanında geliştirilen modüllerin birbirleri ile uyumlu çalışmasını hedeflemektedir. Bu bildiride konu edilen projede, birbirinden bagımsız çalışan yazılım geliştirmeleri ayrı ürünlerde ayrı fonksiyonellikler saglamasının yanı sıra, birbirleri ile bagımlı çalışarak teslim edilebilir yeni bir ürün ortaya koyabilmektedir. Netaş, çevik proje yönetimini Scrum modeli ile uygulamaktadır. Scrum, yazılım geliştiren proje takımlarının; enerjilerini, odak noktalarını, açık ve şeffaf bir şekilde kattıkları bir çevik yazılım geliştirme sürecidir. Scrum modelinde, scrum takımları kendi kendini organize edebilen, girişken takımlardır. Scrum takımları, projedeki teslim mekanizmalarını sprint(koşu) adı verilen kısa süreli (1-4 hafta) süreçler ile saglarlar. Her sprint süreci, tahminler ve içerik planlaması ile başlar, teslim ve her oturum sonunda çıkarılan sonuçlar ile sonlanır. Ürün iş listesi (backlog), scrum master ve ürün sahibi tarafından tasarım tahminleri ile önemli noktaların ve önceliklendirilmiş görevlerin belirlenmesi gerekmektedir. Günlük scrum toplantıları yapılır. Bu yapı, scrum takımlarını birbirine yakın, hızlı iş geliştirebilen, verimli takımlar haline dönüştürür <ref type="bibr" target="#b2">[4]</ref>.</p><p>Scrum Alliance Grup tarafından, Scrum modelinin pratiklerinden olan Scrum of Scrum en iyi pratiklerden biri olarak önerilmiştir <ref type="bibr">[5]</ref>. Bu model, takımlar arası birçok baglılıgı aradan kaldırarak, izole Scrum takımları arasında bölüştürerek çalışır. Scrum masterları (takım liderleri-proje yöneticileri) düzenli olarak lokasyonlar arası buluşur. Bu sayede, Scrum takımları Scrum of Scrum pratigi ile birbirine baglanır. Bu pratik takımlar arası iletişimi, iş bölümünü ve verimliligi artırır. Bunun yanında, çevik yazılım geliştirme sürecine yeni dahil olanlar için uygun hale getirir.</p><p>Bu bildiriye konu olan proje bulut bilişim teknolojileri ile uyumlu, donanım maliyeti düşük uygulama sunucusu ve çoklu ortam video konferans sunucusu geliştirmeleri ile kullanıcı masaüstü ve Web istemcilerinin geliştirilmelerini içermektedir. Büyük ölçekli, çoklu bileşenli bu proje kapsamında geliştirilen sunucu ve istemcilerin entegrasyonu ve testleri de gerçeklenmiştir. Söz konusu proje, son kullanıcıların günlük hayatta sıkça kullandıkları sesli, görüntülü ve yazılı iletişimi bulut bilişim teknolojileri ile saglamaktadır.</p><p>Bu projenin yönetiminde Scrum modeli kullanılmıştır. Bu Scrum takımları, Scrum of Scrum pratigi ile birleştirilmiştir ve scrum masterlar tarafından raporlama ve iş takibi saglanmaktadır. Scrum takımları aşagıda ayrıntılı bir şekilde açıklanmıştır.</p><p>Oluşturulan proje yapısında toplam 5 Scrum takımı oluşturulmuştur. Bu Scrum takımları S ¸ekil 1'de gösterildigi gibidir.</p><p>1. Scrum -Sunucu Geliştirmeleri: NETAS ¸'ın kendi bünyesinde oluşturulmuş olan ve sunucu üzerindeki geliştirmeleri yapan takımdır. Takımın tamamı NETAS ¸mühendislerinden oluşmakta ve aynı lokasyonda çalışmaktadır.</p><p>2. Scrum -Kullanıcı Masaüstü İstemcisi Geliştirmeleri: NETAS ¸'ın hali hazırda diger projelerinde de birlikte çalıştıgı Ermenistan'da bulunan alt yüklenici firma tarafındaki takımdır. Bu takım masaüstü istemcisi üzerindeki geliştirmeleri yapmaktadır.</p><p>3. Scrum -Kullanıcı Web İstemcisi Geliştirmeleri: Kullanıcıya tarayıcı üzerinden sesli ve görüntülü konferansa katılma imkanı saglayacak olan istemci geliştirmelerini kapsar. Hindistan'da bulunan bir yüklenici firma tarafından yapılmaktadır.</p><p>4. Scrum -C ¸oklu Ortam Video Konferans Sunucusu Geliştirmeleri: Video konferans sunucusunun farklı istemcilerin isteklerine cevap verebilecek şekilde geliştirilmesini kapsar. Hindistan'da bulunan başka bir yüklenici firma tarafından yapılmaktadır.</p><p>5. Scrum -Entegrasyon: Uçtan uca çözüm fonksiyon ve kalite testleri ile birlikte farklı bileşenlerin entegrasyonundan ve projenin ürüne dönüşüm sürecinden sorumludur. NETAS ¸bünyesindeki ürün dogrulama ve sistem mühendisleri ve proje mimarlarından oluşmaktadır. a. Takım Yapısı ve Dagılımı: Projenin ihtiyaçları dogrultusunda oluşturulan Scrum modeli hem cografi olarak farklı lokasyonlarda bulunan 4-8 kişiden oluşan 5 farklı takımı içermektedir hem de farklı ülkelerde yer alması nedeniyle kültürel ve sosyo ekonomik olarak farklı etkenlerden etkilenebilmektedir. Uluslararası bir proje olması projenin hem planlanmasını, hem kontrol edilebilmesini hem de takımlar arası bagımlılıkların ve birleşme noktalarının giderilmesini zorlaştırmaktadır.</p><p>b. Proje Planları: Projenin dagıtık ve uluslararası yapısı nedeniyle proje planları yapılırken çeşitli noktalar göz önünde bulundurulmuştur.</p><p>• Bir takımın teslim edecegi çıktı bir başka takım için girdi oldugu durumlar iş listelerinde öncelikli planlanarak proje için toplam zaman ve kaynak faydasının arttırılması planlanmıştır. • Proje planı oluşturulurken, etkileşim ve bütünleşme noktaları belirlenmiş, bu noktaların olabildigince erken dogrulanabilmeleri için de çözüm dogrulama döngüleri sürekli ve geliştirme döngülerine paralel olacak şekilde tasarlanmıştır. • Takımların çevik yazılım geliştirme prensiplerine uyması, 3 ya da 4 er haftalık devinimlerle teslimat yapmaları ve kaliteden sorumlulukları planlanmıştır. • Projenin uluslararası yapısı nedeniyle farklı ülkelerin tatil, bayram ya da izin dönemleri proje planlarına yansıtılmıştır.</p><p>c. İnsan Faktörü ve İletişim: Takımların teknik yeterliligi ve tecrübesi yanında takım olarak yakalanan sinerji, güven, açık iletişim, işbirligi ve yardımlaşma projenin başarıya ulaşması için önemli faktörlerden biridir. Projenin yapısı ve de süresi göz önüne alındıgında projenin bütününde çalışan insan sayısının artması da insanların motivasyonunu etkileyen bir etken olarak öne çıkmaktadır. Projenin uluslararası yapısı nedeniyle video konferans ile günlük scrumlar gerçeklenerek iletişim kuvvetlendirilmiştir.</p><p>d. Teknik Faktörler: Projenin tanımı ve yapısı geregi teknik olarak kurulan altyapı ve entegrasyon ihtiyacı öne çıkmaktadır. Bu entegrasyonu proje planları dahilinde planlanan sürelerde karşılamak için projede otomasyon ihtiyacı öne çıkmaktadır.</p><p>e. Organizasyonel Faktörler: Kurulan scrum takımlarının farklı şirketler bünyesinde yer alması nedeniyle yönetim farklılıkları dogmaktadır. Scrum Masterların scrum of scrum toplantılarında karşılaşılan sorunlara karşı yaklaşım farklılıkları özellikle iletişim noktasında dikkatli olmayı ve proje raporlamalarında ve durum bildirim özetlerinde proje durumunu net ve tarafsız olarak bildirmeyi gerekmektedir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Karşılaşılan Zorluklar Karşısında Kullanılan Yöntemler ve C ¸evik Yazılım Geliştirmedeki Karşılıkları</head><p>Karşılaşılan her bir zorluk karşısında farklı çözüm teknikleri uygulanmış ve projenin başarı ile sonuçlanması için gereken çözümler saglanmaya çalışılmıştır. C ¸evik yazılım geliştirme prensipleri ile örtüşen bu metodoloji ve yaklaşımlar Tablo 3 ve Tablo 4'te listelenmiş ve ayrıntıları verilmiştir. • Dönemsel ihtiyaçlara göre NETAS ¸bünyesinde (on-site) çalışmalar ayarlanmıştır.</p><p>• Kolektif proje planları yapılmış ve adaptasyona izin verecek şekilde entegrasyon noktaları belirlenmiştir.</p><p>• Plan çerçevesinde degişikliklere gidilmesi,</p><p>• Ayrı bir scrum takımı entegrasyon ve uçtan uca çözümden sorumlu tutulmuştur</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>• Degişen durumlara düzenli adaptasyonun saglanması Proje Planları</head><p>• Proje zamanlaması içinde farklı sürüm planları yapılmış ve tamamen ürünleşmeye geçmeden önce alfa, beta gibi farklı sürümler müşterinin kullanımına açılmıştır.</p><p>• Sürekli ve kaliteli yazılım teslimi ile müşteri memnuniyeti saglanması</p><p>• Projenin çeşitli aşamalarında çalıştaylar düzenlenmiş (workshop) ve takımların bir araya gelerek birlikte çalışması saglanmıştır.</p><p>• Yüz yüze görüşmelerle daha iyi iletişim kurulması (co-location)</p><p>İnsan Faktörü ve İletişim • Dönem dönem yerinde (on-site) çalışma olanakları saglanmış ve takımların farklı lokasyonlarda buluşması saglanmıştır.</p><p>• Projelerin birbirine güvenen motive bireyler tarafından geliştirilmesi</p><p>• Takım oluşturma aktiviteleri ile takım sinerjisi oluşturulmaya çalışılmıştır. • Geliştirilen yazılım ilerlemenin başlıca ölçüsüdür</p><p>• Sunucu tarafındaki kodlar mümkün olan en erken aşamada dondurulmuş ve çok acil durumlar dışında degişiklikten kaçınılmıştır.</p><p>• Sürekli ve kaliteli yazılım teslimi ile müşteri memnuniyeti saglanması</p><p>• Projenin çeşitli aşamalarında çalıştaylar düzenlenmiş (workshop) ve takımların bir araya gelerek birlikte çalışması saglanmıştır.</p><p>• Geliştiriciler ve Scrum Masterların birebir iletişim halinde, birlikte çalışması Organizasyonel Faktörler • Dönemsel ihtiyaçlara göre degişen haftalık ya da günlük senkronizasyon toplantıları yapılmıştır</p><p>• Yüz yüze görüşmelerle daha iyi iletişim kurulması (co-location)</p><p>• Açık İletişim yöntemi ile güven ve yardımlaşma olgusu oluşturulmuştur.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Sonuçlar</head><p>Netaş Telekomünikasyon A.S ¸., çevik yazılım geliştirme süreçlerini projelerinde uygulamaktadır. Ar-Ge projelerinde oluşan süreç, kısa zamanda degişebilen, modüler, hızlı ve esnek proje geliştirme yöntemlerini gerektirmektedir. Bu projenin gelişiminde, şelale yazılım geliştirme ile çevik yazılım geliştirme metodolojisi arasında seçim yaparken göz önünde bulundurulan en önemli etkenlerinden birkaçı şu şekilde sıralanabilir.</p><p>-C ¸oklu bileşenden oluşan bu projenin bileşenlerine ayrılarak yüklenici firmalar da dahil olmak üzere uzmanlık alanlarına göre paylaşılması, -Bileşenlerin paralel olarak yazılım geliştirmelerinin saglanması ve modüler bir yapıya sahip olması, -Her bileşenin proje geliştirilirken testlerinin saglanıyor olması, -Farklı firmalar tarafından gerçeklenen her parçanın entegrasyon ihtiyacı ve bu entegrasyonda gereken süreçlerin kısa zaman aralıklarında tamamlanması, -Süreçlerin degişen ihtiyaçları kısa zaman içerisinde karşılayabilecek şekilde yöntemler sunması ve bu degişikliklerin projenin diger bileşenleri üzerindeki etkilerini planlayabilmeyi saglaması gerekmektedir.</p><p>Yukarıda bahsedilen bu etkenler dogrultusunda çevik yazılım geliştirme süreçlerinin bildiride sözü geçen proje için uygun oldugu görülmüştür. C ¸evik yazılım geliştirme süreçleri yerine, şelale yazılım geliştirme süreçleri uygulansaydı, projenin kullanıcı arayüzündeki belirsizliklerin projeye başlanmadan karar verilip tasarımlarının oluşturulması projeye başlangıç zamanını uzatabilirdi. Projenin başlangıcında tasarımı yapılmış yapının projenin ilerleyen safhalarında degişmesi gerekseydi projede degiştirilecek kısımlar daha maliyetli ve yine süreci uzatacak şekilde olabilirdi. Uluslararası ve çoklu bileşenden oluşan bu proje şelale yazılım geliştirme metodolojisi ile geliştirilseydi, dinamik olarak müşteri istegine veya proje performansına göre degişmesi gereken kısımların degiştirilmesi zaman ve yöntem açısından verimsiz olabilirdi. Bileşenlerin ilerleyen safhalarında ilk başta geliştirilmiş bileşenin yapısının sonrasında geliştirilen yapıya uygun olmaması degişimi ve süreci zorlayıcı kılabilirdi. Projenin çoklu bileşenden oluşması ve uluslararası nedeniyle, projedeki iletişim, yardımlaşma ve işbirligi ihtiyacı çevik yazılım geliştirme süreci ile daha kolay karşılanabilirdi.</p><p>Özellikle çevik yazılım geliştirme süreci ile birlikte kullanılan sürekli teslim altyapısı projede kilit bir rol oynamaktadır. Proje bileşenlerinin çoklu olması nedeniyle yapılan herhangi bir degişiklige baglı olarak karşılaşılan problemlerin adreslenmesinde otomasyon altyapısından faydalanılmıştır. İlk kalite testleri otomatik birim testler ile saglanmıştır. Kalite testlerini geçen yazılımlar için otomatik test senaryoları oluşturulmuştur. Otomatik test senaryoları fonksiyonel testlerdir. Fonksiyonel testler kullanılarak sık kod girişi oldugunda geliştiriciye hatalarla ilgili hızlı geri dönüş saglanması ve düzeltilmesi için Jenkins sürekli entegrasyon sunucusu kullanılmıştır. Bu fonksiyonel testler sayesinde otomatik derleme yapılmış ve hatasız olması koşuluyla müşteriye verilecek dosyalar otomatik üretilmiştir.</p><p>Bu ve benzer projelerde kazanılan deneyimlere dayanarak bu çalışmaya konu olan proje gibi çok partili projelerde çevik yazılım geliştirme metodolojilerinin fayda sagladıgı ve projenin başarılı olmasında etkili oldugu gözlemlenmiştir.</p><p>Dagıtık yapılı ve birbirine çeşitli açılardan bagımlı olan projelerde takımların ihtiyaçları, bagımlılıkları, üretimleri ve dolayısıyla planları sıklıkla degişebilmekte ve çevik prensipler bu degişimlerin planlar dahilinde ele alınabilmesini ve yönetilebilmesini saglamaktadır.</p><p>Müşteriye yapılan sürekli ve hızlı teslimat prensibi nedeniyle otomasyon ihtiyaçları ayrıca öne çıkmakta ve proje başlangıcından itibaren takımların hepsinde benzer otomasyon altyapılarının kurulmuş ve fonksiyonel olması gerekmektedir.</p><p>Ayrıca proje planlarında takımların entegrasyon ihtiyaçlarından, teknik bagımlılıklarına, sorumluluk tanımlamalarından, lokasyon farklılıklarından ileri gelen tatil planlamalarına kadar çok çeşitli faktörlerin göz önüne alınması ve planlanması gerektigi deneyimlenmiştir.</p><p>Bu ve benzeri birçok nokta göz önüne alındıgında çevik yazılım geliştirme metodolojisinin, şelale yazılım geliştirme metodolojisine göre daha uygun, esnek ve hızlı planlar yapabilmeye olanak tanıdıgı deneyimlenmiştir ve şirketimiz tarafından uluslararası, çoklu partili projelerde yogunlukla kullanılmaktadır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Kaynaklar</head></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head></head><label></label><figDesc>Tablo 1. 2010-2015 Yılları Arasındaki Tüm Yazılım Projelerinin Başarı Oranları [2</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>S</head><label></label><figDesc>¸ekil 1. Uluslararası, Büyük Ölçekli, C ¸oklu Bileşenli Projelerde Bir Scrum Modeli Örnegi 3 Uluslararası, C ¸oklu Bileşenli C ¸evik Yazılım Geliştirme Projelerinde 3. Partilerle C ¸alışma Sırasında Karşılaşılan Zorluklar Bu bildiriye söz konusu olan projede 3. partilerle çalışma alanlarında karşılaşılan zorluklar ve etkilenen başarı faktörleri şu başlıklar altında incelenebilir.</figDesc></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<monogr>
		<author>
			<persName><forename type="first">Standish</forename><surname>Group</surname></persName>
		</author>
		<ptr target="https://www.infoq.com/articles/standish-chaos-2015" />
		<title level="m">Chaos Report</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<title level="m" type="main">A Multiple Case Study on Contradictions and Preconditions for Outsourcing Agile Software Development Projects</title>
		<author>
			<persName><forename type="first">M</forename><surname>Buslovic</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Deribe</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2012">2012</date>
		</imprint>
		<respStmt>
			<orgName>Linköping University</orgName>
		</respStmt>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<title level="m" type="main">Scaling Agile: An Executive Guide</title>
		<author>
			<persName><forename type="first">S</forename><surname>Ambler</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2010">2010</date>
			<publisher>IBM Agility at Scale</publisher>
		</imprint>
	</monogr>
	<note>White paper</note>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
