Mengapa kita membutuhkan Prioritas dan Tingkat Permasalahan?


11

Saya mengerti apa yang mereka tentukan, tetapi apakah benar-benar berguna untuk menetapkan itu untuk masalah yang ditemukan? Maksud saya, harus diperbaiki dengan cepat atau tidak.

Saya tahu cara mengaturnya, mengelompokkannya, dll. Saya tahu IEEE / ISO harus melakukannya. Saya hanya tidak mengerti mengapa.


Hmm, saya pikir bug yang akan merusak data lebih parah daripada sesuatu yang hanya mengganggu seperti mengatakan beberapa fungsi butuh waktu terlalu lama untuk memuat. Keduanya harus diperbaiki tetapi yang berdampak negatif lebih tinggi harus diperbaiki terlebih dahulu.
thorsten müller

Tidak, seperti yang saya tulis saya tahu apa itu atau bagaimana mengaturnya. Saya hanya tidak melihat manfaatnya.
Pietross


Dalam kebanyakan kasus, tidak. Tetapi selalu ada kasus tepi di mana masuk akal untuk memisahkan keduanya. Apakah pemisahan itu layak dipertahankan untuk setiap masalah hanya untuk memenuhi kesempatan-kesempatan langka itu adalah masalah lain.
biziclop

1
Anda dapat memiliki bug UI yang tidak terlalu memengaruhi kegunaan aplikasi ( keparahan rendah ), tetapi merupakan prioritas tinggi karena jelek. Anda dapat memiliki bug yang membuat aplikasi benar-benar macet ( keparahan tinggi ) tetapi merupakan prioritas rendah karena kondisi untuk mewujudkannya adalah satu dalam sejuta dan dalam semua hal praktis tidak akan pernah benar-benar terjadi (ini mengabaikan fakta bahwa satu-dalam- satu juta peluang muncul sembilan dari sepuluh ).
Binary Worrier

Jawaban:


24

Sangat mungkin untuk memiliki nilai-nilai tersebut berbeda. Jika Anda memiliki penjualan untuk membuat ke lembaga pemerintah penting yang membutuhkan kinerja tinggi tetapi tidak akan pernah menggunakan modul X, maka masuk akal bisnis untuk memperbaiki kesalahan ketersediaan basis data kecil lebih cepat daripada kesalahan parah dalam modul X. Pada dasarnya, alasan teknis bukan satu-satunya faktor ketika Anda menjalankan bisnis perangkat lunak .


Tepat: Prioritas menunjukkan nilai bisnis dan merupakan hasil dari manajemen proyek. Tingkat keparahan mengindikasikan dampak dan merupakan hasil dari bug. Setiap tugas dapat memiliki prioritas, tetapi mis. Fitur baru tidak memiliki tingkat keparahan. Selain dari bug dengan tingkat keparahan tinggi yang kritis terhadap keamanan, bodoh jika membiarkan tingkat keparahan saja yang menentukan prioritas, atau orang-orang akan salah insentif untuk melebih-lebihkan keparahan masalah mereka.
amon

5
Saya pikir yang penting adalah bahwa hanya satu ukuran (prioritas) yang mengontrol urutan pembangunan secara langsung. Betapa berguna tim menemukan "keparahan" tambahan sebagai bagian dari deskripsi cacat sangat opionated: beberapa mungkin merasa itu membantu, yang lain seperti @arnaud berpikir itu "birokrasi" - kedua sudut pandang mungkin masuk akal.
Doc Brown

4
Prioritas Tinggi, Severitas Rendah: Halaman arahan aplikasi Anda, dilihat oleh jutaan pengguna sebulan, memiliki kesalahan ketik pada nama perusahaan Anda. Prioritas Rendah, Keseriusan Tinggi: Sistem crash 25% dari waktu pada startup untuk aplikasi yang sedang pensiun minggu depan.
Gort the Robot

2
Tingkat keparahan umumnya dapat ditentukan oleh aturan oleh penguji otomatis dan langsung. Prioritas hanya dapat dievaluasi secara subyektif oleh bisnis.
Gort the Robot

3

Bug tanggal dan waktu

Bug: Pemrosesan akhir tahun akan benar-benar merusak database Anda. Itu jelas bug yang parah.

Tanggal: 15 Desember. Bug ini prioritas sangat tinggi.

Tanggal: 1 Februari. Bug ini prioritas rendah.


Peluncuran bug rudal secara tidak sengaja

Bug: Perangkat lunak kontrol ICBM muntah ketika pergi dari 28 Februari hingga 1 Maret dalam tahun habis dibagi 4. Hasilnya adalah peluncuran tanpa perintah.

Itu adalah bug yang sama parahnya dengan yang ada. Prioritas sangat rendah - apakah ada kemungkinan realistis perangkat lunak akan digunakan ketika kondisi dipicu?


Kata-kata 'buruk' yang tidak sengaja di layar

Bug: Pesan-pesan yang meluap-luap di layar mereka menghasilkan referensi profan yang tidak disengaja kepada Bob yang muncul. (Dunia nyata: Kami memiliki orang yang bekerja di departemen "Final Ass". "Ass" = "Assembly".)

Sayangnya, besok Anda membuat presentasi di mana mendapatkan penjualan membuat-atau-istirahat untuk perusahaan. Anda membuat presentasi kepada seseorang bernama "Bob". Tingkat keparahan: Sangat rendah. Prioritas: Sangat tinggi.


Terkait dengan bug 'meluap' dan 'tanggal waktu' yang Anda sebutkan - Anda dapat menikmati bug fase bulan

0

Kau menulis:

Maksud saya, harus diperbaiki dengan cepat atau tidak.

Itu betul. Namun, jika Anda seperti kebanyakan perusahaan, sumber daya Anda terbatas. Entah Anda tidak punya cukup banyak orang untuk memperbaiki semua masalah, atau Anda tidak punya cukup waktu.

Mengingat fakta bahwa bug diharuskan diperbaiki dengan cepat atau tidak, dan Anda memiliki banyak bug yang perlu diperbaiki, "prioritas" menjawab pertanyaan "mana yang harus saya perbaiki"?

Keparahan, di sisi lain, adalah indikator yang digunakan oleh orang yang menetapkan prioritas. Dari sudut pandang pengembang, tingkat keparahannya adalah titik diperdebatkan. Dari perspektif pekerjaan penugasan, keparahan adalah bagian penting dari informasi yang membantu proses pengambilan keputusan.

Tentu saja, semua ini adalah informasi yang sangat umum. Jika Anda adalah tim dengan tumpukan bug yang sangat panjang, prioritas dan tingkat keparahan berarti sesuatu yang sama sekali berbeda daripada jika Anda berada di tim yang memiliki basis data bug yang hampir kosong.

Jika Anda berada di tim di mana "keparahan tinggi == prioritas tinggi" tidak ada yang penting dan Anda tidak perlu kedua metrik. Pada akhirnya, ini hanyalah alat. Tim Anda perlu memutuskan cara menggunakannya. Untuk tim Anda, mungkin tidak masuk akal untuk menggunakan keduanya.


0

IMHO, menempatkan Prioritas dan Tingkat Permasalahan hanyalah birokrasi.

Dalam praktiknya, Anda hanya perlu satu ukuran "penting". Seringkali, prioritas digunakan untuk itu, dan keparahan kemudian digunakan sebagai istilah teknis seperti "sistem crash = tinggi atau membuatnya tidak dapat digunakan", "medium = perilaku kereta, berpotensi berbahaya", "gangguan = rendah, menjengkelkan tetapi tidak berbahaya"

Biasanya, prioritas berjalan seiring dengan keparahan. Beberapa contoh balasan adalah "gangguan di mana semua orang selalu mengeluh" atau "kecelakaan pernah terjadi sekali di lingkungan yang eksotis".

... tetapi, pada akhirnya, sebagai pengembang (atau manajer, dll) Anda hanya perlu tahu dalam urutan apa Anda harus memperbaiki / meningkatkan sesuatu, itu saja. Jadi satu ukuran sudah cukup.

Kebutuhan prioritas jelas: ini untuk mengetahui bagaimana laporan bug harus ditangani. Yang lain, IMHO seperti biasa, adalah birokrasi. Mengapa Anda membutuhkannya? Tampaknya tidak berguna untuk menyortir karena prioritas melakukan itu. Dan konsekuensinya (deskripsi tingkat permasalahan) dijelaskan dalam laporan bug.

Saya bahkan berpikir itu berbahaya karena membuatnya kurang jelas bug apa yang lebih penting:

  • Beberapa orang mungkin berpikir bug "kritis" memiliki prioritas lebih tinggi daripada bug "prioritas tinggi".
  • Beberapa pengguna yang melaporkan bug mungkin mengacaukan tingkat keparahan dan prioritas
  • ... sama sekali, itu agak menambah kebingungan tentang urutan bug apa yang harus ditangani

1
Dan apakah pengembang satu-satunya orang yang penting?
biziclop

2
@biziclop Tidak, Anda benar, itu adalah formulasi saya yang buruk. Ini berlaku untuk semua orang: yang penting, untuk manajer, dll juga, adalah apa yang harus diperbaiki terlebih dahulu, dan apa yang kurang penting. Untuk itu, satu ukuran sudah cukup.
dagnelies

1
Yah, itu salah dari perspektif manajemen risiko - prioritas = tingkat keparahan * tingkat kejadian. Apakah kesalahan ketik pada usia frontp lebih rendah daripada crash server fatal yang terjadi jika nama belakang pengguna melebihi 46 karakter?
Pietross

1
@ Pietross: well, Anda menaruhnya: yang mana yang harus ditangani lebih dulu? Kecelakaan terputus berprioritas rendah atau gangguan prioritas tinggi? Bagaimana Anda memprioritaskan? Siapa yang menghakimi? Semua orang melihat daftar? Ketika hanya menggunakan satu ukuran prioritas, itu diprioritaskan sekali, lalu selesai. Dampak dan keparahannya dijelaskan dalam laporan bug.
dagnelies

Hal tentang "severity" adalah Anda dapat dengan mudah mengatakan "crash = high, typo = low". Diperlukan pemikiran untuk menyadari bahwa kesalahan ketik yang membuat 'o' keluar dari kata 'hitung' di beranda adalah prioritas yang lebih tinggi untuk diperbaiki daripada laman yang menolak memuat sama sekali.
Gort the Robot

0

Selain jawaban lain, pertimbangkan skenario ini: bug A akan membutuhkan waktu 30 menit untuk memperbaikinya dan memiliki tingkat keparahan 'rendah'; bug B mungkin membutuhkan waktu 2+ minggu untuk memperbaikinya dan memiliki tingkat keparahan 'tinggi'. Selain itu, bug B dapat mengambil banyak diskusi dan koordinasi dalam tim pengembang dan mungkin di luar tim; bug A dapat segera diperbaiki oleh pengembang tunggal. Tidak apa-apa untuk menetapkan prioritas yang lebih tinggi pada bug A.

Tentu saja 'keparahan' dan 'prioritas' dapat diartikan dengan cara yang berbeda.

Dalam pelacak bug kecil yang saya buat untuk saya gunakan sendiri, saya lebih suka 'kesulitan' dan 'prioritas' di mana masalah tingkat keparahan tinggi selalu memiliki prioritas tertinggi, dan saya mungkin memutuskan untuk menunda mengerjakannya berdasarkan kesulitan.

Satu hal yang saya tidak suka tentang 'keparahan' adalah bahwa itu hanya berlaku untuk bug dan bukan fitur. Mungkin lebih baik memiliki satu daftar semua masalah yang disusun berdasarkan prioritas dan kesulitan karena lebih langsung membantu untuk memutuskan 'apa yang akan saya kerjakan selanjutnya?'.


0

Saya telah merancang dan mengimplementasikan proses di perusahaan perangkat lunak yang disertifikasi ISO9001: 2007. Telah ada pembaruan standar sejak 2007 sehingga mungkin ada persyaratan tambahan yang saya tidak ketahui ... namun:

Standar ISO9001 adalah tentang memastikan bahwa perusahaan Anda merancang dan mengimplementasikan proses yang memiliki loop umpan balik untuk meningkatkan proses ketika cacat produk dan proses diidentifikasi.

Selama fase desain, persyaratan fokus pada apakah solusi yang diusulkan jika diterapkan dengan benar akan benar-benar menyelesaikan brief desain (validasi) dan memeriksa apakah implementasi sebenarnya telah dilaksanakan tanpa cacat (verifikasi)

Pada loop umpan balik, ketika cacat diidentifikasi, itu tidak cukup bahwa mereka dicatat. Cacat juga perlu dinilai untuk tingkat keparahannya, dan pengerjaan ulang diprioritaskan.

Bagian kuncinya adalah bagaimana perusahaan Anda memutuskan untuk menilai tingkat keparahannya, dan membuat keputusan tentang prioritas tidak ditentukan oleh standar ISO. Ini adalah masalah komersial dan tata kelola bagi perusahaan untuk memutuskan dan mendokumentasikan.

Seperti yang tertulis dalam standar sebagai persyaratan, setiap perusahaan bersertifikat akan memiliki proses sekitar menilai tingkat kerusakan dan proses dalam menentukan prioritas pekerjaan untuk memperbaiki bug. Mereka jelas merupakan dua keputusan terpisah yang perlu dibuat.

Tingkat keparahan bug hanya satu titik data. Dampak pelanggan Adalah titik data lain. Ada juga upaya untuk memperbaiki, cacat usia, kehidupan komersial yang tersisa dalam produk, dan faktor lain yang perusahaan memutuskan untuk dimasukkan dalam pengambilan keputusan. Satu hal yang tidak boleh dituliskan sebagai “cacat saat ini bagi manajer produk untuk menentukan prioritas” karena hal itu hanya mendefinisikan otoritas untuk membuat keputusan dan tidak mendefinisikan proses yang mereka ikuti untuk membuat keputusan.

Saya memiliki preferensi untuk memprioritaskan yang condong ke arah memberikan tingkat tinggi perubahan kecil dan penting, karena ini tampaknya memberikan dorongan terbaik untuk keandalan produk secara keseluruhan. Ini berarti bahwa bug yang parah yang akan membutuhkan banyak pekerjaan untuk diperbaiki akan membutuhkan pekerjaan tersebut dipecah menjadi potongan-potongan kecil untuk mendapatkan prioritas yang cukup untuk dijadwalkan.


-3

Untuk alasan yang sangat berbeda prioritas dan tingkat keparahannya:

Contoh sederhana. Bayangkan jika Anda memiliki tempat sempit yang mencegah penskalaan sistem Anda - beberapa algoritma memiliki kompleksitas O (N ^ 3), di mana N adalah jumlah toko klien. Klien mengatakan akan membuka 200 toko baru tahun depan, dan perhitungan yang diperlukan (distribusi barang, perencanaan transportasi, dll.) Tidak akan selesai tepat waktu. Tetapi, saat ini klien ini hanya memiliki 30 toko, dan sumber daya cukup. Tugas untuk mengoptimalkan algoritma ini (ke O (N ^ 2) atau lebih baik) jelas penting (Anda akan kehilangan klien jika tidak diterapkan), tetapi kemungkinan tidak mendesak: Anda memiliki beberapa bulan untuk mengimplementasikan algoritma baru.

Contoh 2: aplikasi mogok secara sistematis, tetapi versi ini tidak digunakan dalam beberapa hari karena peningkatan atau migrasi. Perbaikan sangat mendesak karena kerusakan benar-benar memengaruhi pengalaman pengguna, tetapi tidak terlalu penting.

Tentu saja, kedua parameter disatukan menggunakan beberapa metrik (baik formal maupun informal) untuk menghasilkan rencana kerja jangka pendek, karena yang terakhir adalah satu dimensi (urutan tugas). Namun dalam pandangan jangka panjang mereka tidak akan disatukan.

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.