Haruskah cerita pengguna dibagikan di antara pengembang? [Tutup]


21

Saya biasanya melihat cerita yang memiliki perkembangan back-end dan front-end. Misalnya, pertimbangkan dialog besar dengan beberapa tabel dan beberapa kontrol dinamis. Kami akan membuat beberapa cerita (mungkin satu untuk setiap tabel dan satu lagi untuk sistem kontrol dinamis).

Tim dev kemudian akan berpisah dengan satu orang di back-end dan yang lainnya di front-end. Ini membuatnya mudah bagi orang back-end untuk hanya khawatir tentang struktur lapisan SQL sementara orang front-end berfokus pada hal-hal seperti tata letak. Setelah antarmuka awal antara back-dan front-end disepakati, kedua pengembang dapat memusatkan perhatian mereka untuk menyelesaikan bagian mereka pada akhir sprint.

Kemudian muncul kekacauan. Siapa yang "memiliki" cerita mana? Apa arti "sedang berlangsung" atau "selesai"? Haruskah kita membuat dua cerita terpisah untuk back-end dan front-end? Jika demikian, bukankah itu mematahkan ide cerita pengguna berdasarkan fitur? Sistem kami memiliki gagasan "sub-tugas", yang memudahkan beberapa masalah ini. Tetapi sub-tugas menambah kompleksitas ekstra. Apakah ada cara yang lebih baik? Apakah ini cara "buruk" untuk menggunakan Scrum?

Saya telah menggunakan beberapa bentuk Agile selama beberapa tahun terakhir di beberapa tempat. Saya belum memiliki pelatihan resmi, jadi tolong maafkan terminologi atau ideologi yang salah. Saya hanya mencoba mempelajari cara-cara praktis untuk meningkatkan proses kami.


Anda cukup banyak menutupinya dengan ide sub tugas. Bagaimana dengan konsep ini yang menurut Anda sulit untuk dipahami?
RibaldEddie

1
Sub-tugas tidak sulit untuk dipahami, itu hanya lebih rumit. Jadi sekarang saya kira manajer dev memiliki cerita dan masing-masing dev memiliki sub-tugasnya. Akhirnya berakhir pada 3 objek per fitur (cerita dan dua sub-tugas). Saya kira ini normal.
Pengguna1

1
Kebanyakan proses lincah mencemarkan gagasan bahwa setiap pengembang "memiliki" bagian tertentu dari proyek. Orang-orang hanya mengerjakan tugas, bagian apa pun dari sistem yang disentuh tugas itu. Dalam kasus Anda, sepertinya Anda secara efektif membuat sub-tim kecil untuk menangani satu cerita, yang menurut saya baik-baik saja ... mintalah mereka untuk saling berhubungan untuk memutuskan kapan cerita itu selesai. Saya tidak mengerti mengapa ini harus lebih kompleks dari ini.
Jules

"Ini akhirnya berakhir pada 3 objek per fitur (sebuah cerita dan dua sub-tugas). Saya kira ini hanya normal." - itu biasa, tetapi seharusnya tidak normal. Sebuah kisah lincah benar-benar dapat dipecah menjadi 2 cerita (1 untuk FE, 1 untuk BE). Tujuan cerita tidak selalu merupakan fitur, tetapi untuk memberikan "nilai" bagi pemilik produk. BE dev memberikan banyak nilai dan harus dipisahkan.
PostCodeism

Jawaban:


16

"Cerita" dinamai demikian karena mewakili kisah lengkap, baik , dari perspektif pelanggan. Tanpa front-end atau back-end, tidak ada jalur use-case bagi pelanggan untuk mengeksekusi.

Dalam kasus Anda, saya pikir front-end dan back-end harus menjadi satu cerita. Membaginya menjadi tugas. Pengembang memiliki tugas berbeda. Tugas-tugas ini dapat secara individual dilacak melalui fase mereka - Dalam Kemajuan, Pengodean Selesai, Modul Pengujian Selesai, dll.

Pastikan Anda memasukkan tugas yang ditugaskan QA dalam cerita yang sama - tanpa validasi cerita tidak berguna. QA akan menguji kisah terintegrasi ujung ke ujung yang akan dilihat pelanggan. Hanya dengan demikian keseluruhan cerita harus ditandai sebagai Selesai. Dalam lingkungan Agile yang ideal, pelanggan nyata atau proxy pelanggan juga mencoba cerita dalam aplikasi yang sedang berjalan, dan menandai cerita tersebut Diterima jika memenuhi persyaratan yang disepakati.

Jika Anda ingin loop umpan balik yang lebih cepat, cobalah memecah case-use menjadi fitur end-to-end yang lebih kecil. Misalnya, alih-alih kotak penggunaan seperti "Seorang pelanggan dapat membeli barang menggunakan keranjang belanja", bagilah menjadi "Seorang pelanggan dapat menambahkan produk ke keranjang belanja" dan seterusnya ... Kemudian lengkapi setiap kotak penggunaan yang lebih kecil ujung ke ujung seperti dijelaskan di atas.

EDIT: Saya ingin mendukung poin-poin di atas dengan beberapa sumber. Karakteristik kisah pengguna yang baik diwakili secara singkat dengan akronim yang disebut " INVEST ". Itu dibuat oleh Bill Wake dan dipopulerkan oleh gerakan Scrum. Perhatikan terutama item pada cerita yang Independen dan Vertikal.

Beberapa informasi lebih lanjut di sini dan di sini .


5

Siapa yang "memiliki" cerita mana?

Siapa pun yang mengambil kisahnya. Kunci mereka dari sudut pandang organisasi adalah satu orang bertanggung jawab atas pekerjaan itu. Setelah Anda mendapatkan dua orang, itu terlalu mudah untuk dilewatkan.

Haruskah kita membuat dua cerita terpisah untuk back-end dan front-end? Jika demikian, bukankah itu mematahkan ide cerita pengguna berdasarkan fitur?

Tergantung. Saya telah melihat kedua cara bekerja. Jika ceritanya cukup besar untuk membuat dua pengembang bekerja penuh waktu, maka mungkin cerita itu harus dibagi. Jika kedua pengembang adalah bagian dari dua tim yang berbeda, maka mungkin itu harus dibagi. Jika kedua pengembang akan mengerjakannya selama sprint yang berbeda, maka mungkin itu harus dibagi.

Apakah ini cara "buruk" untuk menggunakan Scrum?

Kunci untuk diingat adalah proses itu ada untuk melayani Anda, bukan sebaliknya. Cerita pengguna adalah cara bagi orang-orang teknis dan non-teknis untuk memfasilitasi komunikasi. Mereka menguraikan apa yang mereka inginkan, semua orang bernegosiasi, dan kemudian Anda memberikan umpan balik dalam cerita tentang kemajuannya.

Selama prosesnya berhasil untuk Anda, itu tidak akan seburuk itu.


3

Di mana kami telah menerapkan model Scrum, sangat diharapkan bahwa banyak pengembang dapat terlibat dalam satu cerita pengguna. Mungkin ada pekerjaan untuk lapisan data, integrasi, CSS front-end, infrastruktur, dll. Tim dapat bersatu pada berbagai sub-tugas untuk sebuah cerita untuk menyelesaikannya.

Yang sedang berkata, satu orang memiliki cerita dan bertanggung jawab untuk memperbarui perkembangannya dan memastikan semua orang melakukan bagian mereka dan bahwa itu bekerja bersama. Ini adalah orang bagi kita yang melaporkan bahwa sebuah cerita "selesai".


3

Seperti yang disarankan orang lain, tim saya juga membagi cerita pengguna kami menjadi tugas. Ini umumnya mudah dilakukan jika Anda mengelola cerita pengguna Anda melalui perangkat lunak (seperti JIRA atau Rally). Maka mudah untuk mengetahui bagian mana dari cerita yang sedang bergerak.

Tetapi alternatif untuk tugas adalah dengan hanya menetapkan kembali kepemilikan karena setiap orang menyelesaikan bagian mereka. Jadi ceritanya akan diteruskan - mungkin pengembang 1 memulainya dengan pekerjaan backend, lalu beralih ke pengembang 2 untuk melakukan UI. Kemudian diteruskan ke tester QA Anda untuk verifikasi. Metode ini harus bekerja dengan baik di lingkungan di mana Anda menggunakan kartu yang sebenarnya di dinding atau jika perangkat lunak Anda tidak melacak tugas.

Tetapi bagaimanapun juga, saya sarankan untuk tidak pernah menyebut cerita "selesai" sampai tim setuju bahwa itu selesai, termasuk pengujian. Dengan begitu setiap orang memiliki kesempatan untuk memberikan masukan. Dan jika Anda menggabungkan ini dengan ide-ide tentang kepemilikan kode kolektif dan ulasan kode maka setiap cerita benar-benar "dimiliki" oleh tim. Mungkin "ditugaskan" untuk orang yang berbeda di sepanjang jalan, tetapi jika seseorang keluar (sakit / liburan / terlalu banyak pertemuan? / Lainnya) pekerjaan masih bisa dilakukan.

Tim saya sering menerima cerita pengguna sebagai bagian dari pertemuan stand-up / SCRUM pagi kami. Dengan begitu setiap orang dapat dengan mudah mengakui atau membantah apakah itu benar-benar "selesai". Di lain waktu kami hanya membiarkan teknisi QA kami melakukan itu - jika dia puas bahwa itu diuji dan berfungsi, dan semua tugas selesai, maka kami menyebutnya selesai.


1

Di mana saya saat ini kami sebut proyek yang lebih besar ini "epik". Sebuah epik terdiri dari beberapa cerita dan dapat menjangkau berbagai sprint / iterasi. Sebuah cerita, bagi kami, selalu diberikan kepada satu pengembang dan harus sesuai dalam satu sprint. Satu cerita kemudian dibagi lagi menjadi tugas. Setiap tugas diselesaikan oleh pengembang yang sama pada cerita itu. Tugas-tugas ini dimaksudkan untuk memberikan wawasan tentang kemajuan cerita selama sprint / iterasi. Ketika setiap cerita selesai, oleh setiap pengembang, epik menunjukkan kemajuan.

Inti dari epik ini adalah untuk memiliki tujuan yang lebih besar yang tidak selalu cocok dengan sprint / iterasi tunggal. Seiring waktu semua cerita selesai dan epos selesai. Epik ditempatkan ke dalam rilis.

Kemudian muncul kekacauan. Siapa yang "memiliki" cerita mana? Apa arti "sedang berlangsung" atau "selesai"?

Kami mendemonstrasikan kode setiap dua minggu di mana cerita untuk sprint / iterasi tersebut harus ditunjukkan kepada para pemangku kepentingan dan disetujui. Dalam konteks ini "selesai" untuk sebuah cerita berarti bahwa saya dapat menunjukkan kepada Anda apa yang dilakukannya. Pengembang memiliki cerita mereka dan bertanggung jawab untuk menunjukkannya (bagian ini adalah semacam penyederhanaan yang berlebihan, tetapi cukup baik untuk jawaban ini; kami mengoordinasikan demo kami melalui satu orang). "Selesai" berarti dapat ditunjukkan dengan sukses. "Sedang berlangsung" berarti saya memiliki tugas yang luar biasa dan cerita tidak lengkap. Sebuah epik selesai ketika semua cerita untuk epik itu telah berhasil ditunjukkan.

Sekarang ini adalah perkembangan kasus yang sempurna. Kami memiliki cerita dan demo yang gagal, pengguna yang menginginkan sesuatu yang lain, dll. Di atas adalah tujuannya dan sebagian besar berfungsi.


1
'"Selesai" berarti dapat ditunjukkan dengan sukses' - Saya tidak yakin tentang ini. Demonstrasi yang sukses tidak berarti harus melewati QA, kecuali demonstrasi Anda mencakup setiap kasus sudut tunggal yang akan dilemparkan oleh tester yang baik.
Mike Chamberlain

1
Kami merilis QA, bukan cerita. Sebuah kisah dilakukan dalam kasus ini. Itu tidak berarti bahwa cacat tidak dapat dibuka atau bahwa cerita tidak dapat dibuka kembali, itu hanya berarti Anda memindahkan cerita ke kolom "selesai" untuk tujuan manajemen proyek. Jika setiap kotak sudut diuji dengan satu cerita, kami tidak akan pernah mengirimkan apa pun ... itu jika Anda dapat secara realistis memikirkan setiap kotak sudut.
jmq
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.