Agile yöntemlerden olan Scrum’ın pratikteki uyarlanmasını incelediğimiz yazı dizisine, Sprint ve ögelerini konu alan 2. bölüm ile devam ediyoruz.  Scrum’ın genel kapsamını ve projeye ilk başlama evresini incelediğimiz 1. bölüme şuradan ulaşabilirsiniz.

Sprint

Agile geliştirilen projeler bir döngü çerçevesinde iterasyonlar halinde çalışır. Scrum’da bu iterasyonlara Sprint denir.  Her bir Sprint, Product Backlog’dan seçilen ögenin alt kümelerine odaklanıp, kullanılabilir (Usable) bir ürün oluşturulan döngülerdir.

Sprint’ler bir aydan kısa olmalıdır. Günümüzde iki veya üç haftalık Sprint’ler en çok tercih edilen seçeneklerdir. Geliştirilen ürün, şirket kültürü, müşteri isteri gibi kriterlere göre en uygun süre ayarlanmalıdır.

Sprint süresi projenin başında belirlenmeli ve bütün Sprint’ler aynı sürede olmalıdır. Belirlenen süre Timeboxed olarak kabul edilir ve asla genişletilemez. Unutulmamalıdır ki, Sprint süresinde ne çıkartabiliyorsak onu teslim edilmelidir. İşleri yetiştirmek için timeboxed süreleri uzatılmamalıdır. Kalan iş bir sonraki Sprint’te yapılmak üzere taşınır.

Şu ana kadar elimizde Product Backlog var ve ilk Sprint’imize başlayabilir durumdayız. Peki Sprint’e başlamak için ne yapmak gerekir?

Sprint Planning

Her Sprint’e başlarken yapılması gereken ilk şey planlamadır. Evet, hala Agile’de bazı planlama biçimleri mevcut. J

Sprint Planning toplantısı, süresi 1 ay olarak belirlenmiş bir Sprint için 8 saattir. Daha kısa süreli Sprintler için bu süreyi orantılı olarak kısaltmak gerekir.

Bu toplantıda, Product Backlog üzeriden itemlar seçilerek Sprint içerisinde geliştirilmek üzere Sprint Backlog listesine eklenir. Product Backlog üst sıralarında, en değerli ögelerin bulunduğundan bahsetmiştim. Mümkün olduğunca bu değerli ögeler Sprint Backlog’a atılmalı ve tüm Sprint boyunca bu ögelere odaklanmak gerekir.

Peki Sprint için, Product Backlog içinden ne kadar öge seçmeliyiz? Bu aslında ilgili ögenin boyutu (Size) ile alakalı değişkenlik gösterir. Dolayısı ile ögelerin büyüklüğüne karar verebilmek için tahminleme (Estimation) yapılması gerekir. Peki kimler tahminleme yapmalıdır?

Estimation

Estimation yani tahminleme, işi yapması beklenen kişiler tarafından yapılmalıdır. Scrum’da işi yapan ve dolayısıyla tahminlemeyi de yapması beklenen geliştirici ekiptir. (Develoment Team)

Development Team, Scrum’daki ikinci roldür. (ilki Product Owner’dı). Burada geliştirici (Developer), ekip içindeki analistlere, tasarımcılara, yazılımcılara, test uzmanlarına, kullanıcı arayüzü tasarımcılarına ve çözüm üretimine katılan bulunan herkese verilen isimdir.

Product Owner,  Product Backlog’a yeni bir item eklediğinde, Delevopment Team’e giderek öğenin anlamını açıklar ve onlardan bir tahminleme yapmalarını ister. Geliştiriciler daha sonra bunu tartışır ve tahmini ortaya çıkarır. PO da yapılan bu tahminlemeyi Product Backlog item’a ekler. Buna, Product Backlog Grooming veya Product Backlog Refinement denir.

Peki Product Backlog ögelerinin boyutu nasıl belirlenmeli?

Size & Story Points

Geleneksel bir yazılım geliştirme yönteminde, tahminler saat veya gün gibi kesin sayılarla yapılır. (adam/ay veya adam/gün gibi) Bu yöntem ile belirlenen estimation çok sağlıklı olmamıyor maalesef. Nedeni ise geliştiriciyi strese sokması ve geliştiricinin kendini garantiye alması sonucu ögeleri fazla eforlandırmasıdır. Örneğin 20 adam saatlik bir ögeye, sorgulanmaktan kaçınmak için 30 adam saatlik bir efor verebilir. Bunu projedeki her öge için yaptığında oldukça fazla eforlanmış bir estimation sonucu çıkar.

Dolayısıyla Agile projelerde tahminleme için bu yöntem tercih edilmez. Zaman tabanlı estimation yerine Story Point yöntemi kullanılarak tahminleme yapılır. Bunun için şu yol izlenir:

Referans Tanımlama (Defining the referance)

Product Backlog içinden, herkesce anlaşılan, küçük bir user story seçilir. Bu bize referans olacaktır. Referans user story için Story Point değeri 1SP olarak belirlenir.

Tahminleme (Estimating)

Diğer user story’ler için tahminleme yapılacağı zaman referans olarak alınan öge ile karşılaştırılır. Buradaki amaç, elimizdeki ögenin, referans ögesinin kaç katı büyüklüğünde olduğunu tahminlemektir. 2 kat büyüklüğündeyse Story Point değeri 2SP olarak belirlenir.

NOT: Bu estimation yöntemi Product Backlog ögeleri için yapılır. Çünkü ilgili tahminlenen öge Product Backlog aşamasında sadece bir User Story halindedir ve yüzeysel bilgi içerir. Sprint Backlog ögeleri seçilen Product Backlog ögesinin detaylandırılmış halidir. Bu yüzden de geleneksel zaman tabanlı yöntem ile tahnimleme yapılabilir.

Tam bu noktada sıra Story Point’leri zamana çevirmeye geliyor. Bunu projenin Velocity’si belirlenerek gerçekleştiriyoruz.

Velocity

Velocity, iteratif geliştirilen projelerde, her iterasyon sonunda, ekibin ne kadarlık ögeyi başarılı bir şekilde tamamlayabileceğini gösteren bir metriktir. Bir başka deyişle ekibin “hızı” da diyebiliriz.

Diyelim ki projemizin ilk 5 Sprint’indeki tamamlanan ögelerin story point toplamları;

• Sprint 1: 73 SP
• S2: 110 SP
• S3: 98 SP
• S4: 131 SP
• S5: 122 SP

Olduğunu düşünürsek, Sprint başına ortalama 107 SP’lik bir velocity ile ürettiğimizi söyleyebiliriz.

Elde edilen velocity değeri hem bir sonraki Sprint için ne kadarlık öge seçilmesi gerektiğini gösterir, hem de projenin kaç sprint sonra biteceğinin bilgisini verir.

Yukarıdaki örnekte, velocity hesabı sonucu, bir sonraki sprint için 107 SP’lik kadar öge seçmemiz gerektiğini anlayabiliyoruz.

Yine aynı örnekten devam edelim. İlk 5 sprint SP bilgileri yukarıdaki gibi olan bir proje toplam 1000 SP değerinde olsun. Projenin toplam kaç sprintte biteceğini hesaplamak için de Proje Toplam SP Değerini, ekibin Velocity değerine bölmemiz yeterlidir.

( Proje Toplam SP Değeri ) / Velocity = Toplam Sprint Sayısı

1000 / 107 = YAKLAŞIK 10 Sprnt

Her sprintte tamamlanan SP değeri farklılık gösterir. Bu yüzden her sprint sonunda velocity’nin tekrardan hesaplanması ve yorumlanması gerekir. Proje ilerledikçe daha sağlıklı velocity değeri elde edilir. Bu da yaklaşık 5 ila 8 sprint sonrasında kararlı hale gelir.

Planning Poker

Scrum ile geliştirilen bir projede 3 ila 9 geliştirici olması önerilir. Her bir geliştirici de Product Backlog ögelerinin estimate edilmesinde söz sahibidir. Fakat tahminlenen öge her kişi için aynı değerde olmayabilir. Farklı bakış açısı ve uzmanlık alanına sahip olan kişilerin farklı değeri vermesi kadar doğal bir şey olamaz. Önemli olan ortak bir yol bulup herkesi o noktada buluşturmaktır.

Planning Poker (Planlama Pokeri), ortak yolda birleşmek için, herkesin fikrini belirttiği çevik bir tahminleme tekniğidir. Oturum başladığında, PO estimate edilecek olan kullanıcı hikayesini geliştiricilere açıklar. Geliştiriciler kendi değerlendirmeleri yapar bir puan belirler ve bu puanı tüm geliştiriciler aynı anda açarlar. Eğer verilen oynar tek tek açıklanırsa, diğer tahmin ediciler bundan etkilenebilir ve tahmin kalitesini düşürebilir. Bu yüzden aynı anda oyların açılması önemlidir.

Bir user story için verilen oylar arasında diğerlerinden çok farklı bir oy varsa, hikayenin doğru anlaşıldığından emin olmak gerekir. Farklı oy veren geliştircinin neden böyle düşündüğü sorulur ve tartışılır. Ortak bir noktaya gelene kadar da oylama tekrar tekrar yapılmalıdır.

Oylar aynı aralıkta olduğunda, oyların ortalaması alınır ve Product Backlog item için tahmini iş miktarı olarak bu ortalama kaydedilir.

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