Kullanıcı Hikayelerinin Bölünmesi (User Story Splitting) Üzerine Bir Örnek

Kısaca User Story Splitting, büyük kullanıcı hikayelerini teknik katmanlara göre değil, bağımsız kullanıcı değeri üreten daha küçük parçalara ayırma yöntemidir. İyi bölünmüş bir hikâye küçük, test edilebilir ve tek başına anlamlı değer sağlayabilir

Eğitimlerde bize en çok sorulan sorulardan biri kullanıcı hikayelerinin (user story) nasıl bölüneceği (split) oluyor. Merak edilen bu konuyu somut bir örnek üzerinden açıklayarak meselenin üzerindeki sisi biraz olsun dağıtmak istiyorum.

Diyelim ki bir bankanın websitesini geliştiriyoruz ve elimizde şöyle bir kullanıcı hikayesi var:

XYZ Bank websitesinin bir ziyaretçisi olarak bankanın sunduğu kredilerle ilgili hesaplama yapabilmek istiyorum. (Bu sayede bankanın sunduğu kredi teklifini öğrenebilir ve diğer bankaların teklifleriyle karşılaştırabilirim.)

Aslında kullanıcı hikayelerini (user story) ifade etmek için en sık kullanılan (As a…., I want to…., so that….) formatı bir kenara koyarsak bu örnekteki kullanıcı gereksinimi “Kredi Hesapla” şeklinde özetlenebilir.

Hikayeyi bu haliyle bir geliştirme takımına veremeyiz. Sistemin sergileyeceği davranışların yani fonksiyonel gereksinimlerin ortaya çıkartılması gerekir. Scrum bu sürece “refinement” diyor.

Kullanıcı hikayelerinin rafine edilmesi yani detaylandırılması için sık kullanılan yöntemlerden biri hikayeye kabul kriterleri (ya da kabul testleri) eklemektir. Sistemin sergilemesi gereken davranışları test senaryoları şeklinde ifade ederek test bakış açısını sürece erken aşamalarda entegre etmiş oluruz ve fonksiyonel gereksinimleri ayrı tanımlayalım, sonra bunlardan yola çıkarak test senaryoları türetelim şeklinde 2 kez iş yapmayız. Çıkarttığımız kabul testleri zaten fonksiyonel gereksinimlere işaret edecektir.

Kabul testlerini ifade etmek için kullanılan popüler bir format Given…. When… Then… formatıdır.

Örneğin yukarıdaki kullanıcı hikayesi için given-when-then formatını kullanarak şöyle bir kabul testi yazabiliriz:

Given kredi tipi ihtiyaç kredisi ve kredi tutarı 100.000 TL ve vade 6 ay

When müşteri kredi hesapladığında

Then taksit tutarı 18.973,85 TL/AY ve faiz oranı % 2,95 olarak görüntülenmelidir.

Çalışır durumdaki uygulamanın neye benzeyeceğini gözümüzde canlandırmak için ufak bir örnek ekran tasarımını da hikayeye iliştirelim.

İlk yazdığımız kabul testi, ihtiyaç varsa hikayenin nasıl daha küçük alt hikayelere bölünebileceğine dair bir fikir verdi bile. Farklı kredi tiplerimiz var ve aslında her bir kredi tipi için ayrı bir hikaye oluşturarak ilk hikayemiz olan “Kredi Hesapla” hikayemizi

• “İhtiyaç Kredisi Hesapla”

• “Konut Kredisi Hesapla”

• “Taşıt Kredisi Hesapla”

şeklinde 3 alt hikayeye bölebiliriz.

Bu noktadan itibaren alt hikayelerimizden biri olan “İhtiyaç Kredisi Hesapla” hikayesine odaklanarak devam edelim.

Kabul testlerini dünüşürken geçerli (valid) girdiler kadar, geçersiz (invalid) girdileri de düşünmek zorundayız. Geçersiz girdiler bizim için birer istisna (exception) senaryosuna dönüştürülebilir.

Bu örnekte “1.000 TL’nin altında kredi kullanılamaz” gibi bir iş kuralımız var. Demek ki ziyaretçi kredi tutarı olarak 1.000 TL’nin altında bir tutar girdiğinde sistem hesaplama yapmayacak ve kullanıcıya uygun bir mesaj gösterecek.

Given kredi tipi ihtiyaç kredisi ve kredi tutarı < 1000 TL

When müşteri kredi hesapladığında

Then “Minimum kredi tutarı 1.000 TL olabilir.” mesajı gösterilir ve imleç kredi tutarı metin kutusuna odaklanır.

Ekran görüntüsünde görülebileceği üzere benzer şekilde “1.000- 50.000 TL aralığındaki krediler için seçilebilecek maksimum vade 36 ay olabilir.” gibi bir iş kuralımız da var. Demek ki vade girdisi için de geçersiz girdi durumları söz konusu olabiliyor.

Bu noktadan hareketle “İhtiyaç Kredisi Hesapla” hikayesini daha da küçültmeye ihtiyacımız varsa geçerli girdi senaryoları ve geçersiz girdi senaryolarını gruplayacağımız iki ayrı alt hikaye daha oluşturabiliriz:

• “Geçerli tutar ve vade ile ihtiyaç kredisi hesapla”

• “Geçersiz tutar veya vade ile ihtiyaç kredisi hesapla”

  
  

Görüldüğü gibi girdi tipleri ve değerlerindeki varyasyonlar hikayeleri alt hikayelere bölmek için doğrudan kullanılabiliyor.

Şimdi böldüğümüz hikayeleri görselleştirelim.

Bazen bir kullanıcı hikayesi bir Sprint’e sığmayacak kadar büyük olabiliyor. Böyle durumlarda hikayeleri alt hikayelere bölerek detaylandırmamız ve Sprint içerisine bu şekilde alarak alt hikayeyi çalışır durumda bir yazılım parçası şeklinde teslim etmemiz gerekiyor.

Bu ve bunun gibi onlarca örneği ele aldığımız eğitimlerimize göz atın!

Çalışmalarınızda sizlere faydalı olması temennisiyle…

Bu yazı Onur Özcan tarafından kaleme alınmıştır. Daha fazla bilgi için biyografi sayfasını ziyaret edebilirsiniz.

Sıkça Sorulan Sorular

User Story ile Epic arasındaki fark nedir?

Epic, tek bir Sprint içinde tamamlanamayacak kadar büyük bir ihtiyaç veya kapsamı ifade eder. User Story ise kullanıcı açısından anlamlı bir sonucu temsil eden ve geliştirilip test edilebilecek daha küçük bir iş parçasıdır.

Bir User Story ne kadar küçük olmalıdır?

Hikâyenin tek bir Sprint içinde geliştirilebilecek, test edilebilecek ve tamamlanabilecek kadar küçük olması beklenir. Ancak yalnızca küçük olması yetmez; ortaya çıkan parçanın kullanıcı veya iş açısından anlamlı bir değer taşıması gerekir.

User Story frontend ve backend olarak bölünebilir mi?

Genellikle bu iyi bir bölme yöntemi değildir. “Frontend’i yap”, “API’yi geliştir”, “veritabanını hazırla” gibi parçalar tek başına kullanıcı değeri üretmez; bunun yerine küçük ama uçtan uca çalışan dikey dilimler oluşturmak daha faydalıdır.

User Story’nin doğru bölünüp bölünmediği nasıl anlaşılır?

Her alt hikâye bağımsız biçimde anlaşılabiliyor, geliştirilebiliyor, test edilebiliyor ve tamamlandığında anlamlı bir davranış sunabiliyorsa bölme genellikle sağlıklıdır. Alt hikâyeler ancak birlikte tamamlandığında anlam kazanıyorsa parçalar fazla teknik ayrılmış olabilir.

Kabul kriterleri User Story’yi bölmek için kullanılabilir mi?

Evet. Kabul kriterlerinde ortaya çıkan farklı iş kuralları, kullanıcı tipleri, senaryolar veya veri varyasyonları hikâyeyi daha küçük parçalara ayırmak için önemli ipuçları sağlayabilir.

Her büyük User Story mutlaka bölünmeli mi?

Hayır. Hikâye Sprint içinde güvenli biçimde tamamlanabiliyor, test edilebiliyor ve belirsizliği düşükse sırf küçültmek için bölmek gerekli değildir. Bölme, teslimatı ve öğrenmeyi kolaylaştırdığı ölçüde değer yaratır.