Bagaimana cara mendefinisikan aturan bisnis yang kompleks menggunakan Cerita Pengguna?

Definisi yang cepat dan kotor dari Kisah Pengguna :

"As a <role>, I want <goal/desire> so that <benefit>"

Dalam definisi yang diterima secara umum ini, ada sedikit ruang untuk mendefinisikan aturan bisnis, kendala, atau input pengguna.

Contoh sepele hanya untuk menggambarkan:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

Dalam contoh konyol ini, di mana orang akan mendefinisikan bidang yang diperlukan saat mendaftarkan buku? Haruskah itu ditulis di mana saja? Atau haruskah aturan bisnis yang disyaratkan disampaikan secara lisan oleh Pemilik Produk?

Kolom adalah bagian dari percakapan yang harus dimiliki. Mereka dapat dituliskan jika itu berguna tetapi itu adalah panggilan penghakiman. Menjaga dokumentasi tetap terbaru mungkin menantang sedangkan perangkat lunak yang berfungsi dapat dilihat sebagai dokumentasi sampai batas tertentu.

Kisah Pengguna - Janji untuk melakukan percakapan akan menjadi entri blog tentang ini.

Contoh sepele Anda memiliki beberapa poin yang saya tidak tahu seberapa baik Anda akan memperhatikan ini. Apa artinya "mendaftar buku baru?" Apa itu "Temukan ketersediaannya secara online?" Di situlah percakapan dimulai dan begitu cerita selesai, mungkin ada cerita baru karena mungkin pendaftaran itu harus disimpan dalam arsip atau laporan harus dibuat secara berkala.

Jawaban sebelumnya memberikan poin yang valid, khususnya tentang cerita pengguna sebagai pengingat untuk melakukan percakapan . Hal-hal lain yang perlu dipertimbangkan:

1. Jika ceritanya terlalu rumit, itu mungkin epik . Anda dapat membagi epos menjadi cerita yang lebih kecil sekarang atau setelah diprioritaskan pada jaminan produk

2. Detail yang menyiratkan kasus-kasus uji dipisahkan dari cerita itu sendiri. [ Mike Cohn ]

   Anda dapat menambahkan di bagian belakang kartu cerita, membuat catatan kecil jika itu benar-benar penting atau memasukkannya ke dalam dokumen tes penerimaan .

Sebagai pedoman untuk mengevaluasi apakah cerita pengguna Anda baik, Anda dapat mengikuti saran Bill Wake :

• Saya ndependen (dari cerita lain)
• Tidak bisa dinegosiasikan
• V aluable (untuk pengguna atau pelanggan)
• E stimable (mendekati perkiraan yang baik)
• S mal (cukup untuk diperkirakan)
• T estable

Anda mungkin ingin membaca Bab 2 "Menulis Cerita" dari buku User Stories Applied, oleh Mike Cohn.

Biasanya pada cerita pengguna yang mencakup luas yang memiliki banyak sisi saya mencoba untuk mendapatkan contoh cerita yang paling umum, dan kemudian untuk spesifiknya saya membuat cerita pengguna anak yang mewarisi dari cerita tersebut. Banyak alat manajemen proyek Agile seperti RallyDev memungkinkan Anda melakukan ini dengan mudah dan menurut saya masuk akal.

Mendaftarkan buku baru sangat luas, jadi mungkin ada 10 cerita pengguna anak lainnya tentang bagaimana <role>buku ingin didaftarkan.

Detail ekstrim dari hal-hal ini atau detail pinggiran yang aneh yang biasanya saya definisikan dalam satu atau lebih tugas di bawah kisah pengguna itu. Tugas-tugas membantu menentukan pengembangan dan pekerjaan desain yang harus dilakukan (pada tingkat umum) untuk memenuhi cerita pengguna itu (Misalnya. Menulis validtor untuk memastikan input dalam bidang deskripsi kurang dari 50 karakter ...) EDIT: Saya hanya ingin menambahkan bahwa mungkin lebih baik untuk menjaga detail ekstrem dari cerita pengguna karena kemungkinan itu bukan sesuatu yang benar-benar diperhatikan oleh pengguna. Pengguna ingin menjelaskan perangkat lunak secara umum dan mereka bergantung pada pengembang perangkat lunak untuk mencari tahu dan menyembunyikan detailnya.

Ini adalah cara saya mendekati masalah tetapi saya yakin ada beberapa cara berbeda.

Jawabannya sederhana, memasukkan aturan bisnis ke dalam kriteria penerimaan.

Contoh sepele hanya untuk menggambarkan:

Sebagai seorang pustakawan, saya ingin mendaftarkan buku-buku baru, sehingga siswa dapat menemukan ketersediaannya secara online

Saya akan puas ketika: * Saya dapat mendaftarkan bidang-bidang berikut: - ISDN - Penulis - Dewey Desimal blah blah * Saya dapat melihat konfirmasi bahwa buku telah terdaftar oleh sistem * Saya dapat melihat buku di dalam sistem

Bagaimana cara mendefinisikan aturan bisnis yang kompleks menggunakan Cerita Pengguna?

Bukan itu gunanya cerita pengguna. Mereka bukan persyaratan perangkat lunak yang menangkap semua detail atau aturan bisnis yang diperlukan untuk menulis implementasi. Mereka hanya deskripsi tentang apa yang harus dilakukan aplikasi dari perspektif pengguna.

Ingat apa yang penting: membangun perangkat lunak yang tepat. Anda menggunakan apa pun yang diperlukan untuk melakukan itu dan cerita pengguna hanya agar Anda memastikan Anda telah mengumpulkan fitur-fitur yang diperlukan aplikasi sehingga Anda dapat kemudian berbicara tentang mereka, memprioritaskan mereka, memperkirakannya, dll. Bagian yang hilang dari pengguna klasik cerita (sebagai ... Saya ingin ... sehingga) adalah tentang komunikasi antara mereka yang terlibat dalam membangun perangkat lunak.

Memiliki detail sebagai kriteria penerimaan, sub-cerita, tugas teknis yang dilampirkan pada cerita pengguna, dalam dokumen spesifikasi atau apa pun, melampaui apa yang membantu Anda dengan cerita pengguna. Pengguna basi hanyalah "subjek" percakapan ketika memutuskan bagaimana membangun perangkat lunak.

Dalam contoh yang diberikan, ada banyak detail registrasi buku yang tidak diketahui banyak pengembang, seperti Dewey atau sistem klasifikasi lainnya, ISBN, nomor akuisisi, salinan / judul / penulis duplikat, edisi lain, dan sebagainya. Untuk sistem baru, perincian seperti itu harus disediakan oleh pelanggan (dan pustakawan, dari semua orang, tentu akan peduli pada mereka).

Mengutip Steve O'Connell, "Sangat menakutkan untuk merenungkan berapa banyak kebijakan bisnis yang dibuat oleh pengembang yang tidak memiliki detail yang diperlukan dalam spesifikasi, jadi buat saja sendiri."