Given – When – Then (Kabul Kriterlerinin Oluşturulması)

Bir önceki yazımda; Kullanıcı Hikayesi, Destan ve Konu kavramlarından bahsetmiş, bu kavramların fonksiyonel katkıları ve kullanım formüllerini ele almıştım.

Theme (Konu), User Story (Kullanıcı Hikayesi) ve Epic (Destan) Kavramları

Kullanıcı Hikayelerinin, kabul kriterlerinin temelini oluşturduğu yadsınamaz; ancak tek bir cümle ile alınan isterler, ürün backloguna girdi olsa da, kabul kriterleri (Acceptance Criteria) ve Tamam (Done) tanımlarının oluşması için yeterli olmayabilir. Bu sebepten dolayı Kullanıcı Hikayelerini, Product Backlog Refinement (Grooming) toplantılarında olabildiğince detaylandırmakta fayda olacaktır. Bu yazımda, detaylandırmanın bir parçası olarak, Kabul Kriterleri’nin belirlenmesi için kullandığımız Given-When-Then (GWT) formülü üzerinde duracağım. Sprint Planlama çıktısı olarak bu formül ile detaylandırılmış PBI’larınız olursa, test senaryolarının çıkartılması konusunda oluşan iş yükünün önemli bir kısmını geride bırakmış ve konu bazında “DONE” tanımını çıkartmış olursunuz.

Dan North ve Chris Matts tarafından geliştirilen Given-When-Then formülü; girdi-işlem-çıktı (input-process-output) sürecine dayandırılmış test odaklı geliştirme (Test-Driven Development) şeklidir. Test senaryoları yazılımın geliştirilmesi süresince koşturarak, programın daha az hata ile geliştirilmesi mantığını esas almıştır. Bu sayede, işlemin öncesindeki ve sonrasındaki durumlar net bir şekilde birbirinden ayrılarak tanımlanır ve müşteri isterinin ürün ile eşleşme durumunun kontrol maddeleri çıkartılmış olur.

Given-When-Then formülünde, her bir senaryonun oluşumu şu üç madde çerçevesinde gerçekleşir;

  • Senaryo tekil bir durum açıklaması ile başlatılır. Bu durum, sonrasında bir ya da birden fazla koşula AND ya da BUT ile bağlanabilir. (xxx GIVEN yyy AND/BUT zzz)
  • İkinci basamakta senaryoyu tetikleyecek aksiyon tanımlanır. Bu aksiyonlar birden fazla koşula bağlı olması durumunda AND/BUT lenerek birbirine bağlanır. (WHEN aaa AND/BUT bbb)
  • Son olarak, bu işlemin sonucunda beklenen çıktıya (output) yer verilir. (THEN www AND/BUT qqq)

Örneği, daha açıklayıcı olabilmesi için Kullanıcı Hikayesi düzeyinden başlayarak açıklamak istiyorum. (Kullanıcı Hikayelerinin nasıl oluşturulduğu ile ilgili yazıma https://www.linkedin.com/pulse/theme-user-story-epic-ali-saracoglu-mba-psm-pspo-itil?trk=prof-post linkinden ulaşabilirsiniz.)

Kullanıcı Hikayesi (User Story):

Bir banka müşterisi olarak,

Bankacılık uygulaması üzerinden online hisse senedi alım/satımı yapılmasını istiyorum,

Böylece tanımlı yetkim kapsamında yatırımlarımı internet üzerinden yönlendirebileceğim.

Bu kullanıcı hikayesine göre, Given-When-Then formulası ile bir çok senaryo çıkartılarak; yapılacak işlem, bu senaryolar altında hikayeleştirilir.

Şimdi bu Kullanıcı Hikayesi’nin, “Hisse Senedi Alım” Senaryosu üzerinden, Given-When-Then kullanarak, Kabul Kriterlerini oluşturalım.

SCENARIO: Bankacılık uygulaması üzerinden online hisse senedi alımı,

GIVEN, Müşteri hisse senedi alım yetkisine sahiptir,

And, Müşteri A,B,C,D Grubu hisse senetlerinden birini seçer,

And, Müşteri yasal uyarıları kabul eder,

And, Müşteri yatırım hesabında yeterli alım bakiyesine sahiptir,

WHEN, Müşteri “Hisse Satın Al” butonuna tıklar,

THEN, Uygulama satın alma emrini Borsa’ya bildirir,

And, Uygulama alım emrinin işleme alındığı bilgisini Müşteri’ye gösterir,

And, Hisse senedi tutarı Müşteri bakiyesinden düşülür,

And, Müşteri portföyünde, alımı gerçekleşen hisse senedi adedi ve hisse alım bedeli görüntülenir.

Given-When-Then formulası yazılırken, “BUT” koşulunun, “AND” ile birbirine bağlanmış koşullar kadar büyük önemi vardır. Müşteri isterleri alınırken, nelerin olması gerektiği kadar, nelerin olmaması gerektiği konusunun da netleştirilmesi ve kısıtlamaların belirlenmesi, Proje başarısı açısından yüksek önem arz eder (konu ile ilgili detaylı bilgi için, “Gold Plating” kavramını inceleyebilirsiniz).

Formül ve örnek incelendiğinde; Kabul Kriterleri oluşturulurken kullanılan Given-When-Then formulasının, işin “Nasıl” yapılacağı sorusuna da cevap verdiğini ve unit-test seviyesinde test senaryolarını kapsadığını fark edeceksiniz. Kullanıcı hikayeleri ile kabul kriterleri bu noktada birbirlerinin tamamlayıcıları olarak değerlendirilmelidirler. Bu sebeple, sprinte alınmış her bir işin, Kabul Kriterleri ve Kullanıcı Hikayelerinin eksiksiz olması; takımın, müşterinin gereksinimleri ile birebir örtüşen bir ürün çıkartması konusunda önem taşır.

Özetlemek gerekirse; Kullanıcı Hikayeleri ve Kabul Kriterlerinin oluşturulmasının kolay ve zaman almayan bir süreç olduğunu belirtmek yanlış olur. Ancak netleştirilmemiş istekler ile başlayan bir sprint süreci, kaynakların boşa tüketildiği bir periyot olacaktır. Unutmamak gerekir ki Agile süreçleri, dokümansız Proje Yönetimi demek değildir. Scrum, her ne kadar değişen koşul ve taleplere göre esneklik göstermeye açık olsa da; sprint başlangıcında tüm isterlerin açık bir şekilde bilinmesi, Sprint Review’daki demonun müşteri istekleri ile örtüşmesinde büyük katkı sağlayacaktır.

Yazar : Ali SARAÇOĞLU

Blog Kategorileri