Quasi ogni bug segnalato è un bug ad alta priorità [chiuso]

Ho notato uno schema mentre lavoravo su diversi progetti software: la grande maggioranza dei bug segnalati aveva una priorità alta / molto alta. Ho chiesto ad alcuni colleghi il motivo per cui ciò potrebbe accadere e hanno affermato che se un bug non ha quel livello di priorità, è molto raro che il bug riceva l'attenzione degli sviluppatori, il che ha davvero senso.

Quindi, volevo sapere se questo problema è comune o se ho avuto solo sfortuna. Ho fatto una rapida ricerca su Google e ho scoperto che alcuni team implementano le linee guida per la segnalazione dei bug o hanno un team "Bug Triage" separato. Se hai affrontato e risolto questo problema, qual è stato l'approccio che ha funzionato per te?

Questa domanda riguarda in particolare il problema dell'inflazione prioritaria: se si affronta lo scenario e quali misure risultano efficaci contro questo problema.

Ho chiesto ad alcuni colleghi cosa potrebbe accadere e hanno detto che se un bug non ha quel livello di priorità, è molto raro che il bug riceva l'attenzione degli sviluppatori, il che ha davvero senso

In realtà, se me lo chiedi, non lo è. Più livelli (usati) di priorità, più informazioni hai. Se effettivamente hai solo una priorità, è la stessa cosa di non avere alcuna priorità.

E poiché hai ancora lo stesso numero di bug da affrontare e la stessa quantità di ore di lavoro in cui farlo, ne consegue che verrà usato qualche altro euristico, possibilmente quello nullo - "primo arrivato, primo servito". E quindi ora hai una metrica di priorità dei bug, tranne che è l'ora di arrivo e non è più sotto il tuo controllo.

Può essere un sintomo di risorse insufficienti allocate alla correzione dei bug (ci sono alcune politiche come " Nessuna nuova funzionalità fino a quando i bug non vengono corretti " che possono aiutare lì. Joel approva ; la comprensione dei limiti e delle conseguenze è una decisione aziendale ).

In un progetto in cui ho lavorato, i bug in arrivo sono stati accumulati in un "buffer senza priorità" e ogni lunedì verifichiamo l'elenco dei bug, stimiamo la difficoltà (una stima molto approssimativa; il più delle volte inseriamo semplicemente "Media") e ordinali per tempo disponibile. Ciò tendeva a sfogliare l'elenco di bug noiosi, poco interessanti o pensati per essere duri; per compensare ciò, i supervisori e il marketing avevano un certo numero di crediti a settimana che potevano spendere per superare la priorità dei bug preferiti e venivano rimborsati per i bug non risolti (questo poneva un limite su quanto un bug disprezzato dallo sviluppatore poteva essere ritardato) .

È stato anche possibile unire, annullare e dividere i bug; Ricordo un modulo che era così irrimediabilmente imperfetto che abbiamo affondato una ventina o trenta segnalazioni di bug in un singolo "riscrivi questa cosa da zero", che è stato quindi suddiviso in "dichiarare chiaramente gli input e gli output della cosa miserabile", "scrivere test per garantire che gli ingressi e le uscite corrispondano alle specifiche "e così via. L'ultimo oggetto era "stampare il vecchio codice su carta riciclata, portarlo sul prato e dargli fuoco" (lo abbiamo fatto anche noi. Ricordo quanto fosse bello. Facevamo a turno l'elogio; era abbastanza esilarante ).

Dopo un po 'di contrattazioni, abbiamo avuto la lista delle cose da fare della settimana, che è stata divisa in "farà", "potrebbe fare" e "non si può fare" che è stata messa in discussione alla prossima settimana. È qui che sono arrivate alcune ulteriori contrattazioni: avevamo detto cinquanta ore da assegnare ai bug ed eravamo sicuri al 95% di sistemare i primi venti. La direzione voleva fortemente che venisse corretto un bug ventunesimo e non gli rimanessero crediti; offriremmo quindi di scambiare quel bug con uno nella lista "Lo farò", o qualcuno direbbe "Fammi uscire dalla sottostruttura di FooBazFeature per un paio di giorni e lo farò", o diremmo "Abbiamo bisogno di più manodopera".

Il sistema non soddisfaceva nessuno, davvero, ma questo era ritenuto (almeno tra gli sviluppatori) un buon segno.

Alcuni ulteriori schemi negativi che sono emersi sono stati il ​​"Wishful Thinking" da parte dei gestori ("Hai dichiarato che il bug 57212 richiede otto ore. Questo è inaccettabile. Rendilo quattro") e il "Debug di Fiat" ("Fai quello che vuoi ma questi quaranta bug devono essere corretti prima della grande demo della prossima settimana. Non puoi avere più tempo, non puoi avere più persone "). Anche la sindrome del pugile ("Lavorerò di più"), che tendeva a funzionare molto bene per un breve periodo , ma di solito portava uno sviluppatore ad andare fuori di testa o a partire per pascoli più verdi.

Se hai questo problema in cui gli utenti assegnano bug con priorità sempre più elevate, l'unica soluzione realistica è un meccanismo di triage. Tutti i bug vengono segnalati con la priorità che preferiscono, ma alcuni manager scadenti dovranno superare tutti i bug segnalati di recente e riportare la priorità a un livello ragionevole.

Dopo un po 'i tuoi utenti riceveranno il messaggio oppure puoi cambiare il sistema di segnalazione in modo che ogni bug abbia una priorità predefinita. Se lo vogliono intensificato, dovranno contattare qualcuno per scontrarlo, il che richiederà qualche giustificazione. Questo fatto da solo farà sì che il 99% di tutti i bug non venga intensificato dall'utente.

Ovviamente hai più bug di quanti tu possa elaborare, quindi forse devi intraprendere una carrellata per correggere il backlog. Ciò mostrerà agli utenti che i loro bug verranno corretti senza che sia necessario contrassegnarli come super-super-dooper-davvero-non-onesto-questa-volta-importante.

DISCLAIMER: Non ho ancora avuto esperienza con gli shenanigans con priorità di bug segnalati dall'utente. So che la domanda lo richiede, ma potrebbe essere utile avere la prospettiva di un estraneo.

Il tuo problema non è che hai troppi bug ad alta priorità. Il tuo problema è che hai troppe persone che hanno il controllo diretto sulla priorità dei bug. Se ogni utente può assegnare direttamente una priorità al proprio bug, segnalerà quasi automaticamente il proprio problema come priorità alta.

Potresti farlo in modo che la priorità dei bug debba essere configurata da un manager o da un drone di helpdesk, ma questo potrebbe portare a favoritismi e ingegneria sociale, in cui un cliente ottiene una priorità artificialmente più alta a causa del suo stato o perché sa come fabbricare i suoi messaggi farli sembrare più importanti. È anche molto più laborioso.

C'è una via di mezzo, in cui i tuoi utenti hanno un certo controllo sulla priorità, ma in un modo che rende più difficile sfruttare il sistema. In sostanza, costringi i tuoi utenti a utilizzare un modello per segnalare bug. Prima selezionano una categoria:

1. Il programma diventa inutilizzabile o si arresta in modo anomalo quando faccio qualcosa.
2. Il programma presenta un difetto grafico che influisce sulla funzionalità.
3. Il programma non mi consente di fare qualcosa che dovrei essere in grado di fare.
   Il programma mi consente di fare qualcosa che non dovrei essere in grado di fare.
4. Il programma dà il risultato sbagliato quando faccio qualcosa.
5. Il programma impiega troppo tempo a fare qualcosa.
6. Il programma presenta un difetto grafico che non influisce sulla funzionalità.
7. Il programma presenta un difetto che non rientra in una delle suddette categorie.

Per fare esempi:

1. Il mio iPhone si arresta in modo anomalo quando ricevo un messaggio contenente simboli ebraici.
2. La schermata di blocco di Android viene ruotata in modo tale che metà di essa cade dallo schermo.
3. Il mio telefono Android a volte non accetta il mio codice di blocco schermo, anche se ho inserito il codice giusto.
4. Quando provo a navigare su PhoneHub.net, il mio telefono mi reindirizza a un sito per adulti.
5. Quando apro l'app di Facebook, ci vuole un minuto per aprirla, anche su connessioni veloci e senza altre app in esecuzione.
6. La tua app ha un errore di ortografia.
7. Ho trovato un difetto di sicurezza nel tuo programma e vorrei segnalarlo.

Come puoi vedere, ciascuno di questi errori ha un diverso grado di gravità e le categorie sono ordinate approssimativamente in base a questa gravità. È quindi possibile assegnare a ciascun bug una priorità in base alla categoria, a chi lo segnala e alle parole chiave che compaiono nella descrizione. I bug della categoria 7 dovrebbero ricevere la priorità assegnata manualmente.

Nota che ciò può avvenire in modo completamente automatico e dovresti lasciarlo accadere automaticamente; in effetti l'automazione è la chiave qui. Gli utenti sono inclini a sopravvalutare la propria importanza per l'azienda, quindi non vedono alcun problema nel segnalare i propri bug come una priorità più elevata di quanto dovrebbero. sono meno propensi a posizionare deliberatamente il loro bug in una categoria diversa, perché ciò richiede loro di mentire sostanzialmente sul bug.

Gli utenti potrebbero comunque inserire i loro bug nella categoria sbagliata, ovviamente. La prima cosa da fare è, dalla versione 1.0, mostrare un messaggio amichevole che incoraggi gli utenti a fornire informazioni accurate sul bug per aiutare gli sviluppatori a trovarlo e risolverlo più velocemente. La maggior parte degli utenti capirà e smetterà di segnalare errori in modo errato. Alcuni utenti potrebbero continuare a fornire informazioni errate. Quando ciò accade, invia a quegli utenti un delicato promemoria via e-mail che informazioni accurate sono importanti e per favore non abusare del sistema. Se continuano a falsificare i record, si avvisa che stanno abusando intenzionalmente del sistema e che continuando ad abusare, i loro bug verranno automaticamente assegnati a una categoria inferiore. Se persistono, puoi regolare il loro moltiplicatore di bug.

Puoi vedere parti di questo sistema in atto in situazioni di supporto ad alto rendimento: aziende tecnologiche giganti come Microsoft, Facebook, Google, società di gioco con molti utenti come Valve e Blizzard, alcuni governi, ... Anche se non sono sicuro dei meccanismi dietro la scena, noti che il loro sistema di supporto rivolto all'utente ha un'interfaccia simile a quella che suggerisco qui, con un sistema di categorie rigorose.

Come hanno detto le persone, questo è il motivo per cui le persone che segnalano bug non riescono ad assegnare priorità. Il tuo team di sviluppo dovrebbe avere il controllo della propria assegnazione di compiti (nell'ambito definito dalla direzione superiore). Così, qualcuno più in alto dice "il lavoro su questa applicazione, fissare questa caratteristica, rendono meglio a fare questo ", e la squadra arriva a decidere come andare su questo, perché sono quelli con la competenza tecnica necessaria per valutare come meglio per raggiungere ciò che la direzione vuole.

Le persone che segnalano i bug dovrebbero assegnare livelli di impatto o gravità , che hanno un ambito definito. Puoi facilmente chiamare le persone per non attenersi ai livelli di gravità concordati, perché hai prove materiali per quei livelli. Per esempio:

1. Completa perdita di funzionalità
2. Perdita parziale di funzionalità
3. Riduzione diffusa dell'efficacia
4. Riduzione localizzata dell'efficacia
5. Fastidio o impedimento (esiste una soluzione alternativa)
6. cosmetico
7. Nessuno se ne è effettivamente accorto, è stato trovato durante oscuri test esplorativi

Per iniziare, puoi usare questi livelli come uno strumento contundente per sottolineare che un disallineamento di un testo del titolo non è un bug di livello 1 perché non rende inutilizzabile l'intera applicazione. Una volta che hanno avuto l'idea, puoi renderla più precisa e iniziare a discutere se il problema tecnico nell'aggiornamento di questa casella di testo è un Livello 5 perché puoi risolverlo facendo clic con il pulsante destro del mouse nella casella di testo alcune volte o un Livello 4 perché sta rallentando tutti in Accounting in modo da ottenere meno moduli elaborati all'ora.

Una volta ottenute informazioni utili e misurabili su quanto è grave il bug per la tua organizzazione , l'assegnazione della priorità diventa ovvia. Qualunque cosa stia attualmente causando il problema più grande per l'organizzazione - perdita di profitti, danni all'immagine pubblica, infelicità dei dipendenti, qualunque cosa - diventerà una priorità assoluta e tu lavorerai da lì.

Va un po 'così:

Mons. A cosa stai lavorando? Dev: questi compiti a bassa priorità Mons.: Non dovresti lavorare su compiti ad alta priorità?

Cliente: quando verrà corretto il mio bug? Dev: è una priorità bassa abbiamo compiti ad alta priorità. Cliente: oh, beh, allora imposta il mio stato di bug su alta priorità.

Ciò porterà a livelli di priorità sempre crescenti. Vedo che hai già superato le priorità più alte. Quali saranno i prossimi sono:

1. Priorità altissima
2. Priorità ultra alta
3. Altissima priorità altissima.
4. Molto Super Ultra Mega Alta priorità.

ecc ecc.

Sì, questo è un processo normale. Finché non ci sono costi associati all'assegnazione della priorità e il chiamante ha influenza, ovviamente cercheranno di risolvere il problema nel modo più rapido e impostare la priorità più alta.

Esistono sostanzialmente 2 modi per contrastare questo:

1. Allontana il controllo dal cliente per quanto riguarda i livelli di priorità.
2. Associare un costo al cliente per livelli di priorità elevati.

Si possono aggiungere livelli di priorità sempre più alti al sistema, specialmente se si tratta di Jira. Dare alle nuove alte priorità sempre più sciocche ma nomi terribili può aumentare l' effetto di Hawthorne sulla qualità delle scelte prioritarie fatte da tutte le parti. Se la massima priorità ha un nome davvero stravagante, l'effetto potrebbe essere permanente. Alla fine, quando qualcuno sceglie una priorità, deve soppesare le conseguenze sociali della scelta della priorità "bug della morte" rispetto a ricevere la dovuta attenzione. Pertanto, la massima priorità è di fatto riservata a qualcosa che è accaduto al CTO a casa di fronte ai suoi ospiti o ad altri incidenti di visibilità equivalente.

Introdurre un costo per supportare le richieste. Puoi consentire a un utente di segnalare solo il numero X di articoli ad alta priorità in un determinato periodo di tempo, il numero Y di articoli a priorità media e la priorità Z bassa.

Ovviamente, ciò significa anche che il team di sviluppo e il management dovranno quindi garantire che un certo numero di questi sarà effettivamente risolto: tutti gli elementi ad alta priorità, la maggior parte degli elementi a media priorità e (forse) alcuni dei articoli a bassa priorità entro un determinato periodo di tempo.

Ma se funzionerà, la direzione dovrà effettivamente acquistarlo, altrimenti l'intero esercizio è una perdita di tempo.

Alla fine della giornata, tuttavia, la tua situazione particolare sembra essere un sintomo del problema che il tuo management non sta allocando risorse sufficienti per affrontare i problemi di supporto. Se i problemi venissero risolti in modo tempestivo, non penso che ciò accada.

Qualcosa del genere è stato implementato nella prima azienda per cui ho lavorato poiché il processo di supporto era disfunzionale e ha portato a una situazione in cui se tutto è un'emergenza, niente lo è. Nel nostro caso, dopo aver controllato la situazione interna, il nuovo responsabile dello sviluppo del software ha fissato un limite al numero di problemi ad alta priorità che un cliente poteva presentare a seconda di quanto ha pagato nei contratti di supporto. Se hanno superato il limite, o hanno tossito più denaro o il problema del supporto è stato ridotto in via prioritaria.

Ciò accade molto spesso nelle grandi aziende in cui l'IT è considerato accessorio e / o esternalizzato. Gli uomini d'affari non capiscono il software e non se ne curano, tutto ciò che importa è che il loro "bug" sia stato risolto ieri, indipendentemente da quanto non sia critico. Non si rendono conto, o si preoccupano, che ci sono centinaia di altri utenti che archiviano anche bug e un team di forse 5 sviluppatori disponibili per risolvere le cose.

Ciò è aggravato dalla cattiva gestione, in particolare i gestori non IT che non possono dire "no" o che semplicemente lasciano che gli uomini d'affari stabiliscano la priorità dei bug. (In entrambi i casi, detto manager non sta facendo il suo lavoro.) La maggior parte dei manager darà la priorità al bug per il quale sono stati contattati l'ultima volta perché "è urgente"; il risultato netto è che gli sviluppatori finiscono per saltare da un bug all'altro, quindi correggere un singolo bug richiede più tempo (cambio di contesto) e alla fine della giornata tutti sono infelici. "Quando ogni bug è un bug ad alta priorità, nessun bug ha la massima priorità."

Sono stato in questa situazione, e generalmente l'unico modo per sfuggire è uscire. Le linee guida per la segnalazione di bug vengono sempre ignorate perché gli utenti non danno come ** t. Il tentativo di introdurre il triage di bug verrà resistito o verrà implementato e quindi ignorato la volta successiva che un utente chiama il proprio responsabile per lamentarsi del "loro" bug.

Fondamentalmente, se gli sviluppatori non hanno il controllo della priorità , hai già perso.

Come azienda, vuoi risolvere i problemi con il più alto rapporto importanza / costo. Gli utenti decidono l'importanza, l'ingegneria decide i costi. Se gli utenti attribuiscono la stessa importanza a tutti i bug, allora solo i costi sono importanti.

In pratica, ciò significa che si definisce la priorità come importanza / costo e non si consente agli utenti o agli sviluppatori di impostare tale priorità direttamente. Nessuna delle due parti ha il quadro completo.

Se gli utenti decidono di valutare tutti i problemi in modo altrettanto importante, va bene, ma significa che l'ingegneria (costo) decide cosa è stato fatto. Spiega loro che l'importanza è l'unico modo in cui possono influenzare (ma non decidere) la priorità.

Alcuni fattori ...

• Spesso la persona segnala che il bug non conosce il quadro generale e non è in grado di decidere quanto sia significativo il bug.
• Spesso i bug a bassa priorità non vengono mai valutati o considerati, quindi è meglio dare una priorità troppo alta e lasciare che la persona che fa il triage lo abbassi.
• Come sviluppatore ho spesso esaminato la segnalazione di bug e ho scoperto che esiste un problema con priorità molto alta dietro il bug, ma il responsabile del prodotto che esegue il triage non si preoccupa del bug.

Quindi penso che tutte le segnalazioni di bug debbano essere esaminate RAPIDAMENTE da uno a due sviluppatori esperti, aggiungendo i loro pensieri alla segnalazione di bug, quindi il bug deve essere valutato. Aspettarsi che la persona che trova il bug sia in grado di impostare una priorità utile nel momento in cui lo trova, sta semplicemente chiedendo troppo.

È del tutto possibile che tutti i bug citati sono di alta priorità. Ho partecipato a progetti che erano entrambi sottofinanziati e non specificati, e quando sono iniziati i test di controllo qualità e gli utenti hanno semplicemente rinunciato a segnalare articoli a bassa priorità, perché sapevano che errori di ortografia o anomalie nell'usabilità erano una perdita di tempo se la funzionalità principale del progetto è stato completamente cancellato. Se il tuo sistema automatizzato per il bagaglio fa collassare i carrelli e distrugge i bagagli , a chi importa se il carattere sui tag è 2pt troppo piccolo?

In una situazione come questa, il progetto sta fallendo. Se sospetti che questa sia anche una possibilità, hai bisogno di un cuore a cuore con le persone che segnalano difetti per scoprirlo. Se le persone gonfiano le segnalazioni di bug, le altre risposte aiuteranno. Se i bug sono cattivi come riportato, è necessario intraprendere azioni estreme .

La maggior parte è già stata detta, ma distillerei l'elenco "bug zoo" in qualcosa di un po 'meno granulare:

A: Il bug arresta l'utente morto nelle sue tracce, fornisce un output errato, generalmente rende il sistema / caratteristica / funzione inutilizzabile. È un bug di "alta priorità".

B: Tutto il resto. Questi sono bug "negoziabili".

I bug NEGOZIABILI rientrano in una serie di preoccupazioni (che inseriresti nel tuo ordine particolare):

1: bug che incidono sulla sicurezza;

2: bug che influiscono sull'usabilità (idoneità allo scopo previsto);

3: bug che incidono sull'estetica;

4: Bug che influiscono sulle prestazioni (un sottoinsieme di usabilità forse?);

5: bug che offendono la tua sensibilità come programmatore professionista;

6: bug che diminuiscono la fiducia degli utenti;

Ecco, questo è il mondo utopico che nessuno di noi in realtà vivono in. Sospiro Per completare la mia risposta alla domanda dichiarato del PO, attraverso l'intera industria del software, è assolutamente comune per gli sforzi di sviluppo di essere in uno stato in cui ogni singolo bug è una delle priorità, uno-super-banger-speciale. E sai cosa dicono di "speciale": quando tutti sono speciali, nessuno è speciale.

Fondamentalmente questo problema è radicato nel problema del decentramento delle priorità. Dovrebbe esserci sempre un numero dispari di persone in grado di stabilire le priorità del carico di lavoro di una squadra e 3 è troppe. In modo che 1 persona sia responsabile per il trattamento efficace. E dovrebbe essere un manager / analista, in consultazione con un responsabile / architetto di sviluppo. E il processo è abbastanza semplice e può essere applicato anche alle richieste di funzionalità. Qual è il costo per fare lo sviluppo? Qual è il valore del risultato atteso per l'azienda. L'uscita di quella funzione è la priorità assegnata.

Di CORSO ogni utente vuole che il problema sia risolto per primo. E non appena lo permetti, il caos. Non hai una priorità valida. È necessario che questo venga eseguito da una SINGOLA persona con autorità (consultandosi con gli altri ove necessario), che abbia VISIBILITÀ su TUTTE le problematiche e le esigenze aziendali e sufficientemente competente da raccogliere la consulenza di esperti aziendali e IT richiesta e quindi generare stime ragionevolmente accurate delle metriche sopra.

A rischio di affermare l'ovvio suppongo che non ci sia alcun software di tracciamento dei bug che sta impostando i bug su priorità alta come impostazione predefinita (o è stato impostato su questa impostazione).

Temo che, in assenza di controlli, questo sia lo scenario predefinito per più team, clienti, ecc. Che segnalano. Se lo status quo viene abusato, una sorta di processo di triage è decisamente in ordine.

Una rapida vittoria che ho visto funzionare molto bene in passato è che P1 (bug con priorità assoluta) genera una pletora di avvisi di gestione. Se il sistema è stato maltrattato, viene immediatamente bloccato. O se è veramente urgente, una teleconferenza o una riunione fisica capita di risolvere il problema il prima possibile.

Sto assumendo qui che stai parlando di tutti i bug, non solo quelli dello sviluppo iniziale. Se in genere sei una pistola per lo sviluppo di campi verdi a noleggio, non è certo insolito che la maggior parte dei bug abbia un'alta priorità dopo il rilascio iniziale alfa.

Non puoi semplicemente avere una priorità e aspettarti che tutto funzioni magicamente. A volte le persone lo capiscono da sole, ma non sempre.

Per assegnare correttamente le priorità, ci deve essere una definizione esattamente di ciò che costituisce ciascuna priorità. Questi criteri devono essere obiettivi, per evitare il favoritismo degli insetti e la definizione delle priorità politiche. Se i criteri oggettivi non vengono seguiti, è necessario che il team lo segua.

Non c'è davvero alcun modo per aggirare questo problema - se non puoi avere criteri oggettivi per quale bug va dove e se le persone rifiutano intenzionalmente di rispettare questi criteri, allora potresti anche non avere priorità assegnate dal mittente - o fare a meno delle priorità, o avere una terza parte assegna la priorità come altri hanno suggerito. I dati in crowdsourcing funzionano solo se i mittenti sono cooperativi e non sabotano attivamente la raccolta dei dati.

Se la difficoltà deriva dal non essere in grado di creare criteri oggettivi, è possibile utilizzare criteri relativi:

• Avere una semplice coda di tutti i bug. Gli utenti sono in grado di inserire bug ovunque nella coda. Dovrebbero inserirsi in una determinata posizione solo se ritengono che il loro bug sia più importante di tutto ciò che c'è sotto. I correttori di bug iniziano dalla cima della coda.
• Supponendo che abbiate già una serie di bug ben classificati, dite a tutti che la condizione per dare priorità a un bug Xè che deve essere più importante di tutti i bug con priorità X-1.
• Spiega ai mittenti che in nessun momento il numero di bug con priorità Xpuò superare il numero di bug con priorità X-1.

Ma sembra che il tuo problema non sia la definizione, ma la convinzione tra i presentatori che i bug a bassa priorità non vengano risolti. Presumibilmente, non puoi convincerli altrimenti, poiché (da quello che dici) la loro convinzione è fondata sul fatto. Quindi, perché li fai inviare questi bug? Finisce per essere nient'altro che lavoro occupato. Potresti, ad esempio, dopo aver raggiunto un certo numero di bug attivi, dire a tutti di non preoccuparsi di fare segnalazioni a meno che non sentano di aver trovato qualcosa di più importante della maggior parte dei bug in sospeso. Certo, questa è solo la soluzione della coda con un limite superiore alla lunghezza della coda.