Hampir setiap bug yang dilaporkan adalah bug prioritas tinggi [ditutup]


50

Saya perhatikan sebuah pola ketika mengerjakan beberapa proyek perangkat lunak: sebagian besar bug yang dilaporkan memiliki prioritas tinggi / sangat tinggi. Saya bertanya kepada beberapa kolega tentang mengapa hal ini dapat terjadi, dan mereka menyebutkan bahwa jika bug tidak memiliki tingkat prioritas seperti itu, sangat jarang Bug mendapatkan perhatian pengembang, yang memang masuk akal.

Jadi, saya ingin tahu apakah masalah ini biasa atau jika saya kurang beruntung. Saya melakukan pencarian Google cepat, dan saya menemukan bahwa beberapa tim menerapkan pedoman Pelaporan Bug atau memiliki tim "Bug Triage" yang terpisah. Jika Anda telah menghadapi dan menyelesaikan masalah ini, apa pendekatan yang berhasil untuk Anda?

Pertanyaan ini secara khusus tentang masalah "Prioritas Inflasi": Jika Anda menghadapi skenario dan hasil pengukuran apa yang efektif terhadap masalah ini.


9
Inilah mengapa 'prioritas' itu bodoh. Apakah X a Prioritas 2 tidak ada artinya, apakah X lebih penting daripada Y yang dapat dijawab dan bermanfaat. Satu-satunya hal yang penting adalah ketertiban.
Nathan Cooper

7
@NathanCooper Ya, tapi Anda tahu, jika kita memiliki bug yang sangat penting, dan kita harus benar-benar memberikan sedikit dorongan ekstra kepada dev Anda tahu apa yang kita lakukan? Itu benar - kami menetapkan prioritasnya ke 11.
gbjbaanb

6
@CarlosGavidia demikian, Anda perlu cara untuk mengambil prioritas dari tangan langsung orang yang mengirimkan bug dan menemukan beberapa cara lain yang objektif untuk menentukan ROI untuk memperbaiki bug.

2
@JuliaHayward secara pribadi saya suka pef / rev meskipun melihat secara khusus pada metrik 'pain' untuk bug: Meningkatkan Bug Triage dengan User Pain juga sangat baik. Tidak satu pun dari ini yang memungkinkan orang yang melaporkan bug menetapkan prioritas bug secara keseluruhan ('prioritas' dalam metrik nyeri bug adalah tentang apa yang dibloknya - bukan tentang seberapa penting perbaikannya).

16
Kisah nyata: Saya pernah memecahkan masalah inflasi prioritas ini dengan memanggil pelanggan saya, dan mengancam akan mengganti nama prioritas yang berbeda menjadi "oranye," "kumquat," dan "orangutang," jika mereka tidak melakukan pekerjaan yang lebih baik dalam membedakan. serveritas cukup untuk membuat bidang tetap bermakna. Ini berhasil (yang sangat disayangkan, karena saya benar-benar memiliki hak admin untuk membuat tingkat keparahan "kumquat", dan saya agak menantikannya)
Cort Ammon

Jawaban:


42

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.


Cinta bagian "dibakar". Kami memiliki rencana serupa untuk salah satu modul kami :)
Roman Reiner

1
Saya terkesan bahwa Anda memiliki sistem yang terorganisir / dinegosiasikan dan masih berhasil membakar pengembang. Itu pasti proyek yang intens!
thanby

Sebenarnya, kami memiliki beberapa manajer yang hebat, dan tidak selalu dengan dinamika manusia yang baik. Jadi setiap sekarang dan kemudian ada ... masalah. Beberapa diatasi, yang lain tidak.
LSerni

Pertanyaan aslinya adalah "(bagaimana menghindari) setiap bug adalah prioritas tinggi". Secara teknis, jawaban (diterima!) Ini TIDAK benar-benar menjawabnya. Itu hanya menyebutkan "bug yang masuk diakumulasikan dalam buffer tanpa prioritas dan setiap hari Senin kami akan meninjau daftar bug, (secara kasar) memperkirakan kesulitan dan mengurutkannya berdasarkan waktu yang tersedia". Tetapi jawaban ini memang memberi banyak pengamatan yang baik, makanan yang baik untuk dipikirkan.
RayLuo

@ RayLuo Tidak, ini adalah jawaban. Alih-alih membuat wartawan menilai prioritas, pengembang menilai prioritas.
JAB

47

Jika Anda memiliki masalah ini di mana pengguna menugaskan bug prioritas yang semakin tinggi maka satu-satunya solusi realistis adalah mekanisme triase. Semua bug dilaporkan dengan prioritas apa pun yang mereka suka, tetapi beberapa manajer yang buruk harus memeriksa setiap bug yang baru dilaporkan dan mengatur ulang prioritasnya ke tingkat yang masuk akal.

Setelah beberapa saat, pengguna Anda akan mendapatkan pesan, atau Anda dapat mengubah sistem pelaporan sehingga setiap bug memiliki prioritas default. Jika mereka menginginkannya meningkat, mereka harus menghubungi seseorang untuk menabraknya, yang akan membutuhkan pembenaran. Fakta ini saja akan menyebabkan 99% dari semua bug dibiarkan tidak ditingkatkan oleh pengguna.

Tentunya Anda memiliki lebih banyak bug daripada yang dapat Anda proses, jadi mungkin Anda perlu memulai perbaikan bug untuk menghapus backlog. Ini akan menunjukkan kepada pengguna bahwa bug mereka akan diperbaiki tanpa perlu mereka ditandai sebagai super-super-dooper-benar-benar-tidak-jujur-saat-penting ini.


8
Tunggu Anda tampaknya sugesst ... Tapi itu tidak mungkin ... Sebenarnya ada pengembang yang tidak memiliki lebih banyak Bug daripada yang bisa mereka proses? Serius? :-D
Martin Ba

49
@MartinBa YMMV tetapi saya telah bekerja di tempat-tempat di mana kami meluangkan waktu untuk merancang dan mengembangkan produk kami dengan hati-hati, dan sementara bug ditemukan, mereka cukup langka. Anda anak-anak hari ini, menulis kode tanpa banyak pemikiran desain di muka, tidak heran Anda menghabiskan semua waktu unit Anda menguji dan refactoring :-)
gbjbaanb

5
Sebenarnya, jika seseorang menghabiskan cukup waktu untuk menguji bug, ia akan segera turun lagi. Dalam tim scrum, pemilik produk akan menjadi orang yang menegaskan kembali pentingnya bug dan pemilik produk dimaksudkan untuk memiliki pengetahuan domain bisnis yang cukup untuk menilai pentingnya bug tersebut. Jika bug tidak pernah berakhir pada sprint backlog, pemilik produk tidak melakukan tugasnya dengan cukup baik.
Cronax

14
@Cronax jika seseorang menghabiskan cukup waktu pengujian unit, Anda menemukan bahwa Anda tidak punya waktu tersisa untuk menulis fungsionalitas apa pun. Jadi saya kira itu tidak menghentikan bug muncul :-)
gbjbaanb

4
@ gbjbaanb selama Anda tetap pada tes unit yang sebenarnya dan tidak berlebihan, metrik gesit / scrum biasa menghabiskan 10-20% dari pengujian unit waktu pengembangan seseorang tampaknya akurat bagi saya. Anda tidak dapat menguji semuanya tetapi itu tetap sama, apa pun jenis pengujian yang Anda lakukan dan bukan tujuan pengujian. Anda hanya memastikan bahwa kode Anda melakukan apa yang dimaksudkan untuk dilakukan, tester akan menilai apakah cocok untuk tujuan.
Cronax

14

PENOLAKAN: Saya belum memiliki pengalaman dengan shenanigans prioritas bug yang dilaporkan pengguna. Saya tahu pertanyaannya menanyakan hal ini, tetapi mungkin membantu memiliki perspektif orang luar.

Masalah Anda bukan karena Anda memiliki terlalu banyak bug prioritas tinggi. Masalah Anda adalah Anda memiliki terlalu banyak orang yang memiliki kendali langsung atas prioritas bug. Jika setiap pengguna dapat secara langsung menetapkan prioritas untuk bug mereka, mereka hampir secara otomatis akan melaporkan masalah mereka sebagai prioritas tinggi.

Anda dapat membuatnya sehingga prioritas bug harus dikonfigurasi oleh manajer atau drone helpdesk, tetapi ini dapat menyebabkan favoritisme dan rekayasa sosial, di mana klien mendapatkan prioritas yang secara artifisial lebih tinggi karena status mereka atau karena mereka tahu cara menyusun pesan mereka ke buat mereka tampak lebih penting. Itu juga jauh lebih padat karya.

Ada jalan tengah, di mana pengguna Anda memiliki kontrol atas prioritas, tetapi dengan cara yang membuatnya lebih sulit untuk mengeksploitasi sistem. Pada dasarnya, Anda memaksa pengguna Anda untuk menggunakan templat untuk melaporkan bug. Pertama-tama mereka memilih kategori:

  1. Program menjadi tidak dapat digunakan atau macet ketika saya melakukan sesuatu.
  2. Program ini memiliki cacat grafis yang memengaruhi fungsionalitas.
  3. Program ini tidak memungkinkan saya untuk melakukan sesuatu yang seharusnya dapat saya lakukan.
    Program ini memungkinkan saya untuk melakukan sesuatu yang seharusnya tidak dapat saya lakukan.
  4. Program memberikan hasil yang salah ketika saya melakukan sesuatu.
  5. Program terlalu lama untuk melakukan sesuatu.
  6. Program memiliki cacat grafis yang tidak memengaruhi fungsionalitas.
  7. Program memiliki cacat yang tidak sesuai dengan salah satu kategori di atas.

Untuk memberi contoh:

  1. IPhone saya macet ketika saya menerima pesan yang berisi simbol-simbol Ibrani.
  2. Layar kunci Android saya diputar sedemikian rupa sehingga setengahnya jatuh dari layar.
  3. Ponsel Android saya terkadang tidak menerima kode layar kunci saya, meskipun saya memasukkan kode yang benar.
  4. Ketika saya mencoba menavigasi ke PhoneHub.net, ponsel saya mengarahkan saya ke situs dewasa.
  5. Ketika saya membuka aplikasi Facebook, dibutuhkan satu menit untuk membuka, bahkan pada koneksi cepat dan tanpa ada aplikasi lain yang berjalan.
  6. Aplikasi Anda memiliki kesalahan ejaan.
  7. Saya menemukan cacat keamanan di program Anda dan ingin melaporkannya.

Seperti yang Anda lihat, masing-masing kesalahan ini memiliki tingkat keparahan yang berbeda, dan kategori diurutkan secara kasar berdasarkan keparahan ini. Anda kemudian dapat menetapkan prioritas setiap bug berdasarkan kategori, yang melaporkannya dan kata kunci yang muncul dalam deskripsi. Bug di kategori 7 harus mendapatkan prioritasnya secara manual.

Perhatikan bahwa ini dapat terjadi sepenuhnya secara otomatis, dan Anda harus membiarkan ini terjadi secara otomatis; sebenarnya otomatisasi adalah kuncinya di sini. Pengguna cenderung melebih-lebihkan kepentingannya sendiri terhadap bisnis, sehingga mereka tidak melihat masalah dalam melaporkan bug mereka sebagai prioritas yang lebih tinggi daripada yang seharusnya. mereka cenderung tidak sengaja menempatkan bug mereka di kategori yang berbeda, karena itu mengharuskan mereka berbohong tentang bug tersebut.

Pengguna mungkin masih memasukkan bug mereka dalam kategori yang salah tentu saja. Hal pertama yang harus Anda lakukan adalah, dari versi 1.0, menampilkan pesan ramah yang mendorong pengguna untuk memberikan informasi akurat tentang bug untuk membantu pengembang menemukan dan memperbaikinya lebih cepat. Sebagian besar pengguna akan memahami dan menghentikan kesalahan pelaporan bug. Beberapa pengguna mungkin masih terus memberikan informasi yang salah. Ketika itu terjadi, kirimkan pengingat lembut kepada para pengguna melalui surat bahwa informasi yang akurat adalah penting dan untuk tidak menyalahgunakan sistem. Jika mereka terus memalsukan catatan, Anda memberi mereka peringatan bahwa mereka sengaja menyalahgunakan sistem dan penyalahgunaan yang terus-menerus akan mengakibatkan bug mereka secara otomatis ditugaskan ke kategori yang lebih rendah. Jika mereka tetap ada, Anda dapat menyesuaikan pengganda bug mereka.

Anda dapat melihat bagian dari sistem ini di tempat dalam situasi dukungan throughput tinggi: perusahaan teknologi raksasa seperti Microsoft, Facebook, Google, perusahaan Permainan dengan banyak pengguna seperti Valve dan Blizzard, pemerintah tertentu, ... Meskipun saya tidak yakin dari kerja di belakang layar, Anda perhatikan bahwa sistem pendukung yang menghadap pengguna memiliki antarmuka yang mirip dengan apa yang saya sarankan di sini, dengan sistem kategori yang ketat.


Jawaban yang sangat bagus Pengguna bahkan tidak boleh diizinkan untuk mengatur sendiri prioritas apa pun dalam laporan bug. Kategori ini adalah saran yang sangat bagus. Pengaturan prioritas manual apa pun harus dilakukan oleh pemilik produk atau yang serupa. Dalam proyek pengembangan kami, masalah yang muncul selama pengujian diprioritaskan oleh pemilik produk dalam pertemuan diskusi dengan master scrum.
awe

11

Seperti yang dikatakan orang, inilah mengapa orang yang melaporkan bug tidak mendapatkan prioritas. Tim dev Anda harus mengendalikan penugasan tugas mereka sendiri (dalam ruang lingkup yang ditetapkan oleh manajemen yang lebih tinggi). Jadi, seseorang lebih jauh mengatakan "bekerja pada aplikasi ini , perbaiki fitur ini , membuatnya lebih baik dalam melakukan ini ", dan tim dapat memutuskan bagaimana melakukannya, karena merekalah yang memiliki keahlian teknis yang diperlukan untuk menilai seberapa terbaik untuk mencapai apa yang diinginkan manajemen.

Orang yang melaporkan bug harus menetapkan tingkat dampak atau tingkat keparahan , yang memiliki ruang lingkup yang ditentukan. Anda dapat dengan mudah memanggil orang-orang untuk tidak berpegang teguh pada tingkat keparahan yang disepakati, karena Anda memiliki bukti material untuk tingkat-tingkat itu. Sebagai contoh:

  1. Hilangnya fungsionalitas sepenuhnya
  2. Hilangnya sebagian fungsi
  3. Pengurangan efektivitas secara luas
  4. Pengurangan efektivitas secara lokal
  5. Gangguan atau halangan (ada solusi)
  6. Kosmetik
  7. Tidak ada yang benar-benar memperhatikan, ditemukan selama tes eksplorasi yang tidak jelas

Untuk memulai, Anda dapat menggunakan level-level ini sebagai instrumen tumpul untuk menunjukkan bahwa ketidakselarasan beberapa teks judul bukan bug Level 1 karena itu membuat seluruh aplikasi tidak dapat digunakan. Setelah mereka mendapatkan ide, Anda dapat membuatnya lebih berbutir halus, dan mulai memperdebatkan apakah kesalahan dalam memperbarui satu kotak teks ini adalah Level 5 karena Anda dapat memperbaikinya dengan mengklik kanan pada kotak teks beberapa kali, atau Level 4 karena memperlambat semua orang dalam Akuntansi sehingga mereka mendapatkan lebih sedikit formulir diproses per jam.

Setelah Anda mendapatkan informasi yang bermanfaat dan dapat diukur tentang seberapa buruk bug itu bagi organisasi Anda , menetapkan prioritas menjadi jelas. Apa pun yang saat ini menyebabkan masalah terbesar bagi organisasi - kehilangan keuntungan, kerusakan citra publik, ketidakbahagiaan karyawan, apa pun - akan menjadi Prioritas Tinggi, dan Anda bekerja dari sana.


Ini. Dan versi singkat untuk tujuan PR adalah bahwa prioritas selalu relatif terhadap hal-hal lain dan karenanya hanya dapat diputuskan dengan membandingkannya dengan hal-hal lain dalam antrian. Hanya karena hal Anda tampaknya perlu dilakukan bukan berarti itu prioritas tertinggi.
Steve Jessop

1
Nah, Anda tidak boleh mengabaikan bahwa masalah dengan dampak tertinggi mungkin jauh lebih sulit untuk diatasi daripada masalah dengan dampak yang sedikit lebih rendah. Maksud saya, apa yang akan Anda kerjakan jika Anda dapat memperbaiki dua bug masing-masing seharga € 100 per hari, atau satu seharga $ 200, untuk upaya yang sama?
Deduplicator

1
Itu poin yang bagus; estimasi upaya akan masuk ke dalamnya juga.
anaximander

@Dupuplikator Maaf tidak cukup Anda mendapatkan € 100 dan $ 200 analog. Apakah Anda mencoba menyarankan dampak yang sedikit lebih rendah tetapi jauh lebih mudah ditangani sebelum yang berdampak paling tinggi tetapi jauh lebih sulit? Dengan kata lain, Anda berbicara konsep Return On Invest (ROI)?
RayLuo

10

Bunyinya agak seperti ini:

Mgr: apa yang sedang Anda kerjakan? Dev: tugas dengan prioritas rendah ini Mgr: bukankah seharusnya Anda mengerjakan tugas dengan prioritas tinggi?

Klien: kapan bug saya diperbaiki? Dev: prioritas rendah, kami memiliki tugas prioritas tinggi. Klien: oh, baik maka atur status bug saya ke prioritas tinggi.

Ini akan menyebabkan tingkat prioritas yang terus meningkat. Saya melihat Anda sudah melampaui prioritas tinggi ke prioritas sangat tinggi. Apa yang akan terjadi selanjutnya adalah:

  1. Prioritas Super Tinggi
  2. Prioritas Ultra Tinggi
  3. Prioritas Sangat Tinggi.
  4. Sangat Super Ultra Mega Prioritas Tinggi.

dll. dll

Ya, ini adalah proses yang normal. Selama tidak ada biaya yang terlibat dengan menetapkan prioritas, dan penelepon memiliki pengaruh, tentu saja mereka akan mencoba menyelesaikan masalah mereka dengan cara tercepat dan menetapkan prioritas tertinggi.

Pada dasarnya ada 2 cara untuk mengatasi ini:

  1. Ambil kendali dari klien mengenai tingkat prioritas.
  2. Kaitkan biaya kepada klien untuk tingkat prioritas tinggi.

7
Itu bukan proses normal. Klien tidak memiliki bisnis yang berinteraksi dengan pengembang pada tingkat itu, jika itu terjadi, manajemen telah sepenuhnya dan sepenuhnya gagal melakukan tugasnya.
Davor Ždralo

@ DavorŽdralo mungkin proses bukan kata yang tepat digunakan di sini. Maksud saya itu hal biasa yang terjadi.
Pieter B

3
Ini adalah proses yang normal sejauh klien akan selalu merasa bahwa bug yang mereka alami lebih penting daripada mungkin. Pada saat yang sama, dev terkenal karena meremehkan pentingnya bug. Inilah sebabnya mengapa Scrum memiliki pemilik produk yang duduk di antara keduanya dengan pengetahuan tentang domain bisnis dikombinasikan dengan tampilan tingkat tinggi ke mana arah aplikasi. Mereka secara unik cocok untuk menilai dengan benar prioritas setiap cerita atau bug.
Cronax

5

Seseorang dapat menambahkan tingkat prioritas yang lebih tinggi dan lebih tinggi ke sistem, terutama jika itu adalah Jira. Memberikan prioritas tinggi baru semakin konyol tetapi nama-nama mengerikan dapat meningkatkan efek Hawthorne bertemu dengan kualitas pilihan prioritas yang dibuat oleh semua pihak. Jika prioritas tertinggi memiliki nama yang sangat aneh, efeknya bisa permanen. Akhirnya ketika seseorang memilih prioritas, mereka harus mempertimbangkan konsekuensi sosial dari memilih prioritas "bug of death" vs. mendapatkannya karena perhatian. Jadi, prioritas tertinggi adalah de facto dicadangkan untuk sesuatu yang terjadi pada CTO di rumah di depan tamunya, atau insiden visibilitas setara lainnya.


4

Memperkenalkan biaya untuk mendukung permintaan. Anda hanya dapat mengizinkan pengguna untuk melaporkan sejumlah item prioritas tinggi dalam jumlah waktu tertentu, jumlah item prioritas menengah, dan prioritas rendah.

Tentu saja, itu juga berarti tim pengembang dan manajemen harus kemudian menjamin bahwa sejumlah ini akan diperbaiki - semua item prioritas tinggi, sebagian besar item prioritas menengah, dan (mungkin) beberapa item prioritas rendah dalam jangka waktu tertentu.

Tetapi jika ini akan berhasil, manajemen sebenarnya harus membeli ke dalamnya, jika tidak seluruh latihan adalah buang-buang waktu.

Namun pada akhirnya, situasi khusus Anda tampaknya merupakan gejala dari masalah yang manajemen Anda tidak mengalokasikan sumber daya yang cukup untuk menangani masalah dukungan. Jika masalah ditangani secara tepat waktu, maka saya tidak berpikir ini akan terjadi.

Sesuatu seperti ini diterapkan di perusahaan pertama tempat saya bekerja karena proses dukungannya tidak berfungsi dan mengarah ke situasi di mana jika semuanya darurat, tidak ada apa-apa. Dalam kasus kami, setelah mendapatkan situasi internal di bawah kendali, manajer pengembangan perangkat lunak baru membatasi jumlah masalah prioritas tinggi yang dapat diajukan pelanggan tergantung pada berapa banyak mereka membayar dalam kontrak dukungan. Jika mereka melampaui batas, apakah mereka batuk lebih banyak uang atau masalah dukungan diturunkan dalam prioritas.


1
Saya mungkin telah salah mengerti inti Anda tetapi jika perangkat lunaknya umumnya berkualitas buruk, mengapa klien harus dihukum karena menaikkan serangkaian bug prioritas tinggi?
Robbie Dee

@RobbieDee yang mengatakan perangkat lunaknya berkualitas buruk? Ini bukan pertanyaan tentang cara memperbaiki praktik kode yang buruk, ini tentang cara menghentikan klien dari meningkatkan setiap masalah dukungan ke prioritas tinggi.
user1666620

Jadi, Anda berbicara tentang biaya atau kuota nosional?
Robbie Dee

@RobbieDee - Tergantung. Sesuatu seperti ini diterapkan di perusahaan pertama tempat saya bekerja karena proses dukungannya tidak berfungsi dan mengarah ke situasi di mana jika semuanya darurat, tidak ada apa-apa. Dalam kasus kami, setelah mengendalikan situasi internal, manajer baru memberi batasan keras pada sejumlah masalah prioritas tinggi yang dapat diajukan pelanggan, tergantung pada berapa banyak mereka membayar dalam kontrak dukungan. Jika mereka melampaui batas, apakah mereka batuk lebih banyak uang atau masalah dukungan diturunkan dalam prioritas.
user1666620

Ah, oke - itu masuk akal.
Robbie Dee

3

Ini sangat sering terjadi di perusahaan besar di mana TI dianggap sebagai pendukung, dan / atau outsourcing. Para pebisnis tidak memahami perangkat lunak dan tidak peduli, yang mereka pedulikan hanyalah bahwa bug "mereka" diperbaiki kemarin, terlepas dari seberapa tidak pentingnya itu. Mereka tidak menyadari, atau peduli, bahwa ada seratus pengguna lain yang juga melaporkan bug, dan mungkin ada 5 pengembang yang bisa memperbaiki masalah ini.

Ini diperburuk oleh manajemen yang buruk, terutama manajer non-IT yang tidak bisa mengatakan "tidak" atau yang membiarkan pebisnis menetapkan prioritas bug. (Dalam kedua kasus tersebut, manajer mengatakan tidak melakukan pekerjaannya.) Sebagian besar manajer akan memprioritaskan bug yang terakhir mereka hubungi karena "ini mendesak"; hasil akhirnya adalah bahwa pengembang akhirnya melompat dari bug ke bug, sehingga memperbaiki satu bug membutuhkan waktu lebih lama (pengalihan konteks), dan pada akhirnya semua orang tidak bahagia. "Ketika setiap bug adalah bug prioritas tinggi, tidak ada bug prioritas tinggi."

Saya sudah dalam situasi ini, dan umumnya satu-satunya cara untuk menghindarinya adalah dengan keluar. Pedoman pelaporan bug selalu diabaikan karena pengguna tidak memberikan ** t. Mencoba memperkenalkan bug triase akan ditolak, atau akan diterapkan dan kemudian diabaikan saat pengguna lain memanggil manajer Anda untuk mengeluh tentang bug "mereka".

Pada dasarnya, jika pengembang tidak memiliki kendali atas prioritas , Anda sudah kalah.


Pengembang yang memiliki kendali atas prioritas dapat sama bermasalahnya. Mereka mungkin melompat ke kemenangan cepat atau hanya memilih bug di daerah yang mereka kenal.
Robbie Dee

@RobbieDee Saya melihat tidak ada salahnya pergi untuk menggantung buah rendah pertama sebagai kebijakan.
Pieter B

1
Kebijakan no-bug adalah tujuan yang mengagumkan, tetapi IMO benar-benar tidak realistis - bug adalah artifak pengembangan perangkat lunak karena orang tidak sempurna. Inilah sebabnya mengapa Anda perlu triase - untuk mencari tahu apa yang perlu diperbaiki sekarang , apa yang bisa diperbaiki jika / ketika ada waktu, dan apa yang mungkin tidak perlu diperbaiki pernah. Dengan begitu Anda bisa menyingkirkan masalah yang paling mengerikan sambil tetap memberikan fitur.
Ian Kemp

1
@RobbieDee Saya telah menjadi pengembang fitur dan pemecah bug, dan saya menemukan bahwa masalahnya adalah bahwa para pembuat fitur dan pemecah masalah masing-masing pada akhirnya beralih ke tim mini mereka sendiri karena mereka tidak bekerja pada kode yang sama dan karenanya tidak perlu berinteraksi. Itu menciptakan segala macam masalah di sekitar kohesi dan semangat tim, terutama jika pemain fitur dan pemecah masalah tidak pernah memutar peran mereka.
Ian Kemp

1
@RobbieDee Dan bahkan lebih buruk lagi jika peran diputar - jika Anda melakukannya pada jangka waktu yang tetap, orang-orang akan terhenti di tengah-tengah pekerjaan dan orang-orang "baru" harus naik lagi; jika Anda melakukannya atas dasar ketika pekerjaan selesai, akan ada ketidakbahagiaan karena selalu seseorang akan merasa pendek berubah ("mengapa saya selalu berakhir menghabiskan lebih lama untuk bug"). Dalam pengalaman saya, satu-satunya cara yang berfungsi adalah memastikan semua fitur devs mix berfungsi dan memperbaiki bug - misalnya, pengembangan fitur selama 4 hari dalam seminggu, dan bug untuk 1 hari.
Ian Kemp

3

Sebagai perusahaan, Anda ingin menyelesaikan masalah dengan rasio kepentingan / biaya tertinggi. Pengguna memutuskan kepentingan, Rekayasa menentukan biaya. Jika pengguna menetapkan kepentingan yang sama untuk semua bug, maka masalah biaya saja yang penting.

Secara praktis, ini berarti Anda mendefinisikan prioritas sebagai kepentingan / biaya, dan tidak mengizinkan pengguna atau pengembang untuk menetapkan prioritas itu secara langsung. Tidak ada pihak yang memiliki gambaran lengkap.

Jika pengguna memutuskan untuk menilai semua masalah sama pentingnya, itu OK - tetapi itu berarti bahwa rekayasa (biaya) memutuskan apa yang dilakukan. Jelaskan kepada mereka bahwa pentingnya adalah satu-satunya cara di mana mereka dapat mempengaruhi (tetapi tidak memutuskan) prioritas.


1
Itu bekerja. Selama semua masalah memengaruhi setiap pengguna secara setara. Kalau tidak, ingat bahwa bug saya selalu mendapat prioritas.
Deduplicator

Itu bekerja, secara teori. Tapi itu tidak benar-benar menyelesaikan masalah asli "hampir setiap bug yang dilaporkan adalah bug prioritas tinggi", pengguna masih dapat melaporkan setiap bug sebagai "sangat penting", dan akhirnya menjadi "bug mudah terlebih dahulu".
RayLuo

3

Beberapa faktor ...

  • Seringkali orang tersebut melaporkan bug tidak mengetahui gambaran yang lebih besar dan tidak dapat memutuskan seberapa penting bug tersebut.
  • Seringkali bug berprioritas rendah tidak pernah di-triase atau dipertimbangkan, oleh karena itu lebih baik memberikan prioritas yang terlalu tinggi dan membiarkan orang yang melakukan triase menurunkannya.
  • Sebagai pengembang, saya sering melihat laporan bug dan menemukan bahwa ada masalah prioritas sangat tinggi di balik bug, tetapi manajer produk yang melakukan triase tidak peduli dengan bug tersebut.

Jadi saya pikir semua laporan bug perlu dilihat CEPAT oleh satu atau dua pengembang yang berpengalaman, menambahkan pemikiran mereka ke laporan bug, maka bug perlu ditinjau. Mengharapkan orang yang menemukan bug untuk dapat menetapkan prioritas yang berguna pada saat mereka menemukannya, hanya meminta terlalu banyak.


3

Sangat mungkin bahwa semua bug yang disebutkan adalah prioritas tinggi. Saya telah mengerjakan proyek yang kekurangan dana dan kurang spesifik, dan ketika pengujian dimulai QA dan pengguna baru saja melaporkan item yang prioritas rendah, karena mereka tahu bahwa kesalahan pengejaan atau gangguan dalam kegunaan adalah pemborosan waktu jika fungsi inti dari proyek tersebut sepenuhnya disemprot. Jika sistem bagasi otomatis Anda menabrak gerobak bersama dan menghancurkan bagasi , siapa yang peduli jika font pada tag 2pt terlalu kecil?

Dalam situasi seperti ini, proyek gagal. Jika Anda curiga bahwa ini bahkan kemungkinan, Anda perlu hati ke hati dengan orang-orang yang melaporkan cacat untuk mengetahuinya. Jika orang menggembungkan laporan bug, maka jawaban lain akan membantu. Jika bug seburuk yang dilaporkan, maka Anda harus mengambil tindakan ekstrem .


2

Kebanyakan sudah dikatakan, tetapi saya akan menyaring daftar "bug zoo" ke sesuatu yang sedikit kurang granular:

A: Bug menghentikan pengguna mati di jalurnya, memberikan output yang salah, umumnya membuat sistem / fitur / fungsi tidak dapat digunakan. Itu adalah bug "prioritas tinggi".

B: Yang lainnya. Ini adalah bug yang "bisa dinegosiasikan".

Bug NEGOSIA jatuh dalam berbagai kekhawatiran (yang akan Anda masukkan dalam urutan tertentu):

1: Bug yang memengaruhi keamanan;

2: Bug yang memengaruhi kegunaan (kesesuaian untuk tujuan yang dimaksudkan);

3: Bug yang memengaruhi estetika;

4: Bug yang memengaruhi kinerja (sebagian dari kegunaan mungkin?);

5: Bug yang menyinggung perasaan Anda sebagai programmer profesional;

6: Bug yang mengurangi TRUST USER;

Jadi itulah dunia utopis yang tidak ada di antara kita yang benar-benar hidup. Desah Untuk melengkapi jawaban saya terhadap pertanyaan OP, di seluruh industri perangkat lunak, sangat umum bagi upaya pengembangan untuk berada dalam status di mana setiap bug merupakan prioritas- one-super-banger-special. Dan Anda tahu apa yang mereka katakan tentang "spesial": ketika semua orang istimewa, tidak ada yang istimewa.


2

Pada dasarnya masalah ini berakar pada masalah penentuan prioritas desentralisasi. Harus selalu ada jumlah orang aneh dengan kemampuan memprioritaskan beban kerja tim, dan 3 terlalu banyak. Sehingga 1 orang bertanggung jawab untuk pelatihan-efektif. Dan itu harus menjadi manajer / analis, dalam konsultasi dengan pemimpin / arsitek dev. Dan prosesnya cukup sederhana, dan dapat diterapkan untuk permintaan fitur juga. Berapa biaya melakukan pengembangan? Apa nilai dari hasil yang diharapkan untuk bisnis. Output dari fungsi itu adalah prioritas yang diberikan.

TENTU SAJA setiap pengguna ingin masalah mereka diperbaiki terlebih dahulu. Dan segera setelah Anda mengizinkannya, kekacauan. Anda tidak memiliki prioritas yang valid. Anda perlu ini dilakukan oleh orang TUNGGAL dengan otoritas (berkonsultasi dengan orang lain jika perlu), yang memiliki VISIBILITAS di SEMUA masalah dan kebutuhan bisnis, dan cukup kompeten untuk mengumpulkan saran bisnis dan pakar TI yang diperlukan dan dengan demikian menghasilkan perkiraan metrik yang cukup akurat. atas.


1

Dengan risiko menyatakan yang jelas saya akan menganggap tidak ada perangkat lunak pelacakan bug yang menetapkan bug ke prioritas tinggi sebagai default (atau telah diatur ke pengaturan ini).

Saya khawatir, bahwa dengan tidak adanya kontrol, ini adalah skenario default untuk banyak tim, klien, dll. Pelaporan masuk. Jika status quo disalahgunakan maka semacam proses triase sudah pasti dilakukan.

Kemenangan cepat yang pernah saya lihat bekerja dengan sangat baik di masa lalu adalah bahwa P1 (bug prioritas utama) menelurkan sejumlah besar peringatan manajemen. Jika sistem telah disalahgunakan, ia segera dihancurkan. Atau jika itu benar-benar mendesak, panggilan konferensi atau pertemuan fisik terjadi untuk mengatasi masalah ini sesegera mungkin.

Saya berasumsi di sini bahwa Anda berbicara tentang semua bug, bukan hanya bug dari pengembangan awal. Jika Anda biasanya seorang senapan pengembangan lapangan hijau untuk disewa, maka tentu saja tidak biasa bahwa sebagian besar bug adalah prioritas tinggi setelah rilis alpha awal.


Di JIRA, prioritas default untuk masalah adalah Mayor ("Kehilangan fungsi")
Carlos Gavidia-Calderon

1
@CarlosGavidia Maka kesalahan akan muncul dengan set-up. Sistem bug biasanya diatur untuk semuanya untuk pergi semacam prioritas sedang.
Robbie Dee

0

Anda tidak bisa hanya memiliki prioritas dan berharap semuanya akan berhasil secara ajaib. Kadang-kadang orang mencari tahu sendiri, tetapi tidak selalu.

Untuk menetapkan prioritas dengan benar, harus ada definisi apa yang menjadi prioritas masing-masing. Kriteria ini harus objektif, untuk menghindari favoritisme bug dan prioritas politik. Jika kriteria objektif tidak diikuti, Anda perlu membuat tim mengikutinya.

Benar-benar tidak ada jalan lain untuk hal ini - jika Anda tidak dapat memiliki kriteria obyektif untuk bug apa yang terjadi di mana, dan jika orang dengan sengaja menolak untuk menghormati kriteria ini, maka Anda mungkin juga tidak memiliki prioritas yang ditetapkan oleh pengirim - baik melakukannya tanpa prioritas, atau memiliki pihak ketiga menetapkan prioritas seperti yang disarankan orang lain. Data crowdsourced hanya berfungsi jika submitter kooperatif, dan tidak secara aktif menyabotase pengumpulan data.

Jika kesulitan muncul karena tidak dapat membuat kriteria objektif, Anda dapat menggunakan kriteria relatif:

  • Dapatkan antrian sederhana untuk semua bug. Pengguna dapat memasukkan bug di mana saja dalam antrian. Mereka hanya boleh memasukkan pada posisi tertentu jika mereka merasa bug mereka lebih penting daripada semua yang ada di bawahnya. Pemecah masalah bug mulai dari bagian atas antrian.
  • Dengan asumsi Anda sudah memiliki satu set bug yang diklasifikasikan dengan baik, beri tahu semua orang bahwa syarat untuk menempatkan bug dalam prioritas Xadalah bahwa bug itu harus lebih penting daripada semua bug dalam prioritas X-1.
  • Katakan submitter bahwa jumlah bug dengan prioritas dapat Xmelebihi jumlah bug dengan prioritas X-1.

Tapi sepertinya masalah Anda bukan definisi, tetapi keyakinan di antara pengirim bahwa bug prioritas rendah tidak diperbaiki. Agaknya, Anda tidak dapat membujuk mereka sebaliknya, karena (dari apa yang Anda katakan) kepercayaan mereka didasarkan pada fakta. Lalu, mengapa Anda membuat mereka mengirimkan bug ini? Akhirnya menjadi pekerjaan yang sibuk. Anda dapat, misalnya, setelah sejumlah bug aktif telah tercapai, beri tahu semua orang untuk tidak repot membuat laporan kecuali mereka merasa mereka menemukan sesuatu yang lebih penting daripada bug yang paling menonjol. Memang, ini hanya solusi antrian dengan batas atas panjang antrian.

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.