Cara Menulis Cerita Pengguna: Panduan Lengkap

Cerita pengguna adalah bagian penting dari pengembangan perangkat lunak tangkas yang tepat: Mari kita lihat peran mereka dan pelajari cara menulis cerita pengguna.

Kerangka kerja tangkas adalah cara yang populer dan efektif untuk menyusun pengembangan perangkat lunak dan mendelegasikan tugas. Menulis cerita pengguna (jangan disamakan dengan cara menulis testimonial) adalah alat dalam pengembangan tangkas yang memungkinkan pengembang memahami apa yang perlu dilakukan dan bagaimana memenuhi persyaratan. Itu menjadikan mereka tempat awal yang sangat penting – tetapi itu juga berarti mereka harus dibangun dengan hati-hati. Inilah yang harus Anda ketahui.

Apa itu Kisah Pengguna?

Ini adalah istilah yang digunakan dalam pengembangan perangkat lunak dalam kerangka kerja yang gesit. Kisah pengguna biasanya dianggap sebagai unit terkecil dalam proyek tangkas atau langkah pertama dalam memenuhi persyaratan. Mereka dibuat ketika sebuah proyek sepenuhnya direncanakan.

Jadi, apa sebenarnya artinya itu? Setiap fitur perangkat lunak memiliki (atau seharusnya) tujuan tertentu ketika ditambahkan ke proyek. Tujuan itu harus memengaruhi keseluruhan pengembangannya dan bagaimana itu dimasukkan ke dalam keseluruhan kerangka kerja. Pengembang dapat mereferensikan tujuan ini kapan pun diperlukan untuk mengambil keputusan, terutama tentang cara memecah tujuan dan apa yang harus diprioritaskan. "Kisah pengguna" hanyalah cara untuk menjelaskan tujuan fitur.

Cerita pengguna ditulis dari sudut pandang pengguna, biasanya hanya dalam satu atau dua kalimat. Mereka menangkap sudut pandang pengguna dan apa yang ingin dilakukan pengguna itu. Setelah selesai, cerita pengguna yang baik adalah cara mudah untuk membicarakan tujuan strategis, fitur apa yang dapat dibuang dengan aman atau harus ditambahkan, dan banyak lagi.

Cara Menulis Cerita Pengguna

Langkah 1. Dapatkan Masukan

Dapatkan Masukan dari pemilik, calon pengguna, dan manajer proyek. Kisah pengguna yang kuat membutuhkan banyak masukan agar akurat. Dapatkan penjelasan yang jelas dari kelompok-kelompok ini tentang apa yang ingin mereka lakukan. Ingat, ini seharusnya tidak langsung diterjemahkan ke dalam cerita pengguna tetapi akan memberikan informasi yang diperlukan. Seorang pemilik mungkin berkata, "Saya membutuhkan orang untuk dapat membayar dengan PayPal di aplikasi saya," yang sangat berguna tetapi bukan cerita pengguna itu sendiri.

Langkah 2. Putuskan Bagaimana Cerita Pengguna Dibuat

Ini tergantung pada alur kerja Anda. Pada tahap awal, cerita pengguna direkam pada kartu indeks atau post-it saat merencanakan keseluruhan kerangka kerja. Kemudian, mereka dimasukkan ke dalam perangkat lunak manajemen proyek. Beberapa anggota tim melewatkan tahap post-it note, sementara yang lain mengandalkannya – mana saja yang cocok untuk Anda.

Langkah 3. Tentukan, Tentukan, Tentukan

Tentukan pengguna: Dengan input, Anda sekarang dapat menentukan pengguna. Ingatlah bahwa ini tidak selalu merupakan pengguna akhir dari fitur produk; itu dapat bervariasi tergantung pada jenis pengguna. Buat persona pengguna jika perlu. Tentukan tindakan yang dilakukan pengguna, dan tentukan tujuan pengguna dalam mengambil tindakan ini. Sertakan informasi penting ini saat menyusun cerita pengguna Anda untuk berbicara dengan audiens target Anda.

Langkah 4. Tulis Ceritanya

Mulailah menulis cerita pengguna Anda, panjangnya hanya satu atau dua kalimat untuk menarik perhatian pembaca. Sangat menggoda untuk menjadi tepat dan teknis di sini, tetapi bahasa yang luas, seperti pernyataan misi, dapat membantu. Perjelas ceritanya, dan pastikan itu dapat diselesaikan atau diselesaikan, sehingga Anda dapat melihat ke belakang dan mengonfirmasi, "Ya, pengguna sekarang dapat melakukan ini!".

Langkah 5. Bagi Menjadi Langkah Lebih Lanjut

Cerita pengguna mungkin memerlukan beberapa langkah untuk mencapai tujuan akhir, yang mungkin memerlukan sedikit restrukturisasi tergantung pada kerangka kerja tangkas yang Anda gunakan. Ingat, kisah pengguna selalu merupakan unit terkecil dalam kerangka kerja. Pada tingkat terperinci ini, cerita pengguna akan membutuhkan waktu beberapa hari untuk diterapkan.

Jika sepertinya mereka akan memakan waktu lebih lama, itu adalah tanda untuk meninjau kembali dan melihat apakah pengalaman pengguna perlu dipecah lebih lanjut dan direstrukturisasi. Jika persyaratan baru ditambahkan, persyaratan tersebut juga harus dipecah menjadi cerita pengguna. Sementara beberapa kalimat ini adalah inti dari cerita pengguna yang efektif, mereka juga dapat diperluas seiring dengan perkembangan. Mari kita lihat lebih dekat hal itu.

Apa saja 3 C dalam Cerita Pengguna?

Kartu : Fase Kartu mengacu pada penulisan cerita pengguna untuk tim pengembangan dalam satu atau dua kalimat. Disebut kartu karena, cerita pengguna awalnya ditulis di kartu indeks, dan banyak tim masih lebih suka melakukannya dengan cara itu. Kartu adalah inti dari persyaratan perangkat lunak khusus dan titik awal untuk semua diskusi. Juga mudah untuk memeriksa apakah cerita pengguna Anda terlalu panjang – jika tidak muat di kartu indeks yang dapat dibaca semua orang, maka perlu dipersingkat.

Percakapan : Setelah kalimat Kartu dibuat, saatnya untuk menuntaskan detailnya. Ini biasanya dimulai sebagai serangkaian pertanyaan antara pengembang, seperti, "Berapa lama waktu yang dibutuhkan untuk menerapkannya?" atau "Bagaimana kita bisa memasukkan tindakan ini?" atau "Apakah kisah pengguna ini penting di sini?" Dan seterusnya.

Pemeriksaan yang cermat terhadap kisah pengguna ini kemungkinan akan menghasilkan pertanyaan tambahan untuk ditanyakan kepada manajer proyek dan pemilik produk, yang harus dibawa ke dalam percakapan jika diperlukan. Saat Percakapan berlanjut, cerita pengguna dapat diubah, disempurnakan, digabungkan, atau dihapus hingga semua orang memiliki pemahaman yang sama. Saat cerita pengguna diselesaikan, mereka dipindahkan ke implementasi, tanda bahwa Percakapan pada dasarnya sudah berakhir.

Konfirmasi : Konfirmasi adalah tentang tes penerimaan, alias kriteria penerimaan. Setelah perubahan diterapkan, dan pengembang melaporkan bahwa itu sudah siap – bahwa kisah pengguna telah terpenuhi – saatnya untuk mengujinya.

Tes penerimaan harus dibuat dengan masukan dari pemilik produk dan dikaitkan langsung dengan cerita pengguna. Dalam skenario kasus terbaik, ini adalah pengguna yang hanya mencoba melakukan apa yang ditunjukkan oleh cerita pengguna dan melihat apakah mereka bisa. Tetapi tes penerimaan dapat bervariasi dan tidak selalu dibuat dengan mempertimbangkan cerita pengguna sebagaimana mestinya. Jika ini menimbulkan masalah, saatnya untuk kembali ke langkah Percakapan sampai tes penerimaan dan cerita pengguna diselaraskan dengan benar. Jika semua tes penerimaan selesai, kisah pengguna akan senang. Sekarang saatnya beralih ke langkah berikutnya dalam pengembangan produk atau merilis fitur tersebut.

C ke-4? : Menariknya, beberapa orang berpendapat bahwa ada C ke-4 yang penting: Konteks. Dalam hal ini, kisah pengguna dilihat bersama kisah pengguna lain dalam kerangka kerja proyek yang lebih besar. Di sini, pengembang bertanya apakah cerita pengguna melengkapi cerita pengguna lain dengan lancar atau jika ada celah – hal-hal yang perlu dilakukan atau dipahami pengguna yang terlewatkan di antara cerita pengguna.

Idealnya, ini terlihat selama fase Percakapan, tetapi itu tidak selalu terjadi. Beberapa tim pengembangan mungkin menginginkan tinjauan akhir tentang bagaimana kisah pengguna yang sudah selesai cocok dengan keseluruhan yang lebih besar dan jika ada pekerjaan lebih lanjut yang perlu dilakukan.

Apa Format yang Baik untuk Cerita Pengguna?

Mari membahas dua teknik pemformatan yang sangat membantu saat membuat kalimat cerita pengguna. Yang pertama sangat sederhana: “Siapa, Apa, dan Mengapa?” Dalam template kalimat, itu bisa dijelaskan seperti ini:

Sebagai [Siapa pengguna], saya ingin [Apa yang Diinginkan pengguna] (sehingga [Mengapa pengguna menginginkannya]).

Templat ini juga dapat dibingkai sebagai: "Sebagai [peran], saya ingin [bertindak], (sehingga [menguntungkan])," untuk terminologi yang disederhanakan. Mengikuti format dasar ini sudah cukup untuk membuat sebagian besar cerita pengguna. Biasanya hanya itu yang Anda butuhkan dan dapat membantu menghemat banyak waktu saat digunakan untuk setiap cerita pengguna.

Namun, terkadang, cerita pengguna lebih sulit untuk didefinisikan dalam proyek yang lebih kompleks. Dalam hal ini, teknik templat cerita pengguna kedua mungkin berguna. Namanya INVEST, singkatan dari:

• Independen : Cerita harus sepenuhnya independen satu sama lain, dan sebagai hasilnya, cerita harus dapat dikerjakan di luar urutan.
• Dapat dinegosiasikan : Cerita harus dirancang untuk diubah selama bagian Percakapan dari proses tersebut.
• Berharga : Kisah pengguna harus menunjukkan nilai yang jelas untuk proyek tersebut. Jika tidak bisa, itu mungkin membuang-buang sumber daya.
• Dapat diestimasi : Cerita pengguna harus diukur nilainya dan diprioritaskan untuk membantu memutuskan apa yang akan dikerjakan sesuai urutan kepentingannya.
• Kecil : Kisah pengguna harus menjadi unit fungsionalitas terkecil dan jika tidak, harus dipecah lebih lanjut.
• Dapat diuji : Kisah pengguna harus dinyatakan dengan cara yang dapat diuji selama proses Konfirmasi.

FAQ Tentang Cara Menulis Cerita Pengguna

Anda mungkin juga tertarik dengan panduan kami tentang cara menulis ulasan game.