Apakah User Story Kompatibel dengan use case?

Mencari di seluruh web, para Pandita Agile menganggap use case dan user story adalah dua hal yang berbeda:

• Mike Cohn:User story bukan use case
• Alistair Cockburn:Sebuah user story adalah seperti seekor gazelle terhadap gazebo
• Extreme Programming.org:User story memenuhi tujuan yang sama dengan use case tetapi tidak sama.

Pendekatan berbasis use case adalah salah satu teknik paling populer untuk mengumpulkan kebutuhan, dan beberapa orang kini menganggapnya sebagai teknik yang sudah ketinggalan zaman dan kuno, yang dikaitkan dengan banyak masalah yang menyebabkan tim Anda TIDAK “Agile” karena masalah-masalah yang muncul dari use case:

• Kebutuhan awal – mencoba mendefinisikan detail semua aspek awal akan menghasilkan banyak usaha dan waktu yang terbuang karena sebagian besar pekerjaan harus dikerjakan ulang.
• Dekomposisi Fungsional: Sifat fungsional dari use case secara alami mengarah pada dekomposisi fungsional suatu sistem berdasarkan use case konkret dan abstrak yang saling terkait melalui asosiasi extends dan include use case.

Jika Anda mencari di web dengan kata kunci ‘use case vs user story’, Anda akan menemukan daftar panjang artikel yang menyebutkan kekurangan, masalah, atau jebakan dari pendekatan use case, sementara daftar manfaat yang terkait dengan user story bahkan lebih panjang. Menarik, dunia teknologi informasi berubah sangat cepat, dan bahkan lebih cepat bagi orang-orang yang beralih dari hal-hal yang dulu dianggap ‘tren’ ke hal-hal ‘tren’ terbaru saat ini.

Menariknya, beberapa orang suka memandang hal-hal dalam pola biner dan mengejar hal-hal yang sedang tren dengan mengaitkannya secara simbolis daripada benar-benar menerapkannya secara tulus. Beberapa orang bahkan tidak ingin orang lain tahu bahwa mereka masih menggunakan use case, karena mereka mungkin dianggap ketinggalan zaman dan kuno.

Sekarang beberapa orang menempatkan tanda sama dengan terkait dengan user story dan use case:

• Agile = user story atau Agile = user story + Scrum
• User story = cukup saja & tepat waktu
• User story = memenuhi ekspektasi pengguna & memuaskan
• Use Case = pengumpulan kebutuhan rinci di awal
• Use case = <<include>> + <<extends>> = dekomposisi fungsional
• Use case adalah gaya hanya ‘input pengguna’ -> ‘respon sistem’
• Use case = gaya lama & ketinggalan zaman

Sebagai penyedia alat, kami cukup netral terhadap metode, alat, dan teknik. Secara pribadi, saya ingin menekankan dengan jelas bahwa saya sangat mengagumi pengembangan Agile, user story, dan proses scrum. Terutama prinsip-prinsip dasar dan praktik terbaik yang terkait dengan konsep-konsep seperti:

• Pencarian kebutuhan daripada pengiriman kebutuhan
• Di bawah prinsip di atas yang menghasilkan dua sifat penting dalam proses pengembangan Agile
  • Tepat waktu
  • Cukup saja

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

Sekarang, mari kita kembali ke topik ‘use case vs user story’. Nah, para Pandita Agile yang berpengaruh sudah memberikan suara untuk itu, apakah saya terlalu keras kepala mencoba membalikkan suara mereka dengan berargumen bahwa keduanya sama atau bahkan mirip?

Mari saya tunjukkan satu contoh untuk menggambarkan apakah user story benar-benar “sangat berbeda” dari use case:

Contoh

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

C pertama dari setiap cerita pengguna harus mengikuti format standar:

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

yang merupakan isi minimal dari cerita pengguna yang dimasukkan ke dalam kartu.

Perbincangan adalah isi dari C kedua dari cerita pengguna yang merepresentasikan diskusi antara pengguna akhir, pemilik proyek, dan tim pengembangan. Dalam perbincangan ini, dicatat diskusi lisan atau berbagai informasi berguna lainnya seperti email, wireframe, atau konten terkait lainnya untuk proyek.

C terakhir dari cerita pengguna adalah konfirmasi yang merupakan kriteria penerimaan yang digunakan untuk memastikan bahwa cerita pengguna telah diimplementasikan dengan benar dan berhasil dikirimkan.

Biarkan saya menjelaskan sedikit lebih lanjut tentang cara mengembangkan bagian konfirmasi dari cerita pengguna. Di sini kita menggunakan template yang paling terkenal bernama Gherkin yang mengadopsi rumus Given-When-Then untuk membimbing penulisan tes penerimaan untuk cerita pengguna:

• (Diberikan.. dan) beberapa konteks
• (Ketika.. dan) beberapa tindakan dilakukan
• (Kemudian.. dan) Lakukan beberapa tindakan

Alat seperti Cucumber dan kerangka pengujian Jbehave mendorong penggunaan template Given/When/Then untuk melakukan pengujian otomatis, meskipun juga dapat digunakan secara murni sebagai heuristik terlepas dari apakah alat akan digunakan atau tidak.

Mari kita kumpulkan semua informasi untuk cerita pengguna ‘daftar kursus’ dan letakkan dalam format 3C:

Saya mengadopsi format 3 C yang umum digunakan untuk merepresentasikan cerita pengguna ‘daftar kursus’. Demikian pula, saya juga mengadopsi format yang paling banyak digunakan untuk menggambarkan kasus penggunaan yang sama ‘daftar kursus’ yang dijelaskan dalam deskripsi kasus penggunaan. Saya memberi nomor pada langkah-langkah bagian konfirmasi (C terakhir) dari cerita pengguna yang terkait dengan nomor langkah yang saya letakkan dalam deskripsi kasus penggunaan. Mereka adalah ‘sembilan langkah’ yang sama dari skenario yang akan ditempatkan dalam masing-masing pendekatan dengan urutan yang berbeda. Saya percaya kedua representasi model ini dapat diterima oleh para tokoh dan pengikutnya masing-masing. Kemudian, pertanyaannya lagi, apakah cerita pengguna sangat mirip dengan kasus penggunaan namun tetap berbeda, atau apakah urutan langkah yang menyebabkan berbagai kritik terhadap pendekatan kasus penggunaan?

Setara Secara Semantik dengan Makna yang Berbeda?

Mari kita selidiki apakah ada kasus serupa dalam domain pemodelan, sehingga dapat dibandingkan dengan situasi di sini, atau mungkin membantu kita memberikan pendapat sendiri tentang ‘cerita pengguna vs kasus penggunaan’, bukan hanya mengikuti keramaian secara buta atau mengulang apa yang dikatakan para tokoh seperti burung beo.

Contoh: Setara Secara Semantik

Dalam UML kita dapat menggambarkan skenario kasus penggunaan dengan diagram urutan, tetapi biasanya kita tidak menggunakan diagram kolaborasi untuk tujuan yang sama; meskipun kedua diagram tersebut secara semantik setara. Dengan kata lain, baik diagram urutan maupun diagram kolaborasi memiliki jumlah objek yang berpartisipasi dalam suatu skenario dengan jumlah pesan yang sama yang beredar di sekitar kumpulan objek yang sama untuk melakukan tugas dalam skenario tersebut. Namun, yang pertama berfokus pada waktu, sedangkan yang kedua berfokus pada ruang. Diagram urutan lebih intuitif saat digunakan bersama pemodelan skenario, sedangkan diagram kolaborasi lebih tepat untuk memodelkan hubungan struktural antar objek. Misalnya, Anda ingin merepresentasikan skenario objek yang terlibat secara struktural ke dalam kerangka MVC (lapisan model/tampilan dan kontrol).

Secara pribadi, saya tidak berpikir menggunakan cerita pengguna akan membuat tim saya menjadi agile, dan kasus penggunaan akan membuat tim saya menjadi ‘terlalu maju’. Yang paling penting adalah bagaimana kita menerapkan dan menggunakan alat-alat tersebut dengan pemikiran dan praktik terbaik tertentu. Saya tidak terlalu khawatir jika orang menganggap saya ‘kuno’ atau ketinggalan zaman ketika sebenarnya saya bertindak secara agile.

Saya masih ingat pada masa analisis dan desain terstruktur, mungkin kita bisa menggunakan Tipe Data Abstrak dalam ADA untuk menerapkan prinsip analisis dan desain berorientasi objek tanpa dukungan OOP pada tahun 198x, benar kan? Sayangnya, Anda bahkan mungkin tidak pernah menemukan konsep Tipe Data Abstrak sama sekali! Oh! Tuhan, saya secara tidak sengaja mengungkapkan—saya sudah tua? Atau, sebaiknya saya berpikir positif—berpengalaman?