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ğitimlerimizi kataloğumuzdan görüntüleyebilirsiniz.

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