Kisah Pengguna: Cara Menulisnya (Dengan Contoh dan Templat)
Kisah pengguna ialah penerangan ringkas dalam bahasa biasa tentang sesuatu ciri yang diceritakan dari perspektif orang yang akan menggunakannya. Ia adalah tulang belakang kebanyakan Backlog agile dan Scrum, dan apabila ditulis dengan baik, ia memastikan pasukan pembangunan kekal fokus pada hasil pengguna sebenar, bukan keperluan teknikal yang abstrak.
Apakah Kisah Pengguna?
Kisah pengguna ialah penerangan ringkas dan tidak formal tentang ciri perisian dari sudut pandangan pengguna akhir. Ia bukan spesifikasi teknikal. Ia adalah tempat letak untuk perbualan tentang apa yang diperlukan oleh pengguna dan mengapa keperluan itu penting bagi produk.
Istilah ini menjadi meluas digunakan melalui Extreme Programming (XP) pada penghujung tahun 1990-an dan kemudiannya dikodifikasikan oleh Mike Cohn dalam bukunya tahun 2004 User Stories Applied. Hari ini, kisah pengguna adalah amalan standard merentas pasukan agile, dari syarikat permulaan dua orang hingga ke bahagian produk perusahaan.
Kisah pengguna memastikan pasukan jujur. Daripada membina ciri kerana ia kelihatan menarik secara teknikal, pasukan menulis kisah pengguna untuk kekal tertambat kepada orang yang mereka bina untuknya. Kisah itu sendiri adalah singkat mengikut reka bentuk. Nilainya datang dari perbualan yang dicetuskannya antara pemilik produk, pembangun, dan pihak berkepentingan.
Fakta Utama
- Kisah pengguna dipopularkan oleh Kent Beck sebagai sebahagian daripada Extreme Programming (XP) pada penghujung tahun 1990-an, kemudian diformalkan dalam buku Mike Cohn tahun 2004 User Stories Applied.
- Menurut Laporan State of Agile ke-17 (Digital.ai, 2023), 83% pasukan agile menggunakan kisah pengguna sebagai format utama mereka untuk menangkap keperluan.
- Pasukan yang menggunakan kriteria penerimaan yang tersusun baik bersama kisah pengguna melaporkan 40% lebih sedikit kecacatan dalam semakan Sprint, menurut tinjauan pengamal Scrum Alliance 2022.
Templat Kisah Pengguna
Format kisah pengguna klasik mempunyai tiga bahagian. Anda akan menemuinya di mana-mana:
Sebagai [peranan], saya mahu [matlamat], supaya [manfaat].
Setiap bahagian melakukan kerja yang khusus.
| Bahagian | Apa yang ditangkap | Contoh |
|---|---|---|
| Sebagai [peranan] | Siapakah pengguna? Mengenal pasti persona atau jenis pengguna yang khusus. | "Sebagai pembeli pertama kali" |
| Saya mahu [matlamat] | Apakah yang pengguna ingin lakukan? Tindakan atau keupayaan yang mereka perlukan. | "Saya mahu menyimpan item ke dalam senarai keinginan" |
| Supaya [manfaat] | Mengapa mereka mahukan itu? Hasil atau nilai yang mereka cari. | "supaya saya boleh kembali kepada mereka kemudian tanpa perlu mencari semula" |
Digabungkan: "Sebagai pembeli pertama kali, saya mahu menyimpan item ke dalam senarai keinginan, supaya saya boleh kembali kepada mereka kemudian tanpa perlu mencari semula."
Format ini berfungsi kerana ia memaksa pasukan memikirkan tiga perkara sekaligus: siapa, apa, dan mengapa. Hilangkan mana-mana satu daripadanya dan kisah itu menjadi lebih sukar untuk diprioritaskan atau dianggarkan. Kisah tanpa klausa "supaya" hanyalah tugas. Ia tidak memberitahu anda nilai apa yang anda cipta, yang menjadikannya hampir mustahil untuk memutuskan sama ada ia patut dibina semasa Sprint.
Kisah Pengguna berbanding Epik berbanding Tugas
Kisah pengguna berada di tengah hierarki tiga peringkat. Mendapatkan kebutiran yang betul sangat penting apabila anda menjalankan perancangan Sprint.
| Peringkat | Apakah ia | Kebutiran | Siapa yang memilikinya | Contoh |
|---|---|---|---|---|
| Epik | Sekumpulan kerja besar yang boleh dipecahkan kepada berbilang kisah | Luas (minggu hingga bulan) | Product Owner | "Penambahbaikan pengalaman membeli-belah" |
| Kisah Pengguna | Ciri atau keupayaan tunggal dari perspektif pengguna | Sederhana (1 Sprint atau kurang) | Product Owner + Pasukan | "Sebagai pembeli, saya mahu menyimpan item ke dalam senarai keinginan..." |
| Tugas | Tindakan teknikal khusus yang diperlukan untuk menghantar kisah | Sempit (jam) | Pembangun | "Bina titik akhir API senarai keinginan" |
Epik terlalu besar untuk dibina dalam satu Sprint, jadi pasukan memecahkannya kepada kisah pengguna. Kisah ditetapkan saiznya untuk muat dalam Sprint. Tugas adalah kerja teknikal sebenar yang diambil dan dijejaki oleh pembangun pada papan.
Kesilapan biasa ialah menulis kisah dalam skop epik dan kemudian tertanya-tanya mengapa tiada yang siap. Jika kisah mengambil masa lebih dari satu Sprint untuk disiapkan, ia mungkin epik yang menyamar. Pecahkan ia.
3 C Kisah Pengguna
Ron Jeffries memperkenalkan kerangka 3 C untuk menerangkan cara kisah pengguna sebenarnya berfungsi dalam praktik. Kad hanyalah titik permulaan.
Kad. Kisah pengguna secara tradisinya ditulis pada kad indeks fizikal (atau yang setara secara digital). Kad itu ringkas mengikut reka bentuk: satu atau dua ayat. Ia bukan spesifikasi penuh. Ia adalah peringatan bahawa perbualan perlu berlaku.
Perbualan. Kad mencetuskan perbincangan antara pemilik produk, pembangun, dan sering pihak berkepentingan. Perbualan ini adalah tempat keperluan sebenar diselesaikan. Kad tidak mengandungi semua jawapan. Orang itu yang mengandunginya.
Pengesahan. Setelah perbualan berlaku, pasukan mendokumentasikan kriteria penerimaan: syarat khusus yang mesti dipenuhi untuk kisah dianggap selesai. Kriteria ini ialah yang diuji dan disahkan sebelum kisah ditutup.
Kebanyakan pasukan menulis kad dan terus ke pengekodan. Itu terbalik. Langkah perbualan adalah tempat kekaburan diselesaikan, kes tepi ditemui, dan pemahaman bersama dibina. Kisah yang melangkau perbualan cenderung kembali untuk kerja semula.
Kriteria INVEST untuk Kisah Pengguna yang Baik
Bill Wake memperkenalkan akronim INVEST untuk memberikan pasukan senarai semak kualiti bagi menilai sama ada kisah pengguna tersusun dengan baik. Jalankan mana-mana kisah melalui senarai ini sebelum memasukkannya ke dalam Sprint.
| Huruf | Kriteria | Maksudnya |
|---|---|---|
| I | Bebas (Independent) | Kisah boleh dibina dan dihantar tanpa bergantung pada kisah lain yang siap dahulu. |
| N | Boleh dirunding (Negotiable) | Kisah bukan kontrak yang tegar. Butiran boleh disesuaikan berdasarkan perbualan dan maklumat baharu. |
| V | Bernilai (Valuable) | Kisah memberikan nilai yang jelas kepada pengguna atau perniagaan. Jika anda tidak boleh menjelaskan nilainya, kisah belum bersedia. |
| E | Boleh dianggarkan (Estimable) | Pasukan mempunyai maklumat yang mencukupi untuk menganggarkan usaha yang diperlukan. Jika mereka tidak boleh menganggarkan, sesuatu tidak jelas. |
| S | Kecil (Small) | Kisah muat dalam satu Sprint. Jika tidak, pecahkan kepada kisah yang lebih kecil. |
| T | Boleh diuji (Testable) | Kisah mempunyai kriteria penerimaan yang boleh disahkan. Jika anda tidak boleh mengujinya, anda tidak boleh mengesahkan ia selesai. |
Jalankan semakan INVEST pantas semasa penghalusan Backlog. Jika kisah gagal mana-mana kriteria, jangan tariknya ke dalam perancangan dahulu. Betulkan terlebih dahulu. Kegagalan paling biasa ialah "Tidak cukup kecil" (sepatutnya epik) dan "Tidak boleh diuji" (tiada kriteria penerimaan yang ditulis lagi).
Cara Menulis Kisah Pengguna
Menulis kisah pengguna yang baik memerlukan lebih daripada mengisi templat. Berikut adalah proses yang berfungsi secara boleh dipercayai.
Langkah 1: Kenal pasti persona pengguna anda
Siapa yang sebenarnya akan menggunakan ciri ini? Jadilah spesifik. "Pengguna" bukan persona. "Pengguna baharu yang belum menetapkan pembayaran" adalah persona. Semakin konkrit persona, semakin mudah untuk menulis kisah yang benar-benar mencerminkan keperluan mereka.
Jika anda belum mempunyai persona formal, perbualan ringkas dengan pasukan sokongan pelanggan anda akan mendedahkan jenis pengguna yang paling biasa dalam masa kira-kira 20 minit.
Langkah 2: Namakan matlamat
Apakah yang pengguna cuba capai? Tuliskannya sebagai tindakan: "tapis hasil carian mengikut harga," "eksport data sebagai fail CSV," "terima e-mel pengesahan selepas pembayaran." Hadkan kepada satu matlamat setiap kisah. Jika anda dapati diri menulis "dan" dalam matlamat, anda mungkin mempunyai dua kisah.
Langkah 3: Nyatakan manfaat
Mengapa pengguna mahukan ini? Apakah hasil yang mereka cari? Ini adalah klausa "supaya." Ia juga bahagian yang paling kerap dilangkau. Jangan langkau. Manfaat memberitahu pasukan bagaimana rupa kejayaan, yang penting apabila pertukaran timbul semasa pembangunan.
Langkah 4: Tambah kriteria penerimaan
Tulis syarat yang mesti dipenuhi oleh ciri tersebut untuk dianggap selesai. Gunakan bahasa biasa atau format Given/When/Then (lebih lanjut di bawah). Kriteria penerimaan bukan pilihan. Tanpanya, setiap pembangun dalam pasukan mempunyai model mental yang sedikit berbeza tentang maksud "selesai."
Langkah 5: Anggarkan kisah
Bekerjasama dengan pasukan untuk menetapkan saiz kisah menggunakan Story Point atau kaedah anggaran relatif yang serupa. Jika anggaran adalah tinggi (biasanya di atas 8 atau 13 pada skala Fibonacci), kisah mungkin terlalu besar. Pecahkan kepada bahagian yang lebih kecil sebelum perancangan Sprint.
Langkah 6: Prioritaskan dan haluskan
Tambah kisah ke dalam Backlog produk dan susun mengikut nilai. Semasa sesi penghalusan Backlog, semak semula kisah yang akan datang dalam Sprint berikutnya untuk memastikan ia masih relevan, ditetapkan saiz dengan betul, dan mempunyai kriteria penerimaan yang jelas. Kisah yang tidak dihaluskan baru-baru ini sering memerlukan kemaskini sebelum bersedia untuk Sprint.
Contoh Kisah Pengguna
Berikut adalah contoh konkrit merentasi tiga jenis produk biasa. Setiap satu mengikut templat standard dan termasuk nota penerimaan ringkas.
| Jenis produk | Kisah pengguna | Nota penerimaan |
|---|---|---|
| E-dagang | "Sebagai pelanggan tetap, saya mahu membuat semula pesanan terdahulu dalam satu klik, supaya saya tidak perlu mencari setiap item semula secara manual." | Troli telah diisi terlebih dahulu dengan item pesanan terdahulu pada harga semasa; pengguna mengesahkan sebelum pembayaran. |
| SaaS (B2B) | "Sebagai pengurus pasukan, saya mahu mengeksport laporan aktiviti pasukan saya sebagai CSV, supaya saya boleh berkongsinya dengan pengarah saya dalam format yang boleh mereka gunakan." | Eksport merangkumi penapis julat tarikh, semua lajur yang kelihatan dalam aplikasi, dan dimuat turun dalam masa 5 saat untuk sehingga 1,000 baris. |
| Alat dalaman | "Sebagai ejen sokongan, saya mahu melihat sejarah tiket penuh pelanggan dalam satu paparan, supaya saya tidak perlu bertukar antara sistem semasa panggilan." | Sejarah menunjukkan 12 bulan terakhir, diisih mengikut tarikh secara menurun, dengan status tiket dan nota penyelesaian kelihatan. |
| Aplikasi mudah alih | "Sebagai pengguna baharu, saya mahu menyelesaikan onboarding dalam masa 3 minit, supaya saya boleh mula menggunakan aplikasi sebelum hilang minat." | Aliran onboarding adalah maksimum 5 skrin, boleh dilangkau pada setiap langkah, dan tidak memerlukan kad kredit. |
| Platform analitik | "Sebagai penganalisis pemasaran, saya mahu menapis metrik dashboard mengikut kempen, supaya saya boleh membandingkan prestasi tanpa menukar paparan." | Penapis digunakan serta-merta (bawah 1 saat), menyokong pemilihan berbilang kempen, dan kekal merentasi sesi. |
Perhatikan bahawa setiap kisah menamakan jenis pengguna yang khusus, bukan "pengguna" yang generik. Dan setiap klausa manfaat menjelaskan motivasi sebenar, bukan sekadar ulangan matlamat.
Kriteria Penerimaan dan Definition of Done
Kriteria penerimaan ialah syarat khusus yang mesti dipenuhi oleh ciri tersebut agar pasukan menganggap kisah pengguna selesai. Ia ditulis sebelum pembangunan bermula, biasanya semasa langkah perbualan.
Format yang paling biasa ialah Given/When/Then (juga dipanggil sintaks Gherkin):
- Given (Diberi) beberapa konteks awal atau prasyarat
- When (Apabila) pengguna mengambil tindakan tertentu
- Then (Maka) hasil tertentu berlaku
Contoh untuk kisah senarai keinginan:
Given pembeli yang telah log masuk sedang melihat halaman produk When mereka mengklik butang "Simpan ke Senarai Keinginan" Then item ditambah ke senarai keinginan mereka dan gesaan pengesahan muncul; butang berubah kepada "Telah Disimpan"
Definition of Done (DoD) berbeza daripada kriteria penerimaan. Kriteria penerimaan adalah khusus untuk satu kisah. DoD ialah standard seluruh pasukan yang terpakai untuk setiap kisah: ujian unit ditulis, kod disemak, digunakan ke pelantar ujian, tiada pepijat kritikal. Kedua-duanya mesti dipenuhi sebelum kisah ditutup.
Jangan keliru antara keduanya. Sebuah kisah boleh memenuhi semua kriteria penerimaannya tetapi masih tidak memenuhi DoD jika, katakan, tiada semakan kod berlaku. Jejaki kedua-duanya.
Kesilapan Biasa Semasa Menulis Kisah Pengguna
Menulis dari perspektif sistem, bukan perspektif pengguna. "Sistem hendaklah menghantar e-mel" adalah keperluan teknikal, bukan kisah pengguna. Tulis semula: "Sebagai pengguna baharu, saya mahu menerima e-mel alu-aluan selepas mendaftar, supaya saya tahu akaun saya berjaya dicipta."
Melangkau klausa manfaat. "Sebagai pengguna, saya mahu menapis hasil" memberitahu pasukan hampir tiada apa tentang keutamaan atau nilai. Mengapa pengguna mahu menapis? Keputusan apa yang akan mereka buat dengan hasil yang ditapis? Klausa "supaya" adalah tempat maklumat sebenar berada.
Menulis epik dan menamakannya kisah. "Sebagai pengguna, saya mahu pengalaman pembayaran yang lengkap" bukan kisah. Ia adalah kawasan ciri. Pecahkan kepada bahagian yang khusus dan boleh dianggarkan: pemilihan kaedah pembayaran, pengesahan pesanan, e-mel resit, dan lain-lain.
Tiada kriteria penerimaan sebelum pembangunan bermula. Kisah tanpa kriteria penerimaan adalah jemputan terbuka untuk kerja semula. Pembangun mentafsir kekaburan dengan cara yang paling mudah dibina, bukan semestinya apa yang dimaksudkan oleh pemilik produk. Tulis kriteria sebelum Sprint bermula.
Terlalu banyak kisah untuk satu Sprint. Pasukan agile kadangkala memuat Backlog dengan lebih banyak kisah daripada yang dapat diselesaikan oleh pasukan secara realistik. Ini membawa kepada kerja yang separuh selesai dan "carta burndown" yang penuh yang tidak pernah mencapai sifar. Gunakan Story Point dan Velocity sejarah untuk menetapkan kapasiti Sprint yang realistik.
Mengabaikan langkah keutamaan MoSCoW. Tidak semua kisah pengguna adalah sama. Sesetengah adalah mesti ada, yang lain adalah bagus untuk ada. Tanpa keutamaan yang eksplisit, pasukan menghabiskan masa Sprint pada kisah bernilai rendah sementara kerja bernilai tinggi menunggu.
Soalan Lazim
Apakah kisah pengguna dalam agile?
Kisah pengguna ialah penerangan ringkas dalam bahasa biasa tentang ciri dari perspektif pengguna, ditulis dalam format "Sebagai [peranan], saya mahu [matlamat], supaya [manfaat]." Ia digunakan dalam pasukan agile untuk menangkap keperluan dengan cara yang mengekalkan tumpuan pada nilai pengguna, bukan spesifikasi teknikal. Kisah pengguna biasanya disimpan dalam Backlog produk dan ditarik ke dalam Sprint berdasarkan keutamaan.
Apakah perbezaan antara kisah pengguna dan epik?
Epik ialah sekumpulan kerja besar yang terlalu besar untuk dihantar dalam satu Sprint. Kisah pengguna ialah hirisan kerja yang lebih kecil dan boleh dihantar. Epik dipecahkan kepada kisah pengguna. Contohnya, "Pengalaman pembayaran" adalah epik. "Sebagai pembeli, saya mahu menyimpan butiran pembayaran saya untuk pembelian masa hadapan" adalah satu kisah pengguna di dalamnya.
Siapa yang menulis kisah pengguna?
Product Owner biasanya menulis atau memiliki kisah pengguna, tetapi kisah pengguna terbaik datang dari kerjasama. Product Owner membawa perspektif perniagaan dan pengguna. Pembangun membawa konteks teknikal. Pereka UX membawa penyelidikan pengguna. Sesi penghalusan Backlog adalah tempat perspektif-perspektif ini bergabung untuk menghasilkan kisah yang tersusun baik dan boleh dianggarkan.
Apakah Story Point?
Story Point ialah unit anggaran relatif yang digunakan oleh pasukan untuk menetapkan saiz kisah pengguna. Daripada menganggarkan dalam jam (yang berbeza mengikut orang dan sering tidak tepat), pasukan membandingkan kisah antara satu sama lain menggunakan skala seperti Fibonacci (1, 2, 3, 5, 8, 13). Kisah bernilai 5 mata adalah kira-kira dua kali lebih kompleks daripada kisah 2 mata. Dari masa ke masa, pasukan membangunkan Velocity yang stabil (mata setiap Sprint), yang menjadikan perancangan Sprint lebih boleh diramalkan.
Apakah maksud INVEST dalam kisah pengguna?
INVEST ialah senarai semak kualiti untuk kisah pengguna: Bebas/Independent (boleh dibina tanpa bergantung pada kisah lain), Boleh dirunding/Negotiable (butiran boleh berubah berdasarkan perbualan), Bernilai/Valuable (memberikan nilai yang jelas kepada pengguna), Boleh dianggarkan/Estimable (pasukan boleh menetapkan saiznya), Kecil/Small (muat dalam satu Sprint), dan Boleh diuji/Testable (mempunyai kriteria penerimaan yang boleh disahkan). Jika kisah gagal mana-mana daripada ini, ia belum bersedia untuk Sprint.
Kisah pengguna yang baik tidak menulis dirinya sendiri. Tetapi pasukan yang meluangkan masa untuk menyempurnakannya dengan betul, menamakan persona pengguna sebenar, menulis klausa manfaat yang jelas, dan melampirkan kriteria penerimaan yang boleh diuji sebelum pembangunan bermula, menghabiskan lebih sedikit masa dalam kerja semula dan lebih banyak masa menghantar perkara yang penting.
Mulakan dengan satu kisah untuk item Backlog berprioriti tertinggi semasa. Gunakan templat, jalankan semakan INVEST, dan tulis dua atau tiga kriteria penerimaan. Itulah tabiatnya. Bina dari sana.
Untuk kerangka berkaitan, lihat struktur pecahan kerja untuk menguraikan skop projek, perancangan Sprint untuk menarik kisah ke dalam Sprint, dan Scrum berbanding Kanban jika anda memutuskan aliran kerja mana yang paling sesuai untuk pasukan anda.
Senior Operations & Growth Strategist
On this page
- Apakah Kisah Pengguna?
- Templat Kisah Pengguna
- Kisah Pengguna berbanding Epik berbanding Tugas
- 3 C Kisah Pengguna
- Kriteria INVEST untuk Kisah Pengguna yang Baik
- Cara Menulis Kisah Pengguna
- Langkah 1: Kenal pasti persona pengguna anda
- Langkah 2: Namakan matlamat
- Langkah 3: Nyatakan manfaat
- Langkah 4: Tambah kriteria penerimaan
- Langkah 5: Anggarkan kisah
- Langkah 6: Prioritaskan dan haluskan
- Contoh Kisah Pengguna
- Kriteria Penerimaan dan Definition of Done
- Kesilapan Biasa Semasa Menulis Kisah Pengguna
- Soalan Lazim
- Apakah kisah pengguna dalam agile?
- Apakah perbezaan antara kisah pengguna dan epik?
- Siapa yang menulis kisah pengguna?
- Apakah Story Point?
- Apakah maksud INVEST dalam kisah pengguna?