SCRUM Yazılım Geliştirme Metodu Üzerine Bir İnceleme ve Değerlendirme. An Overview and Evaluation of SCRUM method in Software Development

Transkript

1 SCRUM Yazılım Geliştirme Metodu Üzerine Bir İnceleme ve Değerlendirme Ecem İren 1, Aylin Kantarcı 2 1 Bilgisayar Müh. Bölümü, Gediz Üniversitesi, İZMİR 2 Bilgisayar Müh. Bölümü, Ege Üniversitesi, İZMİR Özet: Bu bildiride yazılım geliştirmede SCRUM yöntemi çeşitli yönleriyle incelenmiş ve tanıtılmıştır. SCRUM gelişimi ile ilgili bazı rahatsız edici noktalar tespit edilmiş ve dile getirilmiştir. Anahtar Sözcükler: SCRUM, çevik yazılım, GitHub, Huboard An Overview and Evaluation of SCRUM method in Software Development Abstract: In this paper, we examined and introduced SCRUM technique in software development in many aspects. We also emphasized on some disturbing points related to the evolution of SCRUM Keywords: SCRUM, çevik yazılım, GitHub, Huboard 1. GİRİŞ Yaygın olarak kullanılmakta olan Şelale (Waterfall) Yazılım Geliştirme Metodolojisi Gereksinimlerin Belirlenmesi, Analiz, Tasarım, Kodlama ve Ürüne Dönüştürme adımlarını içerir. Şelale metodolojisi gereği bu adımlar arasında katı sınırlar vardır. Bir adım tamamlanmadan diğer adıma geçilmez. Örneğin, Analiz aşamasına geçebilmek için tüm gereksinimlerin tam olarak belirlenmiş olması gerekmektedir. Bu yaklaşımda geri dönüşlerin mümkün olduğunca en aza indirgenmesi hedeflenmiştir. Her aşama sonunda resmi bir inceleme ve dokümantasyon işlemleri yerine getirilir. Geri dönüşler de benzer bir bürokratik yüke sahiptir. Yazılım testi yazılım geliştirme ile bütünleşik değildir. Testler, Ürüne Dönüştürme aşamasında gerçekleştirilir. Tüm yazılımların hata barındırdığı bir gerçektir. Ayrıca gereksinimler de çoğu durumda, büyük projeler söz konusu ise her durumda, tam olarak belirlenmesi mümkün değildir. Yazılım geliştirimi boyunca da mevcut gereksinimler değişebilir ve yeni gereksinimler eklenebilir. Şelale yönteminde geri dönüşten kaçınıldığından değişim ihtiyaçları yazılım geliştirme süreci sırasında dikkate alınmaz. Bu nedenlerden ötürü Şelale Metodolojisi esnek ve sağlam bir metodoloji değildir. Keşifçi geliştirmenin tekrarlamalı yapısını da yansıtmamaktadır [1]. Tüm dezavantajlarına rağmen halen yaygınlığını korumasının nedenleri geliştirilen ilk yazılım geliştirme metodolojisi olması, günümüzdeki yazılım geliştirme birim yöneticilerinin mühendislik eğitimi sırasında bu metodolojiyi öğrenmiş olmaları, mezuniyetten sonra işe başladıkları kurumda bu metodolojinin kullanılmakta olması ve yoğun iş yükü nedeniyle yeni metodolojilere geçişin güçlüğüdür. Öte yandan bilgisayar mühendisliği öğrencileri en küçük projeleri bile iteratif (arttırımlı) bir şekilde geliştirirler: En temel gereksinimler ve bunlara dayalı çekirdek kod ilk önce tasarlanır, kodlanır

2 ve test edilir. Bu kodun sağlamlığı garantilendikten sonra sıradaki uygun gereksinimlere geçilir. Bu gereksinimleri yerine getiren kodlar tasarlanır, kodlanır ve mevcut koda eklenerek test edilir. Bu döngü yazılım geliştirme sürecinin sonuna kadar bu şekilde devam eder. Her nedense doğal, esnek ve makul bir yazılım geliştirme metodu olan İteratif metodoloji (Arttırımlı yaklaşım) Şelale modelinden çok daha sonra literatüre girmiştir. Bu yaklaşımın Şelale modelden ne kadar üstün olduğu da aşikardır. En basitinden Şelale modelinde tasarım aşamasında sistemin tam ve detaylı tasarımı yapılıp dökümante edilmesi gerektiğinden yazılım geliştirimine başlama gecikir. Arttırımlı modelde başlangıçta temel bir tasarım oluşturulur ve pratik bir şekilde dökümante edilir. Dolayısı ile yazılım geliştirimine daha kısa zamanda girişilir. Ana tasarım, geliştirim süreci içinde evrilerek detaylandırılır. Şelale modelde tasarım değişikliği ana tasarım üzerinde yapılır ve tüm tasarım gözden geçirilir. Arttırımlı modelde ilk tasarım üst düzeyde olduğu ve tüm tasarım zaman içinde evrildiği için tasarım aşaması daha esnek ve rahattır [2]. Arttırımlı yaklaşımın Şelale yöntemine göre başka bir üstünlüğü de müşteriyi yazılım geliştirme sürecinin tüm adımlarına katmasıdır. Gereksinimlerin ana belirleyicisi müşteridir. Şelale modelde müşteri sadece Gereksinim belirleme aşamasında sürece katılır. Oysa bir çok durumda müşteri ara geliştirimleri incelediğinde yeni gereksinimlerin farkına varır ya da bazı gereksinimlerin değişiklik yapmanın uygun olduğunu fark eder [2]. Günümüz yazılımları bir çok gereksinimi yerine getiren kapsamlı yazılımlardır. Bu yazılımların geliştiriminde Şelale modeli kullanmak ürün geliştirimini çok zorlaştırır ve ürün teslim tarihini de geciktirir. Öte yandan bu yazılımlar bir ekip tarafından gerçekleştirildiği için öğrencilikte kullanılan Arttrımlı metodoloji de tek başına yeterli olmaz. Bu durumda arttırımlı çatı üzerine geliştirilmiş Çevik Metodolojiler en uygun yazılım geliştirme metodolojileridir. Agile Alliance, Çevik Metodoloji ilkelerini Çevik Bildiri (Agile Manifesto) adı altında aşağıdaki şekilde özetlemiştir. Bu bildirideki maddeler aynı zamanda Çevik Metodolojinin Şelale ve benzeri metodolojilere göre üstünlüklerini oluşturmaktadır [3]. Süreçler ve araçlar yerine bireyler ve bireyler arası etkileşim Ayrıntılı dokümantasyon yerine çalışan yazılım Sözleşmeler yerine müşteri işbirlikleri Belirli bir planı izlemek yerine değişen koşullara hızlı cevap üretme Günümüzde proje ekiplerinde yazılım geliştirme doğasına en uygun Çevik Metodoloji SCRUM metodudur. Bu bildiride SCRUM yöntemi incelenecektir. 2. SCRUM SCRUM, Rugby (Ragbi) oyununda 8 kişiden oluşan bir takım anlamına gelmektedir. Bu takımda her bir birey diğer bireyle topu alanda hareket ettirmek için birlikte hareket eder. Sıkı bir şekilde çalışan takımlar, rolü iyice tanımlanmış olan takım elemanıyla bütünleşmiş (birleşik) birimler ve tek bir amaca odaklanmış bütün bir takım bu oyunun en önemli özelliklerindendir. Yazılım mühendisliğinde SCRUM isimli çevik metod, yazılım ekiplerinin benzer hedeflere sahip olmaları ve benzer strateji ile hareket etmelerinden dolayı Rugby takımından esinlenilerek bu ismi almıştır. SCRUM yazılım geliştirme yaklaşımı, kompleks ortamlarda yazılım inşa etmek için kullanılan arttırımlı bir süreçtir. SCRUM herhangi bir kaotik durumda

3 organizasyonun bu kaosu tolere edecek şekilde geliştirmeyi sürdürmesine olanak tanımaktadır. SCRUM metodolojisi, oldukça esnek bir geliştirme süreci sürdürebilmek için tasarlanmıştır. SCRUM, ürün çıktısını planlamayı ve proje ilerlerken değişkenleri yönetebilmeyi mümkün kılmaktadır. Bu durum, organizasyonlara herhangi bir zaman diliminde projeyi ve teslimatlarını değiştirebilme imkanı vermekte ve bunun sonucunda mümkün olan en kısa sürede en uygun ürün çıktısını ortaya çıkarmaktadır [4]. Bu metodolojinin avantajlarını müşteriye, kuruma ve yazılımcıya yönelik olmak üzere 3 kategoride net bir şekilde açıklayabiliriz: Müşteri açısından avantajlar: Önceki yöntemlerde müşteri sadece gereksinim belirleme ve son ürün aşamalarında sisteme entegre iken SCRUM metodolojisinde yazılım süreci boyunca müşteri-kurum ilişkisi söz konusudur. Başlangıç gereksinimler müşteri ile belirlenir. Tüm yazılım geliştirme süreci kısa süreli koşu (sprint) olarak adlandırılan dönemlere bölünür. Her koşu sonunda bir ara ürün oluşturulur ve müşteriye sunulur. Müşteri ara ürünü incelerken aklına yeni gereksinimler gelebilir, bazı gereksinimlerde değişiklik yapmanın uygun olduğunun farkına varabilir. Müşterinin öngördüğü değişiklikler bir sonraki koşuda yerine getirilir. Bu şekilde geliştirme takımının müşteri ihtiyaçlarına olabildiğince hızlı cevap vermesi sağlanmış olur. SCRUM un en büyük kazanımı bu özelliğinden kaynaklanmaktadır. Geleneksel Şelale yönteminde ara kontroller yoktur ve son aşamada ortaya çıkan değişim istekleri çok büyük zorluk ve huzursuzluk çıkarır. Ürün teslimatının önemli ölçüde uzamasına sebep olur. odaklanacağı için bu yöntem fazla yükü ve iş tekrarını önler. Geliştirme takımının verimliliğinin artması, metodolojinin müşteriye sağladığı faydalar ve müşteri memnuniyeti gibi faktörler müşterinin organizasyon hakkındaki olumlu düşünceler oluşturmasını ve organizasyona referans olmasını sağlar. Bunun sonucunda organizasyonun pazar potansiyeli de artar. Yazılımcı açısından avantajlar: SCRUM yazılımcıların ekipler halinde çalışmasını ve ekiplerin müşteri kanalı ile dış dünyaya açılmasını gerektirir. Şelale yöntemi gibi yöntemlerde bireysellik daha yoğun yaşanır. Yoğun bireysellik yazılımcıda enerji düşüklüğü, işten soğuma ve bu nedenlerle yavaşlama, konsantrasyon düşüklüğü gibi etkiler yaratır. İşin geliştirim süreci uzar ve yazılım hataları artar. Yazılım geliştirme süreci sırasında değil de süreç sonunda yazılımcıdan istenen değişiklikler yazılımcının gerilimini arttırarak isteksiz bir şekilde yazılımını değiştirmesine ve yazılım geliştirme sürecine başlamasına neden olur. Öte yandan SCRUM yazılımcıya dinamik ve sosyal bir ortam sunar. Yazılımcı, geliştirme süreci sırasında ekip arkadaşlarıyla sık sık bir araya geleceği için mutluluğu ve işine olan sevgisi artar. Ekip üyeleri arasında paylaşım ve katkılar yoğun olacağı için karşılaştığı sorunlar daha kısa sürede çözülür ve sorunun da ekip olarak sahiplenilmesi nedeniyle yazılımcının bireysel stresi düşük olur. Yazılım geliştirme süreci değişiklik isteklerini paralel olarak ele almayı gerektirdiği için de geri dönüş yükü minimuma indirgenir ve geri dönüş stresi de normal boyutta olur. Kısaca SCRUM yöntemi yazılım geliştiricinin ruh sağlığını koruyan ve kişisel gelişimine katkı sağlayan bir yöntemdir. Kurumsal avantajlar: Organizasyon sadece öncelik sırasına koyulmuş müşteri senaryolarına

4 3. SCRUM GELİŞİMİ İlk SCRUM uygulaması 2004 yılında Jeff Sutherland tarafından gerçekleştirilmiş ve dünyaya açıklanmıştır [5]. Bu uygulamada 6 aylık bir proje birer aylık koşu (sprint) adı verilen 6 döneme bölünmüştür. Yarım gün süren ilk SCRUM toplantısında ürün gereksinim listesi (product backlog) oluşturulmuş ve sadece ilk koşunun detaylı planlaması yapılmış, diğer koşular ise kabaca tanımlanmıştır. Daha sonra her gün sabah 30 dakikalık bir SCRUM toplantısı yapılmış ve üyeler Dün ne yaptın?, Bugün neler yapacaksın? ve Önünde ne gibi engeller/zorluklar var? sorularına cevap vererek birbirlerini bilgilendirmişlerdir. Ayrıca ekip üyeleri ortaya çıkan problemlere çözüm önerileri sunarak birbirlerini desteklemiş ve o günkü işlerini kolaylaştırmışlardır. Her koşu başında oluşturulan koşu gereksinim listesindeki işler öncelik sıralamasına alınarak gerçekleştirilmişlerdir. Gerçekleştirim sırasında extreme Programming pratiklerine [6] dayalı yazılım testleri de büyük bir titizlikle yerine getirilmiştir. Bir koşu içinde her Cuma günü ara ürün prototipi müşterilere sunulmuştur. Müşteriler, bu sunumlarda yeni gereksinimlerin farkına varmanın yanı sıra önemli yazılım hataları da yakalamışlardır. İzleyen haftada bu hataların düzeltilmesi ve yeni gereksinimlerin gerçekleştirilmesine başlanmıştır. Yazılım geliştiricilerin kodlama hatalarının müşteriler tarafından yakalanmış olması bir mahcubiyet meydana getirerek onları daha dikkatli kod yazmaya sevk etmiş ve zaman içinde kodlama hatalarının hızla düştüğü gözlenmiştir. Her koşu sonunda ilgili şirket yöneticisine de demo yapılarak ürünü kullanması sağlanmıştır. Yöneticiden gelen geri bildirimlerin değerlendirilmesi ve ürüne entegre edilmesi ile o koşu başarı ile kapatılmıştır. Tüm koşular bu şekilde tamamlanarak 6 ay sonunda planlanandan daha çok işleve sahip ürün gecikme olmadan müşteriye teslim edilecek hale getirilmiştir. İlk SCRUM uygulaması tek bir ekipten oluşan bir yazılımcı grubu ile gerçekleştirilmiştir. Çok geniş kapsamlı projelerde projelerin çok sayıda ekip tarafından geliştirilmesi söz konusu olmuştur. Bu durumda ürün gereksinim listesi bağımsız parçalara ayrılarak ve her bir parça 7-9 kişiden oluşan bir ekibe verilerek birbirine paralel olarak SCRUM mantığıyla geliştirilmiştir. Bu uygulamadan da büyük çaplı projeler için SCRUM of SCRUMs isimli bir geliştirme modeli ortaya çıkmıştır. Bu modelde her ekip günlük koşu toplantısını yapar. Daha sonra ekip liderleri bir araya gelerek ikinci bir toplantı daha yaparlar. Bu toplantıda ekip liderleri Senin takımın dün ne yaptı?, Bugün neler yapacaksınız?, Ekibinizin önünde engeller var mı?, Yakınlarda başka bir takımın önüne konulacak bir ara ürün olacak mı? gibi sorularla ekipler arası entegrasyon sağlarlar. Gerektiğinde bu toplantıdan çıkan sonuçları kendi ekipleri ile paylaşarak yazılım geliştirme sürecinin esnekliğini ve dinamizmini korurlar [7]. Kısa süre içinde SCRUM doğallığı ve avantajları ile yazılım şirketlerini cezbetmiş ve yaygınlaşmaya başlamıştır. Buna paralel olarak SCRUM metodolojisi yazılım mühendisliğinin gözde araştırma konularından biri haline gelmiştir. Yenilik peşinde koşan birçok araştırıcı SCRUMa çeşitli katkılar yapmış ve çeşitli yayınlarla bunları yazılım geliştiricilere sunmuşlardır. SCRUM hakkında bilgi veren yüzlerce sayfalık kitaplar yazılmış, geniş kapsamlı web siteleri oluşturulmuştur. Ayrıca, SCRUM eğitimi veren şirketler ve SCRUM işlemini kolaylaştırmayı hedefleyen yazılımlar ortaya çıkmıştır. Kısaca Jeff Sutherland tarafından 3 sayfada tanıtılan bu doğal yaklaşım büyük bir pazar haline gelmiştir.

5 Kuşkusuz SCRUMa ilginin artması ve SCRUM tekniğinin kullanımının yaygınlaşması sevindiricidir. Ancak kısa süre içinde öğrenilebilecek bu doğal tekniği sömürerek yararlanmaya çalışmak da üzüntü vericidir. Bu tekniğin nasıl sömürüldüğünü tüm dünyadaki yazılım ofisleri için SCRUM ana kaynağı olan sitesini inceleyerek görebiliriz. Bu siteyi incelediğimizde elde ettiğimiz bulguları şu şekilde listeleyebiliriz: 1. Bu bölümün başında özetlenen ilk ve başarılı SCRUM uygulamasını tanıtan bildiride SCRUM metodu ile ilgili SCRUM literatürüne girebilecek sadece 3 adet yeni terim sunulmuştu: sprint, product backlog list, SCRUM master. Scrum.org sitesini incelediğimizde What is SCRUM? linkini tıkladığımızda karşımıza gelen bilgiler arasında 2 sözlük dikkatimizi çekiyor: SCRUM Glossary ve Proffessional SCRUM Developer Glossary. Bunlardan ilkinde 29, 2.sinde ise 35 adet terim bulunuyor. 2. SCRUM Guide linkini tıkladığınızda karşınıza 13 sayfalık bir SCRUM tanıtım dökümanı geliyor. Tekniğin başarısını kanıtlayan 5 sayfalık ilk bildiride ise sadece 3 sayfa bu iş için yeterli idi. 3. Büyük projeler için SCRUMs of SCRUMs versiyonu ile ilgili yeterli bilgi ilgili kaynakta sadece 4 madde ile veriliyordu [7]. SCRUM.org sitesinde bu konuyu NEXUS FRAMEWORK başlığı verilerek isimlendiriliyor. İlgili tanıtıcı doküman ise 10 sayfa uzunluğunda. 4. Sitede yukarıda bahsedilen SCRUM dökümanları incelendiğinde tekniğin doğallığından uzaklaştırılarak otomatize edildiği izlenimi yaratılıyor. Dökümanları incelerken SCRUM uygulayabilmek için dökümanların içeriğine tümüyle hakim olmak zorunda olduğunuzu hissediyorsunuz. İlk SCRUM bildirisi gayet akıcı ve motivasyon arttırıcı bir şekilde okunduğu halde bu dökümanlarda robotlaştıran bir öğrenme süreci hakim durumda. 5. Sitede ve dökümanlarda dinamik SCRUM yaşam döngüsü Şekil 1 deki gibi veriliyor. Bu şeklin havalı fakat SCRUM sürecini karmaşık gösteren bir yapıya sahip olduğunu görüyoruz. Şekil 1. sitesinde verilen SCRUM yaşam döngüsü

6 6. Sitede Courses başlığını tıkladığınızda karşınıza ücretli SCRUM kurslarının listesi geliyor. 5 tür eğitim var. Bunlardan 2 si 2şer günlük temel SCRUM ve SCRUM of SCRUMS eğitimleri. Diğer 3ü Product Owner(2 gün), SCRUM Master(2 gün) ve SCRUM Developer (3 gün) eğitimleri. Tüm eğitimler birbirinden bağımsız görünüyor. Ancak her bir eğitime katılabilmeniz için Ön Şartlar listeleniyor. Ön Şartlar sitede 30 soruluk bir OPEN SCRUM testinden başarılı olmanızı ve temel SCRUM eğitimi almanızı gerektiriyor. Her eğitimin sonunda bir test yapılıyor ve bu testi geçerseniz ilgili eğitime ait Uluslararası bir sertifika hakkı kazanmış oluyorsunuz. Her kurs gibi her bir teste girebilmek için yüksek bir ücret ödemeniz gerekiyor. 7. Sertifika alabilmek için alınması gerek testlere siteden ulaşılabiliyor. Ücretsiz olduğu için bu sayfadaki 4 SCRUM eğitimine katılabilmek için ön şart olan OPEN SCRUM test linkini tıkladık. Karşımıza 30 soruluk bir test çıktı. Bu testin sorularını SCRUM konusunda uygulama deneyimi de bulunan Yazılım Mühendisliği alanında Profösörlük derecesi bulunan bir akademisyenle analiz ettik. Sadece 10 soru böyle bir test için uygundu. 5 soru şaşırtmalı ifadeler içeriyordu. 5 soru için 2 adet doğru cevap bulunuyordu. Diğer 10 soruda tamamen yanlış cevaplar doğru cevap olarak veriliyordu. Ayrıca bir çok soru da gereksizdi. Bu sorulara yanlış cevap vermeniz SCRUM yapamayacağınız anlamına gelmiyordu. Dolayısı ile bu testten başarısız olma olasılığınız çok yüksektir ve SCRUM eğitiminin ilk basamağı olan Temel SCRUM eğitimini atlama şansınız yok edilerek bu eğitimi almaya zorlanmaktasınızdır.. 8. SCRUM eğitimleri ile ilgili sayfada her bir eğitim için çeşitli kitaplar da önerilmekteydi. Çok sayıda ve gayet kalın olan bu kitapları incelediğinizde SCRUMun çok detaylı ve çok geniş kapsamlı bir teknik olduğu hissine kapılıyorsunuz. Bu siteyi incelediğinizde SCRUM hakkında hiç bilgi sahibi olmayan bir kişinin kapıldığı izlenim şu şekilde özetlenebilir: SCRUM yüksek miktarda detay içeren karmaşık bir tekniktir. Öğrenmek zaman alır ve tek başına öğrenilmesi zordur. Her biri için yüksek miktarda ücret ödeyerek çok sayıda eğitime katılmak uygun bir seçenektir. Ayrıca yine ücret karşılığında -aslında güvenilir de olmayan- testler alarak uluslararası bir sertifika ile- tüm dünyaya kendinizin yeterli bir SCRUM uygulayıcısı olduğunu kanıtlamanız iyi olabilir. Bir de ülkemizdeki durumu görmek için SCRUM eğitimi veren danışmanlık şirketlerinin programlarını inceledik. Ülkemizde 4-5 şirketin bu eğitimi verdiğini gördük. Eğitim 2 günlüktü ve scrum.org un eğitimleri gibi farklı SCRUM rollerine farklı eğitimler düzenlenmiyordu. Ürün yöneticiler, ekip liderleri, yazılım geliştiriciler aynı kursları alıyordu. Eğitim içerikleri de SCRUMu yeterli düzeyde tanımak ve öğrenmek için yeterli düzeyde idi. Ayrıca Bilgisayar Mühendisleri odasının düzenlediği yarım günlük ücretsiz bir eğitime de rastladık. Bu eğitimin içeriği de oldukça tatmin edici idi. Yarım günlük bu eğitimin de SCRUM tekniğini öğrenmeniz için yeterli olabildiğini gördük. Ülkemiz ve yurt dışındaki SCRUM eğitimlerini karşılaştırdığımızda, ülkemizdeki eğitimin SCRUMun doğal yapısına daha uygun olduğunu, daha düşük maliyetli olduğunu ve SCRUMa geçişi hızlandırıcı olduğunu söyleyebiliriz. SCRUMu kompleks hale getirip öğrenmeyi zorlaştırdıkça ve bunun üstüne bir de maliyeti arttırıldığında SCRUMa geçişin gecikeceği de aşikardır.

7 SCRUMun gelişimini incelemek için bir de SCRUM yazılımlarını inceledik. SCRUM tools şeklinde anahtar kelime verince karşımıza pek çok yazılım geldi. Hepsini detaylı inceleyemeyeceğimiz için konu ile ilgili olarak bu ortamlar hakkında bilgi sahibi olan bir uzmana danışmamızın daha uygun olduğunu gördük. Uzman kişi SCRUM yönetiminde kullanılabilecek en uygun araçların GitHub ve bu ortama entegre edilen HuBoard yazılımı olduğu yönünde görüş bildirdi. GitHub, Linux un yaratıcısı Linus Torvalds tarafından çok yazılımcılı ortamlar için yaratılmış bir kaynak kod kontrol sistemidir. Linus Torvalds ın dağıtık olarak geliştirilen Linux deneyimi nedeni ile bu tür bir ortamın ihtiyaçlarını iyi analiz etmiş olması GitHub u diğer ortamlardan üstün kılan en önemli özelliğidir. GitHub ın temel işleyişi şöyledir: Bir projenin farklı modülleri için birer dallanma yapılır (branching). Depo ya (repository) erişim yetkisi olan bir yazılımcı sorumlu olduğu modülü (dalı) kendi bilgisayarına alır. Gerekli değişiklikleri yapıp kendi makinasında kararlı hale getirdikten sonra (commit) ana depoya (repository) gönderir(push). Diğer kullanıcılar son değişiklikleri kolayca depodan alırlar (pull). Bunun yanı sıra yazılımcının kaynak kodun tümünü kendi bilgisayarına alması (forking) mümkündür. Bu özellik özellikle açık kaynak kod geliştirenlerin işlerine çok yarar. Ayrıca, GitHub CLOUD ortamlarının da depo olarak kullanımını sağladığı için bir çok versiyon kontrol sistemini geride bırakır. Tüm bu işlerin Linux mantığına hakim ve pratik tasarım/geliştirim yapabilen Linus Torvalds sın geliştirdiği çok basit bir protokol olan Git protokolüne dayalı olarak gerçekleştirilmesi GitHub u diğer ortamlardan hızlı ve etkin hale getirmiştir [8]. HuBoard ise GitHub a entegre edilebilen bir proje kontrol aracıdır [9]. GitHub a entegre edilen bir çok proje kontrol aracı bulunmaktadır. Esnek, düzenli ve kolay anlaşılır arayüzü ve CLOUD ortamını GitHub a uyumlu şekilde kullanması Huboard ı diğer proje yönetim araçlarından üstün hale getirmiştir (Şekil 2). Günümüzde GitHub ve ona entegre Huboard kullanan yazılım ekiplerinin sayısı gittikçe artmaktadır. Yakın bir gelecekte bu alana hakim yazılım geliştirme ortamının GitHub/HuBoard olacağı tahmin edilmektedir. GitHub ve HuBoard ortamlarının sadelik ve kullanım kolaylığını gördükten sonra diğer SCRUM araçlarından birkaç tanesinin arayüz görüntülerini inceledik. Bu arayüzlerden bazıları SCRUM un özüne ait olmayan ve kurum için geçerli olmayabilecek bilgilerin girilmesini gerektiriyordu. Arayüz görünümleri genel olarak karmaşık ve dağınıktı. Günlük SCRUM toplantılarının tutanağının girildiği arayüzler de bulunmakta idi. Bu karşılaştırım GitHub ve HuBoard ortamlarının ne kadar doğru bir seçim olduğunu gözler önüne serdi. Diğer yazılımların bir kısmı SCRUMu otomatize hale getirdiğini gördük: Günlük toplantılarda bir deftere not almak varken bilgisayarda çeşitli girişler yapmak toplantıyı doğallıktan uzaklaştırır. Toplantıyı takip etmek de zorlaşır. Tüm bunların SCRUM başarısını olumsuz yönde etkileyeceği ve katılımcıları gereceği açıktır. 4. SONUÇ ve ÖNERİLER SCRUM, değişen gereksinimlere hızlı uyum sağlamayı mümkün kılan, yazılım hatalarını azaltan, yazılım ekiplerinin entegrasyonuna zemin hazırlayan ve bu nedenlerden ötürü müşterilerin ve yazılımcıların memnuniyetini arttıran çevik bir yazılım geliştirme metodudur. SCRUM, mümkün olduğunca basit tutulmalı ve gerçekleştirimiyle ilgili temel gereksinimleri içeren genel bir yöntem olarak tanıtılmalıdır. Her kuruluş kendi SCRUMunu kendi ihtiyaçlarına

8 göre düzenlemelidir. Kesin kurallar esneklik kaybına ve verim düşmesine neden olur. SCRUM adaptasyonunu da güçleştirir. SCRUMun kurum ihtiyaçlarına göre düzenlendiği örnekler mevcuttur [10]. Şekil 2. HuBoard Arayüzü Kaynaklar 1. Tudor D., Walter G. A. Using an Agile Approach in a Large Traditional Organization. IEEE Agile Conference, Basili V. R., Turner A. J. Iterative Enhancement: A Practical Technique for Software Development. IEEE Transactions on Software Engineering, Agile manifesto: 4. Cho J., Issues and Cahllenges of Agile Software Development with SCRUM, Issues in Information Systems, pp: , Sutherland J. Agile Development: Lessons Learned from the First Scrum extremeprogramming web sitesi: GitHub web sitesi: 9. HuBoard web sitesi: Rising L., Janoff N. S. The Scrum Software Development Process for Small Teams. IEEE Software pp:26-32, 2000.