30 saniyelik özet

Acceptance Criteria, Türkçe karşılığıyla kabul kriterleri, belirli bir iş maddesinin beklenen davranışı hangi koşullarda karşılamış sayılacağını açıklar. “Kupon çalışmalı” ifadesi yeterli değildir. Kuponun hangi sepette uygulanacağı, süresi dolduğunda ne olacağı ve başarısız işlemin kullanıcıya nasıl açıklanacağı netleştirilmelidir. Kriterler, geliştirme sonunda ortaya çıkarılan kişisel bir kontrol listesi olarak kullanılmamalıdır. Product Owner, yani ürün sahibi, ilgili uzmanlarla birlikte kullanıcı ihtiyacını ve iş kurallarını açıklığa kavuşturur. Kabul kriterlerinin karşılanması, belirli davranışın doğrulandığını gösterir. Ürünün ortak kalite koşulları ve kullanımda beklenen fayda ayrıca değerlendirilmelidir.

Neden önemli?

Bir kampanya için kupon özelliği hazırlanıyor. Pazarlama ekibi minimum sepet tutarına kargo ücretinin dahil olduğunu düşünüyor. Geliştirici yalnızca ürün bedellerini kullanıyor. Test uzmanı ise örnek sepetlerde toplam tutarı kontrol ediyor. Aynı talep farklı yorumlandığı için sorun teslimata yakın ortaya çıkıyor.

Bu anlaşmazlığın kaynağı kodun yanlış yazılması olmayabilir. İş kuralı hiç kararlaştırılmamışsa ekip, açıklanmayan bir beklentiyi karşılamaya çalışıyordur. Belirsizliği erken görünür kılmak, farklı uzmanlıkların aynı koşulu tartışmasını sağlar.

Yönetici açısından kabul kriterlerinin değeri, beklentiyi doğrulanabilir hale getirmesidir. Bir talebin teslim edilip edilmediğini kişilerin kanaatine göre değerlendirmek yerine, üzerinde konuşulmuş davranışlar incelenebilir. Böylece kapsam değişikliği ile hatalı uygulama daha sağlıklı ayrılır.

Örneğin sonradan yeni bir kupon türü istenmesi, ilk kapsamın yanlış uygulanmasıyla aynı durum değildir. Bu ayrımın yapılabilmesi için mevcut beklentinin kaydı gerekir. Kriterler her değişikliği engellemez; değişikliğin etkisinin konuşulmasını kolaylaştırır.

Buna karşılık çok uzun bir kriter listesi de iyi anlaşılmanın garantisi değildir. Aynı kuralları farklı cümlelerle tekrar etmek veya her teknik adımı kriter olarak yazmak, asıl davranışı görünmez kılabilir. Amaç, önemli koşulları ve belirsizlikleri herkesin değerlendirebileceği açıklıkta tutmaktır.

Terim nedir?

Kabul kriterleri bir kullanıcı hikâyesine, yani ihtiyacı kullanıcı açısından ifade eden iş maddesine, veya başka bir backlog maddesine özgü olabilir. Backlog, ürün için gereken işlerin sıralı listesidir. Kriterler, işin hangi kullanım durumlarını ve sınırları kapsadığını açıklamaya yardımcı olur.

“Ekran anlaşılır olmalı” ifadesinde değerlendirme ölçütü eksiktir. “Geçersiz kupon girildiğinde indirim uygulanmaz ve kullanıcıya neden açıklanır” ifadesi ise incelenebilecek davranışlar içerir. Bu kriter hâlâ ayrıntı gerektirebilir: Geçersizlik hangi kurallara dayanıyor ve açıklama hangi durumda değişiyor?

Bir kriter, her zaman tek bir testle doğrulanmaz. Bir kuralın farklı sınır değerlerde ve farklı kullanıcı yetkilerinde incelenmesi gerekebilir. Kriter beklenen davranışı anlatır; testler bu davranışın belirli örneklerde gerçekleşip gerçekleşmediğini kontrol eder.

Definition of Done, kısaca DoD, tamamlanmış sayılma tanımıdır. Scrum Guide bunu ürünün ortaya çıkan kullanılabilir parçasının gerekli kalite ölçütlerini karşılamasıyla ilgili ortak tanım olarak açıklar. Kabul kriterleri belirli işin davranışını netleştirirken DoD ortak kalite koşullarını kapsar. İkisi birbirinin yerine geçmez.

Kalite tanımı kaynağı: Ken Schwaber ve Jeff Sutherland, The Scrum Guide, Kasım 2020; Definition of Done bölümü.

Örneğin kuponun son kullanma kuralı iş maddesine özgü olabilir. Ürünün genel test, güvenlik incelemesi veya belgeleme koşulları ise ekipteki ortak kalite tanımında yer alabilir. Aynı koşulun her karta kopyalanması yerine ilgili standarda bağlantı vermek yeterli olabilir; bağlamın gerektirdiği özel davranış ayrıca açıklanmalıdır.

Gerçek vaka: GOV.UK Pay’de dil seçimi senaryoları

GOV.UK Pay ekibinden Katie Bates ve Alex Bishop, 29 Temmuz 2019 tarihli yazılarında teslimat sorunlarını ve yaptıkları değişiklikleri anlatıyor. Ekip, kullanıcı hikâyelerinin farklı yorumlara açık kaldığını, bazı ihtiyaçların karşılanmadığını ve işler bitmeden yeniden çalışma gerektiğini belirtiyor.

Çözüm olarak daha fazla ön analiz, hikâyeleri birlikte bölme ve açık kabul kriterleri kullanma çalışmalarına yönelmişler. Behaviour Driven Development, kısaca BDD, beklenen davranışı somut örnekler üzerinden birlikte açıklamaya dayanan yaklaşım olarak kullanılmış.

Yazıdaki ödeme dili örneğinde, genel bir “desteklenen dil gönderilebilir” koşulu yerine ayrı senaryolar hazırlanıyor. “cy” kodu gönderildiğinde ödeme Galce oluşturuluyor. Dil bilgisi gönderilmediğinde İngilizce varsayılan oluyor. Desteklenmeyen “cym” kodunda ödeme oluşturulmuyor ve hata yanıtı dönüyor.

Ekip yaklaşımın iletişimi iyileştirdiğini, aynı konuları tekrar tartışmayı azalttığını ve daha gerçekçi teslimat tahminlerine yardımcı olduğunu bildiriyor. Yazı sayısal bir hızlanma oranı sunmuyor; böyle bir oran çıkarılamaz.

Vakadan çıkarılabilecek ders, başarı koşulunun yanında eksik ve geçersiz girdilerin de konuşulmasıdır. Belirsizlik, kod yazılırken kişisel varsayımla çözülmek yerine ekipçe değerlendirilebilir hale geliyor.

Kaynak: GOV.UK Technology Blog, How GOV.UK Pay used Behaviour Driven Development to improve delivery times, 29 Temmuz 2019.

Varsayımsal örnek: E-ticaret kuponu

Bir mağaza, belirli koşulları sağlayan müşterilere tek kullanımlık kupon sunacak. İlk talepte yalnızca “Kupon ödeme ekranında kullanılabilsin” yazıyor. Ürün sahibi, pazarlama, geliştirme ve test uzmanlarıyla birlikte kuralları inceliyor.

Minimum tutarın indirim öncesi ürün bedelleri üzerinden hesaplanması, kargo ücretinin hesaba katılmaması kararlaştırılıyor. Kuponun geçerlilik zamanı ve bu zamanın hangi saat dilimine göre değerlendirileceği açıklanıyor. Başarısız ödeme denemesinin kupon kullanım hakkını tüketip tüketmeyeceği de açık soru olarak ele alınıyor.

Kriterlerden biri şöyle ifade ediliyor: Kupon geçerliyse ve uygun ürünlerin toplamı minimum tutarı karşılıyorsa indirim uygulanır; kargo bedeli bu tutara eklenmez. Başka bir kriter, süresi dolmuş kuponda indirim uygulanmamasını ve sebebin kullanıcıya bildirilmesini kapsıyor.

Tek kullanım kuralında, başarılı siparişten sonra aynı müşterinin kuponu yeniden kullanamaması bekleniyor. Aynı anda gelen işlemlerde kuralın korunması da değerlendiriliyor. Kullanıcının düğmeye tekrar basması gibi durumlarda çift uygulama oluşmaması gerektiği konuşuluyor. Teknik çözümün nasıl kurulacağını geliştiriciler planlıyor.

Ekip, kararları örnek sepetlerle kontrol ediyor. Minimum tutarın altındaki, eşitindeki ve üstündeki durumlar ayrı değerlendiriliyor. Örnek tutarlar test verisi olarak kullanılıyor; gerçek satış sonuçları gibi sunulmuyor.

Kriterler karşılandığında kupon davranışı doğrulanmış oluyor. Kampanyanın müşteriler için değer oluşturup oluşturmadığı ise ayrıca incelenecek. Kullanıcıların işlemi tamamlayabilmesi, kupon nedeniyle oluşan destek talepleri ve ödeme sürecindeki sorunlar izlenecek. Çalışan bir özellik, başarılı bir kampanya sonucunu kendiliğinden garanti etmiyor.

Yaygın üç hata

  1. Yalnızca başarılı akışı yazmak

Geçerli girdiyle çalışmak yeterli olmayabilir. Eksik bilgi, yetkisiz erişim, sınır değer ve başarısız işlem durumlarını değerlendirin. Her olasılığı aynı ayrıntıda yazmak yerine iş açısından önemli risklere odaklanın.

  1. Kriterleri geliştirme sonunda eklemek

Sonradan ortaya çıkan beklentiler yeniden çalışmaya neden olabilir. Başlangıçta bilinmeyen konuları açık soru olarak tutun. Yeni bilgi geldiğinde kriter değişikliğinin kapsam, tahmin ve mevcut çalışma üzerindeki etkisini ekipçe değerlendirin.

  1. Kriterlere teknik çözümü gereksiz yere kilitlemek

Belirli bir teknoloji zorunlu değilse beklenen davranışı açıklayın. Teknik veya kurumsal bir kısıt gerçekten varsa gerekçesiyle kaydedin. Kullanıcı sonucunu anlatmakla uygulama adımlarını tarif etmek arasındaki farkı koruyun.

Mini uygulama / şablon

Yaklaşan bir iş maddesinde aşağıdaki alanları doldurun.

Kullanıcı ihtiyacı
—
İlgili iş kuralı ve kaynağı
—
Başlangıç koşulu
—
Kullanıcının veya sistemin yaptığı işlem
—
Beklenen gözlenebilir sonuç
—
Eksik veya geçersiz girdi davranışı
—
Yetki ve erişim koşulları
—
Sınır durumları
—
Değişmeden kalması gereken bilgiler
—
Doğrulama örnekleri
—
İlgili ortak kalite standardı
—
Açık soru ve karar sorumlusu
—

Sonra her kriteri okuyup nasıl doğrulanacağını açıklayın. Ekip farklı sonuçlar bekliyorsa önce belirsizliği giderin. Kriterleri karşılayan çözümün kullanıcı ihtiyacını karşılayıp karşılamadığını da inceleyin. Gerekli bilgiler eksikse varsayımı sessizce kurala dönüştürmeyin.

İlgili terimler

User Story, Definition of Done, Business Rule, Functional Requirement, Non-Functional Requirement, Backlog Refinement, User Acceptance Testing, Use Case, Product Backlog, Outcome ve Output, Requirements Traceability Matrix