Agile yöntemlerden olan Scrum’ın Pratikteki Uyarlanması’nı incelediğimiz yazı dizisine, Scrum Development sürecini konu alan 4. bölüm ile devam ediyoruz.

Scrum Development

Sprint Planning toplantısı bittikten sonra, Sprint başlar. Dolayısıyla Sprint Backlog ögelerini için geliştirme süreci de başlamış olur. Sprint başladığında, Sprint Backlog listesine ögeleri değiştirme, kaldırma veya yenisini eklemeye izin verilmez. Çünkü sadece Sprint Backlog listesindeki ögeleri geliştirmeye odaklı (Focused) çalışmak hedeflenmelidir.

Sprint içindeki Scrum Development sürecine, geliştiriciler, Sprint Backlog listesinde üstlerde yer alan ögeleri geliştirmekle başlar. üzerinde çalışılan bir ögenin %100’ü tamamlanmadıkça bir sonraki ögeye geçmemelidirler. Bu süreçte ögeler, tasarlanma (Design), kodlama, entegrasyon ve test süreçlerinden geçmelidir.

Ögelerin Test süreci, her türlü testi içermelidir. Çünkü geliştirilen ögenin gerçekten “%100 yapıldı” (Done) olması gerekmektedir. Bu nedenle Kullanıcı Kabul Testi (User Acceptance Test – UAT) de bunun bir parçasıdır. Ayrıca test süreci tüm Sprint boyunca devam etmelidir, sonraki sprintlere atılmamalı veya bekletilmemelidir.

— İyi bir Kullanıcı Kabul Testi’nin nasıl kurgulanması gerektiği ile ilgili yazıyı buradan okuyabilirsiniz. —

Scrum Development sürecinde, işbirliği (Collaboration) çok önemlidir. Hatta tüm proje boyunca geliştiricilerin aynı yerde çalışması önerilir.

Peki Scrum bize bu işbirliğini sağlamak için nasıl yardımcı olur?

Daily Scrum

Scrum ile geliştirilen projelerde, geliştiriciler, Daily Scrum adı verilen 15 dakikalık günlük toplantılar yapılmalıdır. Bu development team için katılması zorunlu bir toplantıdır. Onlar dışındaki kişiler ise sadece katılımcı olarak yer alabilirler.

Her Daily Scrum toplantısında geliştiriciler şu 3 soruyu yanıtlamalıdır:

• Dünden bu güne ne yaptım? – What I did since yesterday?
• Yarına kadar ne yapacağım? – What I’m going to do until tomorrow?
• Ne gibi sorunlarım olabilir? – What problems I might have?

Burada bazen yanlış değerlendirilen bir durum olabiliyor. Son maddede ekipler sorunları tespit etmek yerine sorunları tartışabiliyor. Fakat bu Daily Scrum için yanlış bir aktivitedir. Unutmayın sadece 15 dakikalık bir toplantıdan bahsediyoruz. Burada sadece ön görülen sorunların belirlenmesi yeterli olacaktır. Ancak toplantı sonrası sorunları tartışılmalıdır. Eğer sorunlar teknik ise development team kendi içinde, eğer teknik değilse Scrum Master yardımı ile bu sorunlar giderilmelidir.

Sprint Performas Ölçümü

Sprint performansını kim ölçmelidir? Scrum uyarlamasında çok fazla sorulan sorulardadır kuşkusuz. Product Owner, Scrum Master veya Development Team?

Development Team için kendi kendini organize edebilir (Self Organized) diye daha önce bahsetmiştik. Bu özelliğinden dolayı da kendi performanslarını ölçmekle sorumlu olmalıdırlar.

Scrum’da sprint performans ölçümü (Sprint Performance Measurement) için planlanan ve gerçekleşenleri karşılaştırmak doğru bir yöntem değildir. Sprint’in herhangi bir zamanındayken, ne kadar öge tamamladık ve Sprint sonunda Sprint Backlog’taki herşeyi testlim edebilecek miyiz diye kontrol edilmelidir.

Development Team, sprint sonuna kadar tüm ögeleri teslim edemeyeceğini fark ederse, Product Owner’a kalan işleri tekrar sıralaması (Order) için haber verilmelidir. Fakat Sprint Backlog içinde herhangi bir düzenleme, ekleme ve/veya çıkarma işlemi kesinlikle yapılmamalıdır.

Peki pazarda değişiklikler oldu ve müşterinin artık Sprint Baclog içindeki ögelerin yarısına ihtiyacı kalmadı. Bu durumda da ögeleri çıkarmamıza izin verilmiyor mu?

Sprint’i İptal Etmek (Sprint Cancelling)

Müşteri artık Sprint Backlog ürünlerine ihtiyaç duymuyorsa ya da daha genel bir ifadeyle Sprint Backlog mantıklı değilse, Product Owner, Sprint’i iptal etme yetkisine sahiptir.

Bu durumda hemen yeni bir Sprint planlanmalıdır. Elbette, tüm değişiklikler, yeni Sprint’i başlatmadan önce Product Backlog listesine dahil edilmelidir.

Sprint iptalini gerektiren durumlarla çok fazla karşılaşılmaz. Bu çok uç bir durumda yapılabilcek bir aksiyon. Bu tarz değişikliklerin olabileceğini öngörebiilyorsak eğer daha kısa Sprint süreleri belirleyerek riski daha da azaltmak daha faydalı olacaktır.

Bu yazı dizisine ait tüm bölümlere aşağıdaki linklerden ulaşabilirsiniz:

• Scrum Farkındalığı ve Uyarlanması Part 1: Scrum Nedir?
• Scrum Farkındalığı ve Uyarlanması Part 2: Sprint ve Ögeleri
• Scrum Farkındalığı ve Uyarlanması Part 3: Scrum Rolleri
• Scrum Farkındalığı ve Uyarlanması Part 4: Scrum Development
• Scrum Farkındalığı ve Uyarlanması Part 5: Scrum Çıktıları (Outputs)

İlkim Dilara KADAKALOĞLU