Scrum (engl. "itişip kakışma“), yazılım Mühendisliği'nde bir uygulama geliştirme yöntemidir. Bu geliştirme yönteminin temel özelliği gözlemci, geliştirmeci ve tekrara dayalı olmasıdır. Birçok modern yazılım projesinin oldukça karmaşık olduğu ve en baştan tümünü planlamanın zor olacağı şeklindeki bir varsayımdan hareket eder.
Bu karmaşıklığı 3 maddeden oluşan ana felsefesi ile yönetir.
- Şeffaflık (transparency): Projedeki ilerlemeler ve sorunlar günlük olarak tutulur ve herkes tarafından izlenebilir olması sağlanır.
- Denetleme (inspection) : Ürünün parçaları ya da fonksiyonları düzenli aralıklarla teslim edilir ve müşteri denetimine sunulur.
- Uyum (adaptation): Gereksinimler en baştan bir defalığına belirlenmez, bilakis her teslimat tekrar değerlendirilir ve yeni duruma uyum sağlanır yapılır.
Amaç başlangıçta hayal edilen ve tasarlanana uyan bir ürünün, hızlı, ucuz ve kaliteli şekilde üretilmesidir. Tasarlanan ürünün gerçekleştirilmesi, müşteri/kullanıcı tarafından mümkün olduğunca detaylı şekilde hazırlanmış bir talepler listesinin aşama aşama gerçekleştirilmesi biçiminde yapılmaz. Bunun yerine müşteri/kullanıcı tarafından istenilen ve tanımlanan işlevler, iki ya da dört haftalık "Sprint" adı verilen dönemler içerisinde geliştirilir ve yeniden gözden geçirilir. Bu kullanıcı bazlı gereksinim tanımı Kullanıcı Hikayesi olarak nitelenir ve özellikler defterinde (Product Backlog) yer alır. Her Sprint sonunda yazılımın fonksiyonel bir parçası bitmiş ve müşteriye teslim edilebilir bir durumda olur.
Scrum Çevik yazılım geliştirme prensiplerini hayata geçiren bir yöntemdir.[2]
Scrum 6 ilke ile yürütülür.Scrum ilkeleri, Scrum metodunu uygulamak için temel kılavuzlardır ve zorunlu olarak tüm Scrum projelerinde kullanımı tercihe bağlı değil zorunludur.
Scrum'ın 6 ilkesi;
- Deneyimsel Süreç Yönetimi - Bu ilke, üç ana şeffaflık, denetleme ve uyum fikrine dayanan Scrum'un ana felsefesini vurgulamaktadır.
- Kendini yöneten Takım - Bu ilke, kendini yönetmesine izin verildiğinde çok daha fazla değer sunan günümüz çalışanlarına odaklanır ve daha iyi bir takımın katılımı ve paylaşılan sahiplenme ile sonuçlanır; Böylece ilerleme için daha elverişli olan yenilikçi ve yaratıcı bir ortam oluşturur.
- İşbirliği - Bu ilke, işbirliğine dayalı çalışma ile ilgili üç temel boyuta odaklanır: farkındalık, etkilrşim ve benimseme. Aynı zamanda, proje yönetimini en büyük değeri sunmak için birlikte veya etkileşimli çalışan ekiplerle paylaşılan bir değer yaratma süreci olarak savunur.
- Değere odaklı Önceliklendirme - Bu ilke, Scrum'un odak noktasını vurgulamakta, projenin başından itibaren sonuna kadar maksimum iş değeri sunmaya odaklanmaktadır.
- Zaman sınırlaması - Bu prensip, zamanın Scrum'da nasıl sınırlayıcı bir kısıtlama olarak kabul edildiğini ve proje planlama ve uygulamasının etkin bir şekilde yönetilmesine yardımcı olmak için nasıl kullanıldığını açıklar. Scrum'daki zaman Sınırlı öğeler arasında Sprintler, Günlük Scrum Toplantıları, Sprint Planlama Toplantıları ve Sprint İnceleme Toplantıları bulunur.
- Artırımlı Geliştirme - Bu prensip artırımlı gelişimi tanımlar ve değişiklikleri daha iyi yönetmenin ve müşteri ihtiyaçlarını karşılayan ürünler oluşturmanın önemini vurgular. Ayrıca Ürün Sahibinin ve kuruluşun artırımlı gelişim ile ilgili sorumluluklarının altını çizer.
Roller
Scrum Süreç-Modeli net olarak üç çeşit rolü tanır: Ürün Sahibi, Takım ve Scrum Ustası Dış roller ya da yan roller olarak da: işletme, müşteri, kullanıcı ve pazarlama Takım kendi içinde üç ayrı yetenek barındırır: Yazılımcı, Testçi ve Tasarımcı
Etkileşim
Scrum Ustası (ScrumMaster) : Takımı korumak ve yardımcı olmak. Ürün sahibine yardımcı olmak.
Ürün Sahibi( Product Owner) : Kullanıcı hikâyelerinin ayrıntılarını takım ile konuşmak. Dış rollerdekiler ile "Kullanıcı Hikâyeleri"ni belirlemek.
Takım(Development Team) : Gereksinim ayrıntılarını Ürün Sahibine (Product-Owner) açıklar.[4]
Ürün Sahibi (Product Owner)
Ürün Sahibi stratejik ürün geliştirmeden sorumludur. Sorumluluğu net bir ürün vizyonunun Tasarımı, iletişimi, özelliklerin tanımı ve önceliklendirme, teslim edilen sprintin işlevselliği ve kabul edilebilir olup olmadığına karar verme ve şirketin ekonomik faydasına uygun ürün tasarımı ve ana amaçları belirler. [5] Yalnızca o teslimat, işlevsellik ve maliyet gibi kararlardan sorumludur.
Ürün Sahibi ürün özelliklerinin tanımlaması işlemini Ürün Gereksinimini (Product Backlog) kullanır ve yazılım Takımı ile birlikte çalışarak kullanıcı hikâyelerini (User Stories) taşır ve kullanıcı bazlı işlevsellikleri ifade eder. Aldığı kararlar bağlayıcıdır ve iptal edilemez.[6]
Ürün Sahibi ya da proje sorumlusu son kullanıcının bakış açısını üstlenir ve yazılım gelişimini kontrol edip yazılımcılar için hazır bulunur. XP metodunun tersine projenin tek sorumlusudur.
Görevleri: Gereksinim Yönetimi, Yayın Yönetimi (Release) ve iletişim
Geliştirme Takımı
Yazılım ekibinin görevi ürün sahibinin taleplerine ve sıralamasına uygun ürünün işlevselliğini sağlamak ve belirlenen kalite standartlarına uymak koşuluyla ürünü teslim etmektir. Ne kadar ve hangi işlevlerin sprinte dahil olacağına kendileri karar verirler.
Scrumda geliştirme takımı bir ekip olarak algılanır ve iyi ya da kötü sonuçlar takım elemanlarına çıkartılmaz bilakis takımı bir birim olarak algılar. Bir takım 5-9 kişiden oluşur.
Ek olarak yazılım takımı kullanıcı hikâyelerinin çerçevesini tahmin edebilir ama kural olarak da bir günü geçmemelidir.
Scrum takım içinde rol dağılımıyla ilgilenmez. Belirtildiği gibi Scrum bir yönetim metodudur. Tabii ki bütün roller ya da daha doğrusu yetenekler başarılı bir proje gelişimi için hazır olmak zorundadır.
Bir takımda olması gereken özellikleri iki başlık altında ifade edebiliriz:
1) Kendi kendine organize ve küçük
2) Multidisipliner ve özerk
Scrum Yöneticisi (Scrum Master)
Scrum Ustası Scrum'un başarılı olmasını sağlamaktan sorumludur. Bunu başarmak için Yazılım Takımı ile birlikte calışır ama takıma tabii olmaz. Scrum kurallarını bildirir, uyumu kontrol eder ve toplantı moderatörlüğünü yapıp Scrum sürecindeki düzensizlikler ile ilgilenir. İş aracı olarak engel-birikimini (Impediment Backlog) takımın önündeki engelleri kaldırmak için kullanır ve bu anlamda sorumluluk taşır. Olası engeller: Takım içindeki iletişim eksikliği, kişisel çelişkiler, takım ve ürün sahibi arasındaki iletişim, dış kaynaklı rahatsızlıkların (ek işlevler gibi) giderilmesi. Scrum ustası yazılım takımına karşı yürütme yetkisi vardır ancak şeflik yetkisi yoktur bu anlamda ne hüküm verebilir ne de disiplin kovuşturması yapabilir (Servant Leaders > Hizmetkar Liderlik). [10]
Scrum ustasının kim olacağının belirlenmesinin en ideal yolu yazılım takımı tarafından seçilmesidir.Pratikte bu pek mümkün olmayabilir.Çünkü iş yapan firmalar Scrum takımının Scrum metodolojisine tam uyum sağlamaları için Scrum konusunda deneyimli bir personeli proje başında belirleyebilir. Eğer Scrum birinci etabını geçtikten sonra, Scrum ustasının rolü değişiklik yöneticisi (Change-Manager) olarak algılanır. [11]
Özet olarak Scrum ustası (Change Agent) : Süreçten sorumlu, takımın arkadaşı ve yardımcısı, sürecin doğruluğunun denetleyicisi, takım ile birebir bağlantılı ve Takımın yanında çalışır.
Görevi:
- Scrumu uygulamak ve ürün sahibi ile yazılım takımına destek olmak.
- Engelleri kaldırmak (örnek; rol sahipleri arasındaki çelişkiler) ve süreçteki sapmaları düzenlemek.
- Takıma hizmet etmek ve meslektaş bir yönetim tarzı ile yönetmek.
Kullanıcı (User)
Kullanıcı ilerideki yazılımın/ürünün kullanıcısıdır. Ürünün nasıl bir perspektif ile kullanılacağı konusunda fikir verir ve gerçek hedef kitlesidir. Kullanıcı Sprint başlangıcı ve sonucunda ürünü test etme amaçlı yer alır ve geri bilgi akışı (Feedback) sağlar.
- Kullanılabilirlik (Usability) konusunda takıma değerli ipuçları verir
- Takım ve ürün sahibi kullanıcı bilgileri doğrultusunda Sprint-planını uyarlar ve son durum tekrar kullanıcı tarafından test edilir.
Yönetici (Management)
Yönetici de kullanıcı ve müşteri gibi Scrum ekibine az oranda tabiidir. Ama scrumun yapısal çerçevesini yönetici belirler. Ek olarak da kaynakları oluşturur(yer, alet vs.). Scrum ustasına destek olur ve mesleki personel organizasyonu sağlar. Scrum ekibini dış taleplerden korumak gibi bir sorumluluğu vardır.
Görevi: Projenin çerçevesi ile ilgilenir ve Scrum ustasının proje alanı içerisindeki belirlediği problemlerin çözümü ile ilgilenir.
Takım ve Etkileşim
Rol dağılımında takım kendi kendini organize eder. Ne Scrum ustası ne de ürün sahibinin takım içinde kimin neyi ne zaman kiminle yapacaklarına dair bir yaptırımı olmaz. Scrum ustasının vazifesi yalnızca takımın farklı etkenlerlerle rahatsız edilmemesine dikkat etmektir.
Rollerin istismar riski
Scrum'da klasik "Proje Yöneticisi'nin olmayışı, özellikle deneyimsiz bir Scrum ekibinde, Scrum ustası ya da ürün sahibinin (Product Owner) bu rolü üstlenmesi tehlike yaratır ve takımın Özerklik statüsüne zarar vererek, Scrumda sapmalara yol açar.Bu tehlikeyi azaltmanın yolu Scrum-ustası ve ürün sahibinin bir Scrum-Expert'inden yardım almasıyla sağlanabilir. [14]
Srum Toplantıları;
Sprint Planlama Toplantısı 1
Bu toplantıda ürün sahibi kendi yazılım takımına ürün içeriğinde(Product Backlog) kararlaştırılan kullanıcı hikayelerini (User Stories) öncelik sırasına göre belirtir ve gereksinimler takım tarafından netleştirilip yazılı olarak kaydedilir. Kullanıcı da işlevsellik konusunda önemli bilgiler verebilir. Bunun dışında ürün sahibi ve takım sprint içinde olması gereken işlevler ve kriterler üzerinde anlaşırlar (bkz. Definition of Done).
Amaç kullanılabilir yazılım elde etmektir: test edilmiş, integre olmuş ve kullanıcı ya açılmış olmalıdır.
Sprınt in kabul şartları kabul kriterleri(test, işlev, performans) ile etkileşimlidir. Bu tarz kararlar sprint sonucunda net şekilde belirlenir ve belirtilen fonksiyonların gerçekten içerdiklerine bakılır ve incelenir.
Açıklamalar yapıldıktan sonra Scrum ustası takımına gelecek sprint de kaç adet kullanıcı hikayesi olacağını sorar ve tek tek değerlendirilip dış baskı olmadan erişilebilirliğine bakılır. [26]
Süre: 60 dakika Sprint(haftalık)
Sprint Planlama Toplantısı 2
Sprint-plan 1 de "NE?" ön planda iken, burada "NASIL?" sorusu ön plana çikar. Yazılım takımı hangi kullanıcı hikâyelerinin Sprint'e dahil olduğunu bilir ve uygulamanin(teorik) teknik boyutu açıklanır. Toplantı Takım'ın kendi sorumluluğunda organize edilir. Genellikle küçük gruplar oluşturulup yapı, test, açık gibi konulara açıklık verilir. Burada beklenen sonuç görevlerin bir günlük süreyi aşmayacak şekilde bitirilmesini kapsar.
Görevler belirlenen kullanıcı hikâyelerinden hareketle duvara ya da beyaz tahtaya (Taskboard) asılır bu sayede hangisinin işlemde ya da sırada olduğu bilinir. [15]
Süre : 60 dakika her Sprint(haftalık)de
Sprint-plan 1 ve 2 aynı gün içerisinde yapılmalıdır.
Günlük Scrum (Daily Scrum)
Günlük Scrum
Her iş günü başlamadan evvel 15 dakikalık bilgi paylaşımı için günlük Scrum toplantısı yapılır. Bu görüşmede herhangi bir problem değerlendirilmez, yalnızca 3 tema işlenir: dün ne yaptım, yarın ne yapıcam, beni ne engelliyor. Eger belirtilen görev bir günde bitmesi mümkün değil ise, görev parçalanıp takıma dağıtılır.
Eger 15 dakıka içinde bazı sorular cevap bulamadığı durumlarda Scrum ustası not alıp bir sonraki toplantıya taşır ya da kendisi çözüm üretir.[16]
Sprint Değerlendirmesi
Değerlendirme Sprint'in sonunda takım tarafından yapılır ve başlangıçta belirlenen hedeflerin kapsamında olup olmadığı Ürün sahibi tarafından değerlendirilir. Eğer teslim edilen işlevde eksiklik(test olmamış ise) var ise o kullanıcı hikâyesi tekrar dan, ürün sahibi tarafından ürün içeriğine(Product Backlog) gönderilir ve öncelik sırası verilir.
Değerlendirmeye kullanıcının(User) katılımı da işlevin testi, ürün tasarımı ve kullanıcı bakışı açısından çok önemlidir. Kullanıcı Hıkayelerin de bir eksiklik var ise Scrum ustası tarafından not alınıp, ürün sahibi tarafından ürün içeriğine aktarılır. [12] Süre olarak 1 ayda biten Sprint in değerlendirmesi en fazla 4 saat sürmeli, az süren sprintlerde süre uyarlanır.
Retrospektif (Geçmişe Bakış)
Geçmişe bakış toplantıları, Sprint Değerlendirme toplantılarından sonra ve Sprint Planlama toplantılarından önce yapılırlar ve geçmiş sprint'teki tecrübeler masaya yatırılarak iyileştirmeler belirlenir. Scrum yönteminin en önemli özelliklerinden birisi bu süreçte suçlu/suçsuz eleştirilerinin yapılmamasıdır
Yapı Taşları
Scrum Task
Ürün İçeriği (Product Backlog)
Ürün İçeriği(Product Backlog) taleplerin oluşturulması ve yönetilmesi için merkezi belgedir ve teslim edilecek işlevsel element ler yönetilir. Toparlanan kullanıcı hikâyeleri ürün sahibi tarafından önceliklerine göre düzenlenir ve gerçeklestirilme zamanı takım'ın yardımı ile tahmin edilir.
Ürün içeriği, geliştirilmekte olan ürün'ün önceliklere göre sıralanmış işlevleri kapsar. Değişim taleplerinin alındığı tek yerdir ve ekleme, cikarma, öncelikler gibi işlemler ürün sahibi tarafından yapılır. Ürün içeriği hiçbir zaman eksiksiz değildir ve böyle bir iddiasi da olmaz, tanımlanmış, iyi anlaşılmış gereksinimleri içerir, öncelikler ise ekonomik fayda, risk gibi faktörlerle değerlendirilip uygulanır.
Ürün içeriği'ne eklenen talepler teknik olarak değil, mesleki ve kullanıcı odaklı olmalıdır. iyi bir kullanıcı hikâyesi üç soruya cevap vermelidir:
- Kullanıcı olarak (kim?) bu islevi (neyi?) şu faydalar (neden?) için istiyorum.
Sprint İçeriği
Sprint içeriği halledilmesi gereken görevleri gösterir. Bu amaç için dört sütunlu bir görev tahtası kullanılır:
1. sütun'da Sprint'de bulunan İş Parçacıkları ("Stories")
2. sütun'da görevler ("ToDo")
3. sütun'da çalışma ("In Progress") ve 4.sütun'da teslime hazır ("Done") olan iş parçacıkları bulunur.
Yazılım takımı elemanları günlük Scrum'da önceki gün hangi görev üzerinde çalıştığını ve bitip bitmediği hakkında bilgi verir. Bir günde bitmeyen görevler ise kırmızı bir nokta ile işaretlenir. Böylelikle engeller kolayca tespit edilir.
İş Bitim Grafikleri (Burndown-Charts)
Örnek bir iş bitim-grafiği
İş bitim grafikleri yapılmış ve geri kalan çalışmayı görselleştirmek için kullanılır.
Bir Sprint yanik grafigi, x-ekseninde günlük zamanı, y-ekseninde bitirilmemiş görevleri gösterir. Bu grafik, Sprint'in belirtilen zaman birimi içinde daha iyi tahmin edilmesini sağlar.
Seçili kullanıcı hikâyelerini izlemek içinde hikâye-iş bitim-grafiği kullanilir. Burada eksik kalan görevler degil eksik hikâyeler gösterilir. Her hikâye eşit büyüklükte olmayacağından, büyüklük bilgisi noktalarla sağlanır. Kalan hikâyelerin toplamı y-ekseninde belirtilir, x-ekseni de Sprint süresini gösterir.
Grafik eğilimleri merdiven şeklindedir. Her azalma değeri bir hikeynin bittiğini gösterir(örnek. 8 noktalı bir hikâye, 8 azalma verir).
Tüm projeyi göstermek için devir(Release)-iş bitim-grafiği kullanılır. Bu durumda y-eksenine bütün ürün içeriğinde belirlenen bitmemis kullanıcı hikâyeleri ve hikâye noktalarının toplanmış sekli gösterilir. Böylelikle proje bitimine kadar kaç tane teslimat yapılacağı anlaşılır.[22]
Engel İçeriği (Impediment Backlog)
Engel İçeriği (belirlenen tüm engeller) Scrum ustası tarafından, kısa bir problem tanımı ve tarih etiketiyle oluşturulur. Ek olarak günlük Scrum sonunda, Scrum ustası karşılaşılan engelleri ekler.
Bitti Tanımı (Definition of Done)
Bitti tanımı, bır kullanıcı hikâyesinin uygulanmasına ait ve yazılıma nüfus eden etkinliklerin kontrol listesidir. Ek belgeler olarak: yorum yazmak, birim testleri ve tasarım belgeleri. Bitti tanımı proje başlangıcında katılımcılar tarafından kararlaştırılır, ayrıca geliştirme sürecindede uyarlanabilir. Sprint'in başlangıcında görevlerin sayısı ve kapsamı hakkında yardımcı olur ve tüm hikâyelerde uygulanmak zorunda değildir. Bitti tanımı Sprint'in sonunda belirli bir hikâyenin ayrıntılı taleplerini belirttiğinden, Sprint'in kabul edilmesine de hizmet eder.
Kaynak <http://www.wikizero.biz/index.php?q=aHR0cHM6Ly90ci53aWtpcGVkaWEub3JnL3dpa2kvU2NydW0>