User story ialah sebahagian kecil kerja yang diterangkan dari sudut pandangan orang yang mendapat manfaat daripadanya. Panduan ini memecahkan templat "Sebagai…, saya mahu…, supaya…", menerangkan senarai semak INVEST untuk cerita yang baik, dan menunjukkan cara memecahkan idea besar kepada cerita yang boleh disiapkan oleh pasukan. Kira-kira 12 minit untuk dibaca.
User story menerangkan keperluan dalam perkataan seharian, dari sisi skrin pengguna. Ia sengaja tidak menyatakan bagaimana untuk membinanya. Itu diputuskan bersama oleh mereka yang akan membinanya, melalui perbincangan dengan mereka yang memerlukannya.
Cara terkenal untuk mengingatinya ialah tiga C oleh Ron Jeffries:
Adakah saya mesti menggunakan user story? Tidak. Panduan Scrum hanya meminta Product Backlog dengan item yang jelas. User story ialah cara popular untuk menulis item itu kerana ia mengekalkan fokus pada manusia dan nilai. Pembaikan pepijat atau naik taraf boleh kekal sebagai tugasan biasa.
Kebanyakan pasukan menggunakan satu ayat mudah. Setiap bahagian ada tugas berbeza, dan cerita hanya sekuat bahagian yang paling lemah.
Orang yang mendapat manfaat. Cukup spesifik sehingga anda boleh pergi dan bercakap dengan mereka.
Apa yang mereka mahu boleh lakukan, dalam perkataan mereka, bukan perkataan pasukan.
Manfaatnya. Ia memberitahu pasukan rupa kejayaan dan membantu Product Owner memutuskan apa yang didahulukan.
| Bahagian | ❌ Lemah | ✅ Lebih baik |
|---|---|---|
| Siapa | Sebagai pengguna… | Sebagai ibu bapa yang membayar yuran sekolah… |
| Apa | …saya mahu senarai juntai kad tersimpan di halaman pembayaran… | …saya mahu membayar dengan kad yang pernah saya guna… |
| Mengapa | …supaya saya boleh membayar. | …supaya bayaran setiap penggal hanya ambil beberapa saat, bukan mencari dompet. |
Bill Wake mencadangkan INVEST pada 2003 sebagai ujian pantas sama ada cerita sedia untuk dikerjakan. Semak setiap cerita dengan enam huruf ini sebelum ia masuk ke Sprint.
Cerita yang bergantung antara satu sama lain mesti dibuat mengikut susunan tetap, yang menjadikan perancangan kaku.
Gagal: "Cerita B hanya berfungsi selepas cerita A siap."
Baiki: gabungkan, atau pecahkan dengan cara lain supaya setiap satu menghasilkan sesuatu yang boleh digunakan.
Cerita ialah titik permulaan perbualan, bukan kontrak dengan setiap butiran ditetapkan.
Gagal: cerita sudah menetapkan susun atur skrin dan jadual pangkalan data.
Baiki: kekalkan keperluan, buang reka bentuk. Putuskan butiran bersama.
Setiap cerita patut menghasilkan sesuatu yang akan disedari dan dipedulikan oleh orang di luar pasukan.
Gagal: "Sebagai pembangun, saya mahu mencipta jadual pangkalan data."
Baiki: potong secara menegak supaya setiap cerita merangkumi bahagian pangkalan data, logik dan skrin yang diperlukannya.
Jika tiada sesiapa dapat meneka saiznya, ada perkara penting yang masih belum diketahui.
Gagal: "Integrasi dengan penyedia pembayaran baharu", sedangkan tiada siapa pernah melihat API mereka.
Baiki: jalankan spike yang pendek dan bertempoh untuk belajar dahulu, kemudian tulis cerita.
Cerita kecil mengalir melalui papan dengan pantas dan memberi maklum balas awal. Sasarkan beberapa yang siap setiap Sprint.
Gagal: "Sebagai pesakit, saya mahu mengurus temu janji saya."
Baiki: pecahkannya. Lihat Bahagian 5.
Jika anda tidak dapat menyatakan cara mengujinya, anda tidak dapat menyatakan bila ia siap.
Gagal: "…supaya aplikasi terasa lebih pantas."
Baiki: tambah kriteria penerimaan: "hasil muncul dalam 2 saat bagi 95% carian."
| Semakan | Keputusan |
|---|---|
| I Berdikari | ✅ Menggunakan data temu janji sedia ada. Tidak perlukan cerita lain dahulu. |
| N Boleh dirunding | ✅ Tidak menyatakan rupa senarai. Penapis pada jadual sedia ada mungkin sudah memadai. |
| V Bernilai | ✅ Slot kosong diisi, jadi lebih ramai pesakit dirawat dan kurang pendapatan hilang. |
| E Boleh dianggar | ✅ Pasukan mengenali data temu janji dengan baik. |
| S Kecil | ✅ Kerja beberapa hari. Menghubungi pesakit yang menunggu ialah cerita berasingan. |
| T Boleh diuji | ✅ Ya, dengan kriteria penerimaan dalam Bahagian 4. |
Kriteria penerimaan ialah syarat yang mesti dipenuhi cerita untuk diterima. Ia dipersetujui dalam perbualan, ditulis pada cerita, dan disemak sebelum ia dikira selesai. Format popular ialah Given / When / Then: situasi permulaan, tindakan, dan hasil yang dijangka.
Idea besar biasanya bermula terlalu besar untuk disiapkan dalam satu Sprint. Cerita sebesar itu sering dipanggil epik. Matlamatnya ialah memotongnya kepada cerita kecil yang setiap satu masih menghasilkan sesuatu yang nyata: hirisan nipis menembusi seluruh kek, bukan lapisan berasingan. Artikel menghiris dan mensaiz menerangkan tekniknya dengan lebih mendalam.
Matlamat yang baik, tetapi terlalu besar: ia merangkumi memilih doktor, mencari masa, mengesahkan, membayar, peringatan, membatalkan dan menukar jadual. Inilah pecahannya:
| Pecah mengikut… | Cara ia berfungsi | Daripada epik tempahan |
|---|---|---|
| Langkah aliran kerja | Satu cerita bagi setiap langkah perjalanan pengguna. | Lihat slot → tempah → terima pengesahan |
| Kes mudah dahulu | Bina versi paling mudah, kemudian tambah variasi. | Seorang GP minggu ini dahulu, kemudian mana-mana doktor, klinik dan tarikh |
| Laluan lancar, kemudian pengecualian | Pastikan ia berfungsi apabila semua berjalan baik, kemudian tangani masalah. | Tempah slot kosong dahulu. "Slot diambil semasa anda menempah" kemudian. |
| Operasi | Cipta, ubah dan buang selalunya cerita berasingan. | Tempah, batal dan tukar jadual |
| Peranan pengguna | Orang berbeza mungkin perlukan versi berbeza. | Pesakit menempah untuk diri sendiri, kemudian ibu bapa menempah untuk anak |
| Peraturan perniagaan | Setiap peraturan boleh menjadi cerita sendiri. | "Batal sehingga 24 jam sebelum" dan "tidak lebih 2 tempahan seminggu" |
| Kualiti kemudian | Pastikan ia berfungsi, kemudian jadikan pantas atau kemas. | Senarai slot asas dahulu, kemudian "hasil dalam masa kurang 2 saat" |
Jangan pecahkan mengikut lapisan. "Cerita 1: pangkalan data. Cerita 2: bahagian belakang. Cerita 3: skrin." Tiada satu pun memberi apa-apa kepada pesakit sehingga ketiga-tiganya siap, jadi ia gagal huruf V dalam INVEST. Setiap cerita patut menembusi setiap lapisan yang diperlukannya.
| # | User story |
|---|---|
| 1 | Sebagai pesakit, saya mahu melihat slot kosong GP biasa saya minggu ini, supaya saya boleh pilih masa yang sesuai tanpa menelefon. |
| 2 | Sebagai pesakit, saya mahu menempah slot kosong dan menerima e-mel pengesahan, supaya saya tahu temu janji saya sudah terjamin. |
| 3 | Sebagai pesakit, saya mahu membatalkan tempahan sehingga 24 jam sebelum, supaya saya tidak dicaj untuk lawatan yang tidak dapat saya hadiri. |
| 4 | Sebagai pesakit, saya mahu memindahkan tempahan ke slot kosong lain, supaya saya tidak perlu membatalkan dan mula semula. |
| 5 | Sebagai pesakit, saya mahu menerima peringatan SMS sehari sebelum, supaya saya tidak lupa temu janji. |
| 6 | Sebagai pesakit, saya mahu memilih mana-mana doktor di mana-mana klinik kumpulan, supaya saya boleh dirawat lebih cepat apabila GP saya penuh. |
Cerita 2 menggabungkan tempahan dan pengesahan dengan sengaja. Tempahan tanpa pengesahan membuatkan pesakit tidak pasti ia berjaya, jadi ia tidak bernilai jika berdiri sendiri.
Cerita yang baik daripada pelbagai jenis produk, masing-masing dengan kriteria penerimaan utama. Perhatikan bagaimana setiap satu menamakan orang sebenar, menerangkan matlamat tanpa reka bentuk, dan memberi sebab yang penting.
| ❌ Cerita lemah | Apa yang salah | ✅ Lebih baik |
|---|---|---|
| "Sebagai pengguna, saya mahu papan pemuka." | Siapa kabur, apa tidak jelas, tiada mengapa. | Sebagai pengurus jualan, saya mahu melihat urusan minggu ini yang berisiko, supaya saya boleh campur tangan sebelum ia terlepas. |
| "Sebagai pembangun, saya mahu menyediakan pangkalan data." | Tugasan teknikal tanpa nilai kepada pengguna. | Jadikannya sebahagian daripada cerita pertama yang memerlukannya. Jika ia benar-benar berdiri sendiri, simpan sebagai tugasan biasa, bukan cerita. |
| "Sebagai pelanggan, saya mahu butang Hantar biru di bawah kanan." | Keputusan reka bentuk, bukan keperluan. Tidak boleh dirunding. | Sebagai pelanggan, saya mahu menghantar borang tanpa menatal ke atas semula, supaya saya tidak terlepas langkah terakhir. |
| "Sebagai pentadbir, saya mahu menambah, menyunting, memadam dan mengeksport pengguna." | Empat cerita dalam satu. Tidak kecil. | Pecahkan kepada empat: tambah, sunting, buang dan eksport, setiap satu dengan mengapa sendiri. |
| "Sebagai pembeli, saya mahu pembayaran yang lebih pantas." | Tidak boleh diuji: sepantas mana itu pantas? | Cerita yang sama, ditambah kriteria "pembayaran selesai dalam 3 langkah atau kurang, bawah 60 saat untuk pelanggan tetap". |
| "Halaman pembayaran" | Sekadar label, bukan cerita. Tiada siapa, apa atau mengapa. | Tulis keperluan di sebaliknya, contohnya cerita yuran sekolah dalam Bahagian 2. |