Apakah ide yang baik untuk menulis spesifikasi persyaratan berdasarkan cerita?

Kami menggunakan metode lincah dalam proyek saya saat ini, dan kami memiliki banyak cerita seperti ini:

• Sebagai asisten, saya ingin membayar pelanggan pengembalian dana sehingga mereka bisa mendapatkan uang ketika mereka memintanya

• Sebagai pelanggan, saya ingin membayar pembelian sehingga saya dapat menerima barang saya.

Cara kami melakukannya sejauh ini adalah memilih cerita yang paling penting setiap sprint dan menguraikannya menjadi sejumlah spesifikasi persyaratan formal (kami mengelompokkan beberapa cerita yang serupa bersama dalam spec yang sama). Bergantung pada ceritanya, itu bisa saja berupa tombol di layar atau seluruh alur kerja.

Masalahnya sekarang adalah karena ada begitu banyak cerita, itu tidak segera jelas, untuk bagian mana pun dari sistem yang terkait dengan cerita itu.

Ini bekerja pada saat pengembang, setiap sprint para dev hanya mendapatkan spesifikasi menguraikan apa yang perlu mereka lakukan dan perubahan yang perlu mereka lakukan. Tetapi dalam hal mempertahankan daftar cerita ini dan untuk pengujian, mulai mendapatkan bug pelacakan sangat sulit dan secara umum hanya mempertahankan spesifikasi, karena satu fungsi di layar mungkin telah didokumentasikan di sejumlah tempat yang berbeda karena itu menjadi dipisah oleh cerita.

Apakah menulis spesifikasi berdasarkan cerita adalah ide yang bagus? Sudahkah kita menulis cerita dengan cara yang salah?

Ini mungkin kontroversial tetapi ini dia!

Kami telah bekerja pada sistem waktu nyata di mana salah satu bos masa lalu saya menyarankan agar kita lakukan AGILE! Sangat mudah untuk memenangkan manajemen atas hal itu; Namun, itu lebih mudah diucapkan daripada dilakukan.

Konsep cerita itu bagus - tetapi untuk menjadi sangat muka, itu cukup kabur. Apa itu cerita, sebenarnya? Masalah sebenarnya adalah bahwa menggunakan cerita alone(dan banyak hal yang sama berlaku untuk Kasus penggunaan) memiliki beberapa masalah - sebagai berikut:

1. Persyaratan tidak boleh di luar konteks (kecuali Anda berkali-kali melakukan pengulangan kotor). Ada asumsi, latar belakang pengetahuan dan persyaratan lain yang terkait dengan persyaratan tertentu; mereka masuk akal hanya di bawah konteks dan hanya di bawah urutan tertentu. Menerapkan yang paling penting terlebih dahulu masuk akal secara bisnis tetapi ketika Anda mengajukannya setidaknya - pertahankan referensi lengkap sejak awal ketika Anda mengumpulkannya. Kata kebutuhan itu sendiri rumit dan tidak terbatas pada Use-Case / Stories. Memang cerita dapat ditindaklanjuti, tetapi kemudian ada persyaratan yang mungkin tidak dapat ditindaklanjuti, seperti kinerja, kendala yang harus dipenuhi, aturan bisnis, dll.

2. Persyaratan harus sesuai dalam ukuran dan dengan cara yang dapat diukur, Anda tidak akan pernah membutuhkan lebih dari 1 cerita besar! Apa yang membentuk persis 1 cerita?

   • apakah ini satu skenario penuh yang terperinci? (mis. satu cerita ketika ATM menolak transaksi)
   • apakah itu satu set tindakan yang dilakukan pengguna? (mis. cerita lengkap tentang penarikan)
   • atau satu layar di antarmuka pengguna? (misalnya layar penarikan sebagai cerita lengkap).
   • Bagaimana cara mengukur aturan bisnis yang sangat renyah dengan cerita? Jujur, itu bisa salah satu di atas. Intinya adalah seberapa banyak Anda terbatas dan granular pergi adalah gaya yang cukup pribadi. Jika berhasil-itu baik-baik saja;

3. Pengetahuan domain sangat dibutuhkan! Contoh sederhana, dari seorang Arsitek yang tahu berbagai sifat Kaca, Baja dan Kayu. pengetahuan ini bukan bagian dari dokumen persyaratan untuk bangunan per katakan! Cara yang sama, jika Anda menulis perangkat lunak perbankan - ada banyak konsep tentang perbankan. Menyatakannya, karena Persyaratan itu sendiri membuatnya tidak dapat ditelusuri karena tidak memberi tahu Anda apa yang harus dilakukan perangkat lunak sebagai lawan dari cara kerja dunia . Apakah cerita termasuk seluk beluk domain seperti itu? atau apakah itu mengecualikan ini?

4. Memodelkan dunia adalah prasyarat yang tidak didukung oleh.
   Ada banyak literatur tentang Pemodelan yang berfokus pada hanya memahami bagaimana dunia bekerja adalah pengetahuan latar belakang. Pemodelan membentuk fondasi yang kuat di mana persyaratan mendapatkan makna yang jelas; Namun hal semacam itu harus dimuka. Sayangnya, sebagian besar praktik tangkas menolak nilai dalam pemodelan dimuka demi kepentingan pengiriman lebih cepat dan lebih ramping; tetapi saya masih berpikir itu adalah penghenti acara utama ketika berbagai hal harus ditingkatkan. Banyak proyek yang berhasil bukan karena pemodelan tidak relevan - tetapi insinyur berpengalaman mengenal mereka dan tidak membutuhkan banyak panduan eksplisit.

Jadi datang ke pertanyaan Anda:

Apakah menulis spesifikasi berdasarkan cerita adalah ide yang bagus? Sudahkah kita menulis cerita dengan cara yang salah?

Saya pikir cerita pengguna memiliki nilai sebagai vonis eksplisit yang diberikan oleh pelanggan. Tetapi jika mereka tidak terorganisir dengan baik dan kurang detail (atau tidak jelas) ada masalah. Kecuali jika Anda memiliki struktur yang lebih besar untuk mengakumulasikan pemahaman yang lebih luas (pengetahuan domain) dan ruang lingkup (total spec). Cerita pengguna hanya untuk segmen atau elemen dalam sistem yang lebih besar.

PS: Saya punya pendapat yang tepat tentang kasus penggunaan (seperti yang digambarkan dalam diagram oval) bahwa kecuali Anda menempatkannya dalam konteks yang sesuai dan pada rincian yang tepat, mereka tidak melakukan pekerjaan dengan baik. (Saya menyebutnya kasus tidak berguna ). Satu-satunya sumber yang kredibel yang saya temukan untuk membuat penulisan kasus penggunaan benar-benar dapat diukur dan bermakna adalah Penulisan kasus penggunaan yang efektif oleh Cockburn

> Writing specs by stories? a good idea?

Ya jika Anda dapat mengatur saling ketergantungan dan prioritas cerita Anda.

Berikut adalah artikel tentang peta cerita yang dapat membantu Anda memesan dan mengatur banyak kisah pengguna.

Saat menulis jawaban ini, saya menyadari ini bukan tentang pengujian, ini tentang dokumentasi. Anda harus terlebih dahulu membaca manifesto tangkas :

[Kami menghargai] perangkat lunak yang berfungsi di atas dokumentasi yang komprehensif

Jadi, Anda harus membuat spesifikasi Anda dapat dieksekusi, yaitu menuliskannya sebagai serangkaian tes yang sepenuhnya otomatis.

Apakah menulis spesifikasi berdasarkan cerita adalah ide yang bagus?

Ya, tentu saja. Ini disebut "pengembangan yang didorong oleh perilaku" atau "spesifikasi dengan contoh". Di ruby ​​ada mentimun alat hebat yang banyak membantu.

Masalahnya sekarang adalah karena ada begitu banyak cerita, itu tidak segera jelas, untuk bagian mana pun dari sistem yang terkait dengan cerita itu.

Mengapa Anda ingin ini menjadi jelas? Maksud saya, apakah Anda benar-benar membutuhkan matriks "keterlacakan / kode" penelusuran? Keuntungan dari menulis tes sebagai spesifikasi adalah bahwa Anda tidak memerlukan penelusuran "persyaratan / tes" yang terpisah, karena tes menjadi persyaratan. Untuk keperluan pengujian integrasi, Anda harus memperlakukan perangkat lunak Anda secara keseluruhan, bukan sebagai bagian yang terpisah.

Anda mungkin memerlukan alat cakupan untuk melihat apakah ada modul "mati", bagian dari sistem Anda yang tidak dicakup oleh tes spesifikasi Anda. Tetapi Anda benar-benar tidak perlu peduli spesifikasi apa yang sesuai dengan kode ini. Itu harus sebaliknya: dari spesifikasi tertentu Anda harus tahu bagian mana dari sistem yang sesuai dengannya. Anda tidak perlu khawatir tentang duplikasi dalam spesifikasi Anda. Dan jika Anda menerapkan prinsip KERING pada kode Anda, akan ada puluhan spesifikasi yang mengeksekusi kode yang sama.

Ini bekerja pada saat pengembang, setiap sprint para dev hanya mendapatkan spesifikasi menguraikan apa yang perlu mereka lakukan dan perubahan yang perlu mereka lakukan. Tetapi dalam hal mempertahankan daftar cerita ini dan untuk pengujian, mulai mendapatkan bug pelacakan sangat sulit dan secara umum hanya mempertahankan spesifikasi, karena satu fungsi di layar mungkin telah didokumentasikan di sejumlah tempat yang berbeda karena itu menjadi dipisah oleh cerita.

Bukan tidak biasa bahwa ratusan tes integrasi rusak oleh satu perubahan kecil dalam modul kritis. Di situlah unit pengujian masuk.

Anda harus menyusun tes Anda sedemikian rupa sehingga Anda dapat mengetahui apakah tes tertentu mencakup persyaratan tingkat tinggi, atau hanya detail halus dari itu. Jika yang terakhir, Anda harus memisahkan tes ini dari suite tes integrasi Anda. Tujuan pengujian unit adalah untuk melokalkan bug. Sehingga jika Anda memperkenalkan bug, akan ada satu dan hanya satu kegagalan pengujian.

Sudahkah kita menulis cerita dengan cara yang salah?

Saya pikir, Anda hanya perlu mengatur cerita Anda menjadi epos baik oleh pengguna, misalnya "Pelanggan", "Asisten", atau dengan fitur / layar / alur kerja ("Pembelian", "Pengembalian").

Dan lagi, tes spesifikasi bukan pengganti untuk pengujian unit. Baca lebih banyak

Anda menyebutkan masalah dan cara Anda menyelesaikannya tetapi Anda lupa menyebutkan beberapa contoh spesifikasi dan pengelompokan Anda dan bagaimana hal itu terkait dengan cara Anda mengembangkan produk Anda.

Menulis spesifikasi berdasarkan cerita? sebuah ide bagus?

Agile tidak melarangnya. Dengan gesit Anda dapat melakukan apa pun yang Anda butuhkan untuk memberikan nilai bisnis maksimal dengan langkah berkelanjutan. Jadi, jika menulis spesifikasi adalah sesuatu yang Anda butuhkan untuk memberikan nilai bisnis yang lebih, itu benar-benar oke untuk melakukan itu.

Contoh Anda menunjukkan dua kisah pengguna. Entah bagaimana mereka mungkin terkait dalam logika bisnis Anda, tetapi itu adalah skenario yang sangat umum.

Jika Anda perlu melakukan bactrack fungsionalitas untuk cerita pengguna, Anda dapat kembali menggunakan apa pun yang paling sesuai dengan Anda termasuk dokumentasi, beberapa diagram atau "spesifikasi" Anda, tetapi Anda harus siap bahwa memelihara artefak ini akan lebih mahal karena kompleksitas aplikasi yang dikembangkan meningkat. Jadi satu-satunya pertanyaan yang harus Anda jawab dalam kasus ini adalah: Jika saya tidak menggunakan spesifikasi saya, apakah harganya lebih mahal? Jika jawabannya ya Anda memilih opsi yang lebih baik.

Agile bekerja paling baik untuk proyek-proyek kecil hingga menengah dengan tim kecil dimana seluruh arsitektur diadakan sebagai pengetahuan diam-diam yang dibagikan dalam tim. Selama perencanaan iterasi, Anda akan menelusuri cerita pilihan Anda, membahas dampak pada implementasi saat ini dan menulis beberapa tugas yang diperlukan untuk menyelesaikan cerita. Dokumentasi nyata dalam kasus seperti itu adalah ruang uji yang memegang penerimaan otomatis dan tes integrasi / unit. Setelah SW atau tim Anda berkembang, pengetahuan diam-diam harus beralih sebagian ke beberapa dokumentasi.

Sekarang di sinilah abstraksi memainkan peran utama. Anda perlu melihat cerita dengan menghormati perspektif yang relevan. Kumpulkan kata benda dan kata kerja dalam pernyataan dan konfirmasikan. Anda tidak dapat mendasarkan model Anda pada asumsi pribadi . Juga memperhatikan detail.

Menulis spesifikasi berdasarkan cerita pengguna tidak dapat akurat. Anda perlu menggali detail ekstra dan terkadang mengabaikan detail yang tidak relevan. Spesifikasi harus ditulis ketika model Anda lengkap dan akurat setelah konfirmasi analis Anda.