Apa itu Cerita Pengguna?

Apa itu Cerita Pengguna?

Cerita pengguna adalah catatan yang mencatat apa yang dilakukan oleh seorang penggunamelakukan atau perlu dilakukan sebagai bagian dari pekerjaannya. Setiap cerita pengguna terdiri dari deskripsi singkat yang ditulis dari sudut pandang pengguna, menggunakan bahasa alami. Berbeda dengan pengumpulan kebutuhan tradisional, cerita pengguna berfokus pada kebutuhan pengguna daripada pada apa yang sistem harus hasilkan. Ini memberi ruang untuk diskusi lebih lanjut mengenai solusi dan hasil sistem yang benar-benar sesuai dengan alur kerja bisnis pelanggan, menyelesaikan masalah operasional mereka, dan yang paling penting menambah nilai bagi organisasi.

Konsep 3C

3C mengacu pada tiga aspek kritis dari cerita pengguna yang baik. Konsep ini diajukan oleh Ron Jeffries, co-pencipta praktik cerita pengguna. Saat ini, ketika kita berbicara tentang cerita pengguna, kita biasanya merujuk pada jenis cerita pengguna yang terdiri dari tiga aspek ini.

1. Kartu – Cerita pengguna ditulis sebagai kartu. Setiap kartu cerita pengguna memiliki kalimat singkat dengan teks yang cukup untuk mengingatkan semua orang tentang isi cerita tersebut.
2. Percakapan – Kebutuhan ditemukan dan disempurnakan melalui percakapan terus-menerus antara pelanggan dan tim pengembangan sepanjang proyek perangkat lunak. Ide-ide penting dan keputusan akan ditemukan dan dicatat selama pertemuan pemangku kepentingan.
   
3. Konfirmasi – atau juga dikenal sebagai kriteria penerimaan dari cerita pengguna. Selama diskusi kebutuhan, pelanggan memberi tahu analis tidak hanya apa yang diinginkan, tetapi juga memastikan kondisi dan kriteria di mana perangkat lunak yang berfungsi akan diterima atau ditolak. Kasus-kasus yang ditentukan ditulis sebagai konfirmasi. Catatan bahwa konfirmasi berfokus pada memverifikasi kebenaran pekerjaan dari cerita pengguna yang sesuai. Ini bukan pengujian integrasi.
   

Bagaimana cara mengidentifikasi cerita pengguna?

Cerita pengguna harus diidentifikasi bersama pemangku kepentingan, lebih baik melalui pertemuan tatap muka. Cerita pengguna adalah proses penemuan kebutuhan, bukan proses analisis kebutuhan di awal. Dalam pendekatan pengumpulan kebutuhan tradisional, analis sistem berusaha memahami kebutuhan pelanggan, lalu menyusun spesifikasi kebutuhan untuk sistem secara rinci. Ini bukan cara kerja pendekatan cerita pengguna. Alih-alih proses dokumentasi, identifikasi cerita pengguna lebih seperti proses pencatatan catatan. Melalui diskusi dengan pengguna, kita mendengarkan dan memahami masalah dan kebutuhan mereka, lalu menuliskan kebutuhan tersebut sebagai cerita pengguna secara bersamaan. Cerita-cerita pengguna ini akan menjadi sumber kebutuhan. Detailnya dapat diisi secara bertahap sesuai kebutuhan, memberikan tim referensi kebutuhan yang cukup selama proses pengembangan proyek.

Pemetaan Proses Bisnis dengan Cerita Pengguna

BPMN adalah salah satu alat paling kuat untuk analisis dan pemodelan bisnis. Tidak hanya kita bisa menggunakannya untuk melakukan perbaikan proses, tetapi juga kita dapat mengidentifikasi cerita pengguna dari proses-proses yang dimaksudkan untuk diotomasi melalui langkah-langkah berikut:

1. Secara sederhana model alur kerja pengguna menggunakan diagram proses bisnis BPMN.
2. Jalani model proses bersama pengguna.
3. Dan, analisis aktivitas bisnis dari masalah tersebut, lalu identifikasi cerita pengguna yang terkait dengan proses yang perlu diotomasi, yang juga dikenal sebagai pemetaan proses bisnis ke cerita pengguna.

Bagaimana cara menulis cerita pengguna?

Ketika menulis cerita pengguna, coba tulis dengan suara pengguna seperti bentuk di bawah ini (atau setidaknya, pastikan apa yang Anda tulis memenuhi pernyataan berikut):

Sebagai <peran>, saya ingin <tujuan bisnis> agar <nilai bisnis/alasan>.

Contoh: Sebagai pelanggan, saya ingin menerima SMS ketika barang tiba agar saya bisa pergi ambil itu.

di mana:

1. <peran> mewakili orang, sistem, subsistem atau entitas lain yang akan berinteraksi dengan sistem yang akan diimplementasikan untuk mencapai tujuan. Dia atau dia akan mendapatkan nilai dengan berinteraksi dengan sistem.
2. <tujuan bisnis> mewakili harapan pengguna yang dapat tercapai melalui interaksi dengan sistem.
3. <nilai bisnis> mewakili nilai di balik interaksi dengan sistem.

Ini bukan aturan tetapi pedoman yang membantu Anda memikirkan cerita pengguna dengan mempertimbangkan hal-hal berikut:

1. Cerita pengguna akan membawa nilai bagi seseorang atau pihak tertentu (misalnya pelanggan).
2. Cerita pengguna memenuhi kebutuhan pengguna (misalnya menerima SMS saat barang tiba)
3. Ada alasan untuk mendukung implementasi cerita pengguna ini (misalnya pelanggan dapat mengambil barang yang dibelinya)

Setiap cerita pengguna harus membawa nilai bagi seseorang. Namun terkadang nilai tersebut cukup jelas hanya dengan membaca tujuan bisnis. Menuliskan nilai sebagai bagian dari pernyataan terasa merepotkan. Dalam kasus seperti ini, kita akan melewatkannya saja. Berikut beberapa contohnya:

Sebagai pelanggan, saya ingin melakukan pembayaran menggunakan kartu kreditagar saya bisa menggunakan kartu kredit saya dalam pembelian online.

Sebagai pengguna, saya ingin melakukan pencarian dengan memasukkan nama teman sayaagar saya bisa menemukan teman saya dengan namanya.

Tidak peduli bagaimana Anda menulis cerita pengguna, ada dua hal yang harus Anda ingat. Pertama, cerita pengguna harus ditulis dari sudut pandang pengguna. Kedua, pertahankan deskripsi ‘cukup saja’. Hindari menambahkan terlalu banyak detail di awal proyek perangkat lunak. Nanti Anda akan memiliki kesempatan untuk menyempurnakan dan mendetailkan cerita pengguna agar menjadi sesuatu yang dapat digunakan oleh pengembang dalam desain dan implementasi.

Siklus Hidup Cerita Pengguna

Secara umum, terdapat enam status utama untuk setiap cerita pengguna sepanjang proyek perangkat lunak:

1. Menunggu – Melalui komunikasi antara pengguna dan tim proyek, cerita pengguna ditemukan. Pada tahap ini, cerita pengguna hanya memiliki deskripsi singkat tentang kebutuhan pengguna. Belum ada diskusi rinci mengenai persyaratan, logika sistem, atau desain tampilan. Faktanya, satu-satunya tujuan cerita pengguna saat ini hanyalah sebagai pengingat bagi semua pihak mengenai diskusi mendatang mengenai permintaan pengguna yang tertulis dalam cerita pengguna ini (kartu). Kemungkinan besar cerita pengguna akan dibatalkan di masa depan.
2. Harus Dilakukan – Melalui diskusi antara berbagai pemangku kepentingan, cerita pengguna yang akan ditangani dalam beberapa minggu ke depan ditentukan, dan dimasukkan ke dalam periode waktu yang disebut sprint. Cerita pengguna semacam ini dikatakan berada dalam status Todo. Belum ada diskusi rinci yang dilakukan pada tahap ini.
3. Dibahas – Ketika cerita pengguna berada dalam status Dibahas, pengguna akhir akan berkomunikasi dengan tim pengembang untuk memastikan persyaratan serta menentukan kriteria penerimaan. Tim pengembang akan mencatat persyaratan atau keputusan apa pun sebagai catatan percakapan. Ahli UX mungkin membuat wireframe atau storyboard agar pengguna dapat melihat fitur yang diusulkan dalam mock-up visual, dan merasakannya. Proses ini dikenal sebagai desain pengalaman pengguna (UX design).
   
4. Dikembangkan – Setelah kebutuhan dipahami dengan jelas, tim pengembangan akan merancang dan mengimplementasikan fitur untuk memenuhi permintaan pengguna.
5. Memverifikasi – Setelah tim pengembangan mengimplementasikan sebuah user story, user story tersebut akan diverifikasi oleh pengguna akhir. Dia/nya akan diberi akses ke lingkungan pengujian atau produk perangkat lunak yang setengah selesai (kadang disebut versi alpha) untuk memverifikasi fitur tersebut. Verifikasi akan dilakukan berdasarkan item verifikasi yang ditulis saat mendetailkan user story. Hingga verifikasi selesai, user story dikatakan berada dalam status Memverifikasi.
6. Selesai – Akhirnya, fitur telah diverifikasi selesai, user story dianggap berada dalam status Selesai. Biasanya, ini merupakan akhir dari user story. Jika pengguna memiliki kebutuhan baru, baik itu tentang fitur baru, atau peningkatan dari user story yang telah selesai, tim akan membuat user story baru untuk iterasi berikutnya.

Mendetailkan User Story – Kapan dan Mengapa?

Hal kunci yang membuat user story berbeda dari pendekatan pengumpulan kebutuhan tradisional adalah bahwa pendekatan user story membagi identifikasi masalah dan solusi menjadi dua tahap, yang dilakukan pada tahap berbeda dalam proyek perangkat lunak. Sementara masalah dan pemahaman singkat terhadap permintaan pengguna ditemukan pada awal proyek perangkat lunak, rincian kebutuhan sistem hanya ditemukan sebelum dimulainya desain dan implementasi. Berikut adalah beberapa manfaat dari pengaturan ini:

1. Dapat merespons kebutuhan pengguna terkini karena kebutuhan dirinci tepat sebelum implementasi, bukan dengan menyelesaikan semua hal pada awal proyek.
2. Dapat lebih mudah mengidentifikasi kebutuhan yang tepat karena baik masalah maupun solusi akan melalui diskusi mendalam. Dalam pendekatan tradisional, karena rincian semua kebutuhan harus ditemukan di awal proyek, maka ‘kebutuhan awal’ bisa berubah seiring waktu, mengakibatkan banyak pemborosan usaha analisis.
3. – Di sisi lain, user story yang ditemukan tidak valid dapat dengan mudah dibatalkan. Anda tidak akan kehilangan banyak waktu dalam studi dan dokumentasi sebelumnya

Cara Menggunakan User Story Secara Efektif?

Sama seperti banyak metodologi pengembangan perangkat lunak lainnya, jika Anda menerapkan user story secara tepat dalam proyek perangkat lunak Anda, Anda akan mampu menghasilkan sistem perangkat lunak berkualitas serta memenangkan kepercayaan dan kepuasan dari pelanggan. Berikut adalah beberapa hal yang perlu Anda pertimbangkan saat menggunakan user story:

1. Jaga agar deskripsi user story tetap singkat.
2. Pikirkan dari sudut pandang pengguna akhir saat menulis user story.
3. Sebuah (UML) use case mewakili tujuan bisnis. Kemampuan untuk mengelompokkan user story di bawah use case memungkinkan Anda memastikan bahwa user story memenuhi tujuan bisnis, dengan kata lain, mereka berbagi tujuan sistem yang sama. Ini berfungsi sebagai tempat penampung untuk Anda mengelola, menjadwalkan, dan memprioritaskan user story dengan cara yang lebih terkelola.
4. Item verifikasi harus ditentukan sebelum Anda memulai pengembangan
5. Perkirakan user story sebelum implementasi untuk memastikan beban kerja tim Anda berada dalam kendali.
6. Kebutuhan ditemukan bersama pengguna akhir, bukan oleh pengguna akhir saja atau hanya oleh tim pengembangan. Menjaga hubungan baik dengan pengguna akhir akan menjadi situasi saling menguntungkan bagi kedua belah pihak.
7. Komunikasi selalu penting dalam memahami apa yang diinginkan pengguna akhir.

Visual Paradigm menyediakan semua alat yang Anda butuhkan dalam pengembangan perangkat lunak agile, yang mencakup alat Diagram Use Case UML, (agile) user story, sprint, storyboard dan wireframe untuk desain UX, alat manajemen tugas, dll.