Haruskah case dibuka kembali untuk bug, atau haruskah bug dibuka sebagai case baru?


9

Saat ini di tempat kerja saya, kami menggunakan FogBugz untuk mengelola semua fitur dan bug kami untuk berbagai aplikasi web kami.

Ketika fitur baru akan ditambahkan ke salah satu aplikasi web kami, Kasus baru dibuat. Misalnya "Buat Formulir Upload CSV".

Saya kemudian mengerjakan case yang mencatat jumlah waktu yang saya habiskan untuk itu. Setelah kasus ini selesai, saya kemudian menyelesaikannya, dan akan ditugaskan kembali ke pembuka kasus (biasanya manajer proyek), yang kemudian menutup kasus ini.

Jika ada bug dengan fitur tersebut, Manajer Proyek saya kemudian membuka kembali kasing, dan mengembalikannya kepada saya dengan daftar bug poin-poin.

Menurut pendapat saya, saya percaya bug berujung peluru ini harus dibuka sebagai kasus bug individu, sehingga mereka dapat dilacak dengan lebih mudah, dan tidak menjadi berantakan dengan catatan kasus fitur asli.

Manajer saya tidak setuju dengan saya yang menyatakan bahwa lebih mudah untuk menyelesaikan total waktu yang dihabiskan untuk fitur tersebut jika semuanya dalam satu kasus.

Selain itu mereka percaya itu kurang membingungkan bagi klien kami karena mereka hanya memiliki 1 referensi nomor kasus untuk fitur ini. Namun saya akan menekankan bahwa bug harus ditangani sebagai kasus yang terpisah karena ini adalah pasca-penyelesaian dari kasus aslinya.

Apakah saya benar dalam menyatakan bahwa bug harus dibuka kembali sebagai kasing baru? Dan apa pro / kontra dari setiap cara mengelola ini?



2
Saya tidak berpikir bahwa ini adalah duplikat nyata, serupa, tetapi ada perbedaan penting: Ini tentang fitur baru yang sedang diterapkan dan waktu pulang-pergi yang relatif singkat ke pengembang. The jawaban kekuatan (atau kekuatan tidak) serupa, tapi pertanyaannya adalah berbeda
Joachim Sauer

1
Tapi mungkin saya salah membaca ini. Apakah bug ditemukan oleh QA / sebelum rilis dilakukan? Atau apakah ini "beberapa bulan kemudian" -kasus?
Joachim Sauer

2
@Curt: itu tidak benar-benar mengubah fakta bahwa dia tidak boleh menutup tiket kecuali dia yakin itu Selesai (untuk apa pun definisi Anda tentang ini).
Joachim Sauer

3
Anda dapat membuka kasing anak dari kasing utama untuk dilacak, semuanya akan didaftar dengan kasing utama saat Anda mencarinya
JF Dion

Jawaban:


10

Baik Anda maupun manajer Anda memiliki alasan yang kuat untuk melakukan transaksi seperti yang Anda masing-masing sukai, dan tidak ada kebutuhan nyata untuk berkompromi. Ada solusi yang berfungsi untuk saya dan mengatasi kedua masalah tersebut.

Untuk kasus seperti Anda, saya menggunakan pendekatan tugas tingkat tinggi / sub-tugas tingkat rendah (konsep yang saya pilih dari JIRA , tidak dapat memastikan apakah FogBugz mendukungnya secara eksplisit seperti yang dilakukannya ). Dengan cara ini, daftar berpoin "yang menghadap klien" menuju ke tugas-tugas tingkat tinggi sementara "iterasi pengembang" yang penting bagi saya tercermin dalam sub-tugas.

Ketika tugas tingkat tinggi "dibuka kembali", saya membuat sub tugas baru untuk melacak upaya tambahan untuk diri sendiri .

http://i.stack.imgur.com/ng4jn.jpg

Dengan cara itu memungkinkan pengembang untuk secara jelas merefleksikan semua permutasi, penyimpangan, dan tikungan yang dilalui oleh spesifikasi fitur, masih membiarkan manajer untuk menyajikannya kepada klien seolah-olah-sempurna. Omong-omong presentasi as-if-perfect memiliki nilai bagi saya sebagai pengembang - karena membuatnya lebih mudah dibaca untuk klien membantu dalam mendapatkan penyesuaian yang lebih akurat.

Ini juga secara alami memungkinkan untuk memiliki justifikasi yang jelas dalam kasus-kasus ketika implementasi fitur membutuhkan lebih banyak waktu daripada yang diperkirakan semula.

Adapun pelacakan waktu per tugas atau sub-tugas - karena JIRA memungkinkan untuk memasukkan pelacakan sub-tugas ke dalam ringkasan tingkat yang lebih tinggi, dapat diterima bagi manajer bahwa saya melacak waktu dalam sub-tugas. Namun, bahkan jika ini bukan masalahnya, saya bisa hidup dengan waktu pelacakan formal dalam tugas "induk" - dalam hal ini saya hanya akan menggunakan komentar sub-tugas untuk menyatakan berapa banyak waktu yang telah dihabiskan untuk iterasi tertentu.


3
FogBugz mendukung subtugas - membuat satu kasing per bug, dan kemudian menetapkan kasing asli sebagai induk masing-masing kasing. Bahkan akan meringkas jumlah total waktu yang Anda habiskan per bug plus orang tua, sementara juga secara individual melacak waktu masing-masing kasus bug yang dihabiskan.
Tacroy

+1 Terima kasih Agas, ini sangat membantu dalam argumen saya untuk penggunaan kasing terpisah untuk bug, dan bagaimana mereka masih dapat dihubungkan dengan fitur asli
Curt

@Curt semoga beruntung. Perlu diingat bahwa ini ada banyak hubungannya dengan memilih pertempuran Anda dengan benar. Apa pun yang mereka bersikeras miliki dalam "tugas orang tua", jangan berkelahi terlalu keras - biarkan mereka menggantung di tali mereka sendiri. Sub-tugas Anda adalah benteng Anda - ini harus menjadi garis pertahanan Anda. Namun, Anda mungkin benar - benar perlu mempertahankannya - fakta bahwa manajer Anda tidak dapat menemukan solusi itu, membuat saya bertanya-tanya apakah mereka cukup memenuhi syarat dalam melacak upaya pengembangan
gnat

7

Jika ini semua terjadi sebelum fitur dirilis ke pelanggan maka hanya ada satu kasing. Argumen di sini adalah bahwa kasus ini tidak benar-benar selesai sampai QA berlalu dan siap untuk dirilis. Manfaat lain - nomor kasus tunggal untuk penagihan dan pengguna akhir sebagai referensi adalah valid dan penting.

Setelah fitur telah dirilis dan bug ditemukan ini harus dinaikkan sebagai masalah baru dalam perangkat lunak pelacakan masalah Anda.


5

Saya setuju dengan Anda sepenuhnya, dan begitu juga FogBugz - itulah sebabnya ia mendefinisikan berbagai kategori untuk Bug dan Fitur. FogBugz tidak dirancang untuk menjadi alat untuk melacak penggunaan waktu; ini adalah produk sampingan yang tidak disengaja dari pengenalan penjadwalan berbasis bukti.

Bug untuk fitur yang diselesaikan dapat ditautkan ke kasing utama untuk fitur (di FogBugz, dengan menggunakan nama tag, atau referensi silang, atau dengan membuatnya sub-kasing). Saya dapat melihat bahwa ini sedikit lebih banyak pekerjaan untuk PM Anda untuk mengkonsolidasikan informasi di beberapa kasus, tetapi sering juga masuk akal untuk dapat memisahkan waktu yang dihabiskan untuk pengembangan asli dan waktu yang dihabiskan untuk pemeliharaan, terutama untuk kontrak harga tetap, dan Anda kehilangan kemampuan untuk melakukan ini jika Anda memasukkan semuanya ke dalam satu kotak.


3

Pendapat saya bahwa sekali tiket ditutup harus tetap ditutup, pelacak bug Anda harus mampu menghubungkan ke kasus lain. Saya akan mencoba menunjukkan bahwa membuat bug baru dan menautkannya ke kasing asli memberikan manfaat yang lebih baik daripada metode yang Anda jelaskan.

  • klien masih dapat memiliki satu nomor referensi yang berisi tautan ke setiap bug.
  • setiap status bug dapat dilacak secara individual, memungkinkan untuk penentuan prioritas dan pelaporan status yang lebih baik.
  • memiliki bug terpisah akan memungkinkan Anda manajer untuk memecah waktu yang dihabiskan untuk bug vs menghabiskan waktu mengembangkan fitur baru, dan seharusnya hanya menjadi upaya tambahan minimal untuk mendapatkan jumlah total untuk semua bug yang terkait dengan perubahan dan pengembangan perubahan itu.
  • memisahkan bug memudahkan manajer Anda untuk mengumpulkan metrik lain seperti total bug, waktu rata-rata per perbaikan bug, rasio bug yang ditutup / sedang berlangsung / diperbaiki.
  • kasus terpisah per bug memungkinkan tugas dibagi lebih baik antara semua pengembang dan meminta pertanggungjawaban masing-masing untuk pekerjaan mereka sendiri, atau memungkinkan kemungkinan ini jika lebih banyak pengembang dipekerjakan di kemudian hari.

Satu-satunya keuntungan untuk pengaturan Anda saat ini adalah sangat sederhana untuk orang-orang yang bukan pengguna utama sistem. Tujuan pelacak bug adalah agar pengembang memiliki tempat untuk melaporkan segala sesuatu tentang bug di satu tempat yang juga cukup ramah bagi orang lain untuk melihat perkembangannya, sistem Anda saat ini tampaknya merusak hampir setiap bagian dari itu.


Saya sebagian besar setuju dengan "tiket tertutup harus tetap ditutup", tetapi selalu ada pengecualian, seperti jika bug diperkenalkan kembali, seperti yang dapat terjadi dengan kemunduran (atau lebih buruk, jika bagian dari proyek hilang dan perlu dipulihkan dari cadangan).
zzzzBov

@zzzzBov itu adalah pengecualian yang cukup signifikan, dan jika Anda menemukan diri Anda dalam posisi itu, saya ragu bagaimana Anda menangani pelacakan bug adalah masalah pada saat itu.
Ryathal

1

Apakah bug ditemukan sebelum atau setelah produk telah 'dikirim / dirilis' ke pelanggan?

Jika sebelum rilis, bug harus dilacak terhadap tiket asli.

Jika setelah rilis, setiap bug harus menjadi tiketnya sendiri.


Kami menyalin aplikasi ke server pengembangan tempat klien dapat mengakses situs. Terkadang bug ditemukan secara internal, kadang-kadang ditemukan oleh klien. Apakah Anda menyarankan bug yang ditemukan secara internal (oleh PM) berarti kasing harus dibuka kembali dan bug terpasang di bagian bawah kasing / tiket?
Curt

Jika bug ditemukan sebelum rilis, mereka harus diperlakukan seolah-olah fitur tidak selesai. Lihat jawaban dari ChrisF.
Colin D

1

Di mana saya bekerja, hanya orang-orang QA yang bisa menutup sebuah kasus. Kami memiliki kotak centang untuk Kode Tinjauan, Insinyur Diuji, dan Demo ke Stakeholder (dalam kasus Anda Manajer Proyek). Jika tim QA melihat kasus yang ditandai sebagai "Selesai" yang tidak memiliki semua bidang ini ditandai, mereka akan menandainya dibatalkan dan mengirimkannya kembali kepada kami.

Setelah sebuah case telah melewati semua fase ini dan QA menutup case, setiap masalah baru yang mereka temukan dicatat sebagai bug.

Sistem ini tampaknya bekerja dengan baik untuk kita.


0

Saya pikir Anda bisa membuat argumen dua arah. Saya akan mencoba untuk duduk dengan PM dan menjelaskan mengapa Anda berpikir memiliki masalah tersendiri akan membantu Anda. Saya pribadi ingin setiap item todo harus menjadi tiketnya sendiri tetapi saya bisa melihat mengapa dia menginginkannya seperti itu.

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.