Gönderiler

Gerçekten yeniden çalışmayı önleyen kabul kriterleri nasıl yazılır

Backlog iyileştirme oturumu sırasında yapışkan notlar ve dizüstü bilgisayar etrafında bir araya gelen, kullanıcı hikayesi için gereksinimleri tartışan çevik ekip Gereksinimlerle ilgili sorunlar, tüm yazılım kusurlarının neredeyse yarısına neden olur. Bunların çoğu aynı temel soruna dayanır: ekip, gerçekte neye ihtiyaç duyulduğunu değil, istendiklerini düşündükleri şeyi yapmıştır. Kabul kriterleri bu soruna çözümdür. Belirsiz bir kullanıcı hikayesini, ürün sahibi ile geliştirme ekibi arasında test edilebilir bir sözleşmeye dönüştürürler. İyi yazıldığında, sprint incelemelerini raydan çıkaran "ama ben şöyle olması gerektiğini düşünmüştüm..." konuşmalarını sonlandırırlar. Bu kılavuz, iki ana formatı, uyarlayabileceğiniz gerçek örnekleri ve deneyimli ekipleri tökezleten hataları kapsar.

Kabul kriterleri nedir (ve ne değildir)

Kabul kriterleri, bir kullanıcı hikayesinin tamamlanmış sayılabilmesi için karşılaması gereken koşullardır. Tek bir soruyu yanıtlarlar: "Bunun çalıştığını nasıl bileceğiz?" Tanımı ile aynı şey değildir. DoD, tüm işler için geçerli evrensel bir kalite standardıdır (kod incelendi, testler yazıldı, staging ortamına dağıtıldı). Kabul kriterleri tek bir hikayeye özgüdür.

	Kabul kriterleri	Tanımı
Kapsam	Bir kullanıcı hikayesi	Tüm iş öğeleri
Odak	Özelliğin kullanıcılar için ne yaptığı	Ne kadar iyi yapıldığı
Kim yazar	Ürün Sahibi + ekip	Tüm Scrum Ekibi
Örnek	"Kullanıcı tarih aralığına göre filtreleyebilir"	"Kod en az 1 geliştirici tarafından incelendi"

Bir hikayenin tamamlanmış sayılabilmesi için her ikisi de karşılanmalıdır. Hala DoD'nizi oluşturuyorsanız, Tanımı Oluşturucumuz başlamanıza yardımcı olabilir.

İki ana format

Kontrol listesi formatı (kural tabanlı)

Basit bir geçti/kaldı koşulları listesi. Beklenen davranışın net olduğu basit özellikler için en iyisidir.

Şifre sıfırlama özelliği:
- Giriş sayfasında "Şifremi unuttum" bağlantısı görünür
- Tıklamak bir e-posta adresi ister
- Geçerli e-postaya 60 saniye içinde sıfırlama bağlantısı gönderilir
- Sıfırlama bağlantısı 24 saat sonra sona erer
- Yeni şifre mevcut şifre gereksinimlerini karşılamalıdır
- Sıfırlamadan sonra, kullanıcı başarı mesajıyla giriş sayfasına yönlendirilir
- Geçersiz e-posta şunu gösterir: "Bu e-posta mevcutsa, bir sıfırlama bağlantısı gönderildi"

Ne zaman kullanılır: Basit özellikler, UI gereksinimleri, iş kuralları, doğrulama mantığı. Hikayelerinizin çoğu bu formatı kullanacaktır.

Given/When/Then formatı (Gherkin)

Davranış Odaklı Geliştirmeden gelen yapılandırılmış bir senaryo formatı. Her senaryo bir ön koşul, bir eylem ve beklenen bir sonucu tanımlar.

Senaryo: Geçerli bir indirim kodu uygulama
Given kullanıcının sepetinde toplam $100 değerinde ürün var
And geçerli %20 indirim kodu "SAVE20" mevcut
When kullanıcı indirim alanına "SAVE20" girer
And "Uygula"ya tıklar
Then sepet toplamı $80'e güncellenir
And "İndirim uygulandı" mesajı görünür

Senaryo: Süresi dolmuş indirim kodu uygulama
Given "OLD10" indirim kodunun süresi dün doldu
When kullanıcı "OLD10" girer ve "Uygula"ya tıklar
Then sepet toplamı değişmeden kalır
And "Bu kodun süresi doldu" hata mesajı görünür

Ne zaman kullanılır: Birden fazla yolu olan karmaşık iş akışları veya Cucumber ya da SpecFlow gibi BDD araçlarıyla otomatikleştirmeyi planladığınız özellikler. Kabul kriterleri için kontrol listesi formatını ve Given/When/Then formatını gösteren, farklılıkları vurgulayan renkli açıklamalarla yan yana iki belge

Hangi formatı seçmelisiniz?

Çoğu ekip hibrit bir yaklaşımı benimser: basit hikayeler için kontrol listesi, karmaşık dallanması veya birden fazla kullanıcı yolu olan her şey için Given/When/Then. Fazla düşünmeyin. O spesifik hikaye için gereksinimleri daha net ileten formatı seçin.

İyi kabul kriterleri yazmak için beş kural

1. Ne'yi tanımlayın, nasıl'ı değil

Kötü: "400ms geçiş animasyonlu modal bileşeni kullan" İyi: "Öğe silinmeden önce onay diyalogu görünür" Kriterler sonuçları tanımlar. Uygulama geliştiricinin işidir.

2. Her kriteri test edilebilir yapın

Bir kriterin karşılanıp karşılanmadığına "evet" veya "hayır" yanıtını veremiyorsanız, çok belirsizdir. Kötü: "Sayfa hızlı yüklenmeli" İyi: "Arama sonuçları 500 sonuca kadar 2 saniye içinde yüklenir"

3. Hatalı yolu da kapsayın

Her mutlu yol için en az bir hata senaryosu yazın. Geçersiz girdiyle ne olur? Düşen bir bağlantıyla? Eksik izinlerle?

4. Kriterleri bağımsız tutun

Her kriter kendi başına doğrulanabilir olmalıdır. Kriter #4 yalnızca #1'den #3'e kadar olan kriterleri okuduktan sonra anlamlıysa, kabul kriterleri değil, bir spec yazmışsınız demektir.

5. Sprint planlamasından önce yazın

Geliştirme sırasında yazılan kabul kriterleri gereksinimler değil, açıklamalardır. Ekibin planlama poker sırasında doğru tahmin edebilmesi için backlog iyileştirme sırasında yazın.

Gerçek dünya örnekleri

E-ticaret arama filtresi

Kullanıcı hikayesi: "Bir alışverişçi olarak, aradığımı daraltabilmek için ürünleri birden fazla kategoriye göre filtrelemek istiyorum."

• Filtreler tüm mevcut ürün kategorilerini gösterir
• Kullanıcılar aynı anda birden fazla kategori seçebilir
• Sonuçlar sayfa yenilemeden gerçek zamanlı güncellenir
• Uygulanan filtreler kaldırılabilir rozetler olarak görünür
• "Tümünü temizle" düğmesi tüm aktif filtreleri kaldırır
• Sonuç sayısı aktif filtreleri yansıtacak şekilde güncellenir (örn. "47 sonuç gösteriliyor")
• Eşleşen sonuç yoksa şunu gösterir: "Filtrelerinize uygun ürün yok. Seçiminizi genişletmeyi deneyin."
• Filtre durumu ürün detay sayfasından geri dönüldüğünde korunur

Ekip davet akışı

Kullanıcı hikayesi: "Bir ekip lideri olarak, işbirliği yapmaya başlayabilmemiz için üyeleri e-postayla davet etmek istiyorum."

Senaryo: Başarılı davet
Given ekip ayarları sayfasındayım
When davet alanına "alex@company.com" giriyorum
And "Davet Gönder"e tıklıyorum
Then 60 saniye içinde bir davet e-postası gönderilir
And e-posta "Bekleyen Davetler" listemde görünür
And davetin gönderildiğini onaylayan bir başarı mesajı görünür

Senaryo: Tekrarlanan davet
Given "alex@company.com" adresini zaten davet ettim
When aynı e-postayı girip "Davet Gönder"e tıkladığımda
Then bir uyarı görünür: "Bu e-postaya zaten davet gönderildi"
And yeniden göndermeyi veya iptal etmeyi seçebilirim

Senaryo: Geçersiz e-posta formatı
Given ekip ayarları sayfasındayım
When "not-an-email" girip "Davet Gönder"e tıkladığımda
Then satır içi bir hata görünür: "Geçerli bir e-posta adresi girin"
And hiçbir davet gönderilmez

Bildirim tercihleri

Kullanıcı hikayesi: "Bir kullanıcı olarak, uyarılarla boğulmamak için hangi bildirimleri alacağımı kontrol etmek istiyorum."

• Ayarlar sayfası her bildirim kategorisi için geçiş düğmesi gösterir
• Değişiklikler otomatik olarak kaydedilir (ayrı bir "Kaydet" düğmesi yok)
• Bir kategoriyi kapatmak 5 dakika içinde o türdeki tüm bildirimleri durdurur
• En az bir bildirim kanalı aktif kalmalıdır (her şeyi yanlışlıkla devre dışı bırakmayı önle)
• "Varsayılanlara sıfırla" orijinal bildirim ayarlarını geri yükler
• Değişiklikler tüm cihazlarda geçerlidir

Net yazılmış kabul kriterleriyle bir kullanıcı hikayesi kartını inceleyen, öğeleri tek tek işaretleyen bir geliştirici

Yaygın hatalar

Fazla belirsiz olmak. "Sistem kullanıcı dostu olmalı" test edilebilir değildir. Öznel dili ölçülebilir koşullarla değiştirin. Uygulama reçete etmek. "Durum yönetimi için Redux kullan" bir teknik spike'a aittir, kabul kriterlerine değil. Kodun nasıl çalıştığını değil, kullanıcının ne yaşadığını tanımlayın. Sadece mutlu yolu yazmak. Kriterleriniz yalnızca güneşli senaryoyu kapsıyorsa, ekibiniz sprint ortasında kenar durumları keşfedecek ve ya köşeleri kesecek ya da tahmini aşacaktır. Kriterleri çok geç yazmak. Geliştirme sırasında yazılan kriterler gereksinimler değil, geriye dönük gerekçelendirmelerdir. İyileştirme sırasında tanımlayın, sprint planlaması sırasında iyileştirin. Kriterleri çok ayrıntılı yapmak. Kriterleriniz 30 adımlı bir test senaryosu gibi okunuyorsa, çok ileri gitmişsiniz. Hikaye başına 5-10 kriter hedefleyin. Daha fazlasına ihtiyacınız varsa, hikaye muhtemelen çok büyüktür ve daha küçük hikayelere bölünmelidir.

Hızlı bir öz kontrol

Bir hikayeyi bir sprint'e dahil etmeden önce şunu gözden geçirin: Bunlardan herhangi biri başarısızsa, hikaye sprint'e hazır olmadan önce bir tur daha backlog iyileştirme gerektirir.

Kabul kriterlerini daha hızlı yazmak

"Üç Silahşörler" yaklaşımı işe yarar: her hikaye için ürün sahibini, bir geliştiricyi ve bir test uzmanını aynı odaya getirin. PO amacı açıklar, geliştirici teknik kenar durumlarını fark eder ve test uzmanı "ya...?" soruları ile delik açar. Kullanıcı hikayeleri yazıyorsanız ve bir başlangıç noktasına ihtiyacınız varsa, Kabul Kriterleri Oluşturucumuz bir hikaye açıklamasından ilk kriterleri taslak halinde hazırlayabilir. İlk %80'i hızlıca alır, böylece ekibiniz boş bir sayfaya bakmak yerine iyileştirme zamanını zor kenar durumlarına harcayabilir.