Bagaimana memengaruhi prioritas bug ke pengembang dan memperlakukannya sesuai?

Kami memiliki proses bug yang saat ini sedang dikerjakan.

Kami memiliki 3 level bug:

Bug P1: Bug yang mencegah pengguna bekerja. Mereka harus dipecahkan di tempat.
P2 bug: Bug yang berdampak tetapi pengguna dapat bekerja
Bug P3: Bug yang tidak berdampak dan di mana pengguna dapat bekerja.

P1 wajib dan harus ditangani saat itu juga. Tetapi untuk P2 dan P3, kami menilai berdasarkan kasus per kasus.

Dengan 3 level yang kami miliki, tim memiliki kecenderungan untuk bekerja pada perkembangan baru yang lebih mendesak yang diminta oleh pelanggan, daripada berurusan dengan P2 dan P3, yang hampir seperti tidak mendesak.

Pertanyaannya adalah sebagai berikut:

Haruskah saya menambahkan tingkat prioritas lain, seperti memiliki P4?

Haruskah saya juga menetapkan target untuk berurusan dengan tiket tidak mendesak seperti di minggu ini, ketika tidak menetapkan tugas pengkodean, Anda harus memperlakukan setidaknya 1 P2?

Saat ini, kami tidak memiliki tujuan seperti yang saya kemukakan di atas, tetapi kekhawatiran saya adalah memberi mereka tujuan seperti itu bisa brutal. Hal yang pasti adalah saya perlu berbicara dengan mereka tentang tujuan, tim suka terlibat dalam diskusi terutama ketika kita menetapkan tujuan.

Memperbarui:

Saya mengajukan pertanyaan ini dalam hal kesamaan. Namun tidak sama sekali.

Pertanyaan saya adalah bagaimana membuat orang berurusan dengan bug, tanpa memaksakan agenda yang ketat dan belum menyelesaikannya. Jadi tidak, pertanyaan yang tersirat tidak membantu saya. Tetap terima kasih.

agile debugging issue-tracking

— Andy K
sumber

Kemungkinan duplikat dari Bagaimana saya bisa meyakinkan manajemen untuk berurusan dengan hutang teknis?

— nyamuk

biasanya tingkat prioritas tidak berguna seperti pemesanan prioritas ... "bug X" lebih penting daripada "bug Y". jika Anda menambahkan p4 pada akhirnya Anda akan menginginkan p5 dan p3.5

— sudo rm -rf slash

Jika Anda memiliki begitu banyak bug P1 sehingga semua pengembang Anda selalu sibuk memperbaikinya daripada bekerja pada P2 / P3, Anda melakukan sesuatu yang sangat salah. Jangan menambahkan fitur lagi untuk sementara waktu. Fokus pada menelusuri dan memperbaiki masalah arsitektur (atau personil) yang hampir pasti menyebabkan banyak bug ini. Jika Anda mengkode dalam C ++, misalnya, pastikan Anda menggunakan RAII di mana pun Anda bisa, jadi jangan lupa secara manual .release().

— Dana Gugatan Monica

Apa tujuanmu? Apakah Anda ingin pengembang bekerja lebih banyak pada perbaikan bug dan lebih sedikit pada fitur-fitur baru? Harap edit pertanyaan Anda untuk menjelaskan. Juga, tolong jelaskan bagaimana pengembang saat ini menerima atau melakukan pekerjaan? Apa yang digunakan untuk memutuskan apa yang akan dikerjakan?

— sleske

fitur, bug, ubah apa pun namanya, perangkat lunak tidak melakukan apa yang diperlukan. Satu-satunya perbedaan antara bug dan fitur adalah siapa yang membayarnya.

— mattnz

Jawaban:

Secara umum Anda memiliki dua sumbu untuk bug: gravitasi dan frekuensi.

Jadi jelas sesuatu yang serius dan sering adalah prioritas utama. Namun, sesuatu yang serius tetapi jarang terjadi harus ditimbang kira-kira sama dengan sesuatu yang tidak serius tetapi sering terjadi. Jadi seandainya Anda menilai gravitasi dari 1 hingga 3 dan frekuensi dari 1 hingga 3, jenis bug yang mungkin harus Anda perbaiki adalah yang melintasi lintas diagonal yang ditentukan oleh gravitasi 1, frekuensi 3, dan gravitasi 3, frekuensi 1.

Kesalahan pemblokiran atau kesalahan yang bisa membuat potensi kerusakan pada informasi klien akan selalu menjadi gravitasi 3. Demikian pula, kesalahan dengan gravitasi 1 kemungkinan tidak akan diketahui oleh pengguna atau memiliki prioritas rendah. Jika Anda tidak yakin di sini, 2 mungkin adalah nomor yang aman untuk ditetapkan.

Kesalahan yang dilihat pengguna setiap kali program diluncurkan akan memiliki frekuensi 3. Kesalahan dengan frekuensi 1 akan menjadi sesuatu yang jarang terjadi jika sama sekali. Sekali lagi, jika Anda tidak yakin, 2 mungkin nomor yang aman untuk ditetapkan.

Ini sebagian besar subjektif pada apa yang merupakan bug dengan gravitasi 3 atau bug dengan frekuensi 3, tetapi gunakan akal sehat Anda. Bug dengan gravitasi 1, frekuensi 2 mungkin merupakan label yang salah eja. Bug dengan gravitasi 2, frekuensi 1, mungkin penanganan kesalahan yang tepat ketika koneksi database sedang turun.

Sekali lagi, ini hanya ide kasar, tetapi idenya adalah untuk memberikan penekanan pada apa yang seharusnya menjadi fokus untuk memperbaiki bug sebagai semacam triase. Jelas tidak mungkin untuk menghilangkan semua bug, memblokir atau sebaliknya, meskipun setidaknya dengan metodologi ini, Anda dapat dengan aman mengatakan bahwa bug tidak terlalu menekan atau terlalu sering. Jika Anda hanya memperbaiki bug yang memblokir kesalahan, maka kesalahan frekuensi tinggi akan diabaikan dan pengguna akan melihat bahwa Anda tidak memperbaiki bug ini.

Juga, untuk kenyamanan, Anda mungkin menemukan Anda lebih suka memberikan nilai huruf untuk gravitasi atau frekuensi, sehingga Anda dapat mengatakan bahwa bug adalah kesalahan B3, dan jelas gravitasi dan frekuensinya.

Semoga berhasil!

— Neil
sumber

Pada kenyataannya, hanya ada satu metrik untuk bug - ROI - berapa biayanya untuk memperbaikinya dibandingkan dengan berapa banyak kerugian perusahaan karena tidak memperbaikinya. Bandingkan dengan fitur-fiturnya. Tentu saja, bagaimana Anda menghitung bahwa metrik melibatkan gravitasi, frekuensi, dll.

— corsiKa

@corsiKa, ya ROI adalah metrik gabungan: "pengembalian" dan "investasi". Dan untuk bug, return dapat dimodelkan sebagai gabungan dari "gravitasi" dan "frekuensi".

— Paul Draper

@corsiKa, semacam analisis egois berdarah dingin tentang keputusan kualitas sebenarnya sangat tidak bertanggung jawab. Ini adalah logika yang sama yang mengarah pada perusahaan farmasi yang menghindari undang-undang pengujian kemanjuran jika mereka dapat "lolos begitu saja," atau mempertahankan obat yang menguntungkan di pasaran terlepas dari keparahan dan frekuensi efek samping. Ini sama tidak bertanggung jawabnya yang mengarah ke botnet besar yang terdiri dari router konsumen yang tidak aman dan perangkat "pintar", karena produsen tidak dapat melihat nilai dolar dalam keamanan yang baik. Gravitasi dan frekuensi adalah metrik yang JAUH lebih baik daripada "dampak garis bawah."

— Wildcard

@Wildcard Saya benar-benar seorang komunis, jadi saya 100% setuju dengan Anda bahwa itu lebih baik. Itu tidak mengubah fakta bahwa ini adalah bagaimana perusahaan perangkat lunak dijalankan, dan melawan arus itu, kecuali jika Anda menjalankan perusahaan, akan menenggelamkan Anda. Meskipun patut dicatat, itu tidak egois. Ini melayani satu orang, tetapi itu bukan diri sendiri, itu adalah perusahaan. Hanya, melempar itu ke sana.

— corsiKa

@Wildcard dan corsiKa perusahaan ini bukan perusahaan besar dan kami tidak mampu mengatakan "oh kami akan kehilangan uang, maka mari kita lakukan sesuatu kalau tidak mari kita tetap menyimpannya". Namun, dalam skema besar ini, saya tidak percaya bahwa pendekatan yang Anda sebutkan itu berkelanjutan dalam jangka panjang. Orang - Pelanggan jauh dari bodoh. Perusahaan-perusahaan yang telah memberitakan Injil semacam itu, Sun, untuk menyebut satu tidak ada lagi di sini. Saya telah bekerja dalam manajemen akun cukup lama sehingga uang tidak menghasilkan seperti itu. Untuk siapa pun, jika Anda kebetulan bekerja untuk perusahaan seperti itu di mana perusahaan tersebut tidak memiliki loyalitas 1 / n

— Andy K

Ini benar-benar bermuara pada apa yang Anda anggap lebih penting. Bug P2 atau fitur baru?

Biasanya sistem manajemen proyek yang gesit akan mencakup semacam pertemuan prioritas di mana tugas-tugas dipesan berdasarkan prioritas dan dikerjakan dalam urutan itu.

Pengembang tidak diizinkan untuk memilih tugas yang mereka kerjakan. Itu pekerjaan manajer proyek. Siapa yang harus memastikan bahwa proyek tersebut memiliki kemungkinan fitur-fitur penting sebanyak mungkin sebelum anggaran habis.

Itu benar-benar hal yang paling penting. Aturan sederhana seperti "perbaiki setidaknya 1 P2 seminggu" tidak terlalu membantu sasaran ini.

— Ewan
sumber

Masalahnya dengan menetapkan prioritas adalah bahwa apa pun granularitas bucket yang Anda pilih, Anda selalu berakhir dengan lebih dari satu ember. Anda perlu menertibkan, bukan hanya mengatakan "semua ini PRIORITAS TOP!"

— Ewan

@ Ewan Ada juga kemungkinan inflasi prioritas di mana ember tertinggi Anda memiliki lebih banyak masalah daripada yang dapat Anda harapkan untuk diatasi, dan tingkat prioritas baru diciptakan di luar sistem pelacakan kutu. Saya telah mendengar orang berbicara tentang P minus 2 masalah.

— kasperd

Mengatakan pengembang tidak diizinkan untuk memilih tugas yang mereka kerjakan akan merusak produktivitas Anda. Jika pengembang diblokir pada masalah prioritas tertinggi yang sedang mereka kerjakan, lebih baik jika mereka dapat mengerjakan masalah lain sementara itu daripada mereka tidak melakukan apa-apa sementara masalah pertama mereka diblokir pada sesuatu. Selain itu masalah yang tidak merugikan pengguna tetapi merugikan produktivitas pengembang sering tidak diprioritaskan setinggi seharusnya. Akhirnya, memberi tahu pengembang bahwa mereka tidak diizinkan membuat keputusan sendiri adalah cara yang pasti untuk menghancurkan motivasi.

— kasperd

@kasperd Saya pikir sebagian besar pengembang menerima bahwa mereka adalah karyawan dan juga super jenius teknis dan menerima bahwa majikan mereka harus memutuskan tugas mana yang harus dilakukan terlebih dahulu. Jelas jika satu diblokir Anda akan pindah ke yang paling penting berikutnya, tetapi Anda tidak melewatkan 10 tugas penting untuk bekerja pada yang keren.

— Ewan

Saya telah menemukan bahwa jika pekerjaan selesai atau diblokir, alih-alih menarik tugas pengembangan lain ke sprint (melakukan scrum) bug seharusnya mengambil prioritas. MS terkenal memberikan semua bug prioritas tertinggi daripada tugas pengembangan ketika bekerja pada Windows 2000 - mereka menemukan bahwa itu adalah cara terbaik untuk menghasilkan perangkat lunak non-kereta (salah satu alasan bahwa 2000 sebenarnya disukai) seolah-olah mereka tidak melakukannya. , bug akan cenderung ketinggalan karena biasanya ada beberapa perkembangan baru untuk dikerjakan.

— Baldrickk

Ini adalah siklus yang cukup umum bagi suatu perangkat lunak untuk menumpuk bug yang tidak penting sampai sesuatu memberi, kemudian peristiwa besar terjadi dan banyak dari mereka diperbaiki pada satu waktu; mungkin dengan mendedikasikan satu atau dua sprint hanya untuk perbaikan bug sebelum rilis baru yang besar, atau oleh perangkat lunak yang EOL dan telah selamat dari heap-o-bug.

Jadi, Anda berada di perusahaan yang baik jika pengembang Anda membiarkan mereka meluncur. Tentu saja Anda bisa bermain-main dengan "aturan" seperti yang Anda sebutkan ("jika Anda tidak bekerja pada fitur baru, Anda harus bekerja pada setidaknya satu P2 per minggu"), tetapi itu kemungkinan hanya akan membuat Anda tidak populer.

Pertanyaan saya adalah bagaimana membuat orang berurusan dengan bug, tanpa memaksakan agenda yang ketat dan belum menyelesaikannya.

Sebagai gantinya, saya akan menyarankan untuk mengubah pola pikir keseluruhan sedikit, dan membuat fitur bug lebih seperti dalam arti bahwa mereka adalah warga negara kelas satu di backlog Anda. Ya, fitur baru sangat bagus; ya, manajemen dan penjualan sangat menyukai fitur-fitur baru. Tetapi memiliki aplikasi yang stabil dan berfungsi baik alih-alih tumpukan besar bug yang berantakan juga penting.

Jangan beri tahu devs Anda bahwa mereka harus melakukan pekerjaan yang tidak mereka sukai; tetapi cobalah untuk mengubah athmosphere sehingga mereka suka mengerjakan bug. Cobalah untuk menanamkan rasa bangga pada aplikasi bebas bug. Jadikan lebih menyenangkan untuk bekerja pada bug dengan secara khusus memungkinkan mereka untuk benar-benar memperbaiki alasan mendasar yang membuat bug itu bermanifestasi (yaitu, bukan hanya solusi cepat / peretasan), jika ada. Merobek beberapa struktur kelas yang rusak dan menggantinya dengan sesuatu yang lebih cocok bisa sangat menghibur bagi para devs. Jika Anda memiliki bagian tengah yang patah yang secara teratur membuat bug bermanifestasi di tempat lain, perbaiki bagian tengah tersebut.

Bagaimana Anda mencapai tujuan Anda sangat tergantung pada karakter Anda sendiri dan karakter tim Anda - jangan coba membodohi mereka dengan apa yang ingin Anda capai, tetapi berdiskusi terbuka, mencoba menjalankan efek teman sebaya, biarkan mereka datang dengan proses kerja sendiri, dan sebagainya.

— AnoE
sumber