Scrum uygulama geliştirme yönteminin temel özelliği gözlemci, geliştirmeci ve tekrara dayalı olmasıdır. Klasik Waterfall yönteminde ise bu tekrarlar bulunmamaktadır ve bazı problemler içermektedir. Teknolojik değişimler ve hızlı değişen müşteri gereksinimlerinin karşılanamaması, müşteri ihtiyacını karşılayan kaliteli ve hızlı ürün çıkarılamaması bu problemlerden başlıcalarıdır.
Scrum, 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ığı üç ilke ile azaltmaya çalışır.
- Şeffaflık: Projedeki ilerlemeler ve sorunlar günlük olarak tutulur ve herkes tarafından izlenebilir olması sağlanır.
- Denetleme : Ürünün parçaları ya da fonksiyonları düzenli aralıklarla teslim edilir ve değerlendirilir.
- Uyarlama: Ürün için gereksinimler en baştan bir defalığına belirlenmez, bilakis her teslimat tekrar değerlendirilir ve duruma göre uyarlamalar yapılır.
Scrum’da amaç başlangıçta hayal edilen ve tasarlanana uyan bir ürünün, hızlı, ucuz ve kaliteli sekilde ü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 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.
Geleneksel Yöntemler Neden Uygun Değil?
- Geleneksel yöntemler kullanılan projelerde projenin tüm gereksinimleri öngörülmeye çalışıldığı için analiz ve tasarım süreci için ayrılan zamanın fazla olması
- Süreç boyunca müşteri ile iletişim az olduğu için çıkan ürünün müşteri ihtiyacını karşılayamaması
- Proje boyunca yapılması gerekli olan bir kısım değişiklikler proje başlangıç aşamalarında fark edilemeyip projenin ilerleyen aşamalarında fark edilmesi
Aşağıdaki örnek Waterfall yöntem akışında başta bir design doküman hazırlıyoruz. Oyun ortada yok ama design aşamasında bu design dokümanı oyunun her şeyini (interface, design, vs.) içeriyor. Test son aşamada yapılıyor ve bir sorun olursa ancak projenin sonunda test edilebilmiş oluyor. Her aşamada test yok, sadece sonda var. Örnek olarak 2 yıl süren bir proje olsaydı 2. yılın sonlarına doğru yapılacak testte hatalar tespit edilebilecekti.
Yine bu akışta müşteri ile sürekli iletişim yerine baştaki Design dokümanına göre hareket edildiğinden sonda çıkan ürünün müşterinin beklentisini karşılamadığı şekilde üretildiği görülebilir.
Scrum’da ise küçük ekiplere bölünüyoruz ve her ekipte bir Scrum Master var. Scrum Masterlar lider değil, sadece o ilgili ekibin bir ihtiyacı olduğunda onu karşılamaktan sorumlu. Örnek olarak; Photoshop lisanslı yazılım temini, donanım ihtiyacı, vs.
Scrum’da ekipler sprint süresine göre işleri bölüyor ve yetiştirmeye çalışıyorlar. Örnek olarak süre 1 hafta ise bu süreyi geçmeyecek şekilde temel fonksiyonlar belirleniyor ve ekipler bu sürelere uymaya çalışıyor. Günlük yapılabilecek toplantılarda her ekip ne aşamada olduğunu ve varsa bir sorunu paylaşıyorlar.
Müşteriler sürekli somut olarak çıktı beklerler. Scrum sprint süreleri ile bu ihtiyacı giderebildiğinden ilerleyiş hakkında müşteriye bilgi vermek ve tamamlanan işleri gösterebilmek adına daha olumlu sonuç vermektedir.
Kaynaklar:
Geleceği Yazanlar Mobil Oyun Atölyesi Scrum Metoduyla Çalışmak
