Kullanıcı hikâyeleri ve kabul ölçütleri: gereksinimleri anlaşılır formüle etme

Kısaca: Bir kullanıcı hikâyesi bir gereksinimi kullanıcının bakış açısından tek cümleyle tarif eder; kabul ölçütleri ne zaman yerine getirilmiş sayıldığını tanımlar.

Biraz daha ayrıntılı: Uzun şartnameler çoğu zaman okunmaz. Çevik ekipler gereksinimleri fayda ve amacı gösteren ve konuşmada somutlaştırılan kısa hikâyeler olarak yazar.

Ayrıntılı

Biçim

olarak <işlevi> istiyorum ki . Örnek: “Müşteri olarak siparişimi e-postayla onaylı almak istiyorum ki ulaştığını bileyim.” Üç bölüm Kim? Ne? Neden? sorularını yanıtlar. “İstiyorum ki” amaçsız işlevleri önler. Hikâye eksiksiz bir sözleşme değil, konuşma vesilesidir.

İyi hikâyeler: INVEST

• Independent (bağımsız)
• Negotiable (pazarlık edilebilir)
• Valuable (kullanıcıya/müşteriye değerli)
• Estimable (tahmin edilebilir)
• Small (bir sprint için yeterince küçük)
• Testable (test edilebilir) Çok büyük hikâyeler (“epic’ler”) daha küçüklere bölünür.

Kabul ölçütleri

Hikâyenin ne zaman bitti olduğunu somut tarif ederler, ideal olarak given – when – then biçiminde:

• Given sepet boş değil, when ödeme yaparsam, then sipariş numaralı bir onay e-postası alırım.
• E-posta 5 dakika içinde gelir; ürünleri, toplamı, teslimat adresini içerir.
• Geçersiz bir e-posta adresi için bir hata mesajı gösterilir. Test edilebilirdirler (evet/hayır), yeterince eksiksizdirler ve testlerin (bkz. BDD) ve kabulün temelini oluştururlar.

Projeye yerleştirme

Hikâyeler ürün backlog’unda durur, önceliklendirilir ve sprint’te uygulanır. Bitti tanımı (DoD) tüm hikâyeler için, kabul ölçütleri tek bir hikâye için geçerlidir. IHK belgelemesinde gereksinimleri ölçütlü kullanıcı hikâyeleri olarak sunabilir ve gereksinim/şartname belgeleriyle tamamlayabilirsin. Ek olarak: kullanım durumu diyagramları, prototipler, taslaklar.

Ayrıca bak: Çevik yöntemler, Gereksinim ve şartname belgeleri, BDD, Kabul ve teslim