Quasi tutti i bug segnalati sono bug ad alta priorità [closed]

I asked some colleagues about what this may be happening, and they mentioned that if a bug doesn't haven't that level of priority it is very rare that the Bug gets developer attention, which indeed makes sense

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

E dal momento che hai ancora lo stesso numero di bug da affrontare e la stessa quantità di manodopera in cui farlo, ne consegue che verrà usata un'altra euristica, probabilmente quella nullo - "primo arrivato, primo servito" . E così ora hai una metrica di priorità bug, tranne che è l'ora di arrivo e non più sotto il tuo controllo.

Può essere un sintomo di risorse insufficienti assegnate al bug fixing (ci sono alcune politiche come " Nessuna nuova funzionalità fino a i bug sono corretti "che possono aiutarti. Approvazione di Joel ; la comprensione dei limiti e delle conseguenze è un < a href="https://softwareengineering.stackexchange.com/questions/198696/keeping-agile-with-zero-bug-defect-policy"> decisione aziendale ).

In un progetto ho lavorato, i bug in arrivo sono stati accumulati in un "buffer senza priorità" e ogni lunedì dovremmo rivedere l'elenco degli errori, la difficoltà di stima (una stima molto approssimativa, più spesso che non ci limitiamo a inserire "Media ") e li ordinano in base al tempo disponibile. Questo ha fatto in modo di scontrare la lista di bug noiosi, poco interessanti o pensati per essere difficili; per compensare ciò, supervisori e marketing avevano un certo numero di crediti a settimana che potevano spendere per superare la priorità dei bug preferiti, e venivano rimborsati per bug non risolti (questo impostava un limite su quanto ritardare un bug disprezzato dallo sviluppatore) .

Era anche possibile unire, cancellare e dividere i bug; Ricordo un modulo che era così irrimediabilmente imperfetto che abbiamo affondato circa venti o trenta segnalazioni di bug in un singolo "riscrivi questa cosa da zero", che è stato poi suddiviso in "indicare chiaramente gli input e gli output della cosa miserabile", "scrivere test per garantire ingressi e uscite corrispondenti alle specifiche ", e così via. L'ultimo articolo era "stampa il vecchio codice su carta riciclata, portalo fuori sul prato e mettilo a fuoco" (lo abbiamo fatto anche io. Ricordo quanto fosse bello. Ci siamo alternati all'elogio, era piuttosto esilarante ).

Dopo una certa contrattazione, abbiamo avuto la lista delle cose da fare della settimana, che è stata divisa in "farà", "potrebbe fare" e "non può fare" che sono stati urtati alla settimana successiva. È qui che è arrivata una certa contrattazione: abbiamo detto cinquanta ore per allocare i bug, ed eravamo sicuri al 95% di aggiustare i primi venti. La direzione desiderava strongmente che venisse risolto un ventunesimo bug e non rimanessero crediti; avremmo quindi offerto di scambiare il bug con uno nella lista "Will do", o qualcuno direbbe "Fammi uscire dalla funzione FooBazFeature per un paio di giorni e lo farò", o diremmo "Abbiamo bisogno di più manodopera".

Il sistema non ha soddisfatto nessuno, in realtà, ma si è creduto che (almeno tra gli sviluppatori) fosse un buon segno.

Alcuni modelli negativi aggiuntivi sono stati il "Pensiero desiderato" nella parte dei manager ("Hai affermato che il bug 57212 richiede otto ore." Questo è inaccettabile. "Fai quattro") e "Debug di Fiat" ("Fai qualunque cosa tu voglia, ma questi quaranta bug devono essere risolti prima della grande demo la prossima settimana. Non puoi avere più tempo, non puoi avere più persone "). Anche la Sindrome del pugile ("Lavorerò più duramente"), che tendeva a funzionare molto bene per un breve periodo , ma di solito ha portato a uno sviluppatore che stava impazzendo o partiva per pascoli più verdi.

Se hai questo problema in cui gli utenti assegnano bug con priorità sempre più elevata, l'unica soluzione realistica è un meccanismo di triage. Tutti i bug vengono segnalati con qualsiasi priorità, ma un manager scarso dovrà passare attraverso tutti i bug appena segnalati e ripristinare la priorità su un livello ragionevole.

Dopo un po 'gli utenti riceveranno il messaggio oppure puoi cambiare il sistema di segnalazione in modo che ogni bug abbia una priorità predefinita. Se vogliono che si intensifichi, dovranno contattare qualcuno per incontrarlo, il che richiederà qualche giustificazione. Questo fatto da solo causerà il 99% di tutti i bug da non lasciare escalation dell'utente.

Ovviamente hai più bug di quanti puoi elaborare, quindi forse hai bisogno di intraprendere una carrellata di bug-fix per cancellare il backlog. Questo mostrerà agli utenti che i loro bug verranno corretti senza che debbano essere contrassegnati come super-super-dooper-davvero-no-onesti-questo-tempo-importanti.

NOTA BENE: non ho ancora avuto esperienza con shenanigans di priorità bug di segnalazione degli utenti. So che la domanda lo richiede, ma potrebbe aiutare ad 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, verrà quasi automaticamente segnalato il problema come prioritario.

Potresti farlo in modo che la priorità dei bug debba essere configurata da un manager o da un dredge dell'helpdesk, ma questo potrebbe portare a favoritismi e ingegneria sociale, dove un cliente ottiene artificialmente una priorità più alta a causa del loro stato o perché sanno come fare i loro messaggi per farli sembrare più importanti. È anche molto più laborioso.

C'è una via di mezzo, in cui gli 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. Per prima cosa selezionano una categoria:

1. Il programma diventa inutilizzabile o si blocca quando faccio qualcosa.
2. Il programma ha 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 per fare qualcosa.
6. Il programma ha un difetto grafico che non influisce sulla funzionalità.
7. Il programma ha un difetto che non rientra in una delle categorie precedenti.

Per dare esempi:

1. Il mio iPhone si blocca quando ricevo un messaggio contenente simboli ebraici.
2. La schermata di blocco di Android viene ruotata in modo che la metà di esso cada sullo schermo.
3. Il mio telefono Android a volte non accetta il mio codice di blocco, anche se ho inserito il codice corretto.
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 aprirsi, 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, ognuno di questi errori ha un diverso grado di gravità e le categorie sono ordinate 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 visualizzate nella descrizione. I bug nella categoria 7 dovrebbero ottenere la priorità assegnata manualmente.

Nota che questo può accadere in modo completamente automatico e dovresti lasciarlo accadere automaticamente; infatti l'automazione è la chiave qui. Gli utenti sono inclini a sopravvalutare la propria importanza per il business, quindi non vedono un problema nel riportare i propri bug come una priorità più alta di quanto dovrebbero. sono meno inclini a posizionare deliberatamente il proprio bug in una categoria diversa, perché ciò richiede che mentiscano fondamentalmente sul bug.

Naturalmente gli utenti potrebbero inserire i loro errori nella categoria sbagliata. La prima cosa che dovresti fare è, dalla versione 1.0, mostrare un messaggio amichevole che incoraggia 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 bug errati. Alcuni utenti potrebbero continuare a fornire informazioni errate. Quando ciò accade, invia a questi utenti un delicato promemoria via mail che è importante che le informazioni siano accurate e che non violi il sistema. Se continuano a falsificare i record, dai loro un avvertimento che stanno abusando intenzionalmente del sistema e l'abuso continuato comporterà automaticamente l'assegnazione di una categoria inferiore ai loro bug. Se persistono, puoi regolare il loro moltiplicatore di bug.

Puoi vedere parti di questo sistema in atto in situazioni di supporto high-throughput: aziende tecnologiche giganti come Microsoft, Facebook, Google, società di gioco con un sacco di utenti come Valve e Blizzard, alcuni governi, ... Mentre io Non sono sicuro del funzionamento dietro la scena, ti accorgi che il loro sistema di supporto rivolto all'utente ha un'interfaccia simile a quella che ti suggerisco qui, con un rigoroso sistema di categoria.

Come si è detto, questo è il motivo per cui le persone che segnalano bug non possono assegnare priorità. Il tuo team di sviluppo dovrebbe avere il controllo della propria assegnazione di compiti (entro l'ambito stabilito dalla gestione superiore). Quindi, qualcuno più avanti dice "lavora su questa app questa , corregge questa , lo rende migliore nel fare questo ", e il team arriva a decidere come fare, perché sono quelli con le competenze tecniche necessarie per valutare il modo migliore per raggiungere ciò che la gestione vuole.

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

1. Completa perdita di funzionalità
2. Perdita parziale della funzionalità
3. Ampia riduzione dell'efficacia
4. Riduzione localizzata dell'efficacia
5. Disturbo o impedimento (esiste una soluzione alternativa)
6. Cosmetici
7. Nessuno in realtà ha notato, è stato trovato durante l'oscuro test esplorativo

Per iniziare, puoi usare questi livelli come uno strumento contundente per sottolineare che un disallineamento di un testo non è un errore di Livello 1 perché non rende inutilizzabile l'intera applicazione. Una volta ottenuta l'idea, puoi renderla più dettagliata e iniziare a discutere se il problema nell'aggiornamento di questa casella di testo è un Livello 5 perché puoi correggerlo facendo clic con il pulsante destro nella casella di testo alcune volte o su un Livello 4. perché sta rallentando tutti in Contabilità in modo da ottenere un minor numero di moduli elaborati all'ora.

Una volta che ti sono state utili, misurabili informazioni su quanto è grave il bug per la tua organizzazione , l'assegnazione della priorità diventa ovvia. Qualunque cosa stia causando il problema più grande per l'organizzazione - perdita di profitti, danni all'immagine pubblica, infelicità dei dipendenti, qualunque cosa - sarà alta priorità, e lavori da lì.

Si possono aggiungere livelli di priorità sempre più alti al sistema, specialmente se si tratta di Jira. Dare alle nuove alte priorità nomi sempre più sciocchi ma terribili può aumentare l'effetto Effetto Hawthorne nella qualità delle scelte prioritarie fatte da tutte le parti . Se la priorità più alta 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 of death", anziché ottenere la dovuta attenzione. Pertanto, la priorità più alta è 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 solo consentire a un utente di segnalare il numero X di elementi ad alta priorità in un dato periodo di tempo, il numero Y di elementi a media priorità e la priorità bassa di Z.

Ovviamente, ciò significa anche che il team di sviluppo e il management dovranno garantire che un certo numero di questi verrà effettivamente corretto: tutte le voci con priorità alta, la maggior parte delle voci con priorità media e (forse) alcuni degli elementi con priorità bassa entro un determinato periodo di tempo.

Ma se funzionerà, la direzione dovrà davvero comprarla, 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 abbastanza risorse per gestire i problemi di supporto. Se i problemi venissero trattati in modo tempestivo, allora non penso che ciò accada.

Qualcosa del genere è stato implementato nella prima azienda per cui ho lavorato perché il processo di supporto era disfunzionale e ha portato a una situazione in cui, se tutto è un'emergenza, nulla lo è. Nel nostro caso, dopo aver preso sotto controllo la situazione interna, il nuovo responsabile dello sviluppo software ha posto un limite rigido al numero di problemi ad alta priorità che un cliente potrebbe presentare a seconda di quanto hanno pagato nei contratti di supporto. Se hanno superato il limite, hanno sputato più denaro o il problema del supporto è stato abbassato in priorità.

Questo accade molto spesso nelle grandi aziende in cui l'IT è visto come accessorio e / o è esternalizzato. Gli uomini d'affari non capiscono il software e non si preoccupano di farlo, tutto ciò che interessa è che "il loro" bug viene corretto ieri, indipendentemente da quanto non sia critico. Non si rendono conto, o si preoccupano, che ci siano altri cento utenti che archiviano bug e un team di forse 5 sviluppatori disponibili a sistemare le cose.

Ciò è esacerbato da una cattiva gestione, specialmente da manager non IT che non possono dire "no" o che semplicemente lasciano agli imprenditori la priorità dei bug. (In entrambi i casi, il manager non sta facendo il suo lavoro.) La maggior parte dei manager darà la priorità al bug per il quale sono stati contattati per l'ultima volta perché "è urgente"; il risultato è che gli sviluppatori finiscono per saltare da bug a bug, quindi risolvere 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 una priorità alta."

Sono stato in questa situazione, e generalmente l'unico modo per sfuggire è uscire. Le linee guida per la segnalazione dei bug sono sempre ignorate perché gli utenti non danno un s ** t. Tentativo di introdurre la triage dei bug verrà respinto o verrà implementato e quindi ignorato la volta successiva che un utente chiama il tuo manager per lamentarsi del "loro" bug.

In sostanza, 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, Engineering decide il costo. Se gli utenti assegnano la stessa importanza a tutti i bug, allora il solo costo è importante.

In pratica, questo significa che definisci priorità come importanza / costo e non consentire a utenti o sviluppatori di impostare direttamente tale priorità. Nessuna parte ha l'immagine completa.

Se gli utenti decidono di valutare tutte le questioni ugualmente importanti, 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 che segnala il bug non conosce l'immagine più grande e non è in grado di decidere quanto sia significativo il bug.
• Spesso i bug a bassa priorità non vengono mai triaging o considerati, quindi è meglio dare una priorità troppo alta e lasciare che la persona che fa il triage lo abbassi.
• Come sviluppatore ho guardato spesso la segnalazione di bug e ho scoperto che c'è un problema molto elevato dietro il bug, ma il product manager che fa triage non si preoccupa del bug.

Quindi penso che tutte le segnalazioni di bug debbano essere viste QUICKLY da uno a due sviluppatori esperti, aggiungendo i loro pensieri alla segnalazione di bug, quindi il bug deve essere triaged. Aspettarsi che la persona che trova il bug sia in grado di impostare una priorità utile nel momento in cui lo trovano, è solo chiedere troppo.

È abbastanza probabile che tutti i bug menzionati siano ad alta priorità. Ho partecipato a progetti che erano entrambi sottofinanziati e sottodimensionati, e quando i test sono iniziati, il QA e gli utenti hanno smesso di riportare articoli a bassa priorità, perché sapevano che gli errori di ortografia o glitch nell'usabilità erano una perdita di tempo se le funzionalità principali del progetto è stato completamente protetto. Se il tuo sistema automatico per il bagaglio sta bloccando i carrelli e distruggendo i bagagli , a chi importa se il carattere dei tag è 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 da scoprire. Se le persone stanno gonfiando le segnalazioni di bug, allora le altre risposte aiuteranno. Se i bug sono negativi come riportato, è necessario intraprendere azioni estreme .

La maggior parte è già stata detta, ma vorrei distillare la lista "bug zoo" in qualcosa di un po 'meno granulare:

A: Il bug blocca l'utente morto nelle sue tracce, genera un output errato, generalmente rende il sistema / funzione / funzione inutilizzabile. Questo è un bug "ad alta priorità".

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

I bug NEGOTIABILI rientrano in una serie di problemi (che avresti inserito nel tuo ordine particolare):

1: bug che influiscono sulla sicurezza;

2: bug che hanno un impatto sull'usabilità (idoneità per lo scopo previsto);

3: bug che hanno un impatto sull'estetica;

4: Bug che influenzano le prestazioni (forse un sottoinsieme di usabilità?);

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

6: Bug che diminuiscono la FIDUCIA DELL'UTENTE;

Quindi questo è il mondo utopico in cui nessuno di noi vive veramente. sospiro Per completare la mia risposta alla domanda dichiarata dall'OP, in tutto il settore del software, è del tutto normale che gli sforzi di sviluppo siano uno stato in cui ogni singolo bug è uno speciale prior-one-super-banger. E sai cosa dicono di "speciale": quando tutti sono speciali, nessuno è speciale.

Fondamentalmente, questo problema è radicato nel problema della decentralizzazione delle priorità. Ci dovrebbe sempre essere un numero dispari di persone con la capacità di dare la priorità al carico di lavoro di una squadra, e 3 sono troppe. In modo che 1 persona sia responsabile per il trasferimento efficace. E dovrebbe essere un manager / analista, in consultazione con un responsabile / architetto. E il processo è abbastanza semplice e può essere applicato anche alle richieste di funzionalità. Quanto costa fare lo sviluppo? Qual è il valore del risultato atteso per l'azienda. L'output di quella funzione è la priorità assegnata.

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

A rischio di affermare l'ovvio, assumerò che non ci sia un software di tracciamento dei bug che imposti i bug ad alta priorità come predefinito (o che sia stato impostato su questa impostazione).

Temo che, in assenza di controlli, questo sia lo scenario predefinito per team multipli, clienti ecc. Se si verifica un abuso dello status quo, una sorta di processo di triage è sicuramente in ordine.

Una rapida vittoria che ho visto funzionare molto bene in passato è che P1 (bug con priorità assoluta) genera una serie di avvisi di gestione. Se il sistema è stato abusato, viene immediatamente urtato. Oppure, se fosse veramente urgente, una chiamata in conferenza o una riunione fisica accedono al problema il prima possibile.

Qui presumo che tu stia parlando di bug all non solo di quelli dello sviluppo iniziale. Se in genere si tratta di una pistola per lo sviluppo di campi verdi, non è insolito che la maggior parte dei bug abbia priorità elevata dopo la versione alpha iniziale.

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

Per assegnare correttamente le priorità, ci deve essere una definizione di esattamente ciò che costituisce ciascuna priorità. Questi criteri devono essere obiettivi, per evitare favoritismi di bug e prioritizzazione politica. Se i criteri oggettivi non vengono seguiti, devi far sì che il team lo segua.

Non c'è davvero alcun modo per aggirare questo - se non si può avere criteri oggettivi per quale errore va dove, e se le persone si rifiutano volontariamente di rispettare questi criteri, allora si potrebbe anche non avere priorità assegnate dai submitter - o fare senza priorità , o avere una terza parte assegnare priorità come altri suggerito. I dati di crowdsourcing funzionano solo se i submitter collaborano e non sabotano attivamente la raccolta di dati.

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

• Avere una semplice coda di tutti i bug. Gli utenti sono in grado di inserire bug ovunque nella coda. Dovrebbero solo inserirsi in una determinata posizione se ritengono che il loro errore sia più importante di qualsiasi cosa al di sotto di esso. I fixer dei bug iniziano dalla parte superiore della coda.
• Supponendo che tu abbia già una serie di bug ben classificati, dì a tutti che la condizione per mettere un bug in priorità X è che deve essere più importante di tutti gli errori nella priorità X-1 .
• Informa i mittenti che in nessun momento il numero di bug con priorità X può superare il numero di bug con priorità X-1 .

Ma sembra che il tuo problema non sia la definizione, ma la convinzione che i bug a bassa priorità non vengano corretti. Presumibilmente, non puoi persuaderli altrimenti, poiché (da quello che dici) la loro convinzione è fondata in realtà. Quindi, perché li fai inviare questi bug? Finisce per non essere altro che occupato. Ad esempio, dopo aver raggiunto un certo numero di bug attivi, puoi dire a tutti di non preoccuparsi di creare report a meno che non ritengano di aver trovato qualcosa di più importante degli più bug in sospeso. Certo, questa è solo la soluzione di coda con un limite superiore per la lunghezza della coda.