Di dunia pengembangan perangkat lunak yang dinamis, kejelasan adalah mata uang. Tim yang berkomunikasi secara efektif menghasilkan produk yang lebih baik, lebih cepat. Di inti komunikasi ini terletak cerita pengguna. Ini bukan sekadar tiket di antrian; ini adalah janji akan percakapan, sarana nilai, dan alat untuk keselarasan.
Panduan ini membimbing Anda melalui mekanisme penyusunan cerita pengguna berkualitas tinggi. Kami akan bergerak dari definisi dasar hingga teknik lanjutan seperti pemetaan dan penyempurnaan. Pada akhirnya, Anda akan memiliki kerangka kerja praktis untuk menulis cerita yang dapat dipahami oleh pengembang, dapat divalidasi oleh pengujian, dan dapat diprioritaskan oleh pemangku kepentingan. Mari kita mulai.
Apa Sebenarnya Cerita Pengguna Itu? 🤔
Cerita pengguna adalah deskripsi singkat dan sederhana dari suatu fitur yang diceritakan dari sudut pandang orang yang menginginkan kemampuan baru, biasanya pengguna atau pelanggan sistem. Ini bukan dokumen spesifikasi. Ini adalah tempat penampungan untuk percakapan.
Berbeda dengan dokumen persyaratan tradisional yang bisa kaku dan panjang, cerita pengguna dirancang agar ringan. Mereka fokus pada siapa, apa, dan mengapa.
Format Standar
Kebanyakan tim Agile menggunakan templat standar untuk memastikan konsistensi. Templat ini membantu menjaga fokus pada nilai pengguna daripada rincian implementasi teknis.
- Sebagai: Saya ingin: Supaya:
- Sebagai: [peran pengguna]
- Saya ingin: [aksi atau fitur]
- Supaya: [manfaat atau nilai]
Pertimbangkan skenario di mana seorang pengguna perlu mengatur ulang kata sandinya. Persyaratan yang buruk mungkin mengatakan, ‘Sistem harus memungkinkan pengaturan ulang kata sandi melalui email.’ Cerita pengguna akan berbunyi:
- Sebagaipengguna terdaftar
- Saya inginmengatur ulang kata sandi saya melalui email
- Supayasaya dapat memulihkan akses ke akun saya tanpa harus menghubungi dukungan
Format ini memaksa tim untuk memikirkan nilai dasar di baliknya. Ini mengalihkan percakapan dari ‘bagaimana kita membangun tombol ini’ menjadi ‘mengapa pengguna perlu mengakses tombol ini’.
Model INVEST: Kriteria Cerita Berkualitas 🌟
Tidak semua cerita pengguna dibuat setara. Beberapa kabur, beberapa terlalu besar, dan beberapa secara teknis mustahil diuji. Untuk menyaring item berkualitas rendah, tim sering menggunakan model INVEST. Akronim ini melambangkan Independen, Dapat Dinegosiasikan, Berharga, Dapat Diperkirakan, Kecil, dan Dapat Diuji.
Independen
Cerita harus se-independen mungkin. Jika sebuah cerita bergantung pada cerita lain yang harus selesai sebelum bahkan bisa dibahas, hal ini menciptakan hambatan. Meskipun ketergantungan ada dalam perangkat lunak, mereka harus dikelola secara eksplisit. Idealnya, tim harus mampu mengambil cerita dan menyelesaikannya tanpa perlu tugas hulu tertentu.
Dapat Dinegosiasikan
Deskripsi cerita bukan kontrak. Ini adalah pengingat dari sebuah percakapan. Detail-detailnya harus dinegosiasikan antara tim pengembangan dan pemilik produk. Fleksibilitas ini memungkinkan tim untuk mengusulkan solusi teknis yang mungkin lebih baik daripada permintaan awal.
Berharga
Setiap cerita harus memberikan nilai. Jika sebuah cerita tidak memberikan nilai bagi pengguna atau bisnis, maka cerita tersebut seharusnya tidak ada. Nilai bisa bersifat fungsional, teknis (seperti mengurangi utang), atau terkait kepatuhan. Jika Anda tidak bisa menjelaskan nilai dari cerita tersebut, kemungkinan besar cerita itu tidak perlu.
Dapat Diperkirakan
Tim harus mampu memperkirakan usaha yang dibutuhkan untuk menyelesaikan cerita. Jika cerita terlalu kabur atau bergantung pada teknologi yang tidak diketahui, maka tidak dapat diperkirakan. Dalam kasus seperti ini, cerita perlu dibagi lebih lanjut atau diteliti melalui spike.
Kecil
Cerita harus cukup kecil agar dapat diselesaikan dalam satu sprint. Jika cerita terlalu besar, maka menjadi proyek. Cerita besar sulit diuji, sulit diperkirakan, dan sulit diprioritaskan. Memecahnya menjadi bagian-bagian kecil memungkinkan umpan balik yang lebih cepat.
Dapat Diuji
Cerita harus memiliki kondisi kepuasan yang jelas. Jika Anda tidak bisa menulis kasus uji untuknya, Anda tidak bisa memverifikasi apakah sudah selesai. Ini terkait langsung dengan definisi selesai.
| Kriteria | Pertanyaan yang Harus Ditanyakan | Contoh Masalah |
|---|---|---|
| Independen | Bisakah kita membangun ini tanpa cerita lain? | “Masuk” bergantung pada “Profil Pengguna” |
| Dapat Dinegosiasikan | Apakah kita terbuka untuk mengubah solusi? | “Gunakan API X” alih-alih “Gunakan Fitur Y” |
| Berharga | Apakah ini membantu pengguna? | “Ubah warna font agar sesuai merek” |
| Dapat Diperkirakan | Apakah kita tahu berapa lama ini memakan waktu? | “Terintegrasi dengan pihak ketiga yang tidak diketahui” |
| Kecil | Apakah ini bisa masuk dalam satu sprint? | “Bangun seluruh dasbor” |
| Dapat diuji | Apakah kita bisa menulis tes untuk ini? | “Buat aplikasi lebih cepat” |
Langkah demi Langkah: Menulis Cerita Pengguna 🛠️
Menulis cerita pengguna adalah proses iteratif. Jarang terjadi dalam satu kali duduk. Berikut adalah pendekatan sistematis untuk merancang cerita yang dapat dipertanggungjawabkan.
Langkah 1: Identifikasi Persona Pengguna
Sebelum menulis satu kata pun, identifikasi siapa yang sedang Anda tulis untuknya. Cerita untuk administrator berbeda dari cerita untuk pengguna biasa. Gunakan kartu persona atau profil yang sudah ada untuk memastikan Anda memahami tujuan dan batasan mereka.
Langkah 2: Tentukan Tindakan
Bersikap spesifik tentang apa yang ingin dilakukan pengguna. Hindari kata kerja samar seperti ‘kelola’ atau ‘tangani’. Gunakan kata kerja aksi seperti ‘klik’, ‘simpan’, ‘hapus’, atau ‘ekspor’. Kejelasan ini membantu pengembang memahami interaksi spesifik yang dibutuhkan.
Langkah 3: Jelaskan Nilainya
Ini adalah bagian paling krusial. Mengapa pengguna peduli? Jika Anda melewatkan bagian ‘agar’, Anda berisiko membangun fitur yang tidak digunakan siapa pun. Secara rutin tantang tim untuk menjelaskan manfaatnya.
Langkah 4: Tambahkan Konteks dan Kendala
Kadang-kadang sebuah cerita membutuhkan konteks tambahan. Ini bisa mencakup kendala teknis, persyaratan regulasi, atau kasus-kasus ekstrem. Tempatkan informasi ini di bidang deskripsi atau sebagai komentar yang terlampir pada cerita, bukan di judul.
Langkah 5: Tinjau Berdasarkan INVEST
Sebelum menambahkan cerita ke dalam backlog, lakukan tinjauan menggunakan daftar periksa INVEST. Apakah cocok? Jika tidak, perbaiki. Lebih baik menghabiskan lima menit menyempurnakan cerita sekarang daripada lima jam memperbaiki salah paham saat pengembangan.
Kriteria Penerimaan: Batas Kepatuhan ✅
Kriteria penerimaan menentukan batas-batas sebuah cerita. Mereka adalah kondisi yang harus dipenuhi agar cerita dianggap selesai. Tanpa mereka, ‘selesai’ bersifat subjektif.
Jenis-Jenis Kriteria Penerimaan
Ada beberapa cara untuk menyusun kriteria penerimaan. Pendekatan yang paling efektif sering kali tergantung pada alur kerja tim.
- Berdasarkan Skenario:Menggunakan sintaks Given/When/Then membantu memperjelas alur logika.
- Daftar Periksa:Poin-poin sederhana yang memverifikasi hasil tertentu.
- Aturan:Aturan matematis atau logis yang harus dipenuhi.
- Alur Pengguna:Mendeskripsikan perjalanan yang dilalui pengguna melalui fitur tersebut.
Contoh Kriteria Penerimaan
Mari kita lihat bagaimana kriteria berbeda berdasarkan jenis cerita.
| Fokus Cerita | Contoh Kriteria Penerimaan |
|---|---|
| Fungsionalitas | |
| Keamanan | |
| Kinerja | |
| Kemudahan Penggunaan |
Menulis Kriteria yang Efektif
Saat menulis kriteria ini, pertahankan sifat atomiknya. Jangan menggabungkan beberapa kondisi menjadi satu kalimat. Setiap kriteria harus menjadi satu kondisi yang dapat diuji. Ini membuat lebih mudah bagi tester untuk memvalidasi pekerjaan dan bagi pengembang untuk mengetahui secara tepat apa yang dibutuhkan.
Hindari istilah subjektif seperti ‘cepat’, ‘mudah’, atau ‘modern’. Gantilah dengan istilah yang dapat diukur seperti ‘di bawah 200ms’, ‘kurang dari 3 klik’, atau ‘sesuai dengan WCAG 2.1’.
Pemetaan Cerita Pengguna: Memvisualisasikan Perjalanan 🗺️
Kadang-kadang daftar cerita tidak cukup. Anda perlu melihat gambaran besar. Pemetaan cerita pengguna adalah teknik yang digunakan untuk memvisualisasikan pengalaman pengguna dan mengatur cerita-cerita menjadi rencana rilis yang utuh.
Membuat Tulang Punggung
Mulailah dengan mengidentifikasi aktivitas utama yang dilakukan pengguna. Ini adalah tulang punggung horizontal Anda. Untuk situs e-commerce, ini bisa berupa: Menjelajah, Mencari, Tambah ke Keranjang, Checkout, dan Kelola Akun.
Menambah Langkah
Di bawah setiap aktivitas, daftarkan langkah-langkah spesifik yang diperlukan. Ini adalah cerita pengguna Anda. Susun secara horizontal sesuai urutan pelaksanaannya. Ini menciptakan tulang punggung perjalanan pengguna.
Prioritas untuk Rilis
Setelah peta dibuat, Anda dapat memotongnya secara horizontal. Baris teratas mewakili Produk Minimum yang Layak (MVP). Baris berikutnya menambah nilai lebih. Ini membantu tim memprioritaskan apa yang harus dibangun terlebih dahulu berdasarkan nilai pengguna, bukan kenyamanan teknis.
Manfaat Pemetaan
- Memberikan pandangan menyeluruh terhadap produk.
- Mengidentifikasi celah dalam alur pengguna.
- Memfasilitasi perencanaan dan penjadwalan rilis yang lebih baik.
- Mendorong kolaborasi antara desainer dan pengembang.
Penyempurnaan dan Perkiraan 📏
Menulis cerita hanyalah separuh pertarungan. Tim harus memahami cakupan dan usaha yang terlibat. Ini terjadi selama sesi penyempurnaan.
Mengklarifikasi Ambiguitas
Selama penyempurnaan, tim mengajukan pertanyaan. “Apa yang terjadi jika pengguna tidak memiliki koneksi internet?” “Bagaimana kita menangani email duplikat?” Pertanyaan-pertanyaan ini mengungkap kompleksitas tersembunyi. Jangan menunggu hingga sprint dimulai untuk mengajukan pertanyaan-pertanyaan ini.
Mengukur Ukuran Cerita
Tim sering menggunakan pengukuran relatif daripada jam. Ini mengakui bahwa memperkirakan waktu sulit dan bervariasi dari satu individu ke individu lain. Metode umum meliputi:
- Poker Perencanaan:Anggota tim memberikan suara terhadap ukuran menggunakan kartu.
- Poin Cerita:Nilai numerik yang mewakili kompleksitas, usaha, dan risiko.
- Ukuran Kaos T:Kecil, Sedang, Besar, X-Besar untuk perencanaan tingkat tinggi.
Terlepas dari metode yang digunakan, tujuannya adalah mencapai kesepakatan bersama. Jika tim memiliki perbedaan pendapat yang signifikan, cerita perlu dibagi lebih lanjut atau diteliti lebih dalam.
Rintangan Umum yang Harus Dihindari ⚠️
Bahkan tim yang berpengalaman membuat kesalahan saat menangani cerita pengguna. Kesadaran terhadap rintangan umum ini dapat menghemat waktu dan frustrasi yang signifikan.
1. Menulis Cerita Teknis sebagai Cerita Pengguna
Tugas seperti “Refactor skema basis data” atau “Tingkatkan versi perpustakaan” penting, tetapi bukan cerita pengguna. Mereka adalah tugas teknis. Meskipun harus ada di backlog, mereka harus dikemas sebagai utang teknis atau pekerjaan infrastruktur, bukan sebagai nilai langsung bagi pengguna. Jika harus menulis cerita untuk hal ini, bentuknya sebagai “Sebagai seorang pengembang, saya ingin memperbarui perpustakaan agar kita menghindari kerentanan keamanan.”
2. Mengabaikan “Sehingga”
Melewatkan klausa manfaat menyebabkan penambahan fitur yang berlebihan. Tim membangun hal-hal yang terlihat bagus tetapi tidak menyelesaikan masalah. Selalu paksa tim untuk membenarkan nilai dari hal tersebut.
3. Membebani Deskripsi
Deskripsi cerita tidak boleh menjadi novel. Jika cerita membutuhkan 10 halaman dokumentasi, itu terlalu besar. Pisahkan menjadi bagian-bagian kecil. Deskripsi harus berupa ringkasan, dengan tautan ke spesifikasi rinci jika diperlukan.
4. Menangani Cerita sebagai Kontrak Tetap
Ingat aspek yang dapat dinegosiasikan. Jika tim menemukan cara yang lebih baik untuk menyelesaikan masalah, mereka harus mengusulkannya. Kepatuhan kaku terhadap permintaan awal dapat menghambat inovasi.
5. Mengabaikan Kasus Tepi
Cerita sering berfokus pada jalur yang menyenangkan. Pengujicoba dan pengembang harus secara eksplisit menyebutkan kasus tepi. Apa yang terjadi jika input bernilai null? Bagaimana jika jaringan gagal? Ini harus menjadi bagian dari kriteria penerimaan.
Kolaborasi dan Komunikasi 🗣️
Cerita pengguna adalah alat untuk kolaborasi. Ia menggabungkan pemilik produk, tim pengembangan, dan pengujicoba. Tanpa komunikasi, cerita hanyalah teks di layar.
Tiga Teman
Praktik umum adalah pertemuan “Tiga Teman”. Ini melibatkan Pemilik Produk, Seorang Pengembang, dan Seorang Pengujicoba yang membahas sebuah cerita sebelum memasuki sprint. Mereka meninjau cerita bersama untuk memastikan pemahaman dan cakupan yang memadai.
- Pemilik Produk: Memastikan nilai dan prioritas.
- Pengembang: Memastikan kelayakan teknis dan kompleksitas.
- Penguji:Mengonfirmasi kemampuan pengujian dan kasus tepi.
Umpan Balik Berkelanjutan
Jangan menunggu hingga ulasan sprint untuk mendapatkan umpan balik. Bagikan draf cerita dengan pemangku kepentingan sejak awal. Dapatkan masukan mereka mengenai kata-kata dan proposisi nilai. Ini mengurangi risiko membangun hal yang salah.
Alat Bantu Visual
Teks saja tidak cukup. Gunakan kerangka kabel, mockup, atau diagram untuk melengkapi cerita. Sebuah gambar dapat menjelaskan alur kerja yang kompleks lebih cepat daripada satu paragraf teks. Lampirkan artefak ini langsung ke catatan cerita.
Pikiran Akhir tentang Seni Cerita 🎯
Menguasai seni cerita pengguna membutuhkan latihan. Ini membutuhkan perubahan pola pikir dari menulis persyaratan menjadi memfasilitasi percakapan. Tujuannya bukan membuat dokumen yang sempurna, tetapi menciptakan pemahaman yang jelas.
Mulai kecil. Fokus pada model INVEST. Pastikan setiap cerita memberikan nilai. Bersedia memecahnya lebih jauh jika terasa terlalu besar. Libatkan tim Anda dalam proses penulisan.
Ketika dilakukan dengan baik, cerita pengguna menjadi tulang punggung pengiriman Anda. Mereka menyelaraskan tim, memperjelas visi, dan memastikan setiap baris kode memiliki tujuan. Terus menyempurnakan pendekatan Anda, dan biarkan cerita-cerita tersebut membimbing pekerjaan Anda.