Cara Menulis User Stories (Dengan Contoh dan Kriteria Penerimaan)
User story ialah penerangan ringkas tentang sesuatu ciri dari sudut pandang pengguna: "Sebagai [jenis pengguna], saya mahu [matlamat] supaya [sebab]." Di bawahnya anda tulis kriteria penerimaan, beberapa syarat khusus yang mesti benar supaya story itu dikira selesai. Pastikan setiap story cukup kecil untuk dibina dan diuji sekali jalan, dan tulis kriteria supaya sesiapa sahaja boleh menyemaknya.
User stories dipopularkan oleh pasukan perisian agile, tetapi ia sama berguna apabila anda membina sendiri dengan pembina aplikasi AI. Story yang baik ialah prompt yang baik.
Formatnya
User story mempunyai tiga bahagian:
Sebagai [siapa], saya mahu [apa] supaya [mengapa].
- Siapa ialah jenis pengguna yang khusus: pelawat kali pertama, ahli berbayar, penyambut tetamu klinik, pentadbir. Bukan "pengguna" secara am.
- Apa ialah perkara yang mereka mahu lakukan, dalam kata-kata mereka sendiri. Bukan cara skrin berfungsi.
- Mengapa ialah hasil yang mereka pedulikan. Ia bahagian yang selalu dilangkau, dan yang menghalang anda daripada membina perkara yang salah.
Contoh:
Sebagai ahli gim, saya mahu membatalkan tempahan kelas dari telefon saya supaya seseorang dalam senarai menunggu boleh mengambil tempat saya dan saya tidak dikenakan yuran tidak hadir.
Bahagian "mengapa" memberitahu dua perkara yang "apa" tidak beritahu: ia mesti berfungsi di telefon, dan peraturan senarai menunggu serta yuran turut terlibat.
Kriteria penerimaan
Story menyatakan apa yang dimahukan. Kriteria penerimaan menyatakan bila ia selesai. Ia perlu cukup khusus supaya dua orang akan bersetuju sama ada setiap satu lulus.
Cara biasa menulisnya ialah Diberi / Apabila / Maka:
- Diberi keadaan permulaan
- Apabila pengguna melakukan sesuatu
- Maka ini ialah hasilnya
Untuk story tempahan gim itu:
- Diberi saya mempunyai tempahan lebih 12 jam dari sekarang, apabila saya ketik Batal dan sahkan, maka tempahan itu dibuang dan saya nampak "Tempahan dibatalkan".
- Diberi saya membatalkan tempahan dan kelas itu mempunyai senarai menunggu, apabila pembatalan disimpan, maka orang pertama dalam senarai menunggu mendapat tempat itu dan e-mel.
- Diberi tempahan kurang 12 jam dari sekarang, apabila saya ketik Batal, maka saya nampak bahawa yuran pembatalan lewat dikenakan sebelum saya sahkan.
- Diberi saya berada pada skrin lebar telefon, maka butang Batal kelihatan tanpa perlu skrol ke sisi.
Senarai semak biasa juga boleh digunakan, selagi setiap item boleh diuji. "Membatalkan itu mudah" tidak boleh diuji. "Pembatalan mengambil paling banyak dua ketikan dari senarai tempahan" boleh diuji.
Langkah demi langkah: menulis story yang baik
Langkah 1: Mulakan daripada pengguna sebenar dan masalah sebenar
Pilih satu jenis pengguna dan sesuatu yang mereka bergelut dengannya hari ini. Jika anda telah membuat temu bual pelanggan, gunakan kata-kata mereka. "Saya selalu terlupa batalkan dan kena caj" ialah titik permulaan yang lebih baik daripada "tambah ciri pembatalan".
Langkah 2: Tulis story satu baris
Isi templat itu. Jika anda tidak dapat menulis "supaya" yang meyakinkan, tanya sama ada ciri itu diperlukan langsung.
Langkah 3: Tambah tiga hingga enam kriteria penerimaan
Liputi kes kejayaan utama dahulu, kemudian variasi penting: peranan yang berbeza, keadaan kosong, had, ralat. Jika anda menulis lebih daripada enam, story itu mungkin terlalu besar.
Langkah 4: Catatkan apa yang di luar skop
Satu baris menjimatkan banyak tolak-ansur: "Di luar skop: bayaran balik untuk kelas berbayar; pentadbir membatalkan bagi pihak ahli." Ia menghalang story daripada membesar semasa anda membina.
Langkah 5: Semak dengan INVEST
INVEST ialah senarai semak biasa untuk story yang baik. Sebuah story sepatutnya:
| Huruf | Maksud | Ujian ringkas |
|---|---|---|
| I | Bebas (Independent) | Boleh dibina tanpa menunggu story lain |
| N | Boleh dirundingkan (Negotiable) | Menerangkan keperluan, bukan reka bentuk tetap |
| V | Bernilai (Valuable) | Pengguna akan perasan jika ia dilancarkan |
| E | Boleh dianggar (Estimable) | Anda boleh meneka kasar saiznya |
| S | Kecil (Small) | Dibina dan diuji dalam satu sesi |
| T | Boleh diuji (Testable) | Setiap kriteria penerimaan boleh disemak |
Anda tidak perlu menilai setiap story. Ia paling berguna apabila sesuatu story terasa tidak kena dan anda mahu tahu sebabnya.
Contoh baik dan buruk
| Story lemah | Masalah | Story yang lebih baik |
|---|---|---|
| Sebagai pengguna, saya mahu papan pemuka. | Tiada pengguna khusus, tiada sebab, tidak boleh diuji | Sebagai pemilik kedai, saya mahu melihat pesanan dan hasil hari ini pada satu skrin supaya saya tahu dengan sekali pandang sama ada hari itu berjalan lancar. |
| Sebagai pentadbir, saya mahu pangkalan data mempunyai lajur status. | Menerangkan pelaksanaan, bukan keperluan | Sebagai pentadbir, saya mahu menandakan pesanan sebagai dihantar supaya pelanggan berhenti e-mel untuk bertanya di mana pesanan mereka. |
| Sebagai pelanggan, saya mahu mengurus akaun saya. | Terlalu besar: meliputi banyak ciri | Sebagai pelanggan, saya mahu menukar alamat e-mel saya supaya resit dihantar ke peti masuk baharu saya. |
| Sebagai pelawat, saya mahu laman ini pantas. | Bukan story; kualiti yang semua orang perlukan | Tulisnya sebagai kriteria pada setiap story, atau sebagai sasaran prestasi yang berasingan. |
Cara memecahkan story yang terlalu besar
Story yang besar ialah tempat projek sering terhenti. Cara biasa untuk memecahkannya:
- Mengikut peranan pengguna. Ahli membatalkan tempahan mereka sendiri; kakitangan membatalkan tempahan sesiapa.
- Mengikut langkah dalam aliran. Semak imbas kelas; tempah kelas; terima peringatan.
- Kes mudah dahulu. Batalkan kelas percuma sekarang; uruskan yuran dan bayaran balik dalam story kemudian.
- Mengikut variasi data. Sokong satu lokasi dahulu, beberapa lagi kemudian.
- Laluan utama, kemudian ralat. Bina ia berfungsi dahulu, kemudian tambah pengendalian untuk kelas penuh, pas tamat tempoh, dan sebagainya.
Setiap bahagian masih perlu menjadi sesuatu yang boleh digunakan dan disedari oleh pengguna.
Menggunakan user stories sebagai prompt
User story dengan kriteria penerimaan sangat hampir kepada prompt yang baik untuk pembina aplikasi AI. Ia memberi AI siapa, apa, mengapa dan definisi selesai. Hantar satu story setiap mesej:
Sebagai ahli gim, saya mahu membatalkan tempahan kelas dari telefon saya supaya seseorang dalam senarai menunggu boleh mengambil tempat saya. Kriteria penerimaan:
- Batal ada pada setiap tempahan dalam Tempahan Saya, dengan langkah pengesahan.
- Membatalkan lebih 12 jam sebelum kelas hanya membuang tempahan.
- Kurang 12 jam sebelum, tunjukkan "Yuran pembatalan lewat sebanyak $5 dikenakan" sebelum mengesahkan, dan rekodkan yuran pada tempahan.
- Jika kelas mempunyai senarai menunggu, orang pertama mendapat tempat dan e-mel.
- Berfungsi pada skrin lebar telefon. Di luar skop: bayaran balik, kakitangan membatalkan bagi pihak ahli. Bina ini, kemudian semak setiap kriteria dalam pratonton dan beritahu saya mana yang lulus.
Anda juga boleh meminta AI mendraf story daripada idea kasar, kemudian menyuntingnya sendiri:
Ini idea aplikasi saya: [dua atau tiga ayat]. Tulis user stories untuk versi pertama, dikumpulkan mengikut jenis pengguna, setiap satu dengan 3 hingga 5 kriteria penerimaan Diberi/Apabila/Maka. Tandakan yang mana penting untuk pelancaran dan yang boleh ditangguhkan.
Sentiasa baca dan sunting hasilnya. AI tidak mengenali pengguna anda; andalah yang mengenali mereka.
Kriteria penerimaan juga berfungsi sebagai pelan ujian anda. Apabila story telah dibina, lalui setiap kriteria sendiri. Panduan kami tentang menguji aplikasi anda sebelum pelancaran dibina atas idea ini.
Tempat user stories sesuai dengan dokumen lain
- Dokumen keperluan produk menerangkan keseluruhan produk: masalah, pengguna, skop. User stories ialah bahagian terperinci di dalamnya. Lihat cara menulis PRD dengan AI.
- Laporan bug menerangkan sesuatu yang rosak berbanding story yang sudah dibina. Lihat cara menulis laporan bug yang baik.
- MVP ialah set story terkecil yang memberikan nilai teras. Lihat apa itu MVP.
Kesilapan biasa
- "Sebagai pengguna…" Terlalu kabur. Namakan jenis pengguna yang sebenar.
- Melangkau "supaya". Tanpa sebab, anda tidak boleh membuat pertukaran yang munasabah.
- Menulis penyelesaian dan bukannya keperluan. "Saya mahu dropdown" mengunci reka bentuk sebelum sesiapa memikirkannya.
- Kriteria yang tidak boleh diuji. "Mudah", "pantas" dan "intuitif" ialah harapan, bukan kriteria.
- Story yang sebenarnya epik. "Uruskan akaun saya" ialah sepuluh story.
- Menulis setiap story di hadapan. Tulis beberapa yang seterusnya secara terperinci; simpan yang lain sebagai satu baris sehingga anda sampai kepadanya.
Story dalam Mythex
Dalam Mythex, mod Plan ialah tempat yang baik untuk menukar idea kepada story: ejen membincangkan pendekatan sebelum menyunting apa-apa. Apabila sesuatu story sudah sedia, tukar ke Build dan tampalnya, satu story setiap mesej. Selepas setiap satu, /test boleh mengklik melalui pratonton dan menyemak aliran, dan anda boleh memulihkan mana-mana balasan dengan Revert to this point jika ia berjalan ke arah yang salah. Lihat prompt yang berkesan dalam dokumentasi, dan panduan kami tentang menulis prompt untuk pembina aplikasi AI.
Senarai semak user story
- Menamakan jenis pengguna yang khusus
- Menerangkan keperluan, bukan reka bentuk
- Mengandungi sebab "supaya" yang sebenar
- Mempunyai tiga hingga enam kriteria penerimaan yang boleh diuji
- Meliputi sekurang-kurangnya satu kes tepi atau ralat
- Menyatakan apa yang di luar skop
- Cukup kecil untuk dibina dan diuji sekali jalan
- Kriteria disemak selepas dibina, satu demi satu
Soalan lazim
Apakah format user story?
Templat yang biasa ialah: Sebagai [jenis pengguna], saya mahu [matlamat] supaya [sebab]. Diikuti oleh kriteria penerimaan, senarai ringkas syarat yang mesti benar supaya story itu dikira selesai.
Apakah kriteria penerimaan?
Kriteria penerimaan ialah syarat yang khusus dan boleh diuji yang menentukan bila user story selesai. Ia sering ditulis sebagai Diberi / Apabila / Maka: diberi keadaan permulaan, apabila pengguna melakukan sesuatu, maka hasil tertentu berlaku.
Berapa besar sepatutnya user story?
Cukup kecil untuk dibina dan diuji dalam satu sesi, dan masih bernilai dengan sendirinya. Jika story mempunyai lebih lima atau enam kriteria penerimaan atau meliputi beberapa skrin, pecahkannya mengikut peranan pengguna, mengikut langkah dalam aliran, atau kes mudah dahulu dan kes tepi kemudian.
Adakah user stories berguna apabila membina dengan AI?
Ya. User story dengan kriteria penerimaan hampir kepada prompt yang ideal: ia menyatakan untuk siapa ciri ini, apa yang mereka perlukan, dan tepat bagaimana untuk menyemaknya berfungsi. Menghantar satu story setiap mesej juga memastikan perubahan AI kecil dan mudah diuji.