Mulai dari kisah pengguna hingga kode saat menggunakan TDD (scrum)


8

Saya masuk ke scrum dan TDD dan saya pikir saya memiliki beberapa kebingungan yang ingin saya dapatkan tanggapan Anda. Mari kita asumsikan saya memiliki kisah pengguna di backlog saya, agar saya dapat mulai mengembangkannya sebagai bagian dari TDD saya perlu memiliki persyaratan, sejauh ini?

Benarkah untuk mengatakan bahwa manajer produk dan QA harus bertanggung jawab untuk mengambil cerita pengguna dan memecahnya menjadi tes penerimaan?

Saya pikir hal di atas benar karena tes penerimaan perlu formal, sehingga dapat digunakan sebagai tes, tetapi juga dapat dibaca manusia sehingga produk dapat menyetujui bahwa mereka adalah persyaratannya, bukan?

Apakah benar juga bahwa saya kemudian mengambil tes penerimaan ini dan menggunakannya sebagai persyaratan saya, yaitu mereka adalah satu set kasus penggunaan yang saya terapkan (melalui TDD)? Saya harap saya tidak membuat terlalu banyak kekacauan tapi itu aliran saat ini yang saya pikirkan saat ini.

Pembaruan
Saya pikir niat awal saya tidak jelas sehingga saya akan mencoba untuk mengulangi. Saya ingin tahu lebih detail tentang alur scrum mengubah cerita pengguna menjadi kode saat menggunakan TDD.
Titik awal sudah jelas, pengguna memunculkan suatu kebutuhan (atau perwakilan pengguna sebagai produk) yang merupakan uraian singkat 1-2 baris dalam format yang diketahui dan yang ditambahkan ke jaminan simpanan produk.
Ketika ada pertemuan perencanaan musim semi, cerita pengguna diambil dari backlog dan ditugaskan ke pengembang.
Agar pengembang dapat menulis kode, mereka memerlukan persyaratan (terutama dalam TDD karena persyaratannya berasal dari tes mana).
Kapan, oleh siapa dan format apa yang dikompilasi?
Apa yang ada dalam pikiran saya adalah bahwa produk dan QA menentukan persyaratan melalui tes penerimaan (saya berpikir otomatis menggunakan FitNesse atau semacamnya tapi itu bukan inti yang saya pikir) yang membantu melayani 2 tujuan pada saat yang bersamaan:

  1. Mereka mendefinisikan "Selesai" dengan benar.
  2. Mereka memberi pengembang sesuatu untuk mendapatkan tes.

Saya tidak yakin kapan ini ditulis (sebelum sprint mereka diambil maka itu mungkin akan sia-sia karena informasi tambahan akan tiba atau cerita tidak akan diambil, selama iterasi maka pengembang mungkin akan terjebak menunggu mereka. ..)


1
Anda menulis tes saat kode, tes penerimaan bukan tes yang Anda tulis selama TDD.
CaffGeek

Saya tahu, tapi saya menulis TDD terhadap beberapa persyaratan, bukan? dalam bentuk apa mereka harus masuk?
Ittai

4
Saya mohon berbeda - tes penerimaan pasti dapat mendorong perkembangan Anda. Anda dapat menentukan serangkaian pengujian (unit, integrasi, sistem, dan penerimaan) untuk menunjukkan kapan aplikasi berfungsi dan dapat diterima. Anda kemudian dapat membuat kode aplikasi hingga lulus tes. Itu tentu saja adalah pengembangan yang digerakkan oleh tes.
Matthew Flynn

1
@Ittai: Saya pikir apa yang Chad katakan, adalah bahwa TDD dimulai dengan unit test, yang didefinisikan oleh pengembang sendiri. Saat pengembang menerjemahkan kasus penggunaan / persyaratan ke dalam desain kode tingkat lebih rendah, ia mengerjakan satu kelas pada satu waktu, dan menulis unit test untuk kelas itu. Pada level itu, ini "ad hoc" karena pengembang membuat tes yang diperlukan untuk membuktikan validitas kode.
Sam Goldberg

1
"Dari mana saya mendapatkan persyaratan dari"? Cerita Tidak jelas mengapa ini tidak cukup sebagai jawaban. Bisakah Anda menjelaskan mengapa cerita secara ajaib berbeda dari "persyaratan" yang ingin Anda lihat?
S.Lott

Jawaban:


11

Benarkah untuk mengatakan bahwa manajer produk dan QA harus bertanggung jawab untuk mengambil cerita pengguna dan memecahnya menjadi tes penerimaan?

Kebanyakan. Mereka mungkin tidak benar-benar menulis tes penerimaan aktual. Mereka mungkin menyetujui sesuatu yang Anda tulis. Tetapi mereka menyetujui tes penerimaan. Iya.

tes penerimaan harus formal, sehingga dapat digunakan sebagai tes, tetapi juga dapat dibaca manusia sehingga produk dapat menyetujui bahwa itu adalah persyaratannya, bukan?

Tidak relevan. Mereka dapat diformalkan sebagai tes otomatis. Atau mereka mungkin informal dan mungkin tugas Anda untuk membuat tes otomatis dari kriteria tes penerimaan informal.

Juga. "Persyaratan" adalah kisah pengguna. Tidak ada kebutuhan nyata untuk membuat versi lain dari cerita yang disebut "persyaratan." Beberapa orang suka menguraikan cerita sebelum kode mereka. Anda dapat menyebut persyaratan ini, tetapi "desain" adalah kata yang lebih baik. "Elaborasi" adalah kata terbaik.

Apakah benar juga bahwa saya kemudian mengambil tes penerimaan ini dan menggunakannya sebagai persyaratan saya, yaitu mereka adalah satu set kasus penggunaan yang saya terapkan (melalui TDD)?

Iya. Kisah itu mengarah pada tes penerimaan. Cerita ini diperlukan perilaku (yaitu, "persyaratan"). Kisah ini mengarah pada tes yang mendorong desain dan pengembangan perangkat lunak.

itulah arus yang ada dalam benak saya saat ini.

Sebenarnya tidak ada banyak "aliran" untuk ini.

Story -> tes penerimaan.

Story -> elaborasi ("desain", "persyaratan") -> tes unit -> kode.

Story -> Pengguna dapat melakukan sesuatu yang bernilai.

Story -> Story points -> perhitungan kecepatan.

Perhatikan polanya. Ceritanya sebagian besar menggerakkan segalanya.


Kapan, oleh siapa dan format apa yang dikompilasi?

Pertama. Tentukan "persyaratan". Apa bedanya dengan cerita itu sendiri?

Apa yang saya pikirkan adalah bahwa produk dan QA menentukan persyaratan melalui tes penerimaan

Tidak biasanya.

selama iterasi maka pengembang mungkin macet menunggu mereka.

Salah. Pengembang dapat (dan sering kali) membantu menulis ini. Itulah inti dari "pengembangan": menguraikan cerita menjadi "selesai" yang didefinisikan dengan baik.

Lagi. Ketika Anda memiliki keraguan atau pertanyaan, Anda harus benar-benar membaca Agile Manifesto. Manifesto cukup jelas: pengembang harus berbicara dengan pemilik produk, pengguna, QA, dan semua orang yang merupakan pemangku kepentingan. Interaksi sebenarnya adalah hal terpenting yang bisa terjadi.


Terima kasih, Bisakah Anda menguraikan,;), sedikit lebih banyak tentang tahap elaborasi Story->? Saya mendapat kesan bahwa sebuah cerita lebih berupa: "Saya, sebagai pengguna, ingin masuk ke situs web untuk membeli produk" Ini tidak termasuk rincian yang cukup bagi saya untuk memulai TDD melawan karena saya perlu lebih banyak detail , lebih banyak kasus penggunaan. Lebih banyak jalan, bahagia dan tidak bahagia.
Ittai

"Aku butuh lebih banyak detail, lebih banyak kasus penggunaan. Lebih banyak jalan, bahagia dan tidak bahagia." Baik. Saya tidak mengerti apa lagi yang perlu Anda ketahui tentang elaborasi. Anda memberikan deskripsi lengkap tentang apa yang perlu terjadi. Apa lagi yang ingin Anda ketahui? Bagaimana cara meminta informasi?
S.Lott

Semacam, Apa yang saya coba pahami adalah apakah pada awal sprint hanya ada cerita pendek pengguna dan kemudian pengembang perlu "menggali" informasi dari produk? Karena saya mendapat kesan (mungkin secara keliru) bahwa ketika sprint dimulai, pengembang memiliki serangkaian persyaratan yang tidak dilakukan tetapi 80% (berasal dari cerita pengguna). Saya mencoba mengumpulkan aliran. Kapan transformasi dari kisah pengguna satu-liner (dari 2 liner) pergi ke serangkaian spesifikasi terperinci.
Ittai

1. Tidak ada "aliran"; tidak ada "langkah". Lebih sederhana dari itu. Tulis tes dan kode. 2. Sumber informasi tergantung pada organisasi Anda. Sebagian besar organisasi memberikan cerita kepada pengembang untuk diuraikan. Beberapa akan mencoba melakukan beberapa elaborasi selama perawatan di awal sprint. 3. Baca Agile Manifesto. agilemanifesto.org . Anda diharapkan berinteraksi dengan pemilik produk. Dalam. Sering. Intinya bagi Anda untuk mengumpulkan data yang Anda butuhkan sehingga Anda dapat membangun kode untuk mendukung cerita.
S.Lott

1
"Kapan transformasi dari kisah pengguna satu-liner (dari 2 liner) menuju ke spesifikasi yang terperinci". Selalu. Jika Anda ingin melakukan desain, jangan ragu untuk melakukan desain. Beberapa orang menuliskan desain mereka. Beberapa tidak. Jika Anda menyukai gagasan menulis banyak spesifikasi, tidak apa-apa. Jangan berlebihan. Intinya adalah untuk menulis tes dan kode. Jika desain membantu Anda fokus, jangan ragu. Banyak orang menemukan bahwa menulis tes membantu mereka fokus. Jika Anda menemukan kebutuhan untuk dokumen spesifikasi yang besar dan kompleks, kisah Anda terlalu kompleks.
S.Lott

2

Saya akan menjawab Anda dari perspektif Extreme Programming (XP) mengenai tes penerimaan.

Ketika saya pertama kali masuk (dan membaca buku-buku), saya membaca bahwa itu benar-benar peran pengembang untuk bekerja dengan klien / pengguna untuk mengembangkan / mendokumentasikan tes penerimaan. Salah satu tujuan XP adalah meningkatkan komunikasi langsung antara pengguna / klien dan pengembang. Ini sering ideal, karena mengurangi kemungkinan kesalahan pengkodean karena miskomunikasi persyaratan.

Saya telah melakukan TDD selama sekitar 8 tahun, dan telah mengikuti pendekatan di atas. Saya pikir itu telah meningkatkan kecepatan pengembangan, dan kepuasan dengan sistem karena klien / pengguna melihat bagaimana mereka secara langsung mempengaruhi pengembangan aplikasi.

Kesulitan utama yang saya hadapi (dengan klien yang lebih kecil), adalah sangat sulit untuk membuat mereka berpartisipasi dalam menentukan tes penerimaan. (Biasanya saya harus melakukannya untuk mereka, dan mengirimkannya kepada mereka untuk ditinjau.) Klien yang lebih besar yang pernah bekerja sama dengan saya, biasanya memiliki pola pikir ini, jadi mereka siap untuk memberikan tes penerimaan khusus.

Dari apa yang saya baca tentang scrum, saya tidak yakin itu mendefinisikan peran mana yang bertanggung jawab untuk mendefinisikan / menulis tes penerimaan. Saya menganggap itu bisa berbeda dari satu tim ke tim lainnya.

Saran saya adalah, Anda sebagai pengembang, Anda harus berpartisipasi sebanyak mungkin dalam proses definisi pengujian. Dan tujuannya adalah untuk mendapatkan hasil sprint di depan pengguna secepat mungkin, sehingga mereka dapat memberi tahu Anda segala sesuatu yang mereka lupa pikirkan (atau apa yang mereka katakan salah kepada Anda) secepat mungkin.


1

Kisah pengguna bukan "Sebagai pengguna, saya ingin XXX agar YYY" ! Kisah pengguna adalah janji untuk komunikasi masa depan dengan PO. Itu memecahkan masalah Anda dengan lebih detail. Anda harus berkomunikasi dengan PO selama sprint untuk mendapatkan informasi yang Anda butuhkan.

Cerita pengguna juga memiliki lebih banyak fitur daripada kalimat pendek yang menjanjikan komunikasi. Bagian yang diperlukan dari kisah pengguna adalah kriteria penerimaan. Kriteria penerimaan harus diketahui sebelum berkomitmen untuk cerita pengguna (mereka harus diketahui sebelum memperkirakan cerita pengguna). Kriteria penerimaan adalah input untuk tes penerimaan = tes penerimaan harus menguji kriteria penerimaan.

Jadi, ketika Anda mulai mengerjakan cerita pengguna dengan pendekatan TDD Anda (bukan QA) harus terlebih dahulu membuat tes penerimaan otomatis berdasarkan kriteria penerimaan untuk mendapatkan tes gagal untuk itu. Anda akan melanjutkan dengan menerapkan kode yang diperlukan menggunakan TDD sebelum lulus tes penerimaan. Anda akan melanjutkan dengan tes penerimaan berikutnya. Saya menulis tentang itu juga di pertanyaan lain .

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.