Apa alur kerja bug di tim tangkas / Scrum Anda?

9

Ini milik kami: - Jika bug terkait dengan cerita di sprint saat ini, kami memperbaikinya. - Jika bug tidak terkait dengan berita di sprint saat ini dan tidak kritis, bug dikirim ke pemilik produk untuk diprioritaskan. - Jika bug tidak terkait dengan cerita di sprint dan itu sangat penting, kami memperbaikinya.

— pengguna11347
sumber

Pertanyaan yang bagus, tetapi saya akan mengembangkannya juga untuk menanyakan bagaimana prosesnya bekerja dengan baik dan apa yang tidak ... Apa yang akan mereka ubah?

— Walter

Siapa yang melaporkan bug ini - pengembang atau QA? Kapan Anda merilis kode ke QA - di akhir sprint, atau selama itu? Jika yang terakhir menjawab kedua pertanyaan, maka Anda akan mendapatkan bug terkait dengan cerita yang dilakukan di sprint sebelumnya, saya pikir, dan jika tidak, tidak. Distribusi mana yang Anda miliki dapat mewarnai proses bug Anda.

— Tom Anderson

7

Apa pun yang terkait dengan pekerjaan dalam sprint saat ini sudah diperbaiki, kami bahkan tidak menganggapnya bug dan tidak menuliskannya demikian. Kami hanya menganggap sesuatu sebagai bug jika itu adalah bagian dari sesuatu yang sudah kami pertimbangkan Selesai.

Ketika bug baru muncul, kami menambahkannya ke tumpukan dan mendapat prioritas dari para pemangku kepentingan kami. Jika kami memiliki waktu tersisa dalam sprint, kami cenderung menangani bug yang lebih mudah yang mungkin memiliki prioritas lebih rendah tetapi merupakan sesuatu yang dapat kami selesaikan dalam waktu yang tersisa.

— Jason
sumber

2

Bagaimana Anda melacak bahwa bug itu ada? Katakanlah orang A menemukan bug dan orang B memperbaiki bug. Apakah Anda tidak meletakkan sesuatu di papan tugas?

— user11347

2

Saya selalu berpikir bug hanyalah sebuah cerita yang sudah memiliki tes gagal, jadi itu lebih baik didefinisikan daripada konsep cerita pertama yang khas untuk fitur.

Jadi, jika Anda yakin bahwa bug adalah cerita, Anda memperlakukannya seperti halnya cerita lainnya dalam hal estimasi dan prioritas.

— Tom Willis
sumber

"bug hanya cerita yang sudah memiliki tes gagal" - itu hebat!

— ianmayo

2

Saya pikir cara terbaik untuk mendekati ini adalah menentukan apa yang sebenarnya ingin Anda pertimbangkan sebagai Bug.

Banyak pengembang tidak akan menganggap sesuatu yang tidak berfungsi sebagaimana mestinya yang sedang mereka kerjakan bukan bug, karena jujur itu bukan bug. Jika Anda sedang mengerjakan sesuatu dan masih memiliki cacat maka bug spesifik tidak benar-benar lengkap sehingga tidak ada cacat yang sebenarnya. Kebalikannya berlaku untuk pekerjaan yang diselesaikan, jika Anda telah menentukan bahwa ada sesuatu yang lengkap dan siap untuk pengujian / rilis / produksi dan Anda kemudian menemukan cacat dalam kode atau penggunaan maka Anda pasti memiliki bug.

Perusahaan saya menggunakan metodologi berikut untuk menentukan kapan bug harus diperbaiki:

Jika bug sangat penting maka ditambahkan ke sprint saat ini terkait dengan produk itu, pada prioritas yang sesuai. Biasanya kami berencana dalam waktu sekitar 10% tambahan waktu untuk memungkinkan ini menjadi sprint, serta memiliki hal-hal tambahan yang sebenarnya tidak kami rencanakan untuk diselesaikan tetapi jika kami tidak memiliki bug atau sesuatu diselesaikan lebih cepat dari yang kami harapkan kami dapat kemudian lengkap.

Jika bug tidak kritis maka kami cukup menambahkannya ke dalam backlog dan biasanya menyelesaikannya di sprint berikutnya.

mengapa ini adalah aliran yang ideal ada beberapa kebocoran yang jelas untuk itu, dan kadang-kadang hal-hal yang tidak 'kritis' dari perspektif pemrograman mungkin perlu segera diselesaikan jika manajemen memutuskan bahwa itu perlu diselesaikan lebih awal dari yang kita pikir seharusnya lengkap.

Di samping itu saya berpikir bahwa hal terbaik untuk dilakukan adalah memilih struktur dan kemudian mematuhinya. Beberapa kerugian terbesar terhadap produktivitas mulai terjadi ketika Anda mulai melakukan sesuatu tanpa struktur. Setelah Anda mulai merendahkan struktur Anda, sangat mudah untuk membuatnya menjadi menurun.

Itu mungkin telah terlalu menjawab pertanyaan Anda, tetapi itu hanya pemikiran saya tentang bagaimana hal-hal ini harus ditangani.

— msarchet
sumber

1

Kami melakukan pekerjaan kerusakan yang sedang berlangsung. Mirip dengan pengaturan Anda, jika ada masalah kritis yang terkait dengan pekerjaan saat ini, kami memperbaikinya sebagai bagian dari pekerjaan. Lagi pula, tidak dapat menyebut sebuah cerita "selesai" jika ada cacat yang terkait dengannya.

Untuk bug lain, kami biasanya memperbaikinya jika waktu memungkinkan. Jika ada masalah mendesak, kami menarik kembali beberapa cerita dan menghabiskan waktu pada perbaikan bug sebelum kembali ke pekerjaan fitur normal.

— Adam Lear
sumber

1

Bug yang ditemukan selama Sprint hanyalah bagian dari pengembangan.

Bug yang ditemukan setelah akhir Sprint masuk ke Product Backlog. Kami tidak pernah berdebat dengan pengguna apakah ada bug atau peningkatan atau perubahan. Jika pengguna ingin menyebutnya bug, maka baiklah, tetapi masih masuk ke PB hanya pekerjaan baru lainnya.

— Dave
sumber