Mengapa kita membutuhkan Prioritas dan Tingkat Permasalahan?

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.

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 .

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.

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.

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

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?'.

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.

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.