Acceptance Criteria ve Example Mapping: Kuralları Örneklerle Netleştirmek

Sürüm notu: Bu yazı kavramsaldır; Example Mapping için Matt Wynne'in Cucumber blogunda 8 Aralık 2015'te yayımlanan "Introducing Example Mapping" yazısı, Definition of Done için Scrum Guide 2020 esas alınmıştır.

Önce Tahmin Et

Önceki yazıda ilk release'in kartları belli oldu. Pembe satırda iki kart var ki arkasındaki kurallar hâlâ açık soru: "Kurumsal indirim" ve "Kısmi sevkiyat seçimi". Hakan'dan beklenen cevap sonunda bir e-postayla geliyor: "Kurumsal siparişte minimum 20 adet şartı var, kurumsal indirim de yüzde 10." Emre e-postayı okuyup rahatlıyor: "İki if. Yarım gün."

Okumaya devam etmeden şu üç siparişe Hakan'ın cümlesiyle cevap vermeyi dene. Bir okul 5. sınıf matematik kitabından 12, fen kitabından 7 adet istiyor: sipariş geçer mi? Bir kütüphane, zaten yüzde 25 kampanyada olan bir hikâye kitabından 20 adet istiyor: indirim yüzde 25 mi, yüzde 10 mu, yoksa ikisi üst üste mi? Liste fiyatı 84,95 TL olan bir kitaptan 3 adet alınıyor ve indirimli satır toplamı 229,365 TL çıkıyor: faturada 229,36 mı yazmalı, 229,37 mi? Hangisine e-postadan kesin bir cevap verebildin?

Acceptance Criteria: Story'nin "Bitti" Tanımı

Acceptance criteria, bir story'nin Product Owner tarafından kabul edilmesi için karşılaması gereken koşullardır. 03. yazıdaki card, conversation, confirmation üçlüsünün confirmation ayağı tam olarak budur: konuşmada varılan anlaşmanın, sonradan "bu çalışıyor mu?" diye sınanabilecek hâli. İki özellikleri onları her şeyden ayırır: yalnızca o story'ye aittirler ve davranışı anlatırlar, uygulamayı değil.

Pratikte iki biçimde yazılırlar. Kural tabanlı biçim, story'nin sağlaması gereken kuralları kısa ve kontrol edilebilir cümleler olarak sıralar: "Toplam adedi 20'nin altında olan kurumsal sipariş gönderilemez." Senaryo tabanlı biçim ise kuralı somut bir durum üzerinden anlatır: "Kurum matematik kitabından 19 adet sipariş ettiğinde, sipariş reddedilir ve kuruma 19 adetle minimumun altında kaldığı söylenir." İlki kısa ve taranabilirdir; ikincisi yanlış anlaşılmaya daha az yer bırakır, çünkü sayılar ve sonuç ortadadır. İyi bir story'de genellikle ikisi birlikte bulunur: kural başlık gibi durur, altındaki örnekler onu netleştirir. Bu yazıda kuralları ve örnekleri konuşarak bulacağız; 07. yazıda örnekleri Given-When-Then biçimine, yani Gherkin'e çevireceğiz.

Test edilebilir bir criteria'nın ölçütü basit: iki kişi aynı sistemi inceleyip "karşılanıyor" ya da "karşılanmıyor" demekte anlaşabilmeli. "İndirim doğru hesaplanır" bu testi geçemez, çünkü "doğru"nun ne olduğu yazmıyor. "Liste fiyatı 250 TL olan kitaptan 40 adette satır toplamı 9.000 TL olur" geçer. İlk yazıdaki belirsiz kelime avı burada da geçerli: "uygun", "doğru", "gerekirse" gibi kelimeler acceptance criteria'da da sorun işaretidir.

Acceptance Criteria, Definition of Done ve Definition of Ready

Bu üç kavram backlog konuşmalarında sık karışır. Scrum serisinin "Increment ve Definition of Done" yazısında farkı tek cümleyle koymuştuk: acceptance criteria tek bir item'a özgüdür, Definition of Done ise bütün Increment için geçerli kalite standardıdır. Bookstore'da "kampanya indirimi ile kurumsal indirim üst üste uygulanmaz" yalnızca indirim story'sini ilgilendirir; acceptance criteria'dır. "Kod review edildi, testler CI hattında yeşil, yeni endpoint'ler authorization testleriyle korunuyor" ise her story için aynıdır; Definition of Done'a aittir. Ayrım testi kolay: bir madde her story'de kelimesi kelimesine tekrar ediyorsa yanlış yerdedir.

Definition of Ready ise Scrum Guide'da yer almaz; birçok ekibin kendi eklediği bir kontrol listesidir. Scrum serisinin "Product Backlog ve Product Goal" yazısında bu listenin kapı bekçisine dönüşme riskini konuşmuştuk: "acceptance criteria'sı tam yazılmamış story sprint'e giremez" kuralı, kâğıt üzerinde düzen getirir ama pratikte konuşmayı sprint öncesine ve tek kişiye, genellikle Product Owner'a yığar. Selin'in ekibi bu yüzden bir hazırlık listesi yerine kısa bir alışkanlık seçiyor: sprint planning'den önce, kuralı belirsiz her story için yirmi beş dakikalık bir Example Mapping oturumu.

Example Mapping: Dört Renk Kart

Example Mapping, Cucumber projesinin lideri Matt Wynne'in 2015'te tanıttığı, bir story'nin etrafındaki konuşmayı yapılandıran basit bir tekniktir. Malzeme dört renk karttan ibaret. Sarı kart story'nin kendisidir ve masanın en üstünde durur. Mavi kartlar story'nin kurallarıdır, yani zaten bilinen acceptance criteria. Yeşil kartlar her kuralın altına dizilen somut örneklerdir. Kırmızı kartlar ise odadaki kimsenin o an cevaplayamadığı sorulardır.

Wynne oturumun katılımcıları için en azından "three amigos"u önerir: bir geliştirici, bir test bakışı getiren kişi ve bir ürün sorumlusu. Bookstore'da ayrı bir test uzmanı yok; Ayşe bu oturumlarda bilerek test şapkasını takıyor ve her kurala "bu nerede kırılır?" diye bakıyor. İyi anlaşılmış bir story için önerilen süre yaklaşık 25 dakika. Süre aşılıyorsa bu bir bilgi: story ya fazla büyük ya da hâlâ fazla belirsiz.

İki küçük alışkanlık tekniği hızlı tutar. Birincisi, örnekler oturumda Given-When-Then biçiminde yazılmaz; Wynne örneklere Friends dizisinin bölüm adları gibi "the one where..." diye başlayan kısa adlar vermeyi önerir. Bookstore ekibinde bu "hani şu ... olan" biçimine dönüşüyor: "hani şu tam 20 adet olan", "hani şu kampanyalı kitap olan". İkincisi, sonucu bilinmeyen bir örnek örnek değildir, sorudur; yeşil kart yerine kırmızı karta yazılır.

Bir Oturum: "Kurumsal İndirim" Kartı

Salı sabahı. Masada Selin, Emre ve Ayşe var; Hakan ilk on dakika için katılıyor. Selin sarı kartı ortaya koyuyor: "Kurumsal indirim: satın alma sorumlusu kurumsal indirimin uygulandığı toplamı görür." Altına Hakan'ın e-postasından iki mavi kart çıkıyor: "Sipariş en az 20 adet olmalı" ve "Kurumsal indirim yüzde 10."

Ayşe ilk mavi karta örnek yazmaya başlıyor ve daha ilk örnekte durmak zorunda kalıyor. "Tek kitaptan 20 adet, geçer. Peki 19 matematik, 1 fen?" Hakan cevaplıyor: minimum siparişin toplam adedine bakar, kitap başına değil. Ayşe bunu kartın üzerinde netleştiriyor: "Sipariş toplamda en az 20 adet içerir." Altına üç yeşil kart: "hani şu 19 matematik ve 1 fen olan: geçer", "hani şu 10 ve 10 olan: geçer", "hani şu 12 ve 7 olan: 19 adet, reddedilir". Emre bir örnek daha ekliyor: reddedilen siparişte kuruma kaç adetle sınırın altında kaldığı söyleniyor mu? Hakan "evet, yoksa telefonla sorarlar" diyor; bu da bir örnek oluyor.

İkinci mavi karta gelince kampanya sorusu çıkıyor. Hikâye kitapları yazın yüzde 25 kampanyada; bir kütüphane bu kitaptan 20 adet isterse ne olur? Hakan'ın cevabı oturumda geliyor: indirimler üst üste binmez, hangisi büyükse o uygulanır. Bu cevap yeni bir mavi kart olarak masaya iniyor ve altına iki yeşil kart alıyor: "hani şu 250 TL'lik matematikten 40 adet olan: satır 9.000 TL, indirim yüzde 10" ve "hani şu 120 TL'lik kampanyalı hikâye kitabından 20 adet olan: satır 1.800 TL, indirim yüzde 25".

Hakan ayrıldıktan sonra Emre, Önce Tahmin Et'teki üçüncü siparişi masaya koyuyor: 84,95 TL'lik fen kitabından 3 adet. Liste toplamı 254,85 TL, yüzde 10 indirimle 229,365 TL. Kuruşa nasıl yuvarlanacak, satır bazında mı, sipariş toplamında mı? Odadaki kimse bilmiyor; bu kırmızı bir kart ve sahibi Bookstore muhasebesi, çünkü faturayı ERP (Enterprise Resource Planning; şirketin muhasebe, stok ve fatura işlerini yürüten kurumsal yazılım) sistemine aktaran onlar. Emre kartın üzerine kime ve hangi tarihe kadar sorulacağını yazıyor.

Yirmi beş dakikanın sonunda masanın durumu şöyle:

Muhasebenin cevabı perşembe geliyor: ERP her satırı ayrı yuvarlıyor ve yarım kuruşu yukarı alıyor. Kırmızı kart, altında "hani şu 3 adet fen kitabı olan: satır 229,37 TL" örneğiyle yeni bir mavi karta dönüşüyor. Bu cevap sprint ortasında gelseydi, Emre'nin kodu büyük ihtimalle .NET'in varsayılan yuvarlamasıyla, yani banker's rounding ile 229,36 üretecek ve fark ilk faturada, okulun muhasebesinde ortaya çıkacaktı.

İkinci Kart: "Kısmi Sevkiyat Seçimi"

İkinci sarı kart çok daha farklı bir masa üretiyor. Story şu: stok yetersizken kurum, kısmi sevkiyat ile bekletme arasında seçim yapar. İlk mavi kart kolay: kurum seçimini siparişi gönderirken yapar. Sonra kartlar çoğalıyor. Eksik kalan kitaplar ikinci bir sevkiyatla mı gider? İkinci sevkiyatın kargo ücretini kim öder? Fatura sevk edilen kadar mı kesilir, sipariş tutarının tamamı için mi? Bir satır üç kampüse bölünmüşse ve stok yalnızca birine yetiyorsa ne olur? Stok sipariş gönderilirken mi kontrol edilir, depoda toplama sırasında mı?

On beş dakika sonra masada yedi mavi ve dört kırmızı kart var. Kırmızıların ikisinin sahibi depo, biri Bookstore muhasebesi, biri kurumsal satış. Ayşe'nin örneklerinden biri ise ilk kartla bağlantı kuruyor: kısmi sevkiyatta ilk koli 12 adet çıkarsa minimum 20 adet kuralı bozulur mu? Selin bunu oturumda cevaplayabiliyor: minimum siparişe bakar, sevkiyata değil. Bu, yeni bir kural değil, ilk karttaki kuralın kapsamını netleştiren bir örnek.

Bu masadaki asıl bulgu tek tek kartlar değil, masanın şekli. İlk story'de üç kural ve her birinin altında birkaç örnek vardı. Burada kurallar örneklerden fazla ve neredeyse her kuralın yanında bir soru duruyor.

Oturumun Sonunda: Hazır mı, Bölünmeli mi, Araştırılmalı mı?

Wynne masayı okumanın birkaç ipucunu verir ve bunlar karar için yeterli. Çok sayıda kırmızı kart, ekibin story hakkında hâlâ öğrenecek çok şeyi olduğunu gösterir. Çok sayıda mavi kart, story'nin büyük olduğunu ve bölünmesi gerektiğini düşündürür. Tek bir kuralın altında çok sayıda örnek birikmişse o kural aslında birkaç kuraldır. Süre dolduğunda ekip başparmak oylamasıyla story'nin geliştirmeye hazır olup olmadığına karar verir; küçük sorular açık kalabilir.

"Kurumsal indirim" kartı için oylama hızlı: üç başparmak yukarı. Masada bir kırmızı kart kalmıştı, ama cevabı story'nin büyüklüğünü değiştirmeyecekti; sahibi ve tarihi belliydi. Story hazır.

"Kısmi sevkiyat seçimi" için cevap hayır ve iki ayrı karar çıkıyor. Birincisi bölmek. 04. yazıdaki eksenlerden kural varyasyonu burada işe yarıyor: kurumun iki seçeneğinden biri, "hepsi hazır olunca tek sevkiyat", depo ve muhasebe sorularının hiçbirine dokunmuyor. Depo zaten workshop'ta "bir sipariş, bir sevkiyat" kuralını istemişti. Release 1'de yalnızca bu dilim kalıyor: herhangi bir kitabın stoku yetmiyorsa sipariş bütün olarak bekler ve tek sevkiyatla çıkar. İkincisi araştırmak. "Eksikleri sonra gönder" dilimi depo ile muhasebenin cevabına bağlı; ekip bunun için bir spike açmıyor, çünkü bilinmeyen teknik değil, iş kuralı. Selin depo sorumlusu ve muhasebeyle yarım saatlik bir görüşme ayarlıyor ve kart ikinci release'e iniyor.

Bu karar story map'te de bir değişiklik demek: pembe satırdaki "Kısmi sevkiyat seçimi" kartı yerini "Stok yetmezse sipariş bütün olarak bekler" kartına bırakıyor. Selin bu değişikliği Nevin Hanım'a da haber veriyor; eylülde hangi seçeneğin olmayacağını önceden bilmek, okul için sürpriz yaşamaktan iyidir.

Haritadan Kartın Arka Yüzüne

Example map oturumda kalırsa iki gün sonra unutulur. Ekip haritayı "Kurumsal indirim" story'sinin arka yüzüne, yani acceptance criteria'sına şöyle taşıyor: her mavi kart bir kural cümlesi, her yeşil kart o kuralın altında bir örnek satırı.

• Kurumsal sipariş toplamda en az 20 adet içerir. Örnekler: 19 + 1 geçer; 10 + 10 geçer; 12 + 7 reddedilir ve kuruma siparişin 19 adet olduğu söylenir.
• Kurumsal indirim liste fiyatından yüzde 10'dur. Örnek: 250 TL'lik kitaptan 40 adet, satır toplamı 9.000 TL.
• Kampanya indirimi ile kurumsal indirim üst üste binmez; büyüğü uygulanır. Örnek: yüzde 25 kampanyalı 120 TL'lik kitaptan 20 adet, satır toplamı 1.800 TL.
• Her satır toplamı ayrı ayrı kuruşa yuvarlanır, yarım kuruş yukarı. Örnek: 84,95 TL'lik kitaptan 3 adet, satır toplamı 229,37 TL (kaynak: Bookstore muhasebesi, perşembe).

Bu liste hem kural tabanlı hem senaryo tabanlı: kural cümlesi neyin geçerli olduğunu, sayılar tam olarak ne beklendiğini söylüyor. Liste fiyatı, adet ve beklenen sonuç belli olduğu için her satır doğrudan bir teste dönüşebilir; 07. yazıda bunu Gherkin ile, 08. yazıda Reqnroll ile yapacağız.

Üretimde Dikkat

Örneklerdeki sayılar gerçek olsun. "Bir kitap, birkaç adet" yerine 84,95 TL ve 3 adet yazmak, yuvarlama sorusunu ortaya çıkaran şeydi. Elinde katalogdan, geçen eylülün siparişlerinden gerçek fiyatlar ve adetler varsa onları kullan.

Kırmızı kartı sahipsiz bırakma. Her soru kimin cevaplayacağı ve hangi tarihe kadar bilgisiyle kalkar; cevap geldiğinde kart mavi karta ya da yeşil karta dönüşür ve bu dönüşüm acceptance criteria'ya işlenir. Cevabı veren kişi ve tarih de yanına yazılır; ilk yazıda konuştuğumuz traceability'nin en hafif hâli bu.

Haritanın fotoğrafını değil içeriğini sakla. Duvardaki kartların fotoğrafı bir hafta sonra kimse tarafından açılmaz. Kural ve örnekleri story'nin kendisine yazın; yeni bir örnek bulunduğunda, örneğin production'da bir okulun beklenmedik bir siparişinde, oraya eklenir.

Oturumu kısa tut ve sık yap. Yirmi beş dakikalık oturumlar sprint planning'den önceki haftaya yayıldığında, tek seferlik iki saatlik bir refinement toplantısından daha çok soru yakalar ve kimseyi yormaz.

Sık Düşülen Tuzaklar

İlk tuzak acceptance criteria'yı arayüz adımları listesi olarak yazmak: "Kullanıcı Yeni Sipariş'e tıklar, listeyi yapıştırır, Hesapla düğmesine basar, sağ üstte toplamı görür." Bu cümleler bir kural söylemiyor; düğmenin adı değiştiğinde yanlış, kural değiştiğinde ise hâlâ doğru görünür. Criteria davranışı anlatmalı: hangi siparişin hangi toplamı alacağını.

İkinci tuzak edge case'leri sprint ortasında keşfetmek. Yuvarlama sorusu oturumda çıkmasaydı sprint'in yedinci günü bir test sırasında çıkacak, Emre muhasebenin cevabını beklerken story yarım kalacaktı. Example Mapping'in asıl işi bu tür soruları sprint'ten önce görünür kılmak.

Üçüncüsü oturumu Product Owner'ın monoloğuna çevirmek. Selin kuralları okur, ekip başını sallarsa ortaya çıkan şey bir harita değil, bir sunumdur. Örnekleri yazan geliştirici ve test bakışı olmalı; kuralın sınırını bulan şey onların "peki şu durumda?" sorusudur.

Dördüncüsü her olasılığı örneğe çevirmek. Kırk yeşil kartlık bir kural ya birkaç kuraldır ya da ekip aynı sınırı farklı sayılarla tekrar test ediyordur. Bir kuralı netleştirmek için genellikle sınırın iki yanı ve bir ilginç durum yeter.

Beşincisi Example Mapping'i Definition of Ready'nin yeni maddesine çevirmek. "Haritası çıkarılmamış story sprint'e giremez" kuralı, kısa bir konuşma alışkanlığını yine bir kapıya dönüştürür. Bazı story'lerin kuralı o kadar açıktır ki harita gerekmez.

Küçük Bir Deneme

★☆☆ Backlog'unda sıradaki story'nin acceptance criteria'sını oku. Her maddeyi işaretle: davranış mı anlatıyor, arayüz adımı mı? Arayüz adımı olanları bir kural cümlesine çevir.

★★☆ Bir story için yirmi beş dakikalık bir Example Mapping oturumu yap; elinde kart yoksa dört renk yapışkan not ya da bir dijital whiteboard yeter. Oturum sonunda mavi, yeşil ve kırmızı kartları say ve bu yazıdaki ipuçlarıyla story'nin hazır mı, bölünmeli mi, araştırılmalı mı olduğuna karar ver.

★★★ Ekibinin son üç sprint'inde sprint ortasında ortaya çıkan bir kural sorusunu bul. O story için geriye dönük bir example map çıkar: soru hangi kuralın altında kırmızı kart olarak çıkardı ve onu kim cevaplayabilirdi? Bunu bir sonraki retrospective'e götür.

Example Mapping ile kurumsal siparişin davranışını kurallar ve örneklerle netleştirdik. Ama oturumda hiçbir karta sığmayan cümleler de duyduk: "1.000 satırlık liste beklemeden kontrol edilsin", "eylülde sistem çökmesin", "okulun siparişini başka okul görmesin". Bunlar tek bir story'nin kuralı değil, sistemin kalitesine dair beklentiler. Bir sonraki yazıda non-functional requirement'lara geçiyoruz: ISO (Uluslararası Standardizasyon Örgütü) ve IEC'nin (Uluslararası Elektroteknik Komisyonu) ortak standardı ISO/IEC 25010:2023'ün quality model'ini, "hızlı olsun"u ölçülebilir hâle getirmeyi ve bu requirement'ların nereye yazılacağını göreceğiz.