Yang harus dilakukan terlebih dahulu: menggunakan kasus atau cerita pengguna?

Saya telah mendengar tentang kasus penggunaan (saya berbicara tentang deskripsi, bukan diagram) dan kisah pengguna yang digunakan untuk mengumpulkan persyaratan dan mengaturnya dengan lebih baik.

Saya bekerja sendiri, jadi saya hanya mencoba menemukan cara terbaik untuk mengatur persyaratan, untuk memahami apa yang harus dilakukan dalam pengembangan. Saya tidak punya, atau perlu, metodologi formal dengan dokumen besar dan sebagainya.

Kisah-kisah pengguna Saya sepertinya terbiasa membangun tumpukan produk, yang berisi semua yang perlu dilakukan dalam pengembangan.

Case use, di sisi lain, memberikan deskripsi tentang bagaimana hal-hal dilakukan dalam sistem, aliran interaksi antara aktor eksternal dan sistem.

Bagi saya, untuk satu kasus penggunaan ada beberapa cerita pengguna.

Ini mengarahkan saya ke pertanyaan berikut: ketika menemukan persyaratan, apa yang harus saya lakukan pertama kali? Temukan dan tulis cerita pengguna atau temukan dan tulis kasus penggunaan? Atau mereka harus dilakukan "pada saat yang sama" entah bagaimana?

Sebenarnya saya agak bingung. Mengenai kasus penggunaan dan kisah pengguna, untuk pengembang yang bekerja sendiri, apa alur kerja yang baik, untuk menggunakan metodologi ini dengan benar agar memiliki pengembangan yang lebih baik?

Kasus penggunaan dan kisah pengguna adalah alat untuk mengumpulkan dan mengekspresikan persyaratan.
Seperti yang sudah Anda temukan, kasus penggunaan tunggal biasanya memiliki cakupan yang lebih luas daripada cerita pengguna tunggal karena mencoba menjelaskan interaksi pengguna sepenuhnya termasuk kesalahan dan penyimpangan dari jalur normal. Kisah pengguna dapat secara kasar dibandingkan dengan satu aliran melalui use case.

Seperti halnya semua alat, terserah Anda untuk menggunakan alat yang menurut Anda diperlukan dalam situasi tertentu. Ini berarti bahwa Anda dapat menggunakan hanya kasus penggunaan, hanya cerita pengguna atau kombinasi kasus penggunaan dan cerita pengguna sesuai keinginan Anda.

Semakin umum untuk menggunakan cerita pengguna sebagai unit kerja dari apa yang dapat dikembangkan dan disampaikan dalam satu iterasi / sprint.
Dengan pemikiran itu, saya tidak akan terlalu fokus mengumpulkan persyaratan sebagai kasus penggunaan, kecuali jika kasus penggunaan datang secara alami ketika berbicara dengan para pemangku kepentingan.

Dalam kasus saya, saya selalu menemukan bahwa tingkat detail yang diperlukan untuk kasus penggunaan penuh terjadi dengan memikirkan cerita pengguna saya terlebih dahulu. Pertanyaan pertama yang saya tanyakan adalah "apa yang harus dilakukan orang?". Setelah saya memiliki skenario, maka lebih mudah untuk mulai menelusuri semua kasus penggunaan dan varian aliran untuk sistem.

Yang sedang berkata, untuk pengembang tunggal yang bekerja sendiri, Anda tidak benar-benar perlu peduli apakah itu kasus penggunaan atau cerita pengguna atau lengket di dinding yang mengatakan "jangan lupa tentang 'x'". Yang Anda butuhkan adalah proses apa pun yang membuat Anda berpikir tentang apa yang ingin dicapai oleh pengguna Anda dan membantu Anda melacak berbagai hal yang harus mereka lakukan. Segala sesuatu yang lain terserah Anda hingga tingkat detail yang perlu Anda tulis untuk merencanakan pengembangan Anda.

Misalnya, ketika saya mengerjakan proyek sampingan solo, tugas pekerjaan saya terlihat seperti ini:

1. Gabung
2. Lihat daftar 'foo'
3. Simpan pilihan dari daftar
4. Cari

Sejujurnya, masing-masing dari mereka tidak akan memiliki apa-apa selain perkiraan. Mengapa? Karena saya hanya menggunakan mereka sebagai pengingat apa yang harus saya lakukan agar pengguna dapat melakukannya dan saya akan mencari tahu detailnya ketika saya berkeliling ke bagian itu. Dengan tim yang terdiri dari satu orang, semuanya dapat berada di kepala Anda dan tidak apa-apa, karena Anda tidak perlu berkomunikasi dengan orang lain.

Sekarang, ada peringatan ...

Pengembang tunggal bekerja dengan spesialis lain

Apakah Anda perlu melaporkan kemajuan ke tim lain? Apakah Anda memiliki penguji yang perlu memvalidasi pekerjaan Anda? Apakah Anda memiliki manajemen yang ingin tahu apa yang telah Anda lakukan? Apakah Anda memiliki manajer proyek yang perlu memprediksi garis waktu? Apakah Anda memiliki pemilik produk yang menentukan fitur yang diperlukan?

Jika orang-orang ini adalah bagian dari proyek Anda, maka Anda perlu memastikan tugas pekerjaan Anda memiliki cukup banyak informasi tentang mereka untuk memungkinkan mereka melakukan pekerjaan mereka. PM mungkin perlu cara melihat ukuran relatif dari hal-hal dan kemajuan melalui pekerjaan itu. Penguji Anda akan membutuhkan perincian tentang bagaimana hal-hal diharapkan mengalir (menggunakan kasing) dan Anda bahkan dapat meminta mereka untuk membantu Anda menulisnya. Manajemen mungkin ingin tahu apa yang sedang Anda kerjakan, sehingga Anda akan memerlukan deskripsi bisnis yang cukup sehingga mereka dapat memahami fitur yang akan Anda sampaikan.

Jika Anda menjawab 'ya' untuk semua pertanyaan itu, Anda mungkin perlu memiliki jaminan simpanan yang lebih terdokumentasi karena Anda akan menggunakannya untuk berkomunikasi dengan anggota tim Anda yang lain.

• Anda mungkin perlu memiliki konsep 'Epik' atau 'Fitur' yang akan menjadi fungsionalitas tingkat tinggi yang dapat Anda gunakan untuk melaporkan kepada manajemen atau pemilik produk Anda.
• Anda akan memiliki Cerita Pengguna bersarang di dalam Epos / Fitur yang akan menentukan blok fungsionalitas yang lebih kecil yang akan digunakan untuk mengkomunikasikan kemajuan dengan manajer proyek Anda, mendefinisikan tugas pekerjaan Anda dalam sprint, dan akan digunakan untuk mengomunikasikan tujuan bisnis ke tim uji.
• Anda akan menggunakan kasing atau kasing uji untuk cerita untuk menangkap berbagai keputusan aliran tingkat rendah yang diperlukan untuk memastikan bahwa Anda, bisnis, dan tim pengujian disejajarkan dan tahu apa yang akan diterima sebagai 'benar'.

Semua hal di atas hanya dapat diabaikan jika Anda yang mendefinisikan pekerjaan, mengelola kemajuan, menguji perangkat lunak, dan memutuskan apakah ada sesuatu yang 'benar'. Hentikan upaya ekstra dan pastikan Anda melakukan apa yang penting: membangun perangkat lunak yang berfungsi!

Jika Anda melakukan beberapa jenis lincah, jawaban dogmatisnya adalah, Lakukan apa yang berhasil untuk Anda.

Proses harus menjadi bagian dari retrospektif Anda. Anda harus berbicara tentang kemacetan, redundansi, masalah komunikasi, dokumen yang tidak pernah dibaca, dll. Dan, itulah pengaturan di mana perubahan proses harus disetujui dan idealnya digerakkan.

Dalam pengalaman saya, Manajer Proyek, Analis, dan "orang bisnis" dilatih untuk melakukan proses "luar-dalam." Mereka mengumpulkan persyaratan, yang sering diberikan secara lisan oleh para pemangku kepentingan dalam bentuk cerita pengguna. Mereka mengajukan pertanyaan untuk diklarifikasi, sehingga mereka dapat membuat dokumen "use case" yang terperinci, yang tim pengembang coba terjemahkan kembali ke dalam cerita pengguna yang dapat mereka ulangi di ...

Rekomendasi saya, berdasarkan pengalaman saya sendiri: Cobalah untuk memasukkan tim atau analis Anda atau siapa pun untuk memasukkan cerita pengguna ke dalam simpanan, dengan detail minimal. Sertakan informasi prioritas dan jelaskan "masalah" yang ingin dipecahkan oleh cerita. Mungkin daftar beberapa solusi potensial ... tetapi, lebih dari itu, biarkan "kasus penggunaan" muncul sebagai pengembang Anda beralih dengan QA dan / atau pemangku kepentingan pada cerita.

Catat kasus penggunaan yang Anda gunakan dalam dokumentasi Anda saat cerita terselesaikan, dalam format apa pun yang membantu orang memahami sistem.

Cerita pengguna dan kasus penggunaan tidak saling eksklusif dan tidak ada "harus" .

Mereka hanyalah alat yang mungkin atau mungkin tidak membantu untuk meningkatkan proses Anda ke beberapa titik. Ada banyak cara yang mungkin, saya hanya akan mengusulkan satu dengan kasus penggunaan dan cerita yang digunakan bersama:

• Untuk backlog dan perencanaan, coba kisah pengguna sebagai placeholder fitur tingkat tinggi. (Tentu saja menggunakan case hingga level tujuan pengguna juga dapat membantu.)
• Untuk mendokumentasikan persyaratan yang sudah diterapkan, penggunaan case akan berfungsi sebagai yang terbaik.

Itu tergantung . Jika Anda bekerja sendirian, cobalah pendekatan yang berbeda dan lakukan yang terbaik untuk Anda.

Penafian: Ada banyak metodologi cara menulisnya. "Cerita pengguna" memiliki definisi yang sangat umum sedangkan "Use cases" dapat memiliki arti yang sangat berbeda. Saya merujuk pada diagram UML klasik, yang sangat umum.

Kisah pengguna atau Use case

Dalam pengalaman saya, ada berbagai pola pikir di mana cara yang lebih baik untuk dipahami. Jadi saya akan memutuskan pada setiap tim proyek baru, bagaimana mendokumentasikan persyaratan. Biasanya kombinasi adalah umum, menggunakan Use cases untuk ikhtisar dan cerita pengguna untuk detail.

• Gunakan kasing , terutama sebagai diagram, lebih cocok untuk orang yang berpikir secara visual
• Cerita pengguna lebih disukai oleh orang yang berpikir dalam diskusi yang sangat banyak bicara

(ini berdasarkan pendapat, tanpa dasar ilmiah)

Apa yang harus dilakukan pertama kali?

Saat menulis persyaratan untuk sebuah proyek, saya akan mulai pada tingkat yang sangat abstrak. Menggunakan use case, Anda akan melukis diagram (UML-) dengan tujuan global proyek. Dengan cerita pengguna, tulis beberapa "cerita epik" yang menggambarkan tujuan utama.

Langkah kedua adalah masuk ke detail. Dengan melakukan ini, Anda harus mencoba menyimpan referensi ke "cerita epik" atau tujuan global. Ini banyak membantu menyusun persyaratan.

Saya akan melihatnya sebaliknya: Apa yang perlu datang terakhir?

Langkah terakhir adalah Anda (atau orang lain) memasukkan persyaratan ke dalam simpanan Anda. Persyaratan harus sedemikian rupa sehingga Anda tahu bagaimana kode yang Anda tulis harus berperilaku, dan agar penguji dapat memverifikasi bahwa kode Anda berperilaku seperti seharusnya.

Persyaratan ini dapat direkam dengan sangat baik dalam bentuk kisah pengguna yang terdefinisi dengan baik. Jadi kisah pengguna bisa menjadi langkah terakhir. Kasus penggunaan biasanya akan berubah menjadi lebih dari satu cerita pengguna, jadi mereka harus datang sebelum cerita pengguna.

Dulu saya berpikir Use Case dimaksudkan untuk pendekatan air terjun, sementara User Stories datang dengan proses Agile. Butuh beberapa saat untuk menyadari bahwa mereka tidak eksklusif.

Karena Anda tidak perlu membagikan ini, itu bukan tentang komunikasi, kecuali dengan diri Anda sendiri. Selama Anda dapat memahami catatan Anda seminggu kemudian, Anda baik-baik saja. Jika tidak, tambahkan lebih detail ketika Anda perhatikan persyaratannya.

Apakah Anda memerlukan cara visual dan fleksibel untuk mengikuti kemajuan Anda dan menetapkan prioritas? Jika demikian, Cerita Pengguna akan berguna, bersama dengan papan progres yang akan Anda temukan di sebagian besar metodologi tangkas (todo, done, sprint saat ini).

Ketika datang ke persyaratan murni, mengetahui apa yang perlu dipecahkan dan bagaimana, saya sarankan memulai dengan User Stories karena mudah dibuat (satu kalimat), atau Diagram Kasus Penggunaan yang mencantumkan hanya aktor dan tindakan tingkat tinggi.

Saat detail dibutuhkan, telusuri lebih banyak dengan Kisah Pengguna. Ketika Anda menjumpai proses yang kompleks (bercabang, banyak persyaratan dan prasyarat), Anda dapat MENGaitkan Cerita Pengguna ke Case Use, baik Anda menggunakan diagram atau versi templat teks. Dan ingatlah bahwa bahkan itu dapat dibuat dengan berbagai tingkat detail. The Persyaratan Software buku oleh Karl Wiegers & Joy Beatty merekomendasikan menjaga hanya tingkat detail yang diperlukan untuk memahami. Jika ada sesuatu yang sangat jelas bagi Anda, Anda tidak perlu menelusuri.

Di atas adalah apa yang saya pribadi tidak dapatkan pada awalnya: Cerita Pengguna adalah titik awal, "ringkasan", tetapi masing-masing dapat dilengkapi dengan dokumen tambahan untuk lebih menentukan apa yang dimaksud dan dibutuhkan, termasuk Kasus Penggunaan rinci bila diperlukan.