Kriteria Penerimaan: Cara Menulisnya (Dengan Contoh)

Kriteria penerimaan ialah syarat yang mesti dipenuhi oleh sebuah kisah pengguna sebelum pasukan anda menganggapnya sedia untuk dihantar. Tulis dengan betul dan anda akan mengurangkan kerja semula, pertikaian, dan pepijat mengejut semasa semakan.

Apakah kriteria penerimaan?

Kriteria penerimaan ialah satu set syarat yang spesifik dan boleh diuji yang dilampirkan pada satu kisah pengguna. Ia mentakrifkan apa yang perlu dilakukan (dan tidak dilakukan) oleh ciri tersebut dari perspektif pengguna. Apabila setiap syarat lulus, kisah itu diterima. Apabila satu pun gagal, kerja diteruskan.

Anggap ia sebagai kontrak antara orang yang meminta ciri tersebut dengan pasukan yang membinanya. Tiada tekaan. Tiada "saya ingat anda bermaksud sesuatu yang lain." Hanya senarai syarat lulus-atau-gagal yang jelas, ditulis sebelum pembangunan bermula.

Kriteria penerimaan wujud di peringkat kisah. Ia menjawab soalan: "Bagaimana kita tahu kisah ini selesai?" Itu soalan yang berbeza daripada "Bagaimana kita tahu Sprint selesai?" yang dijawab oleh definition of done.

Fakta Utama

• Format Given-When-Then untuk kriteria penerimaan diperkenalkan oleh Dan North sebagai sebahagian daripada behaviour-driven development (BDD) sekitar tahun 2006, memberikan pasukan cara yang berstruktur dan boleh diuji untuk menyatakan tingkah laku yang dijangka. (Sumber: Dan North, "Introducing BDD," dannorth.net, 2006.)
• Agile Alliance menyatakan bahawa kriteria penerimaan yang kabur atau tiada adalah antara punca kerja semula yang paling kerap berlaku dalam projek agile. (Sumber: Agile Alliance Glossary, agilealliance.org.)
• Pasukan yang menulis kriteria penerimaan sebelum menulis kod melaporkan peralihan yang lebih pantas dari pembangunan ke QA kerana penguji sudah tahu apa yang perlu disahkan.

Format penulisan kriteria penerimaan

Terdapat dua format yang paling kerap digunakan pasukan. Tiada satu yang lebih baik secara universal. Pilih yang sesuai dengan cara kerja pasukan anda.

Given-When-Then (berasaskan senario)

Juga dikenali sebagai format Gherkin, ini berasal daripada behaviour-driven development (BDD). Ia menyusun setiap syarat sebagai senario dengan tiga bahagian:

• Given -- keadaan awal atau konteks
• When -- tindakan yang dilakukan pengguna
• Then -- hasil yang dijangka

Contoh -- log masuk pengguna:

Given a registered user is on the login page
When they enter a valid email and correct password and click "Sign In"
Then they are redirected to their dashboard and see a welcome message

Given a registered user is on the login page
When they enter a valid email and an incorrect password
Then they see an error message: "Email or password is incorrect" and remain on the login page

Format ini sesuai apabila tingkah laku adalah berurutan dan anda boleh menulis pelbagai senario kegagalan bersama laluan yang berjaya. Jurutera QA boleh mengubah setiap senario terus menjadi kes ujian.

Berasaskan peraturan (senarai semak)

Sesetengah pasukan lebih suka senarai titik peluru yang lebih ringkas. Format ini sesuai untuk kisah di mana syarat adalah bebas, bukan berurutan.

Contoh -- carian produk:

- Keputusan carian muncul dalam masa 2 saat untuk sebarang pertanyaan
- Keputusan disusun mengikut relevan secara lalai
- Pengguna boleh menapis keputusan mengikut kategori, julat harga, dan penilaian
- Jika tiada keputusan ditemui, halaman menunjukkan: "No results for [query]. Try different keywords."
- Bar carian mengekalkan pertanyaan pengguna selepas keputusan dimuatkan

Kriteria penerimaan berasaskan peraturan lebih cepat ditulis dan lebih mudah dibaca. Ia paling sesuai untuk kekangan UI, keperluan prestasi, dan kes tepi yang tidak sesuai dengan urutan tindakan pengguna.

Kriteria penerimaan berbanding definition of done

Kedua-dua konsep ini sering mengelirukan. Ia menyelesaikan masalah yang berbeza.

Sebuah kisah boleh lulus semua kriteria penerimaannya tetapi masih gagal definition of done, contohnya jika ia tiada ujian unit atau tidak disemak oleh rakan sekerja. Kedua-dua senarai mesti lulus sebelum kerja benar-benar selesai.

Lihat huraian penuh dalam artikel definition of done.

Ciri-ciri kriteria penerimaan yang baik

Tidak semua senarai syarat layak sebagai kriteria penerimaan yang baik. Inilah yang membezakan yang berguna daripada yang kabur:

Boleh diuji. Setiap syarat mesti mempunyai hasil lulus atau gagal yang jelas. "UI kelihatan cantik" tidak boleh diuji. "Butang memenuhi nisbah kontras 4.5:1" boleh diuji.

Ditulis dari perspektif pengguna. Kriteria penerimaan menerangkan apa yang dialami pengguna, bukan bagaimana kod disusun. Elakkan butiran pelaksanaan seperti "API mengembalikan status 200." Lebih baik: "pengguna melihat profil mereka yang dikemas kini dengan serta-merta."

Spesifik. Nombor, keadaan, dan label penting. "Tindak balas pantas" menjadi "tindak balas di bawah 1.5 saat." "Mesej ralat" menjadi "teks tepat: 'Kata laluan mesti sekurang-kurangnya 8 aksara.'"

Dipersetujui sebelum pembangunan bermula. Kriteria yang ditulis selepas ciri siap dibina cenderung merasionalkan apa yang telah dibina, bukan menerangkan apa yang diperlukan. Tulis semasa backlog refinement.

Tidak terlalu banyak. Tiga hingga lapan syarat adalah julat yang sihat. Sebuah kisah dengan lima belas kriteria penerimaan berkemungkinan adalah dua atau tiga kisah yang tersembunyi dalam satu.

Cara menulis kriteria penerimaan

Langkah 1: Mulakan dengan kisah pengguna

Anda tidak boleh menulis kriteria penerimaan tanpa kisah pengguna yang jelas. Sahkan anda mempunyai satu dalam format ini:

Sebagai [persona], saya mahu [matlamat], supaya [sebab].

Jika kisah itu kabur, pertajamkan dahulu sebelum menulis syarat.

Langkah 2: Tanya "apa yang mesti benar agar ini berfungsi?"

Senaraikan tingkah laku dan hasil yang mesti dihasilkan oleh ciri tersebut. Liputi laluan yang berjaya dahulu, kemudian kes tepi dan keadaan kegagalan.

Langkah 3: Pilih format

Pilih Given-When-Then jika tingkah laku adalah berurutan dan QA akan menguruskan penciptaan ujian. Pilih berasaskan peraturan jika syarat adalah bebas atau anda berada di bawah tekanan masa.

Langkah 4: Tulis dalam bahasa yang boleh diuji

Gantikan perkataan yang kabur. "Dengan cepat" menjadi nombor. "Diformat dengan betul" menjadi format yang tepat. "Sepatutnya berfungsi pada mudah alih" menjadi "susun atur responsif pada lebar 375px."

Langkah 5: Semak bersama pasukan sebelum pembangunan bermula

Kongsi draf dengan pembangun, QA, dan pihak berkepentingan. Pembangun akan mengesan syarat yang mustahil secara teknikal. QA akan mengesan kes tepi yang hilang. Pihak berkepentingan akan mengesan ralat logik perniagaan. Lakukan ini semasa backlog refinement atau perancangan sprint supaya semua orang selaras sebelum sebaris kod ditulis.

Langkah 6: Lampirkan pada kisah

Tambah kriteria yang telah dimuktamadkan pada kisah dalam product backlog anda. Ia kekal dilampirkan sepanjang pembangunan dan menjadi senarai semak yang digunakan pasukan anda semasa sprint review.

Contoh kriteria penerimaan

Berikut adalah tiga contoh yang telah disiapkan merentas jenis kisah yang berbeza.

Contoh 1: Log masuk pengguna

Kisah: Sebagai pengguna yang kembali, saya mahu log masuk dengan e-mel dan kata laluan saya, supaya saya boleh mengakses akaun saya.

Given the user is on the sign-in page
When they enter a registered email and correct password and click "Sign In"
Then they are redirected to their dashboard within 2 seconds

Given the user enters an incorrect password three times
When they attempt a fourth login
Then the account is locked for 30 minutes and the user sees:
"Too many failed attempts. Try again in 30 minutes."

Given the user is signed in
When they click "Sign Out"
Then their session ends and they are redirected to the homepage

Contoh 2: Jumlah pembayaran

Kisah: Sebagai pembeli, saya mahu melihat jumlah pesanan saya sebelum membayar, supaya saya tahu dengan tepat berapa yang perlu saya bayar.

Contoh 3: Carian tanpa keputusan

Kisah: Sebagai pengguna, saya mahu tahu apabila carian saya tidak menghasilkan apa-apa, supaya saya boleh mencuba kata kunci yang berbeza.

- Apabila carian menghasilkan sifar keputusan, halaman memaparkan: "No results for '[query]'. Try different keywords."
- Bar carian mengekalkan pertanyaan asal pengguna
- Cadangan kategori berkaitan muncul di bawah mesej jika tersedia
- Tajuk halaman dikemas kini untuk mencerminkan keadaan carian kosong

Kesilapan biasa yang perlu dielakkan

Menulisnya selepas selesai. Kriteria penerimaan yang ditulis selepas pembangunan menerangkan apa yang dibina, bukan apa yang diperlukan. Tulis dahulu.

Terlalu kabur tentang keadaan ralat. Kriteria hanya untuk laluan yang berjaya menyebabkan pembangun meneka tentang pengendalian kegagalan. Sentiasa masukkan sekurang-kurangnya satu senario kegagalan.

Mencampurkan butiran pelaksanaan teknikal. "Perkhidmatan memanggil API pembayaran dengan permintaan POST" bukan kriteria penerimaan. "Pengguna melihat pengesahan pembayaran dalam masa 3 saat" adalah.

Membuat terlalu besar. Jika kriteria penerimaan anda meliputi beberapa ciri yang berbeza, pecahkan kisah itu. Kisah yang baik dengan kriteria yang baik muat pada satu kad indeks.

Meninggalkan semakan pasukan. Kriteria yang ditulis secara bersendirian (biasanya oleh product owner) terlepas kekangan pembangun dan kes tepi QA. Semak bersama sebelum Sprint bermula. Gunakan agile ceremonies seperti refinement untuk melakukan ini secara konsisten.

Soalan lazim

Apakah kriteria penerimaan?

Kriteria penerimaan ialah syarat yang spesifik dan boleh diuji yang mesti dipenuhi oleh sebuah kisah pengguna sebelum pasukan menerimanya sebagai selesai. Ia mentakrifkan apa yang perlu dilakukan oleh ciri tersebut dari perspektif pengguna, dan ditulis sebelum pembangunan bermula.

Siapa yang menulis kriteria penerimaan?

Product owner biasanya menggubal kriteria penerimaan, tetapi seluruh pasukan, iaitu pembangun, QA, dan kadang-kadang pihak berkepentingan, menyemak dan memperhalusinya sebelum pembangunan bermula. Menulis kriteria secara bersendirian menghasilkan kes tepi yang terlepas dan kerja semula.

Apakah perbezaan antara kriteria penerimaan dan definition of done?

Kriteria penerimaan adalah bagi setiap kisah: ia menerangkan apa yang mesti dilakukan oleh satu ciri tertentu. Definition of done adalah global: ia adalah senarai semak yang terpakai untuk setiap kisah dalam Sprint (semakan rakan sekerja, liputan ujian, dokumentasi, dan sebagainya). Sebuah kisah mesti lulus kedua-duanya sebelum dihantar.

Apakah Given-When-Then?

Given-When-Then ialah format berstruktur untuk menulis kriteria penerimaan sebagai senario yang boleh diuji. "Given" menetapkan konteks, "When" menerangkan tindakan pengguna, dan "Then" menyatakan hasil yang dijangka. Ia diperkenalkan oleh Dan North sebagai sebahagian daripada behaviour-driven development (BDD) sekitar tahun 2006 dan digunakan secara meluas dalam pasukan agile hari ini.

Berapa banyak kriteria penerimaan yang sepatutnya ada dalam sebuah kisah pengguna?

Sasarkan tiga hingga lapan. Kurang daripada tiga sering bermakna kisah itu kurang terperinci. Lebih daripada lapan biasanya bermakna kisah itu terlalu besar dan perlu dipecahkan kepada kisah yang lebih kecil.

---

Kriteria penerimaan yang baik tidak menjamin produk yang hebat, tetapi ia mencegah satu kategori kegagalan tertentu: membina sesuatu yang tidak dimaksudkan oleh sesiapa pun. Tulis lebih awal, semak bersama, dan anda akan mendapati sprint review anda berubah daripada perdebatan tentang maksud "selesai" kepada demonstrasi perisian yang berfungsi dengan lancar.