Cara menangani cerita yang berbagi fungsi

27

Saya punya dua cerita (saya tahu mereka kehilangan bagian manfaatnya)

  1. Sebagai Pengguna Manajemen Kredit, saya dapat melihat perbedaan penggajian saat ini dan sebelumnya untuk Kantor.
  2. Sebagai Pengguna Manajemen Kredit, saya dapat menerima email yang berisi PDF dari perbedaan gaji saat ini dan sebelumnya untuk Kantor.

Keduanya terkait karena mereka akan memiliki kriteria Permintaan / Filter yang sama. Satu-satunya perbedaan adalah bahwa dalam cerita "Tampilan", hasilnya ditampilkan kepada Pengguna dan dalam cerita "Email", hasilnya ditulis ke PDF yang diemailkan ke Pengguna.

Saya berjuang dengan pemisahan aspek umum dari dua cerita ini atau jika saya harus melakukannya.

Misalnya, keduanya akan memiliki kueri yang sama, apa yang mereka lakukan dengan hasil berbeda.

Haruskah saya memisahkan pertanyaan menjadi cerita lain yang murni teknis?

Pembuatan PDF dan pengiriman email harus dilakukan secara offline, haruskah itu menjadi cerita teknis?

Saya bisa melihat memecah dua cerita menjadi 2 cerita fungsional dan 2 cerita teknis.

  1. Sebagai Sistem, saya dapat menghitung perbedaan gaji saat ini dan sebelumnya untuk Kantor.

  2. Sebagai Pengguna Manajemen Kredit, saya dapat melihat perbedaan gaji saat ini dan sebelumnya untuk Kantor.

  3. Sebagai Sistem, saya dapat membuat dokumen PDF tentang perbedaan gaji saat ini dan sebelumnya untuk Kantor.

  4. Sebagai Pengguna Manajemen Kredit, saya dapat meminta untuk menerima email yang berisi PDF tentang perbedaan gaji saat ini dan sebelumnya untuk Kantor.

Masalahnya saya terus kembali ke adalah bahwa 4 cerita tidak independen dan tidak "mengiris kue".

Jadi saya tidak yakin bagaimana menghadapi keduanya.

agile  requirements  user-story 
— Joe Young
sumber
4
jika Anda akan menggunakan "kisah pengguna teknis" sadari bahwa ada 3 hal di sini bukan 4. Perbedaan yang Anda hitung dari model dan dua jenis tampilan, tampilan PDF, dan tampilan GUI. Anda hanya menyajikan laporan secara berbeda.
— candied_orange
1
Atasi salah satunya. Lalu mengatasi yang lain. Sesederhana itu.
— Ant P
Mengapa mereka dua cerita?
— JeffO

Jawaban:

55

Cerita Pengguna bukan spesifikasi sistem atau persyaratan fungsional. Sebaliknya, mereka adalah awal dari percakapan yang dapat mengarah pada spesifikasi atau persyaratan tersebut.

Oleh karena itu, saya berharap ada tumpang tindih dalam implementasi sistem. Cerita Pengguna tidak dimaksudkan untuk menggambarkan tumpang tindih fungsional atau untuk menghilangkannya. Tujuan dari User Stories adalah untuk menangkap harapan fungsional dari sudut pandang pengguna, bukan untuk menggambarkan detail implementasi.

— Robert Harvey
sumber
3
Sebenarnya mulai menulis sesuatu yang sangat mirip, tetapi jawaban ini sudah mencakup semua aspek saya, jadi +1.
— Doc Brown
Sama di sini, jauhkan implementasi dari itu.
— candied_orange
1
@ JoYoung: detail implementasi masuk - ke implementasi, di mana lagi? Dan bagaimana Anda mengatakan ini pengembang lain tergantung pada struktur komunikasi tim Anda. Tentu saja, mungkin ada persyaratan fungsional yang terlibat di sini, seperti "ketika melihat perbedaan penggajian online, atau ketika mengambil mereka sebagai PDF, penting untuk mendapatkan konten yang persis sama dalam kedua kasus" . Jika demikian, tambahkan ini sebagai catatan untuk setidaknya satu (lebih baik keduanya) cerita pengguna. Namun, jangan berikan deskripsi bagaimana persyaratan ini akan diterapkan ke dalam cerita.
— Doc Brown
3
Desain bukan tentang memberi tahu pengembang cara mengatasi masalah. Ia memberi tahu pengembang masalah apa yang harus dipecahkan.
— candied_orange
1
Ketika Anda menilai biaya waktu dari cerita-cerita ini, bagaimana Anda kemudian menilai mereka? Katakanlah bagian permintaan umum membutuhkan waktu 5 jam, bagian tampilan web membutuhkan 6 jam, dan bagian tampilan PDF membutuhkan waktu 7 jam. Apakah Anda memperkirakan waktu, apakah Anda secara sewenang-wenang mengatakan satu biaya 11 jam (5 + 6) dan 7 lainnya (atau sebaliknya: 12 dan 6), atau apakah Anda memperkirakannya pada 6 dan 7, tetapi perhatikan di tempat lain di beberapa cara overhead 5 jam untuk keduanya digabungkan? 11 dan 12 (5 ditambahkan ke keduanya)? Jika Anda mengatakan "Model ini tidak dimaksudkan untuk menangani kasus-kasus seperti itu. Bicara saja." mungkin masih direkam di storyboard, tapi bagaimana caranya?
— Aaron
15

Jangan: Coba dan pisahkan ceritanya, Lakukan satu cerita lalu yang lain.

Lakukan: Pastikan tim pengembang menyadari cerita kedua.

Masalah dengan mencoba merencanakan tugas-tugas terperinci dan menyusun model generik yang dapat menangani keduanya dengan cara yang elegan adalah sulit.

Tujuan dari cerita pengguna adalah untuk menyelesaikan sesuatu. Elegan adalah tujuan sekunder dan harus diserahkan pada refactoring.

Jelas itu sangat menjengkelkan jika Anda mengambil ini secara maksimal dan tidak memberi tahu siapa pun tentang sepuluh tugas serupa lainnya yang perlu dilakukan, tetapi juga benar-benar dapat dibayangkan bahwa tugas kedua atau ketiga tidak terpikirkan sampai yang pertama selesai. Jika Anda ingin merencanakan semuanya, pergilah dengan air terjun.

— Ewan
sumber
4

Dalam perjanjian kekerasan dengan Robert Harvey, tujuan cerita pengguna adalah untuk memahami apa yang harus dapat dilakukan oleh pengguna. Saat Anda melakukan perawatan, pelanggan memahami dan peduli tentang kisah pengguna, tetapi pengembang sedikit lebih peduli. Setelah Anda mengajukan cukup pertanyaan untuk memahami dan memperkirakan pekerjaan, Anda dapat membuat tugas untuk mendukungnya.

Dalam kasus khusus ini, Anda bisa membuat tugas yang memungkinkan inti dari kedua cerita pengguna yang akan dilakukan bersama dengan apa pun yang Anda atasi terlebih dahulu.

Hal-hal penting untuk ditambahkan ke kisah pengguna adalah:

  • Kriteria penerimaan
  • Asumsi
— Berin Loritsch
sumber
Perlu dicatat bahwa Anda tidak perlu mendokumentasikan lebih dari cerita. Kisah ini memberi Anda konteks tingkat bisnis. Pelacakan terperinci yang Anda butuhkan terserah Anda (dan sebagian besar tergantung pada kendala organisasi). Anda harus berusaha menguranginya (orang-orang dalam proses dan semua itu).
— Ant P
@AntP, setuju, tetapi ini mengarah ke Definition of Done (DoD) dan itu harus sesuai di belakang kartu 3x5 Anda yang memiliki kisah pengguna.
— Berin Loritsch
2

Sebenarnya, User Stories adalah janji percakapan untuk memahami hasil yang diinginkan.

Misalnya, mengambil kisah pengguna kedua Anda

Sebagai Pengguna Manajemen Kredit, saya dapat menerima email yang berisi PDF dari perbedaan gaji saat ini dan sebelumnya untuk Kantor.

Pikirkan hal-hal berikut:

  • Apa "kebutuhan" pengguna yang mendorong persyaratan ini? (Apakah PDF dalam email sebagai solusi berasal dari mereka? Ini mungkin tidak menjawab kebutuhan dan tim Anda dapat menemukan solusi yang lebih baik)
  • Apa irisan minimum yang dapat mengatasi "kebutuhan" pengguna ini dan memvalidasi solusi Anda? Umpan balik pendek sangat berharga.

Saat mendekati pemisahan cerita, ingat kriteria INVEST Anda jika memungkinkan.

  1. Saya bergantung
  2. Tidak bisa dinegosiasikan
  3. V aluable
  4. E mudah terstimulasi
  5. S mal
  6. T estable

Tidak masalah untuk memiliki cerita yang memiliki urutan alami. Pertimbangkan itu - biasanya cerita pertama lebih besar karena membawa fungsi yang diperlukan dan cerita kedua dibangun di atasnya.

Saya akan menantang kisah-kisah "teknis", karena umumnya kisah-kisah itu kemungkinan besar merupakan tugas untuk membantu mendukung penerapan cerita yang berfokus pada hasil pengguna.

— Ilessa
sumber
2

TL; DR

Dengan asumsi kedua cerita pengguna ditarik ke dalam lingkup dalam iterasi yang sama, itu adalah tugas tim untuk menguraikan cerita menjadi rencana implementasi dan tugas yang menyertainya. Cerita pengguna memberikan konteks dan ruang lingkup; mereka bukan implementasi, spesifikasi, atau item daftar punch.

Cerita Harus Diuraikan untuk Tugas Iterasi

Apakah Anda mengikuti Scrum atau metodologi gesit lainnya, itu adalah kesalahan umum untuk melewati fase perencanaan iterasi. Di Scrum, ketika Item Tumpukan Produk (tidak perlu cerita pengguna, secara tegas) ditarik ke dalam Sprint saat ini, tim kemudian harus menggunakan bagian dari Perencanaan Sprint untuk memfaktorkan kesamaan antara item pekerjaan, mengidentifikasi dependensi, dan kemudian kembangkan Sprint Backlog untuk menangkap pekerjaan tingkat tugas.

Seperti yang Anda tunjukkan dalam posting Anda, itu tidak biasa (dan sebenarnya diinginkan) untuk iterasi yang gesit untuk memuat cerita pengguna yang terkait erat. Dalam Scrum, ini muncul melalui penggunaan Sprint Goal. Di luar kerangka Scrum, sering kali masih masuk akal untuk menarik cerita terkait karena tujuan bersama atau ketergantungan bersama. Dengan mengekstraksi dan kemudian mengerjakan dependensi bersama dalam satu iterasi tunggal, tim sering kali dapat menghindari perlunya refactor atau beralih pada kode untuk fitur yang serupa-tetapi-tidak-identik di masa depan.

Tugas Melaksanakan Cerita

Berikut cara lain untuk berpikir tentang perencanaan ketergantungan untuk cerita pengguna. Secara umum:

  1. Sebuah epik / tema digunakan untuk perencanaan jangka panjang atau pengelompokan pada jaminan simpanan.
  2. Cerita pengguna digunakan untuk mengkomunikasikan tujuan, konteks, dan ruang lingkup.
  3. Perencanaan just-in-time digunakan untuk mengembangkan implementasi yang sesuai dalam satu iterasi tunggal.
  4. Tugas mengimplementasikan rencana tepat waktu yang memenuhi Definisi Selesai untuk satu atau lebih cerita pengguna.

Memperlakukan cerita pengguna sebagai rencana implementasi atau daftar tugas dianggap oleh sebagian besar praktisi sebagai anti-pola lincah. Apa pun yang Anda pilih untuk memanggilnya, jangan lewatkan fase perencanaan tepat waktu dari kerangka kerja tangkas Anda, dan pastikan untuk melacak dependensi dan berbagi detail implementasi di suatu tempat dalam proses tim Anda.

— CodeGnome
sumber
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.