Googling di web, Agile Sage menganggap kasus penggunaan dan cerita pengguna adalah dua hal yang berbeda:

• Mike Cohn:  Kisah pengguna bukanlah kasus penggunaan
• Alistair Cockburn:  Kisah pengguna untuk use case seperti gazebo untuk gazebo
• Extreme Programming.org:  Cerita pengguna memiliki tujuan yang sama seperti kasus penggunaan tetapi tidak sama.

Pendekatan use case driven adalah salah satu teknik terpanas untuk menangkap kebutuhan dan beberapa orang sekarang menganggapnya sebagai teknik gaya lama yang sudah ketinggalan zaman yang terkait dengan banyak masalah yang menyebabkan tim Anda TIDAK “Agile” karena masalah use case :

• Persyaratan di muka – mencoba mendefinisikan detail semua aspek di muka akan menghasilkan banyak usaha dan waktu yang terbuang sia-sia karena banyak pekerjaan yang perlu dilakukan ulang.
• Dekomposisi Fungsional: Sifat fungsional dari use case secara alami mengarah pada dekomposisi fungsional sistem dalam hal use case konkret dan abstrak yang terkait dengan perluasan dan termasuk asosiasi use case.

Jika Anda mencari di Web dengan kata kunci “use case vs user story”, Anda akan menemukan daftar panjang artikel yang menyarankan tentang kekurangan, masalah, atau jebakan dari pendekatan use case, sementara ada daftar manfaat yang lebih panjang yang terkait dengan cerita pengguna. . Menarik, banyak hal berubah begitu cepat di industri TI, dan bahkan lebih cepat bagi orang-orang yang beralih dari hal-hal yang dulu “trendi” ke hal-hal yang “trendi baru” sekarang.

Menariknya, beberapa orang suka melihat hal-hal dalam pola biner dan mengejar hal-hal trendi dengan mengaitkannya secara simbolis daripada benar-benar mempraktikkannya dengan sungguh-sungguh. Beberapa orang bahkan tidak ingin memberi tahu orang lain bahwa mereka masih menggunakan kasus penggunaan, atau mungkin dianggap ketinggalan zaman dan gaya lama.

Sekarang beberapa orang memberi tanda sama dengan yang terkait dengan cerita pengguna dan kasus pengguna:

• Agile = cerita pengguna atau Agile = cerita pengguna + Scrum
• Kisah pengguna = cukup & tepat waktu
• Kisah pengguna = memenuhi harapan & memuaskan pengguna
• Kasus Penggunaan = Pengambilan persyaratan terperinci di muka
• Use case = <<include>> + <<extends>> = dekomposisi fungsional
• Use case adalah “input pengguna” -> hanya gaya “respons sistem”
• Use case = gaya lama & ketinggalan jaman

Sebagai vendor alat, kami cukup netral dalam metode, alat, dan teknik. Secara pribadi, saya ingin menekankan dengan jelas bahwa saya adalah penggemar berat pengembangan Agile, kisah pengguna, dan proses scrum. Khususnya, prinsip-prinsip yang digarisbawahi dan praktik terbaik yang terkait dengan konsep-konsep seperti:

 

• Penemuan kebutuhan daripada pengiriman kebutuhan
• Berdasarkan prinsip di atas yang menghasilkan dua sifat penting dalam proses pengembangan Agile
  • Tepat waktu
  • Cukup

(Saya akan menulis lebih banyak posting terkait prinsip-prinsip di atas dengan pendapat saya sendiri, yang terkait erat dengan bidang penelitian PhD saya pada tahun 1992-1995 – metamodel & transformasi skema)

Sekarang, mari kembali ke topik “use case vs user story”. Nah, Agile Sages yang berat sudah memberikan suara untuk itu, apakah saya begitu keras kepala mencoba untuk membatalkan “suara mereka dengan mengatakan bahwa mereka serupa atau bahkan sama?

Mari saya tunjukkan sebuah contoh untuk menggambarkan apakah cerita pengguna “sangat berbeda” dari kasus pengguna:

Contoh

Cerita pengguna yang baik lebih dari sekadar pernyataan. Sebuah cerita pengguna standar terdiri dari tiga bagian, biasanya disebut sebagai tiga C.

“C” pertama dari setiap cerita pengguna harus mengikuti format standar:

Sebagai [peran], saya ingin [melakukan sesuatu], sehingga [manfaat]

yang merupakan konten minimal dari cerita pengguna untuk dimasukkan ke dalam kartu.

Percakapan adalah isi dari “C” kedua dari cerita pengguna yang mewakili diskusi antara pengguna akhir, pemilik proyek, dan tim pengembangan. Dalam konversi ini, merekam diskusi verbal, atau banyak informasi berguna lainnya seperti, email, gambar rangka atau konten terkait lainnya untuk proyek.

“C” terakhir dari cerita pengguna adalah konfirmasi yang merupakan kriteria penerimaan yang digunakan untuk mengonfirmasi bahwa cerita pengguna diimplementasikan telah diperbaiki dan berhasil dikirimkan.

Biarkan saya menguraikan sedikit lebih jauh tentang bagaimana mengembangkan bagian konfirmasi dari cerita pengguna. Di sini kami menggunakan template paling terkenal yang disebut Gherkin yang mengadopsi formula Diberikan-Kapan-Lalu untuk memandu penulisan tes penerimaan untuk Kisah Pengguna:

• (Mengingat.. dan) beberapa konteks
• (Ketika .. dan) beberapa tindakan dilakukan
• (Lalu .. dan) Lakukan beberapa tindakan

Alat-alat seperti, kerangka kerja pengujian Mentimun dan Jbehave mendorong penggunaan template Diberikan/Kapan/Kemudian untuk melakukan pengujian otomatis, meskipun itu juga dapat digunakan murni sebagai heuristik terlepas dari apakah alat akan digunakan.

Mari kumpulkan semua informasi untuk cerita pengguna “daftar kursus” dan masukkan ke dalam format 3C:

Saya mengadopsi format 3 Cs yang umum digunakan untuk mewakili kisah pengguna “daftar kursus”. Demikian juga, saya juga mengadopsi format yang paling banyak digunakan untuk mendeskripsikan use case “register course” yang sama yang diuraikan oleh deskripsi use case. Saya memberi nomor langkah-langkah bagian konfirmasi (C terakhir) dari cerita pengguna yang terkait dengan nomor langkah yang saya masukkan ke dalam deskripsi kasus penggunaan. Mereka adalah “sembilan langkah” yang sama dari skenario untuk ditempatkan di setiap pendekatan dengan urutan yang berbeda. Saya percaya kedua model representasi dapat diterima untuk orang bijak dan pengikut yang sesuai. Lalu pertanyaannya lagi, apakah user story sangat mirip dengan user case namun berbeda atau urutan langkah-langkahnya yang menimbulkan berbagai kritik terhadap pendekatan use case?

Semantik Setara dengan Arti Berbeda?

Mari kita selidiki apakah ada kasus serupa di domain pemodelan, sehingga dibandingkan dengan situasi di sini, atau mungkin membantu kita untuk memberikan suara kita sendiri pada “cerita pengguna vs kasus penggunaan”, tetapi tidak mengikuti orang banyak secara membabi buta atau mengulangi apa yang orang bijak berkata seperti pembicaraan burung beo.

Contoh: Semantik Setara

Dalam UML kita dapat menggambarkan skenario use case dengan sequence diagram, tetapi kita biasanya tidak menggunakan diagram kolaborasi untuk tujuan yang sama; bahkan melalui kedua diagram secara semantik setara. Dengan kata lain, diagram urutan dan diagram kolaborasi memiliki jumlah objek yang sama yang berpartisipasi dalam sebuah skenario dengan jumlah pesan yang sama melewati kumpulan objek yang sama untuk melakukan tugas skenario. Namun, yang pertama adalah fokus waktu dan yang terakhir adalah fokus ruang. Sequence diagram lebih intuitif jika digunakan dengan pemodelan skenario, sedangkan diagram kolaborasi cocok untuk memodelkan hubungan struktural antar objek. yaitu Anda ingin mewakili skenario objek yang berpartisipasi secara struktural ke dalam kerangka kerja MVC (lapisan model/tampilan dan kontrol).

Secara pribadi, saya tidak berpikir menggunakan cerita pengguna akan membuat tim saya menjadi lincah, dan kasus penggunaan akan menyebabkan tim saya menjadi “muka”. Yang paling penting adalah bagaimana kita menerapkan dan menggunakan alat-alat itu dengan pola pikir dan praktik terbaik seperti apa di baliknya. Saya tidak terlalu khawatir tentang orang-orang yang menganggap saya “gaya lama” atau ketinggalan zaman ketika saya benar-benar bertindak gesit.

Saya masih ingat di hari-hari analisis dan desain terstruktur, mungkin kita dapat menggunakan Tipe Data Abstrak di ADA untuk menerapkan prinsip-prinsip analisis dan desain berorientasi objek tanpa dukungan OOP di 198x, bukan? Sayangnya, Anda mungkin tidak menemukan konsep Tipe Data Abstrak sama sekali! Oh! Ya Tuhan, saya tidak sengaja mengungkapkan – saya sudah tua? Atau, saya harus berpikir positif – berpengalaman?

Bagaimana menurutmu? Apa suara Anda tentang ini? Beri tahu saya atau koreksi saya jika saya salah.