Gajah bukanlah jerapah, dan cerita pengguna bukanlah persyaratan. Mereka memiliki ciri-ciri umum dan konteks yang sama, tetapi ini tidak menyamakannya. Namun, banyak orang percaya bahwa cerita pengguna adalah semacam bacaan baru dari apa yang secara tradisional disebut persyaratan perangkat lunak - lagipula, pasti ada persyaratan pada suatu proyek, bukan? Jadi, saya akan menjawab - tidak, dan sekali lagi tidak . Pertama, ini bukan persyaratan, dan kedua, persyaratan bukanlah yang sebenarnya kita butuhkan. Kisah pengguna, pertama-tama, adalah kesempatan untuk melihat opsi penerapan yang berbeda, sehingga nantinya Anda dapat memanfaatkan peluang yang telah terbuka. Dan persyaratannya ... adalah menyelesaikan semuanya terlebih dahulu, sehingga nanti Anda akan macet di dalamnya.
Apakah ada gunanya menulis artikel seperti itu? Bukankah hal di atas tampak jelas? Tidak, saya percaya bahwa pernyataan yang sering muncul seperti "persyaratan dalam backlog" menandakan bahwa paradigma berpikir tetap sama, hanya tanda-tandanya telah berubah. Dokumen persyaratan mulai disebut backlog, persyaratan itu sendiri - cerita pengguna, dan sekarang kami "gesit" ...
Tanda lain dari kesalahpahaman yang mungkin terjadi adalah praktik luas penyimpanan cerita pengguna dalam database dengan penetapan ID unik. Mungkin saja hal ini dilakukan hanya demi kenyamanan, tetapi mungkin saja ini adalah akibat dari kecenderungan terus-menerus untuk berpikir dalam kerangka persyaratan.
Tetapi praktik memasukkan cerita pengguna ke dalam kontrak sudah menjadi tanda 100% bahwa cerita pengguna dianggap sebagai persyaratan. Masalahnya di sini adalah bahwa cerita pengguna, menurut definisi, tidak bisa sejelas persyaratan, dan ini merendahkan nilai kontrak. Tentu saja, persyaratan terkadang juga dapat diinterpretasikan dengan cukup bebas, tetapi teknik penulisannya pada awalnya menyiratkan penghapusan ambiguitas, yang tidak dapat dikatakan tentang cerita pengguna. Selain itu, persyaratan tahan terhadap perubahan karena termasuk dalam kontrak proyek. Untuk mengubah atau menambahkan persyaratan baru, persyaratan tersebut harus diteruskan melalui CCB . Dengan kata lain, pemangku kepentingan harus menyetujui dan menyetujui terlebih dahulu. Lihat di bawah untuk detail lebih lanjut tentang kontrak.
Jadi, apa cerita pengguna itu? Anggap mereka sebagai alat perencanaan. Dengan bantuan cerita pengguna, kami memprioritaskan, mengevaluasi, dan memutuskan di sprint mana fungsi yang sesuai akan diterapkan. Ini semua adalah fitur khas alat perencanaan, jadi jangan mencoba mengubahnya menjadi fitur lain.
Kekuatan cerita pengguna adalah memunculkan dialog. Alih-alih hanya mengambil dan meneruskan spesifikasi kepada rekan kerja yang diinterpretasikan terlebih dahulu oleh pengembang, kemudian oleh penguji, kami memulai diskusi. Kami menyertakan karyawan dengan keterampilan berbeda dalam komunikasi. Dan - untuk setiap fitur baru.
Karena cerita pengguna, dengan demikian, tidak memiliki banyak makna, kami dapat dengan mudah membuangnya setelah implementasi fungsi yang sesuai. Jika mau, Anda dapat menyimpan statistik dengan hati-hati tentang jumlah cerita yang terjual, tetapi ini sangat mungkin dan terbatas.
Ternyata kami tidak membutuhkan persyaratan? Nyatanya ini tidak benar. Bagaimanapun, dengan satu atau lain cara ada batasan. Misalnya, peralatan medis harus sesuai dengan peraturan FDA . Jadi mari kita sebut mereka kendala!
Namun, persyaratan menjelaskan Sistem secara rinci, mungkin ada beberapa nilai dalam deskripsi seperti itu bagi kita? Misalnya, bagaimana kita dapat menentukan apakah beberapa perilaku sistem adalah bug atau bukan, jika kita tidak memiliki persyaratan formal yang disajikan dalam satu bentuk atau lainnya? Teknik "Spesifikasi dengan Contoh" akan membantu kita di sini. Jadi diputuskan bahwa beberapa fungsi harus diterapkan. Anda menulis aturan bisnis dan serangkaian contoh sedemikian rupa sehingga: a) mudah dibaca; b) dapat diwujudkan. Dari uraian ini harus jelas apa yang harus dilakukan Sistem. Dan juga, jika terjadi kesalahan sebagai akibat dari perubahan - pelanggaran aturan bisnis mana yang menjadi penyebab disfungsi ini.
Seperti yang saya tulis sebelumnya, deskripsi bug harus sederhana dan jelas. Bug adalah hal-hal yang menghancurkan informasi, dan itu buruk terlepas dari apakah kita memiliki deskripsi persyaratan yang mencakup kasus tertentu atau tidak.
Kontrak
(oleh Matthias Skarin)
Jadi apa yang akan kita gunakan selain spesifikasi persyaratan? Bagaimanapun, kita perlu memahami apakah kita telah menerapkan dengan tepat apa yang dibutuhkan? Kami akan menggunakan kontrak tangkas. Agile - kontrak adalah kesempatan untuk melihat hutan untuk pepohonan, mereka memungkinkan Anda untuk fokus pada esensi proyek dan pencapaian bersama dari tujuan tersebut, yang implementasinya akan memenuhi kebutuhan pengguna.
Ingatlah, ketika Anda memikirkan tentang kontrak selama proyek untuk memeriksa apakah pasangan Anda telah melanggar sesuatu, ini berarti ada sesuatu yang tidak beres. Kontrak harus membangun kepercayaan di antara para pihak sehingga menjadi mungkin untuk melampaui rincian, dan tidak macet di dalamnya.
Ringkasan
- Terlepas dari kenyataan bahwa gajah dan jerapah memiliki empat kaki, mereka adalah hewan yang berbeda.
- Cerita pengguna bukanlah persyaratan, tetapi alat perencanaan.
- Hal terdekat dengan persyaratan adalah Spesifikasi dengan Contoh.