Saya bertanya kepada beberapa kolega tentang apa yang mungkin terjadi, dan mereka menyebutkan bahwa jika bug tidak memiliki tingkat prioritas seperti itu, sangat jarang Bug mendapatkan perhatian pengembang, yang memang masuk akal
Sebenarnya, jika Anda bertanya kepada saya, itu tidak benar. Semakin banyak (digunakan) tingkat prioritas, semakin banyak informasi yang Anda miliki. Jika Anda secara efektif hanya memiliki satu prioritas, itu sama dengan tidak memiliki prioritas sama sekali.
Dan karena Anda masih memiliki jumlah bug yang sama untuk diatasi, dan jumlah jam kerja yang sama untuk melakukannya, berarti beberapa heuristik lain akan digunakan, mungkin yang nol - "pertama datang, pertama dilayani". Dan sekarang Anda memiliki metrik prioritas bug, kecuali itulah saat kedatangan dan tidak lagi di bawah kendali Anda.
Ini bisa menjadi gejala tidak cukup sumber daya yang dialokasikan untuk memperbaiki bug (ada beberapa kebijakan seperti " Tidak ada fitur baru sampai bug diperbaiki " yang dapat membantu di sana. Joel menyetujui ; memahami batasan dan konsekuensi adalah keputusan bisnis ).
Dalam satu proyek yang saya kerjakan, bug yang masuk diakumulasikan dalam "tanpa prioritas buffer" dan setiap hari Senin kami akan meninjau daftar bug, memperkirakan kesulitan (perkiraan yang sangat kasar; lebih sering kita memasukkan, "Rata-rata") dan urutkan berdasarkan waktu yang tersedia. Ini memang cenderung menghancurkan daftar bug yang membosankan, tidak menarik atau dianggap sulit; untuk mengimbangi itu, pengawas dan pemasaran memiliki sejumlah kredit tertentu per minggu yang dapat mereka habiskan untuk menabrak prioritas bug favorit, dan diganti untuk bug yang tidak terpecahkan (ini menetapkan batas pada seberapa banyak bug yang dihina oleh pengembang dapat ditunda) .
Dimungkinkan juga untuk menggabungkan, membatalkan, dan memecah bug; Saya ingat satu modul yang sangat cacat sehingga kami menenggelamkan sekitar dua puluh atau tiga puluh laporan bug ke dalam satu "tulis ulang hal ini dari awal", yang kemudian dibagi menjadi "nyatakan dengan jelas input dan output dari barang yang celaka", "tulis tes untuk memastikan input dan output sesuai dengan spesifikasi ", dan seterusnya. Item terakhir adalah "cetak kode lama pada kertas daur ulang, bawa keluar di halaman dan bakar" (kami juga melakukan itu. Saya ingat betapa enak rasanya. Kami bergiliran pada pidato; itu sangat lucu; ).
Setelah beberapa tawar-menawar, kami memiliki daftar tugas minggu ini, yang terbagi dalam "akan melakukan", "mungkin" dan "tidak bisa" yang bertemu minggu depan. Di sinilah beberapa tawar-menawar masuk: kami telah mengatakan lima puluh jam untuk mengalokasikan ke bug, dan kami 95% yakin untuk memperbaiki dua puluh pertama. Manajemen sangat ingin bug dua puluh satu diperbaiki dan tidak ada kredit yang tersisa; kami kemudian akan menawarkan untuk menukar bug itu dengan yang ada di daftar "Akan lakukan", atau seseorang akan mengatakan "Keluarkan saya dari sub-sub FooBazFeature selama beberapa hari dan saya akan melakukannya", atau kami akan mengatakan "Kami membutuhkan lebih banyak tenaga kerja".
Sistem tidak memuaskan siapa pun, sungguh, tapi ini diyakini (setidaknya di antara para pengembang) sebagai pertanda baik.
Beberapa pola negatif tambahan yang muncul adalah "Wishful Thinking" pada bagian manajer ("Anda menyatakan bug 57212 membutuhkan delapan jam. Itu tidak dapat diterima. Jadikan empat") dan "Debug oleh Fiat" ("Lakukan apa pun yang Anda inginkan tetapi empat puluh bug ini harus diperbaiki sebelum demo besar minggu depan. Anda tidak dapat memiliki lebih banyak waktu, Anda tidak dapat memiliki lebih banyak orang "). Juga Sindrom Boxer ("Saya akan bekerja lebih keras"), yang cenderung bekerja sangat baik untuk waktu yang singkat , tetapi biasanya menyebabkan pengembang panik atau pergi ke padang rumput yang lebih hijau.