Bagaimana cara meyakinkan tim saya bahwa spesifikasi persyaratan tidak perlu jika kita mengadopsi cerita pengguna?

9

Kami berencana untuk mengadopsi cerita pengguna untuk menangkap 'niat' pemangku kepentingan dengan cara yang ringan daripada SRS berat (spesifikasi persyaratan perangkat lunak). Namun, meskipun mereka memahami nilai cerita, masih ada keinginan untuk 'mengubah' cerita menjadi bahasa seperti SRS dengan semua atribut, prioritas, input, output, sumber, tujuan dll.

Cerita-pengguna 'menghilangkan' kebutuhan akan SRS formal seperti artefak untuk memulainya jadi apa gunanya memiliki SRS? Bagaimana saya bisa meyakinkan tim saya (yang semuanya adalah orang-orang CS yang sangat berkualifikasi - baik karena pendidikan dan latihan) bahwa SRS akan 'dihilangkan' jika kami mengadopsi cerita pengguna untuk menangkap persyaratan fungsional sistem? (NFR dll dapat ditangkap juga, tapi itu bukan maksud pertanyaannya).

Jadi inilah argumen 'alur kerja' saya: Tangkap persyaratan awal sebagai cerita-pengguna dan kemudian uraikan untuk kasus-kasus penggunaan (yang harus didokumentasikan pada tingkat rendah yaitu menggambarkan interaksi dengan prototipe / maket UI dan merupakan pos yang dapat dikirim penyebaran). Jadi, beralih dari kisah pengguna ke kasus penggunaan alih-alih cerita pengguna ke SRS ke kasus penggunaan.

Bagaimana Anda semua saat ini menangkap cerita pengguna di tempat kerja Anda (jika ada) dan bagaimana Anda menyarankan saya 'membuat kasus' karena tidak ada SRS di hadapan cerita pengguna?

agile requirements user-story requirements-management PhD
sumber
itu tidak akan terjadi dalam sehari, ambil pendekatan mudah
Yusubov
Jika Anda bekerja untuk penyedia layanan perangkat lunak maka SRS mungkin tidak diperlukan untuk melakukan implementasi tetapi untuk melakukan "permainan menyalahkan" ketika pelanggan ingin mengurangi biaya atau argumen penyedia layanan bahwa lebih banyak uang diperlukan atau keduanya akan dibawa ke pengadilan.
k3b

Jawaban:

14

Langkah kecil. Lanjutkan menulis SRS sebentar. Kemudian panggil pertemuan dan diskusikan apakah mereka masih memiliki tujuan. Apakah masih ada yang membacanya? Apakah waktu yang dihabiskan untuk mereka dibenarkan? Apakah ada langkah perantara lain yang akan lebih ringan?

Anda tidak pernah tahu, Anda mungkin menemukan bahwa Anda salah. Ingat manifesto Agile, kami menemukan nilai lebih dalam "Bekerja perangkat lunak daripada dokumentasi yang komprehensif," tetapi masih ada nilai dalam yang terakhir.

Dugaan saya adalah bahwa Anda akan dengan cepat menemukan bahwa keinginan untuk terus menulis dokumen berat hilang ketika mereka melihat seberapa dekat penggunaan kasus dan kisah pengguna terkait.

pdr
sumber
2
@ PDF: Anda benar. Hampir primal. Dan itulah mengapa Anda tidak akan memenangkan pertempuran ini dengan logika apa pun, hanya dengan bukti. Langkah kecil.
pdr
2
Saya telah bekerja untuk para manajer yang menghadapi perubahan dengan langkah-langkah kecil itu adalah kata sandi mereka untuk "lakukan hanya cukup untuk gagal sehingga saya bisa mengatakan saya benar" ini bukan jalan menuju sukses karena ini menunjukkan kurangnya pemahaman mendasar tentang metodologi baru dan kurangnya dukungan penuh oleh manajemen yang penting untuk perubahan yang berhasil. Ini kedengarannya bagus secara teori, tetapi dalam praktiknya itu adalah alasan untuk tidak berubah dan mengklaim kemenangan bahwa cara baru tidak berhasil dan cara lama tidak. Dengan demikian SRS diperkuat dan cerita-cerita akan dilabeli sebagai pekerjaan ekstra dan Anda akan kembali ke tempat Anda berada.
2
Pengalaman saya tidak tunggal, itu lebih dari 22 tahun saya di industri ini, yang sebagian besar adalah konsultasi. Jadi saya telah bekerja dengan lebih banyak manajer dan pembuat keputusan daripada kebanyakan orang dalam jumlah waktu yang sama. Maksud saya adalah pendekatan langkah kecil ini adalah pendekatan kegagalan, hanya komitmen manajemen tingkat atas terhadap perubahan dan filosofi di balik perubahan yang akan mengarah pada implementasi yang sukses. Jika rekan-rekannya tidak yakin, membiarkan mereka terus melakukan apa yang mereka inginkan tidak akan meyakinkan mereka, itu hanya memberi makan kita masih membutuhkan cara lama dan cara baru membuang-buang waktu argumen.
1
@JarrodRoberson Saya hanya ingin menambahkan bahwa pengalaman saya lebih dekat mencerminkan pengalaman Anda. Ada dua jenis orang, dan dengan demikian dua jenis manajer, konservatif dan pengambil risiko. Konservatif secara alami menolak perubahan dan risiko. Ketika mereka menemukan model yang berfungsi, bahkan dengan buruk, mereka tetap menggunakannya. Ketika perubahan dipaksakan atau ditekan pada mereka, mereka secara tidak sadar menyabotnya dengan mencoba mengambil langkah kecil . Inilah sebabnya mengapa satu-satunya waktu saya pernah melihat pekerjaan adopsi Agile yang sebenarnya adalah ketika dipimpin oleh pengambil risiko.
maple_shaft
2
@maple_shaft: Caranya adalah dengan terus bergerak maju. Jika perubahan tambahan tidak berhasil, jangan lantas mengambil langkah yang sama kembali, pertimbangkan mengapa itu tidak berhasil ... seperti mungkin Anda masih menghabiskan terlalu banyak waktu, menulis dokumen yang sekarang tidak berguna. Sekarang saya akan mengakui bahwa dibutuhkan manajer yang baik untuk berpikir seperti itu, dan sebagian besar akan kembali ke zona nyaman mereka. Tapi, dengan alasan yang persis sama, itu tidak berarti bahwa satu-satunya pilihan lain adalah perubahan drastis. Manajer yang buruk akan mengacaukannya.
pdr
6

Epik adalah Placeholder

Dalam hampir semua metodologi Agile konsep Epics akan sebanyak yang Anda butuhkan untuk Spesifikasi Persyaratan, pemegang tempat adalah apa yang Anda butuhkan di tingkat itu. Entri-entri itu akan diprioritaskan terus-menerus, setiap detail lebih banyak merupakan usaha yang sia-sia jika persyaratannya mendapat prioritas rendah untuk waktu yang lama, atau bahkan tidak pernah diterapkan. Mendokumentasikannya dan mengelola dokumentasi di sekitarnya akan membuang-buang waktu. YAGNI mencakup kegiatan persyaratan serta kegiatan pengkodean.

Alat adalah teman Anda!

Jika Anda menggunakan alat yang tepat untuk mengumpulkan dan mengelola cerita pengguna, maka Anda dapat menghasilkan Spesifikasi Persyaratan dari mereka. Spesifikasi persyaratan adalah dokumen artefak temporal , itu bukan dokumen hidup, ini adalah snapshot dari persyaratan dalam waktu. Dan tidak pernah selaras dengan kenyataan.

Secara otomatis menghasilkan artefak

Cerita pengguna yang dapat diekspor dari alat yang tepat jauh lebih berharga daripada dokumen artefak statis kapan saja. Secara pribadi saya lebih suka Pelacak Penting untuk melacak Cerita Pengguna, saya bahkan menulis serangkaian plugin MoinMoin dengan Python untuk menerbitkan semua berbagai Cerita dan status mereka di Wiki (yang berisi catatan pengembang terperinci dan sejenisnya tentang cerita), data langsung selalu lebih baik daripada data statis.

Wiki menjadi dokumen langsung dari semua toko / persyaratan dan status penyelesaian serta prioritasnya dengan perincian dan komentar serta data meta lainnya.

Jauh lebih baik daripada dokumen Word yang sangat besar di Sharepoint yang baru saja diemailkan terus-menerus dan tidak pernah diperbarui, menjamin bahwa setiap orang memiliki versi yang berbeda dan tidak selaras dengan orang lain!

Kisah Pengguna Lebih Kaya daripada Kasus Penggunaan

The Use Story jauh lebih berharga daripada Use Case karena mereka mengatakan MENGAPA .

Format Kisah Pengguna: As a [ROLE] I [ACTIVITY] so that [WHY]jauh lebih ekspresif daripada Use Cases yang seperti The System [shall/shall not/may/must] perform [action](di mana tindakan adalah bagan alur).

Dengan Kisah Pengguna, Anda memiliki SIAPA yang ingin melakukan sesuatu, Anda memiliki APA yang ingin mereka lakukan (yang dapat menunjuk pada diagram / dokumen yang lebih rinci untuk tugas-tugas kompleks) dan Anda memiliki bagian terpenting MENGAPA mereka ingin melakukan kegiatan ini.

Jika Anda memiliki yang pertama, yang kedua benar-benar berlebihan, dan hanya noise yang terbaik. Spesifikasi persyaratan formal tradisional dari metodologi Waterfall tidak memiliki tempat di lingkungan Agile.

Pada akhirnya

Jika manajemen Anda tidak berkomitmen untuk berubah, Anda tidak akan berhasil dengan metodologi baru. Saya telah bekerja untuk perusahaan 100 miliar dolar per tahun, mereka tidak mengambil langkah kecil untuk pindah ke Agile / SCRUM, mereka hanya mengatakan, seluruh perusahaan pindah ke ini, di sini adalah cara baru dalam melakukan sesuatu, di sini adalah ketika pelatihan Anda tentang cara baru akan dimulai, berikut adalah alat baru yang akan kami gunakan, di sini adalah tanggal kami mulai melakukan hal-hal dengan cara ini. Itu bekerja untuk mereka dalam waktu kurang dari setahun. Saya telah berupaya mengimplementasikan ini di perusahaan-perusahaan kecil dengan kesuksesan yang sama.

Komitmen

implementasi langkah bayi , terlepas dari apa perubahan itu, adalah resep untuk kegagalan. Ini adalah kata sandi untuk manajemen yang diam-diam tidak mereka setujui dan secara pasif membuat Anda gagal. Mereka mengatakan saya tidak percaya ini cukup untuk berkomitmen untuk itu, jadi saya akan membiarkan Anda melakukan cukup hanya untuk gagal / tidak berhasil , dengan cara itu mereka dapat mengatakan mereka mencoba dan tidak berhasil dan mereka cara mereka mengelola bekerja baik-baik saja selama ini. Komitmen parsial pada akhirnya mengarah pada kegagalan.

Dalam kasus Anda, mereka mungkin diam-diam tidak percaya pada Cerita Pengguna, dan setelah beberapa saat melakukan keduanya, mereka akan mulai mengklaim bahwa itu adalah Cerita Pengguna yang tidak berguna dan bukan SRS, dan akan mendorong untuk berhenti menulis Cerita Pengguna. , Yang hanya akan menuntun Anda ke belakang bukan ke depan.

kmote
sumber
Anda akan cukup terkejut, kisah pengguna Dikelola oleh alat yang dapat (dan memang) mengekspornya sebagai persyaratan. Namun, kekhawatiran tampaknya adalah 'menerjemahkan' cerita-pengguna ke dalam bahasa SRS "sistem akan ..." dll. Dan TIDAK meninggalkannya sebagai cerita pengguna.
PhD
1
Nah, jika hang up adalah termanologi "harus / harus / mungkin" Anda mungkin meludah ke angin dengan orang-orang itu. Cerita Pengguna memberi tahu WHO / APA dan yang paling penting MENGAPA sesuatu perlu dilakukan, jauh lebih bermanfaat daripada kasus penggunaan statis, yang lebih salah dan benar dalam kebanyakan kasus.
2
-1: Tidak setuju sama sekali dengan sebagian besar jawaban, namun menyatakan itu dan SRS adalah "Spesifikasi persyaratan adalah dokumen artefak temporal, itu bukan dokumen hidup," begitu salah menunjukkan kesalahan yang mengganggu pemahaman apa sebuah SRS adalah untuk, atau bagaimana itu digunakan ketika dilakukan dengan benar - biasanya hanya di rumah model perangkat lunak air terjun warisan hari ini.
mattnz
5
SRS adalah dokumen mati segera setelah diterbitkan. Saya telah menulisnya sejak 1990. Mereka seperti rencana perang, mereka tidak pernah selamat dari kontak pertama. Dan mereka tidak pernah mengikuti implementasi aktual, kecuali jika Anda memiliki tim penulis berdedikasi yang terus-menerus mengedit hal itu dan itupun salah karena terputus dari perubahan konstan dan pengembang yang selalu mendahului dokumen, dan tidak selalu beri tahu pemilik dokumen apa yang sedang terjadi. Perusahaan menghabiskan 1000 jam menulis hal-hal seperti itu, dan dokumen-dokumen diletakkan di atas rak dan membusuk saat pengembangan dimulai.
3
@JarrodRoberson +1 untuk Anda. Memang mattnz benar juga bahwa SRS seharusnya menjadi dokumen yang hidup, tetapi kemudian Anda mengambil beberapa masalah produksi kritis yang permintaan pelanggan diubah, sambil bekerja pada satu atau lebih rilis basis kode bercabang, persyaratan yang disalahartikan oleh analis bisnis, pengembang, dan QA ... yang tersisa dengan Anda adalah dokumen yang bukan cerminan sebenarnya dari sistem saat ini, tetapi juga bukan cerminan sejati dari kebutuhan pengguna. Kisah pengguna benar-benar diadopsi oleh perusahaan yang lebih mementingkan klien daripada sistem.
maple_shaft
0

Saya akan mencoba dan menggunakan humor.

Mulai dengan http://www.halfarsedagilemanifesto.org/

Diskusikan hal ini untuk sementara waktu ( pengalihan )
dan bicarakan tentang arti konflik di dalamnya ( diskusi terbuka ),
kemudian setelah beberapa saat beralih ke organisasi Anda ( inden )
dan periksa SRS dan apakah masuk akal dengan pengaturan proyek baru .

Kemudian saya akan menyimpulkan (atau mungkin dalam pertemuan lain) dengan diskusi tentang perubahan dalam pendekatan re: SRS dan lihat apakah Anda memiliki lebih banyak konsensus.

Pada akhirnya Anda juga dibatasi oleh anggaran dan melayani orang-orang bisnis sehingga mungkin ada titik di mana Anda sedikit lebih tegas dalam apa yang digunakan, tetapi ini benar-benar tergantung pada industri, ukuran perusahaan, faktor organisasi dan banyak lagi. faktor-faktor lain seperti itu.

Michael Durrant
sumber
5
Berhati-hatilah. Hanya akan bekerja jika rekan kerja Anda sangat aman & Anda memiliki hubungan yang baik dengan mereka. Banyak orang marah jika Anda menggunakan humor untuk mengatakan bahwa mereka salah & terkungkung.
MarkJ
-1

Meyakinkan mgmt untuk menjauh dari SRS dan mulai menggunakan kisah pengguna pada dasarnya sama dengan meyakinkan mgmt untuk mengadopsi Agile. Ada statistik menarik di luar sana tentang manfaat produktivitas Agile. Salah satu contoh adalah presentasi yang diberikan VersionOne pada konferensi 2013. Perlihatkan mgmt data industri ini dan jika mereka adalah tipe pendengaran, Anda memiliki kesempatan.

Joe
sumber
1
Maaf, itu tidak banyak jawaban. Anda mengatakan 'tunjukkan statistik' dan bahkan tidak memberikan tautan.
Jan Doggen
dan jangan menulis kata-kata dan kalimat lengkap ...
jwenting