Cerita dan persyaratan pengguna adalah binatang yang sangat berbeda.
Persyaratan
Persyaratan mengandaikan bahwa desain aplikasi dilakukan sebelumnya, dan pengembangan itu adalah implementasi dari desain itu. Oleh karena itu persyaratan berfokus pada bagaimana menerapkan suatu fungsi.
Contoh persyaratan:
- Buat formulir kontak pengguna dengan bidang-bidang berikut: nama, nama keluarga, email, teks bebas dan tombol kirim. Ketika tombol kirim ditekan, email dikirim ke tim dukungan kami.
Cerita pengguna
Cerita pengguna fokus pada apa yang harus dicapai, dan bersikeras bahwa desain produk dilakukan pada menit terakhir dan merupakan kolaborasi antara orang produk dan orang pengembang. Rinciannya diputuskan selama implementasi berdasarkan peluang.
Contoh cerita:
- Sebagai Jimmy pengguna, saya ingin menghubungi tim dukungan Anda ketika saya tidak dapat menggunakan situs dengan benar sehingga mereka dapat membantu saya.
Apa bedanya?
Seperti yang Anda lihat, pasti ada perbedaan dalam jumlah detail yang disediakan, tetapi ada juga banyak informasi yang hanya tersedia dalam cerita, yaitu tujuan apa yang sedang kami coba capai dengan fitur ini.
Walaupun mungkin tampak bahwa tujuannya relatif tidak penting, ini adalah asumsi yang salah dalam pengembangan tangkas. Biasanya ada dua kasus di mana mengetahui tujuan itu sangat penting: mengurangi biaya peluang dan memungkinkan kelincahan.
Biaya peluang
Jika ada asumsi tersembunyi dalam persyaratan, itu bisa sangat sulit untuk dicapai. Misalnya: apakah ada server email yang tersedia? Jika tidak, persyaratan mungkin membutuhkan waktu lebih lama untuk dikembangkan. Dalam beberapa kasus lain, cara yang lebih sederhana untuk mencapai tujuan yang sama mungkin terlewatkan karena desainnya.
Sebaliknya, kisah pengguna adalah tentang pengguna yang menghubungi departemen dukungan kami. Jika mengirim surat tidak layak atau terlalu mahal, kami dapat menemukan solusi yang berbeda di tempat: menulis ke database, misalnya, atau menggunakan formulir melalui Google docs, atau cukup memasukkan alamat email alih-alih formulir. Ini tidak dapat dengan mudah dilakukan dengan persyaratan, tetapi itu mudah dilakukan dengan cerita dan orang produk yang hadir.
Kelincahan
Untuk alasan ini, dengan persyaratan kami biasanya cenderung memikirkan asumsi tersembunyi ini sebelumnya dan memastikan tidak ada hambatan. Jadi dalam hal ini mungkin ada persyaratan yang berbeda, dijadwalkan sebelumnya, yang memastikan server email hadir.
Ini membawa kita ke perbedaan besar lainnya antara cerita dan persyaratan yang hierarki . Seperti yang telah saya sebutkan di atas, persyaratan harus, berdasarkan sifatnya sendiri, dipesan dalam beberapa hierarki alami sehingga dependensi terpenuhi. Cerita, di sisi lain, fokus pada tujuan dan tidak memiliki kendala seperti itu.
Ini dirancang, karena dengan gesit penting sekali untuk menambah, menghapus, menjadwal ulang, dan memodifikasi cerita yang diperlukan selama pelaksanaan proyek. Persyaratan umumnya dapat ditambahkan, kadang-kadang dimodifikasi atau dihapus, tetapi umumnya sangat menyakitkan untuk memindahkannya karena semua ketergantungan. Ini tidak dilakukan sesering mungkin. Jika Anda bekerja dengan persyaratan, implementasi tangkas Anda akan menderita, atau mungkin tidak akan sangat tangkas sama sekali, dalam arti mampu merangkul perubahan.