Menulis cerita pengguna adalah keterampilan dasar bagi setiap insinyur perangkat lunak yang memasuki lingkungan Agile. Meskipun banyak tim mengandalkan platform digital untuk mengelola tugas, memahami mekanisme inti dari cerita pengguna tanpa ketergantungan pada perangkat lunak membangun fondasi yang lebih kuat. Panduan ini berfokus pada proses manual, menggunakan benda fisik seperti catatan perekat, papan tulis, dan kartu indeks untuk merancang persyaratan yang jelas dan dapat diambil tindakan. Tujuannya adalah kejelasan berpikir, bukan kenyamanan layar.
Ketika Anda menghilangkan perangkat lunak, Anda dipaksa untuk terlibat secara mendalam dengan isi cerita. Tidak ada fitur auto-complete atau template siap pakai yang bisa disembunyikan. Anda harus mengungkapkan nilai, pelaku, dan kebutuhan secara eksplisit. Disiplin manual ini memastikan bahwa tim memahami ruang masalah sebelum menulis satu baris kode pun. Di bawah ini, kami mengeksplorasi anatomi sebuah cerita, kriteria penerimaan, dan metode menyempurnakan ide tanpa bantuan digital.
📖 Memahami Konsep Inti
Cerita pengguna adalah deskripsi ringan 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 penampung untuk percakapan. Tindakan fisik menulis cerita pada kartu atau kertas memperkuat niat ini. Cerita ini dimaksudkan untuk dipindahkan, diedit, dibuang, atau digabungkan. Sistem digital seringkali memaksa Anda masuk ke struktur yang kaku terlalu dini. Metode manual menjaga cerita tetap fleksibel.
Mengapa Harus Manual?
Ada beberapa alasan kuat untuk berlatih menulis cerita secara manual, terutama bagi insinyur baru:
- Fokus pada Nilai:Tanpa kolom yang harus diisi, Anda fokus pada proposisi nilai yang sebenarnya.
- Beban Kognitif:Menulis dengan tangan membuat Anda lebih lambat, memberi waktu untuk berpikir sebelum Anda menetapkan teks.
- Kolaborasi:Kartu fisik memungkinkan tim untuk secara fisik mengatur ulang pekerjaan, memvisualisasikan alur dan prioritas.
- Kemandirian:Anda mempelajari format ini dengan sangat baik sehingga dapat menulis persyaratan yang valid bahkan jika alat tidak tersedia.
📋 Anatomi Cerita Manual
Setiap cerita pengguna mengikuti struktur tertentu. Saat menulis secara manual, gunakan format yang konsisten pada kartu indeks atau catatan perekat Anda. Konsistensi ini memungkinkan tim untuk meninjau informasi dengan cepat selama sesi perencanaan. Format standar terdiri dari tiga bagian yang berbeda. Jangan melewatkan salah satunya.
1. Persona (Siapa)
Identifikasi peran atau jenis pengguna tertentu. Hindari istilah umum seperti ‘pengguna’. Harus spesifik. Apakah itu ‘Administrator’, ‘Pengunjung Tamu’, atau ‘Pelanggan Berbayar’? Persona menentukan izin dan konteks dari fitur tersebut.
2. Tindakan (Apa)
Jelaskan kemampuan atau tindakan yang ingin dilakukan pengguna. Ini adalah kata kerja. Harus berupa tujuan tingkat tinggi, bukan detail implementasi teknis. Misalnya, ‘cari item’ lebih baik daripada ‘masukkan kueri ke database SQL’. Tindakan ini mewakili niat pengguna.
3. Manfaat (Supaya)
Ini adalah bagian paling penting yang sering diabaikan oleh pemula. Mengapa pengguna menginginkan ini? Apa nilai yang diberikan? Jika Anda tidak bisa menjawab ini, cerita mungkin tidak bernilai. Klause ‘Supaya’ menghubungkan fitur dengan hasil bisnis atau pengguna.
Struktur Contoh
Tulis ini dalam satu atau dua baris. Buat tetap ringkas.
- Sebagai [Persona],
- Saya ingin [Tindakan],
- Supaya [Manfaat].
📝 Menentukan Kriteria Penerimaan
Sebuah cerita tidak lengkap tanpa kriteria penerimaan. Ini adalah kondisi yang harus dipenuhi agar cerita dianggap selesai. Saat menulis secara manual, kriteria ini harus dicantumkan tepat di bawah kartu cerita atau pada lembar terpisah yang dilampirkan padanya. Mereka berfungsi sebagai kasus uji untuk pekerjaan rekayasa.
Kriteria penerimaan menghilangkan ambiguitas. Mereka menentukan batas-batas fitur. Tanpa kriteria ini, dua insinyur mungkin mengimplementasikan solusi yang berbeda untuk cerita yang sama. Penulisan manual mendorong Anda untuk mempertimbangkan kasus-kasus tepi sebelum pengembangan dimulai.
Format Given/When/Then
Untuk kriteria yang tepat, gunakan struktur Given/When/Then. Ini adalah terjemahan manual dari Behavior Driven Development (BDD). Struktur ini menyusun logika secara jelas.
- Diberikan: Konteks atau keadaan awal.
- Ketika: Kejadian atau tindakan yang dilakukan.
- Maka: Hasil yang diharapkan.
Contoh Kriteria
- Diberikan pengguna telah masuk,
- Ketika mereka mengklik tombol keluar,
- Maka mereka akan diarahkan ke halaman beranda.
- Ketika mereka mengklik tombol keluar,
Tabel Jenis Kriteria
Berbagai jenis kriteria ada. Tabel membantu mengkategorikannya selama proses penulisan manual.
| Jenis | Deskripsi | Contoh |
|---|---|---|
| Fungsional | Perilaku spesifik sistem | “Sistem mengirim email setelah pengiriman formulir” |
| Non-Fungsional | Kendala kinerja atau keamanan | “Halaman dimuat dalam waktu kurang dari 2 detik” |
| Logika Bisnis | Aturan yang mengatur data | “Diskon hanya berlaku untuk pesanan di atas $50” |
| Kemudahan Penggunaan | Persyaratan kemudahan penggunaan | “Tombol harus terlihat tanpa harus menggulir halaman” |
🌐 Memvalidasi dengan Model INVEST
Setelah Anda menulis sebuah cerita secara manual, Anda harus memvalidasi kualitasnya. Model INVEST adalah kerangka kerja standar untuk hal ini. Anda dapat menggunakan daftar periksa di selembar kertas terpisah untuk mengevaluasi setiap cerita sebelum menambahkannya ke dalam backlog. Ini memastikan pekerjaan dapat dikelola dan bernilai.
Bebas
Cerita harus bersifat mandiri. Cerita tersebut tidak boleh bergantung pada cerita lain yang harus selesai terlebih dahulu agar bernilai. Meskipun terdapat ketergantungan teknis, nilai cerita harus dapat berdiri sendiri. Jika Anda harus menunggu Cerita A agar dapat membuat Cerita B, pertimbangkan apakah Cerita B bisa dibagi.
Dapat Dinegosiasikan
Cerita adalah janji untuk berdiskusi, bukan kontrak. Ini memungkinkan terjadinya percakapan antara insinyur dan pemangku kepentingan. Jika teks terlalu rinci, maka akan berubah menjadi spesifikasi, bukan cerita. Beri ruang bagi eksplorasi teknis.
Bernilai
Setiap cerita harus memberikan nilai bagi pengguna atau bisnis. Jika sebuah cerita tidak memenuhi persyaratan ‘Sehingga’ secara efektif, maka harus dibuang atau direvisi. Nilai adalah faktor utama yang mendorong isi backlog.
Dapat Diperkirakan
Tim harus mampu memperkirakan usaha yang dibutuhkan. Jika sebuah cerita terlalu samar, maka tidak dapat diperkirakan. Jika terlalu kompleks, pecah menjadi bagian-bagian yang lebih kecil. Penulisan manual membantu mengidentifikasi ketidakjelasan karena Anda harus menuliskan detail secara fisik.
Kecil
Sebuah cerita harus cukup kecil agar dapat diselesaikan dalam satu iterasi atau sprint. Cerita yang besar merupakan risiko. Mereka sering menghasilkan pekerjaan yang tidak selesai. Jika sebuah cerita terasa seperti proyek, bagi menjadi cerita-cerita kecil yang saling berurutan.
Dapat Dites
Anda harus mampu memverifikasi bahwa cerita telah selesai. Jika tidak ada kriteria penerimaan, maka cerita tidak dapat diuji. Penulisan manual mendorong Anda untuk mendefinisikan dengan jelas seperti apa bentuk ‘selesai’ itu.
Daftar Periksa INVEST
Gunakan tabel ini untuk meninjau cerita Anda selama perencanaan.
| Huruf | Pertanyaan yang Harus Diajukan | Status |
|---|---|---|
| I | Dapatkah ini dikembangkan tanpa yang lain? | [ ] |
| N | Apakah cakupan terbuka untuk diskusi? | [ ] |
| V | Apakah ini memberikan nilai yang jelas? | [ ] |
| E | Dapatkah kita menebak usaha yang dibutuhkan? | [ ] |
| S | Apakah ini bisa masuk dalam sprint? | [ ] |
| T | Apakah ada kondisi lulus/gagal yang jelas? | [ ] |
🔍 Proses Penyempurnaan
Penyempurnaan, juga dikenal sebagai pemeliharaan, adalah kegiatan menyiapkan cerita untuk pengembangan di masa depan. Anda tidak perlu perangkat lunak untuk melakukan penyempurnaan. Bahkan, tindakan fisik memindahkan kartu di atas meja dapat meningkatkan pemahaman terhadap alur kerja. Sesi penyempurnaan melibatkan meninjau cerita, memperjelas detail, dan memecah item besar.
Langkah 1: Tinjauan
Kumpulkan tim di sekitar meja besar. Letakkan kartu-kartu tersebut. Bacakan setiap cerita dengan keras. Tindakan sederhana ini dapat menangkap kesalahan yang tidak terlihat saat membaca secara diam-diam. Dengarkan adanya ambiguitas di bagian ‘Sehingga’.
Langkah 2: Pemecahan
Jika sebuah kartu terasa terlalu berat, potonglah. Tulis cerita baru yang lebih kecil pada kartu baru. Letakkan kartu baru di atas kartu asli atau di sampingnya. Pastikan kartu asli diperbarui untuk mencerminkan pemecahan ini. Pemisahan visual ini membantu mengelola cakupan kerja.
Langkah 3: Pertanyaan
Selama tinjauan, tim mengajukan pertanyaan. Tulis pertanyaan-pertanyaan ini pada lembar terpisah. Jangan menjawabnya segera. Pertanyaan menunjukkan celah dalam pengetahuan. Mereka menjadi item tindakan untuk sesi berikutnya. Ini memisahkan perencanaan dari jawaban.
Langkah 4: Penyusunan Urutan
Susun kartu-kartu tersebut berdasarkan ketergantungan atau nilai. Gunakan benang atau pita di atas meja untuk menunjukkan koneksi. Jika Kartu A harus terjadi sebelum Kartu B, gambarlah garis di antara keduanya. Alur visual ini membantu mengidentifikasi hambatan sebelum pengembangan dimulai.
📈 Teknik Prioritas
Setelah Anda memiliki daftar cerita, Anda harus memutuskan apa yang akan dibangun terlebih dahulu. Metode prioritas manual sering kali lebih efektif daripada pengurutan digital karena melibatkan interaksi fisik dengan pekerjaan.
Metode MoSCoW
Warnai kartu Anda atau gunakan bentuk berbeda untuk menunjukkan prioritas. Ini adalah teknik manual klasik.
- M – Harus Ada:Kritis untuk rilis. Tidak ada pengecualian.
- S – Sebaiknya Ada:Penting tetapi tidak vital. Dapat ditunda jika diperlukan.
- C – Bisa Ada:Diinginkan tetapi tidak diperlukan.
- W – Tidak Akan Dibuat: Setuju untuk tidak dimasukkan ke dalam cakupan saat ini.
The Weighted Shortest Job First (WSJF)
Untuk pendekatan yang lebih matematis, berikan angka pada nilai dan waktu. Tuliskan angka-angka tersebut di kartu. Hitung rasio secara manual. Ini memaksa tim untuk mengukur nilai daripada mengandalkan perasaan. Ini adalah latihan yang berharga bagi insinyur baru untuk memahami pertukaran bisnis.
⚠️ Kesalahan Umum yang Harus Dihindari
Bahkan dengan pendekatan manual, kesalahan terjadi. Insinyur baru sering terjebak dalam perangkap tertentu saat menulis cerita tanpa bimbingan validasi perangkat lunak.
1. Bahasa Teknis
Jangan menulis cerita dari sudut pandang sistem. Hindari kata-kata seperti ‘database’, ‘API’, atau ‘backend’. Tulis dari sudut pandang pengguna. Sistem tidak terlihat bagi pengguna. Jika Anda menulis ‘Sistem memperbarui cache’, pengguna tidak peduli. Mereka peduli tentang kecepatan halaman.
2. Kriteria Penerimaan yang Hilang
Mudah untuk menulis bagian ‘Sebagai…’ dan lupa bagian ‘Sehingga…’ atau kriteria. Cerita tanpa kriteria adalah item daftar tugas, bukan cerita pengguna. Ini menciptakan ambiguitas. Selalu minta kriteria sebelum kartu dianggap selesai.
3. Terlalu Banyak Detail
Menulis cerita bukan berarti menulis spesifikasi. Jika Anda menulis lima paragraf pada satu kartu, kemungkinan besar Anda terlalu mendetail. Buat kartu tetap kecil. Detail seharusnya ada dalam percakapan saat penyempurnaan, bukan di kartu itu sendiri.
4. Mengabaikan Kasus Tepi
Penulisan manual sering fokus pada jalur yang menyenangkan. Anda harus secara eksplisit menuliskan apa yang terjadi ketika sesuatu gagal. Tambahkan kriteria untuk kondisi kesalahan. ‘Diberikan jaringan sedang mati, ketika pengguna mengirimkan, maka mereka melihat pesan coba lagi.’
5. Kurangnya Kolaborasi
Menulis cerita secara terpisah adalah pemborosan waktu. Cerita adalah awal percakapan. Jika Anda menulis cerita tanpa mendiskusikannya dengan rekan kerja, kemungkinan besar akan disalahpahami. Selalu tinjau secara manual bersama rekan kerja.
👩💻 Berpindah ke Digital Nanti
Meskipun panduan ini berfokus pada metode manual, tim akhirnya beralih ke sistem digital untuk pelacakan dan pelaporan. Keterampilan yang Anda pelajari di sini langsung dapat diterapkan. Ketika Anda akhirnya menggunakan platform digital, Anda akan menulis cerita yang lebih baik karena memahami struktur inti. Anda tidak akan mengandalkan perangkat lunak untuk menentukan nilai bagi Anda.
Transisi berjalan lancar jika fondasinya kuat. Alat digital menjadi penyimpanan untuk pekerjaan manual yang sudah Anda pikirkan. Anda cukup menyalin isi kartu ke dalam sistem. Logikanya tetap sama.
📝 Latihan Praktis untuk Insinyur Baru
Untuk memperkuat konsep-konsep ini, coba latihan berikut. Ini tidak memerlukan perangkat lunak, hanya kertas dan pena.
- Langkah 1: Pilih fitur yang Anda gunakan setiap hari (misalnya, bilah pencarian di situs web).
- Langkah 2: Tulis cerita pengguna di kartu indeks menggunakan format standar.
- Langkah 3: Tulis tiga kriteria penerimaan menggunakan Diberikan/Bila/Maka.
- Langkah 4: Terapkan daftar periksa model INVEST pada kartu.
- Langkah 5: Tulis dua pertanyaan yang kamu miliki tentang cerita tersebut yang akan diajukan oleh seorang pengembang.
- Langkah 6: Tinjau kartu bersama rekan kerja. Minta mereka mengkritik bagian ‘So That’.
💬 Pikiran Akhir tentang Disiplin Manual
Menguasai seni cerita pengguna adalah tentang ketepatan dan empati. Ini mengharuskan kamu untuk menempatkan diri dalam posisi pengguna. Ini mengharuskan kamu untuk jelas dan ringkas. Proses manual menghilangkan kebisingan antarmuka perangkat lunak dan hanya menyisakan pesan. Disiplin ini membuatmu menjadi insinyur yang lebih baik. Ini membuatmu menjadi komunikator yang lebih baik.
Ketika kamu menghilangkan alat-alatnya, yang tersisa hanyalah logika. Logika inilah yang menggerakkan perangkat lunak. Dengan berlatih secara manual, kamu memastikan logikamu kuat sebelum meminta komputer untuk menjalankannya. Pendekatan ini mengurangi pekerjaan ulang dan meningkatkan kualitas. Ini adalah kepercayaan diri yang tenang terhadap kemampuanmu dalam menentukan nilai.
Ingat, tujuannya bukan untuk mengisi antrian digital. Tujuannya adalah menyelesaikan masalah bagi seseorang. Pertahankan manusia dalam proses. Buat cerita tetap sederhana. Pertahankan kriteria yang jelas. Prinsip-prinsip ini akan membantumu dengan baik, terlepas dari alat apa yang akhirnya kamu gunakan.
📊 Ringkasan Poin Penting
- Struktur:Selalu gunakan Sebagai seorang / Saya ingin / Supaya.
- Kriteria:Tentukan Diberikan/Ketika/Maka untuk kejelasan.
- Validasi:Periksa terhadap INVEST sebelum menyelesaikan.
- Kolaborasi:Tinjau kartu secara fisik bersama tim.
- Fokus:Utamakan nilai pengguna daripada implementasi teknis.