Bagaimana cerita pengguna tidak mengandung persyaratan (saat ditulis pada kartu) dan masih dapat diimplementasikan

18

Saya telah diberi tahu "Kisah Pengguna bukan persyaratan, itu hanya pengingat apa yang diinginkan pelanggan, Anda tidak bisa memasukkan persyaratan dalam sebuah cerita". Tapi mari kita ambil contoh bahwa pelanggan menginginkan pemrosesan berbeda untuk kartu kredit yang berbeda. Ada persyaratan ketat yang harus diterapkan dan diketahui sehingga kasus uji dapat ditulis. Ke mana harus pergi persyaratan jika tidak dalam cerita pengguna?

Bagaimana pengembang dapat berkembang dari sebuah cerita jika tidak ada persyaratan yang lebih rendah? Bagaimana penguji dapat menulis kasus uji (yang rinci) berdasarkan kisah pengguna? Di mana persyaratan seperti batasan DB, validasi bidang, dll. Tinggal di luar kisah pengguna?

agile scrum requirements

— pengguna144171
sumber

6

Cerita pengguna hanya itu - persyaratan tingkat pengguna. 'Persyaratan perangkat lunak' tingkat rendah (seringkali batasan apa yang dianggap dapat diterima) harus selalu dipanen secara terpisah dan didokumentasikan secara terpisah dengan referensi yang sesuai.

— Gusdor

7

Inti dari mendapatkan cerita pengguna adalah bahwa sebagian besar pengguna program Anda tidak akan pernah tahu atau peduli bagaimana cara kerjanya . Mereka tidak peduli tentang struktur basis data, pemisahan masalah, struktur kelas, dll .; mereka peduli dengan stabilitas, kecepatan dan kemudahan penggunaan. Itu sebabnya Anda menangkap cerita mereka, untuk mencari tahu untuk apa mereka akan menggunakan program ini. Bagaimana Anda kemudian mengimplementasikannya adalah seluruh tingkat persyaratan yang terpisah, para pengguna umumnya tidak akan mampu atau mau memberi tahu proses itu.

— jonrsharpe

2

Agas: Sebenarnya tidak. Saya bertanya karena saya benar-benar tertarik bagaimana hal ini dapat dilakukan dengan benar karena saya yakin, mengingat meluasnya penggunaan SCRUM, ini pasti menjadi masalah bagi banyak tim.

— user144171

4

@maple_shaft masalah dengan elemen "rantish" adalah ini cenderung menarik jawaban rantish. Saya setuju bahwa ada inti yang masuk akal di sana, bertanya-tanya apakah itu dapat diedit untuk hanya mempertahankan inti itu dan menghapus undangan untuk jawaban ranty

— nyamuk

2

Ada pertanyaan yang bagus di sini, tetapi ini ditulis sebagai kata-kata kasar. Saya berupaya mengedit.

— DA01

28

Jawaban ini akan fokus pada bagaimana bekerja dengan Cerita Pengguna dan persyaratan tingkat yang lebih rendah. Saya tidak akan membahas kebajikan, atau ketiadaan, tentang Scrum atau Agile. Saya tidak akan berbicara tentang guru juga.

Jawaban ini mengasumsikan Anda setuju dengan Scrum tetapi belum menemukan cara untuk membuatnya bekerja untuk Anda.

Seperti yang telah disebutkan orang lain, Cerita Pengguna dimaksudkan untuk membahas bagaimana Pengguna menginginkan perangkat lunak menjadi. Karena Pengguna tidak peduli tentang hal-hal implementasi tingkat rendah seperti tabel basis data, batasan, pola arsitektur, dll, Anda tidak akan menemukan detail seperti itu di Kisah Pengguna.

Namun, itu tidak berarti detail ini tidak boleh direkam di mana pun.

Ketika pengembang mengimplementasikan Cerita Pengguna, mereka perlu mengetahui detail level yang lebih rendah yang biasanya tidak akan diketahui Pengguna. Informasi ini dapat berasal dari UKM, BA, Pemilik Produk, arsitek Anda, atau ahli lain atau orang yang berpikiran teknis.

Apakah ini berarti rincian tingkat rendah harus dicatat dalam Cerita Pengguna? Tidak (dan ya).

Di beberapa titik antara waktu cerita itu dibuat dan diimplementasikan, seseorang perlu memikirkan bagaimana cara mengimplementasikannya. Ini biasanya berupa percakapan dengan orang-orang yang terlibat dalam Story (Pengguna, arsitek, pengembang, dll). Percakapan ini harus menghasilkan Kriteria Penerimaan yang tidak ambigu yang dengan jelas menggambarkan ruang lingkup penerapan Kisah Pengguna. Rincian ini perlu direkam di suatu tempat dan di mana itu benar-benar terserah Anda. Kuncinya di sini adalah bahwa detail ini didapat setelah Kisah Pengguna dibuat. Saya pikir inilah yang gurumu coba tekankan.

Sebagai pengembang, jelas bahwa Anda akan membutuhkan cara untuk mengaitkan persyaratan yang lebih spesifik dengan Kisah Pengguna Anda. Hanya bagaimana Anda melakukannya sepenuhnya terserah tim Anda.

Jika orang-orang di tim Anda ingin menyimpan detail ini dari Cerita Pengguna maka Anda mungkin perlu menghormatinya. Ada manfaat untuk menjaga Cerita Pengguna tingkat tinggi Anda bebas dari detail implementasi. Itu membuat mereka tetap ramping dan jaminan simpanan Anda dapat dibaca sebagai riwayat apa yang diinginkan Pengguna dan Pemilik Produk Anda. Jadikan saja kebutuhan Anda sebagai pengembang yang dikenal juga. Anda harus bisa membuat kompromi di mana hanya dengan menautkan ke Kisah Pengguna membuat semua orang senang.

— MetaFight
sumber

3

+1 Kriteria Penerimaan menambahkan lebih detail

— Pecahan

3

Yup, BS-nya. Dan Scrum tidak tangkas.

Saya benci kekakuan yang disebut praktisi gesit yang menelpon Anda bahwa ada satu cara untuk melakukan gesit dan bahwa Anda harus mengikuti semua aturan yang tercantum dalam tulisan suci dari metodologi 'gesit' mana pun yang mereka gunakan. Itu semua BS.

Agile adalah tentang menjadi gesit.

Agile adalah tentang menyelesaikan sesuatu dengan biaya minimum. Ini tidak berarti "tidak ada dokumentasi" karena Anda biasanya berakhir lebih banyak mendokumentasikan dalam peran lincah, Anda hanya melanjutkan dengan mendokumentasikan tanpa harus merencanakan proses untuk melakukan dokumentasi. Demikian pula dengan pengkodean, pengujian dan penangkapan persyaratan. Satu-satunya hal yang penting dalam proses gesit adalah hal-hal yang membantu Anda menyelesaikan pekerjaan Anda, dengan cepat dan efisien tanpa BS.

Jadi dalam hal ini, jika memasukkan persyaratan pengguna dalam kartu membantu Anda menulis, menguji, mendokumentasikan, dan mendemonstrasikan kode yang diperlukan ... masukkan persyaratan pada kartu dan beri tahu guru bahwa tim selalu benar.

Apa yang dipikirkan oleh tim dev Anda yang lain? Dalam metodologi yang benar-benar tangkas, jika mereka semua berpikir bahwa persyaratan harus dituliskan di depan tanpa 'percakapan pengguna', maka itu harusnya, Anda melakukan apa yang menurut tim paling berhasil bagi mereka untuk melakukan pekerjaan mereka. Jika tim berpikir bahwa percakapan pengguna adalah hal yang baik, maka dengarkan mereka dan pahami mengapa mereka memikirkan hal ini dan bawa diri Anda ke dalam cara mereka bekerja.

— gbjbaanb
sumber

4

Apakah Anda keberatan untuk mengatakan ini dengan cara yang kurang merendahkan (yaitu, non-)? Saya setuju dengan Anda pada topik, tetapi orang-orang memiliki pendapat yang berbeda dan itu bukan pembenaran untuk kehilangan sopan santun Anda dengan cara itu.

— Frank

Sebenarnya, saya tidak bisa membayangkan persyaratan yang tidak tertulis di muka - bahkan untuk hal-hal paling sederhana seperti bidang numerik Anda perlu tahu panjang, datatype, validasi. Menurut para guru itu, hal-hal ini tidak perlu ada dalam cerita. Tetapi ketika Anda menulis kode, US level tinggi tidak berguna, Anda harus mengetahui kendala, arus, dll. Saya belum pernah melihat proyek dengan US murni dua kalimat yang efisien untuk implementasi dan pengujian.

— user144171

3

Klien menyetujui integer 8 bit, jadi itu bukan kesalahan saya.

— JeffO

2

@ gbjbaanb: Agile hanyalah kata mewah baru untuk "menggunakan akal sehat", yaitu menemukan keseimbangan yang tepat antara analisis / desain awal dan dengan cepat memberikan solusi parsial untuk mengumpulkan umpan balik. Saya menemukan istilah lincah cukup menjengkelkan karena sangat sedikit yang baru untuk ide-ide ini, selain namanya. Yang lebih buruk terjadi ketika kerangka kerja yang agak tidak fleksibel seperti SCRUM dikenakan sebagai gesit . IMO benar-benar gesit berarti menjatuhkan kata-kata gesit dan SCRUM dan menyesuaikan proses Anda dengan kebutuhan Anda, seperti yang selalu kami lakukan sebelum gelombang tangkas dimulai.

— Giorgio

1

@Alex dia sangat banyak bertanya dalam konteks SCRUM dan proses tangkas.

— gbjbaanb

3

Hanya saja jangan sebut ini sebagai Kisah Pengguna dan semua orang akan senang.

Saya pikir jawabannya adalah, Anda dapat menuliskan ini di mana pun Anda inginkan.

Secara umum, implementasi spesifik tidak termasuk dalam cerita pengguna karena beberapa alasan:

Anda tahu apa yang diinginkan pelanggan, tetapi Anda tidak tahu bagaimana itu akan diterapkan.
Pelanggan sadar ada persyaratan yang lebih spesifik yang terlibat, tetapi sebenarnya tidak peduli dan / atau memahaminya.
Semua orang berpikir mereka sepenuhnya menyadari implementasi spesifik saat ini, tetapi tidak ada yang mau menuliskannya karena dalam pengalaman mereka, semuanya akan berubah dan tidak ada yang mau menulis ulang.

Tidak ada aturan yang menghilangkan dokumen tambahan bila perlu. Mungkin klien membutuhkan akses ke sana dan mungkin tidak. Jika Anda berharap untuk menghasilkan semacam kontrak antara Anda dan klien pada implementasi spesifik seolah-olah Anda bisa mengikutinya dan ketika tidak berhasil menyalahkan klien untuk menyetujuinya, Anda salah. Jika klien memahami rincian teknis pemrosesan kartu kredit, Anda harus membagikan dokumen ini dengan mereka dan mungkin menjadikannya bagian dari percakapan.

— JeffO
sumber

1

Tapi di sini masalahnya, beberapa US clain adalah semua yang Anda butuhkan tetapi saya katakan bahwa itu tidak mungkin ketika cerita tentang "apa" dan bukan tentang "bagaimana". Jika mereka menginginkan layar masuk, berapa panjang bidang yang akan dimiliki? Karakter apa yang akan diizinkan? dll ... pengguna tidak peduli, tetapi pengembang dan penguji akan dan karenanya ini harus ditulis di suatu tempat.

— user144171

4

Jadi, tulislah! Tidak ada yang salah dengan dokumentasi tambahan jika itu yang diperlukan untuk menyelesaikan pekerjaan. Hanya mengerti bahwa dalam banyak kasus, Anda tidak dapat memperlakukan ini seperti semacam kontrak klien. Klien benar-benar akan menggunakan layar login Anda dan kemudian memberitahu Anda bahwa mereka membutuhkan lebih banyak karakter terlepas dari apa yang dikatakan dokumentasi Anda. Sekarang Anda harus memutuskan apakah Anda ingin mengubah kode Anda, dokumentasi atau keduanya.

— JeffO

Dan jika itu adalah usaha besar untuk menyesuaikan panjang input, kode Anda tidak terlalu gesit, jadi sedikit atau tidak ada dokumentasi tidak akan membuat banyak perbedaan.

— JeffO

2

@ user144171 Mencoba untuk menuliskan SEMUA persyaratan untuk proyek, atau fitur, di muka, dan dengan cara yang paling terperinci, hingga ke bagian terakhir, sama buruknya dengan tidak memiliki persyaratan sama sekali. Hal yang sama berlaku untuk desain.

— AK_

@AK_ Saya tidak berpikir dia menyatakan bahwa semua ini perlu dilakukan dimuka, tetapi tentu cukup harus dilakukan dimuka sebelum berlari di mana tumpukan yang cukup besar ada.

— maple_shaft

2

Saya pikir jika yang dikatakan oleh konsultan Scrum Anda adalah bahwa Scrum tidak memerlukan persyaratan, maka Anda memiliki beberapa konsultan yang sangat buruk. Mereka bahkan salah untuk memberi tahu Anda bahwa cerita pengguna sebenarnya bukan persyaratan sama sekali, mereka hanya menjadi salah satu jenis persyaratan.

Apa sajakah jenis persyaratan perangkat lunak?

Persyaratan Bisnis

Ini umumnya merupakan kebutuhan bisnis tingkat tinggi, sesuatu yang umumnya akan berjumlah semacam pernyataan gaya eksekutif tentang suatu sistem. Ini sengaja tingkat tinggi dan luas dan dengan sendirinya tidak dapat diimplementasikan tanpa jauh lebih detail.

Persyaratan Pengguna

Ini adalah persyaratan Kisah Pengguna yang Anda kenal. Mereka umumnya dapat ditampung pada catatan tempel.

Aktor - Biasanya pengguna atau pemangku kepentingan.
Need - Beberapa item atau fungsi umum yang dibutuhkan oleh pengguna
Alasan - Alasan atau konteks di balik mengapa kebutuhan ini ada
Kriteria Penerimaan - Ini adalah kerangka kerja untuk pengujian penerimaan pengguna dan selama Sprint Demo bagaimana Pemilik Produk akan dapat memutuskan apakah cerita pengguna diterima atau tidak.

Persyaratan Fungsional atau Sistem

Ini sepertinya bagian yang hilang dari puzzle Anda. Didorong dari persyaratan tingkat pengguna, persyaratan fungsional mendefinisikan aktor dan properti tingkat sistem, serta perilaku dan fungsi sistem. Ini juga bisa dilakukan dalam format cerita dan dimasukkan ke dalam simpanan Anda. Barang-barang ini harus berdiri sendiri dan dapat diimplementasikan secara independen dari persyaratan satu pengguna.

Aktor - Suatu sistem atau komponen sejenis.
Need - Kebutuhan, atau properti, atau pernyataan perilaku sistem yang harus ada.
Alasan - Konteks di balik mengapa ini diperlukan dalam sistem
Kriteria Penerimaan - Skenario, perilaku, fungsi dan aliran yang diperlukan untuk mengkomunikasikan bagaimana pengujian Sistem dan Integrasi harus dilakukan. Ketika jenis tes ini lulus untuk persyaratan maka kita tahu persyaratan fungsional ini telah selesai. Ini bisa ada dalam dokumentasi eksternal dari cerita pengguna Anda tetapi harus diselesaikan sebelum cerita ini ditugaskan dalam sprint.

Persyaratan fungsional menentukan solusi Anda yang kedengarannya seperti apa yang Anda gambarkan sebagai kesenjangan dalam proses Anda.

Jenis persyaratan penting yang perlu disebutkan tetapi tidak penting untuk pertanyaan Anda: Persyaratan Non-Fungsional, Persyaratan Teknis, dll ...

— maple_shaft
sumber

Saya tidak yakin tentang perbedaan Anda antara persyaratan pengguna dan persyaratan fungsional. Persyaratan pengguna, seperti di AS, harus persyaratan fungsional, dan persyaratan fungsional sangat berbeda dari persyaratan sistem.

— Alex

@Alex: Kisah pengguna / persyaratan => ingin menarik uang dari ATM, persyaratan fungsional => total waktu untuk mengeluarkan tagihan tidak boleh melebihi 30 detik. Persyaratan pengguna tidak mencakup persyaratan fungsional.

— jmoreno

@ jmoreno "Kisah pengguna" itu dalam contoh Anda bukan cerita pengguna, ini adalah titik awal dalam cerita pengguna. Dan "persyaratan fungsional" tentang waktu eksekusi berada di zona abu-abu, persyaratan fungsional utama di sana adalah untuk mengeluarkan tagihan, batasan waktu bisa memiliki banyak asal.

— Alex

2

@ jmoreno Sebenarnya metrik kinerja seperti itu dianggap sebagai Persyaratan Non-Fungsional

a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors

. Perilaku itu sendiri adalah fungsi dari suatu sistem . Kisah pengguna membandingkan keduanya dengan mendefinisikan kebutuhan pengguna. The Fungsi pengguna adalah bukan apa yang kita ketahui sebagai Use Case dan bukan persyaratan fungsional.

— maple_shaft

@Alex Lihat komentar saya di atas. Saya pikir Anda berdua bingung tentang apa persyaratan fungsional itu.

— maple_shaft

1

A User Story adalah salah satu jenis artefak khusus dengan tujuan untuk mendeskripsikan antarmuka yang diharapkan pengguna dari sistem dan itulah sebabnya detail level rendah tidak seharusnya ada di sana. Jika Anda meletakkannya di sana, Anda mengubah maksud artefak dan itu tidak lagi sesuai dengan definisi AS.

Gunakan bentuk spesifikasi lain untuk menangkap persyaratan tingkat bawah dan keputusan desain. Tepatnya apa bentuk-bentuk lain ini adalah sesuatu yang harus diselesaikan di organisasi Anda dan disesuaikan dengan lingkungan spesifik Anda.

Pertanyaan Anda terdengar sangat mirip dengan sesuatu seperti

Saya memiliki CarFactory ini dan saya perlu membuatnya membuat Sepeda juga, tetapi OOD kami "Guru" mengatakan saya tidak diizinkan untuk melakukan itu. Apa ini BS!?!

Hormati pemisahan kekhawatiran dan kohesi artefak Anda, baik yang ada di kode Anda maupun yang ada di proses Anda.

— Alex
sumber

1

Saya pikir tujuan dari pendekatan ini bukan untuk membatasi cerita pengguna, tetapi untuk mencegah persyaratan yang buruk.

Dalam pengalaman saya, pengguna umumnya tidak mampu menulis persyaratan. Pengembang pada umumnya tidak memiliki persyaratan penulisan. Heck, mari kita akui saja: persyaratan sulit untuk ditulis!

Saya pikir itu akan valid bagi pengguna untuk menulis sesuatu dalam istilah persyaratan sebagai bagian dari cerita penggunaan. Namun, hal itu seharusnya tidak secara otomatis menjadikannya persyaratan. Memiliki dua kisah penggunaan yang saling bertentangan adalah masalah kecil; memiliki dua persyaratan yang saling bertentangan adalah masalah utama dalam pemutusan kontrak. Tidak ada gunanya mempromosikan satu sama lain sebelum waktunya.

Saya pikir sudut pandang kejam datang dari pengakuan sifat manusia. Jika orang mulai berpikir tentang cerita pengguna sebagai tempat untuk mengajukan persyaratan, mereka akan mulai melakukannya. Keuntungan sebenarnya dari menggunakan cerita daripada cara lain untuk mengumpulkan persyaratan seperti informasi adalah bahwa kata-kata itu dituliskan dalam kata-kata dan notasi alami pengguna. Ini membuatnya lebih mungkin bahwa pengembang berpikir dari perspektif pelanggan. Di dunia yang sempurna, istilah persyaratan yang dingin bisa juga ada di sana. Pada kenyataannya, kata-kata seperti itu cenderung menyebabkan pengembang menempel pada persyaratan yang mudah dipahami dan melewatkan kata-kata halus dan nuansa pengembangan tangkas ingin menggali menggunakan cerita yang digunakan.

— Cort Ammon - Pulihkan Monica
sumber

1

Masalah dengan garis pemikiran ini adalah bahwa ia bekerja dengan baik dalam proyek kreatif di mana kebutuhan pengguna jelas tetapi spesifikasi kerasnya terbatas. Ketika kita mulai berbicara tentang interaksi sistem yang kompleks dan terutama kendala regulasi dan kebutuhan bisnis untuk parameter sistem yang terdefinisi dengan keras, maka cerita pengguna saja sering gagal menangkap detail penting. Jadi mereka memulai percakapan tetapi ketika saya memiliki 20 halaman spesifikasi dan aturan keras yang tidak membungkuk maka itu terlalu banyak untuk diserap dalam "percakapan". Persyaratan fungsional juga diperlukan di sini.

— maple_shaft

1

Saya setuju persyaratan diperlukan, saya hanya berpikir mereka harus pergi ke tempat lain. Saya tidak dapat berbicara untuk seluruh dunia, tetapi saya telah menemukan bahwa sangat mudah untuk merebut tujuan cerita pengguna dan mengubahnya menjadi buklet yang penuh dengan persyaratan. Jika itu terjadi, saya tidak punya tempat untuk cerita pengguna untuk pergi. Di dunia yang sempurna, Anda bisa menempatkan keduanya dalam cerita pengguna, tetapi pengembang adalah manusia dan budaya berubah-ubah. Jika sebuah tim terbiasa menggunakan cerita pengguna untuk persyaratan, mungkin secara budaya tidak mungkin untuk kembali ke apa yang saya yakini sebagai tujuan utama mereka.

— Cort Ammon - Reinstate Monica

1

Buat keputusan sendiri

Jawaban untuk 'Jadi, bagaimana sebenarnya pengembang dapat mengembangkan cerita jika tidak ada persyaratan yang lebih rendah?' sangat sederhana - persyaratan terperinci yang ortogonal dengan kebutuhan pengguna akhir (mis. kendala DB, validasi bidang, dll) sebenarnya tidak penting bagi pengguna. Jika kebutuhan pengguna dapat dipenuhi oleh validasi bidang yang sangat berbeda, struktur DB sangat berbeda atau bahkan mungkin tidak ada DB tradisional sama sekali, maka akan kontraproduktif jika pengguna membuat informasi seperti itu dengan implementasi tertentu dalam pikiran, yang mungkin sangat berbeda dengan bagaimana sistem diimplementasikan pada akhirnya.

Anda adalah pengembang profesional, jadi buat keputusan profesional sejauh kemampuan Anda tentang detail implementasi. Seorang pengguna yang menginginkan sebuah meja dapat memberi tahu seorang tukang kayu jenis kayu apa yang mereka inginkan, tetapi si tukang kayu diharapkan memutuskan seberapa tebal kaki-kaki meja itu untuk menangani beban yang masuk akal. Jika Anda kekurangan informasi untuk membuat keputusan yang berarti, maka itu perlu didiskusikan dengan pengguna, tetapi sekitar 90% konten untuk dokumen persyaratan terperinci sebenarnya tidak memerlukan informasi apa pun selain dari kisah-kisah pengguna yang tidak jelas akal sehat dan praktik terbaik industri .

Semua perincian itu tidak sewenang-wenang - ada pilihan yang buruk dan pilihan yang lebih baik, dan mereka harus didokumentasikan karena mempengaruhi bagian lain dari implementasi, tetapi pada akhirnya mereka masih detail implementasi yang dapat dan harus diputuskan oleh tim pelaksana sesuai untuk kebutuhan pengguna dan praktik terbaik.

Analogi mobil standar - jika pelanggan menginginkan mobil dicat merah, maka klarifikasi yang sesuai untuk kisah pengguna adalah menanyakan warna merah mana yang lebih baik, tetapi bukan komposisi kimia cat; namun diharapkan mereka tidak akan memilih untuk mengecat mobil dengan cat air yang akan luntur saat hujan, karena itu praktik terbaik untuk tidak melakukannya.

— Peter adalah
sumber

1

TL; DR

Kisah pengguna adalah untuk mendokumentasikan nilai apa yang harus ditambahkan ke produk, dan mengapa. Detail implementasi (misalnya bagaimana nilai harus ditambahkan, diuji, diukur, atau divalidasi) dibatasi oleh cerita, tetapi tidak terkandung di dalamnya. Mereka sengaja dibiarkan sebagai artefak terpisah untuk mempertahankan fleksibilitas dan kelincahan dalam kerangka kerja.

Spesifikasi dan perincian implementasi paling sering ditangkap dalam artefak lain seperti Pengembangan Penerimaan-Didorong Tes (ATDD), Pengembangan Didorong Uji (TDD), dan skrip dan skenario Pengembangan Perilaku Berbasis Driven (BDD). Artefak khusus ini tidak diamanatkan oleh kerangka kerja Scrum, tetapi mereka pasti akan memberi Anda titik awal yang baik jika Anda belum memiliki kontrol proses efektif lainnya.

Cerita Pengguna Bukan Spesifikasi

Poster asli (OP) menanyakan pertanyaan berikut :

[A] pelanggan menginginkan pemrosesan berbeda untuk kartu kredit yang berbeda, ada persyaratan ketat yang harus diterapkan dan diketahui sehingga kasus uji dapat ditulis ... DI MANA SAYA HARUS MEMASANG JIKA TIDAK DALAM KISAH?

Kisah pengguna adalah fitur yang memberikan nilai , menyediakan beberapa konteks untuk memandu percakapan tentang implementasi, dan sudut pandang yang terkait dengan konsumen nilai yang akan mendapat manfaat dari nilai yang disampaikan oleh fitur.

Seluruh titik dari cerita pengguna adalah bahwa rincian pelaksanaan tidak preskriptif. Tim bebas untuk mengimplementasikan fitur dengan cara apa pun yang memberikan nilai yang diidentifikasi kepada konsumen nilai dalam konteks yang sesuai.

Contoh yang Dikerjakan

Contoh Kisah Pengguna

Ini lebih mudah untuk dijelaskan jika Anda mulai dengan serangkaian cerita pengguna yang kurang ambigu. Karena OP tidak memberikan kisah pengguna yang dapat ditindaklanjuti yang mengikuti mnemonik INVEST , saya akan menciptakan satu demi contoh. Pertimbangkan kisah berikut:

Sebagai pengguna yang lebih suka membayar dengan kartu Discover,
saya ingin opsi untuk melakukan pembelian saya dengan kartu Discover
sehingga saya tidak terbatas pada Visa, Mastercard, atau American Express.

Ini menyediakan fitur konkret, menyediakan beberapa konteks yang dapat memandu keputusan implementasi yang harus dibuat oleh tim, dan mengidentifikasi konsumen nilai sebagai pelanggan pemilik kartu Discover. Itu bukan seperangkat spesifikasi, tapi itu yang Anda butuhkan untuk memiliki percakapan yang tepat dengan pelanggan dan dengan tim tentang cara terbaik untuk mengimplementasikan cerita selama iterasi pembangunan.

Analisis dan Implementasi

Implementasi aktual tergantung pada tim. Tim harus melakukan beberapa analisis untuk menentukan:

Cara termudah untuk mengimplementasikan fitur baru.
Manakah dari berbagai opsi implementasi yang akan paling mudah untuk mendukung ke depan, tanpa menimbulkan hutang teknis.
Cara menerapkan prinsip terbuka-tertutup dan YAGNI untuk memastikan bahwa fitur baru Anda kuat tanpa direkayasa berlebihan.

Salah satu prinsip inti dari Agile Manifesto adalah kolaborasi pelanggan. Tim lintas-fungsi, pengorganisasian diri diharapkan dapat berkolaborasi dengan pelanggan untuk mengerjakan rincian implementasi dalam pedoman yang disediakan oleh kisah pengguna.

Jika cerita pengguna Anda tidak ditulis dengan baik, atau jika tim tidak memiliki keterampilan atau kematangan proses untuk melakukan analisis yang cukup yang diperlukan oleh kerangka kerja tangkas mereka, maka ini jelas akan jauh lebih sulit daripada yang seharusnya. Seluruh buku telah ditulis tentang bagaimana membuat cerita pengguna yang baik pada tingkat rincian yang tepat; sayangnya tidak ada peluru perak, tetapi itu adalah keterampilan yang bisa dipelajari untuk tim tangkas.

Desain yang Didorong oleh Tes dan Perilaku-Didorong

Cara terbaik untuk memastikan bahwa analisisnya masuk akal, dan bahwa implementasinya baik dan mendukung adalah melalui penggunaan praktik TDD dan BDD. Misalnya, mengingat cerita di atas, tim harus menangkap implementasi yang direncanakan melalui artefak seperti:

Fitur mentimun dengan skenario yang dapat diuji.

Ini paling berguna untuk mendorong pengembangan tes penerimaan, dan untuk mendokumentasikan ekspektasi pengguna terhadap perilaku aplikasi. Misalnya, kisah pengguna harus memiliki satu atau lebih fitur Mentimun terkait yang menjelaskan bagaimana pengguna dapat memeriksa dengan kartu Discover, dan seperti apa proses itu bagi pengguna.
RSpec menguji yang memvalidasi perilaku (bukan detail implementasi internal) fitur kode baru.

Ini paling berguna untuk mendokumentasikan dan memvalidasi perilaku fitur yang dimaksud dalam aplikasi. Sebagai contoh, kisah pengguna akan mendorong pembuatan unit dan tes integrasi yang memastikan bahwa menggunakan kartu Discover memunculkan perilaku spesifik kartu apa pun yang diperlukan aplikasi untuk mengesahkan penjualan melalui gateway pembayaran.

Alat khusus tidak penting. Jika Anda tidak menyukai Mentimun atau RSpec, gunakan alat atau metodologi apa pun yang paling cocok untuk tim Anda. Namun, intinya adalah bahwa detail implementasi didasarkan pada kisah pengguna , tetapi tidak ditentukan olehnya . Sebaliknya, implementasi (atau spesifikasinya, jika Anda mau) adalah detail yang harus dikerjakan selama pengembangan fitur secara kolaboratif.

— CodeGnome
sumber

0

Banyak jawaban bagus di sini. Semoga saya bisa menambahkan beberapa nilai dengan yang lain ...

Saya pikir salah satu hang up tim Anda mungkin bermigrasi dari metodologi non-Agile.

Itu biasanya beberapa bentuk metodologi air terjun dan, dalam praktiknya, yang biasanya melibatkan upaya mendokumentasikan semua persyaratan teknis sebelum garis kode ditulis.

Tapi itu tidak selalu berhasil. Seringkali itu tidak berhasil. Alasannya? Karena persyaratan jarang selaras dengan kenyataan. Banyak hal berubah. Oleh karena itu pindah ke Agile.

Dengan Agile, Kisah Pengguna adalah hal yang paling diperhatikan pengguna. Mereka ingin mendapatkan formulir titik A ke titik B. Cara menuju ke sana dalam hal implementasi ada di tangan Anda. Jika Anda sedang menunggu seseorang memberi tahu Anda persyaratan teknis, maka itu tidak benar-benar Agile. Jika Anda memiliki pertanyaan, tanyakan. Jika Anda membutuhkan dokumentasi, dokumentasikan, tetapi Anda tidak ingin pelanggan membuat semua keputusan ini untuk Anda. Mereka mungkin memiliki pendapat, tetapi dalam lingkungan Agile pendapat itu harus (seperti yang disarankan oleh guru Anda) dalam percakapan.

Mungkin terasa bahwa ini adalah beban bagi tim Anda, tetapi menganggapnya sebagai barang mewah. Tim Anda sekarang memiliki banyak suara dalam solusi - yang belum tentu terjadi dalam model air terjun.

— DA01
sumber