Bugs rispetto al miglioramento rispetto alla nuova funzione

Question

Quando si pianifica e si dà la priorità a ciò che deve essere incluso in una release, si fa distinzione tra bug, miglioramenti delle funzionalità e nuove funzionalità?

Ad esempio, i bug hanno sempre la priorità: si correggono tutti i bug noti prima di lavorare sulle nuove funzionalità? Usi un sistema formale per confrontare il costo rispetto al valore di ogni cambiamento nel tuo arretrato? E se sì, paragoni bug e caratteristiche usando la stessa formula? Questo è diverso per software commerciale vs software aziendale interno vs open source?

EDIT: alcune grandi risposte - grazie. Mentre avevo un'opinione preconcetta sul fatto che è necessario trattare bug, funzionalità, miglioramenti uguali e semplicemente selezionare il lavoro in base al costo/beneficio di ciascuno, penso che la realtà sia che questo dipende dalla situazione.

Answer 1

Questa scelta si chiama triage, un termine dai reparti di emergenza negli ospedali in cui devono decidere chi viene trattato (e, a volte, sfortunatamente, chi vive e muore).

Come con tutte le decisioni aziendali, è un problema di costi/benefici. Qual è il vantaggio di correggere un bug o aggiungere una funzionalità? Quanto costerà (incluso il costo opportunità di non fare qualcos'altro)?

Scegli quelli che hanno il maggior vantaggio per il minor costo. Quello a cui miri è il massimo bang-per-buck. Le risorse sono limitate, i desideri non lo sono, il perenne problema del capitalismo :-)

Non ha senso riparare un bug sperimentato da un solo cliente che non ha intenzione di lanciare più attività ripetute a modo suo se significa una funzionalità che ne venderà centinaia di copie è caduto nel frattempo.

Per quello che vale, la nostra azienda ha un database di modifiche richieste in cui i clienti possono sostanzialmente votare per quello che vogliono vedere nelle prossime versioni dei nostri prodotti. L'effettiva creazione di queste modifiche richieste in quel database è limitata alla forza vendita poiché non vogliamo che tutte le richieste vengano mostrate senza essere valutate e discusse almeno un po 'con i clienti.

Inoltre, ci rivolgiamo regolarmente ai nostri più grandi clienti (in termini di entrate generate) con l'elenco per capire quali funzionalità devono essere aggiunte (sono libere di suggerire anche i propri desideri, che vengono anche inserite nel database - ovviamente il potere di voto dipende un po 'dalle entrate).

Questo è piuttosto separato dal nostro sistema di bug, anche se molto spesso vengono generati bug che sono in realtà nuove richieste di funzionalità, e vengono spediti attraverso il nuovo database di funzionalità. È possibile che ciò possa accadere anche per veri bug che sono considerati a basso impatto o che hanno soluzioni alternative adeguate.

Answer 2

Mi piace pensare che le correzioni di bug debbano sempre venire prima di miglioramenti e nuove funzionalità, in tutti i casi. Anche se il bug in particolare non ti infastidisce troppo come lo sviluppatore, qualcuno da qualche parte si sta rovinando la giornata quando compare il tuo piccolo errore.

Answer 3

Consideriamo sempre il costo della correzione del bug rispetto ai problemi causati da esso. A volte, non vale la pena di avere ogni singolo bug correttamente corretto, causato da root, quindi risolto.

Molte volte un particolare miglioramento o una nuova funzione viene finanziata o almeno fortemente raccomandata da un cliente grande/buono, quindi anche questo riguarda le questioni.

Answer 4

distinguere, sì.

i bug hanno la priorità, sì.

tutte le priorità critiche/normali e sopra i bug prima, sì.

sì, la regola 80/20.

no, i bug e le caratteristiche devono essere trattati in modo diverso perché sono ponderati in modo diverso.

sì, tutte le applicazioni commerciali, open source e interne hanno il loro modo di fare le cose.

Ad esempio, FogBugz utilizza la pianificazione basata sull'evidenza ed è l'unica gestione/tracker che io conosca che utilizza tale formula.

Spero che questo aiuti!

Answer 5

Chiediamo ai nostri utenti. Abbiamo un prodotto di nicchia e una piccola base di utenti.

Seriamente, il gruppo di utenti paga manutenzione o pensa di acquistare.

Quindi chiediamo loro cosa vorrebbero.

Suggeriscono correzioni, chiedono nuove funzionalità.

Diciamo loro della roadmap di sviluppo: perché abbiamo le cose che vogliamo fare al prodotto, a causa dei tempi che cambiano, idee di design. Modifiche ai regolamenti.

E se ogni cliente dice "abbiamo davvero bisogno della funzione X": quindi verrà dopo.

Se dicono "voi ragazzi dovete sistemare il bug dove clicco lì e non lo fa blah:" allora quel bug viene corretto.

Software commerciale: con i clienti che votano per le modifiche. Ovviamente, prendiamo le loro scelte in merito al consiglio: l'azienda ha altre cose a cui sta pensando.

Answer 6

Devi guardarlo dal punto di vista di ciò che il bug è. Un bug show-stopper è sempre la priorità numero uno. Se le persone non riescono ad accedere o se i dati critici non possono essere inseriti o modificati, ecc., Ciò deve avere la precedenza su praticamente tutto.

I bug di minore importanza possono essere utilizzati come necessario. Possiamo ritardare la correzione di un bug perché sappiamo che stiamo lavorando su quella sezione per un miglioramento la prossima settimana. Quindi la correzione del bug andrà con il miglioramento. Possiamo ritardare la correzione di un bug se è minore e un miglioramento pianificato sostituirà il codice completamente a breve. Un importante miglioramento potrebbe avere la precedenza sulla correzione di alcuni refusi sull'interfaccia. Un cliente potrebbe dirci che questo altro progetto è più critico e farlo prima di correggere il bug (il nostro software è altamente personalizzato dal client). Tutto dipende dall'influenza del bug e dei piani e delle politiche aziendali esistenti una volta superato il fermo dello spettacolo. Un bug che disturba un cliente importante può avere una precedenza più alta anche se sembra minore per lo sviluppatore. Se l'amministratore delegato desidera che venga corretto ora, non importa quanto poco importante sembra rispetto al resto del carico di lavoro, viene risolto ora.

Answer 7

Per i bug, è piuttosto semplice: se hai intenzione di risolverlo, correggilo prima di scrivere altro codice. Perché? Più codice aggiungi, più difficile sarà trovare il bug esistente.

Se stai bene con l'idea del bug che non viene mai corretto, taggalo e aggiungi funzionalità.

Answer 8

Bug? Non abbiamo bug. Sono funzionalità non documentate.

Per noi la scelta è sempre basata su decisioni di business e come sviluppatore non ho alcun input oltre a offrire la mia opinione su quale dovrebbe essere la priorità assoluta. Il più delle volte, le funzionalità superano i bug perché l'aggiunta di funzionalità "viene visualizzata" nell'area aziendale come i progressi sono stati fatti e i bug che avrei potuto correggere un anno fa continuano ad esistere perché il lato business vuole solo vedere "progresso". Il triage è ottimo se consentito, ma troppo spesso nell'ambiente aziendale, si tratta di risultati visibili, non di funzionalità.

Answer 9

Una cosa non ha menzionato finora la gravità del bug. Se il bug ha un'elevata severità (come crash, non può superare il test di durata, e sicuramente dipende dal tipo di applicazione che hai), dovresti risolverlo definitivamente prima di aggiungere nuove funzionalità.

Answer 10

Il punto 5 di The Joel Test: 12 Steps to Better Code costituisce un argomento convincente (a mio parere) che è una buona idea correggere i bug prima di scrivere un nuovo codice.