Quando va bene spedire un prodotto con un bug noto?

Quando va bene spedire un prodotto con un bug noto?

Presumo che tu stia parlando di un bug "noto" (altrimenti la domanda non ha senso). Bene, la risposta dipende da questi fattori:

1) Chi è l'utente e come accetterà il bug nel caso venga rilevato?

2) Qual è il potenziale impatto (danno) del bug?

3) È possibile ritardare la spedizione del software al fine di correggere il bug?

4) Soprattutto: cosa ti aspetti dal tuo software? Time-to-market? Qualità? Vuoi vedere se i tuoi clienti usano il software abbastanza a lungo per trovare il bug?

Deve essere sempre OK, perché non esiste un software senza errori.

È una chiamata di giudizio. Ricorda, un bug può essere molte cose. Se è una delle principali funzionalità che non funziona, allora lo risolvi prima. Se è qualcosa di minore che ha un impatto minimo o nullo sulle utilità del programma, potresti lasciarlo scorrere.

Quindi guardalo da un punto di vista costi / benefici.

Spedisci prodotti con bug noti quando il costo totale e il rischio di correggere l'errore supera qualsiasi problema e impatto negativo deriverebbe dalla presenza del bug.

Quindi, se hai un periodo di test di 2 settimane prima del rilascio e viene trovato un piccolo bug, la domanda è ... sta risolvendo quel bug che vale le 2 settimane aggiuntive che un team potrebbe ora dover spendere per testare nuovamente l'applicazione e l' installazione (un passo spesso dimenticato nella creazione di software)? Quali sono i costi per la reputazione o nelle vendite se il software è in ritardo? Le persone si arrabbieranno? Potrebbero essere abbastanza felici di vivere con un bug minore se la funzionalità principale può essere consegnata in tempo.

I rischi includono il rischio di introdurre un nuovo problema, non solo nel correggere il bug, ma anche cose che potrebbero derivare dalla creazione di una nuova installazione.

L'impatto negativo è sia il tempo che l'impegno con i clienti che segnalano il bug e cose come il danno alla reputazione.

I bug sono di diversa gravità. In qualsiasi società di software in cui ho lavorato, abbiamo classificato i bug in ordine di priorità da P0 a P4.

P0 Il software non funziona / si arresta in modo anomalo e potrebbe causare danni al business dei clienti. P1 Non funziona come previsto e si blocca costantemente nella funzionalità principale P2 Si arresta occasionalmente e o una funzionalità laterale potrebbe non funzionare. P3 Alcuni elementi del software non funzionano come previsto / problema P4 Cosmetic progettato.

Ho lavorato in posti in cui i P4 non vengono riparati perché hanno un effetto così piccolo sul software.

Direi che va bene spedire se il tuo software ha riscontrato problemi P3 / P4, lo inserirò nelle note di rilascio e noterò che stanno lavorando.

Non avrei mai rilasciato software con un problema P0, P1 o P2 di cui ero a conoscenza.

Si chiama " problema noto ". Google, Microsoft, Apple, ecc. Tutti spediscono prodotti con bug, sia noti che sconosciuti. Cerca di minimizzarli, ma non aspettare la perfezione. Spedisci velocemente, spedisci spesso.

Non è possibile spedire software senza bug. Il consiglio che posso dare è che è sempre meglio dire al tuo cliente: "Questa versione non può farlo e quello, ma risolviamo questo" rispetto alla situazione in cui il cliente ti dice che hai un bug.

quando è una "caratteristica"! ;)

Una nota seria, a meno che tu non sia un programmatore perfetto con una configurazione di test perfetta, per testare perfettamente ogni singolo percorso di codice e, alla fine, che potrebbe potenzialmente esistere, è improbabile che spedirai un prodotto senza errori.

Pertanto, sii pragmatico, se tutto ciò che hai riscontrato nei tuoi test è stato corretto, qualsiasi cosa in più dovrebbe essere riparata in base alle necessità.

Finché sei onesto con i tuoi clienti, puoi spedire con bug. Raccontare loro tutti i bug esistenti mostra loro che hai una buona conoscenza del tuo software e che è davvero ben testato (se lo è ...). :)

Ovviamente la cosa migliore è evitare la spedizione con bug.

Spesso è meglio avere una spedizione del prodotto in tempo, con un elenco di problemi noti, piuttosto che non spedire affatto.

Una delle cose nel mondo della programmazione che dà fiducia alle persone in un progetto è se hanno programmato il rilascio e se il programma è valido .

Questo è il motivo per cui Ubuntu rilascia le versioni ogni sei anni, anche se ci sono ancora problemi aperti.

Direi che una buona regola empirica è "questo bug è uno showtopper?"

Se il bug fa fallire uno "scenario di percorso felice", allora non spedire assolutamente con quel bug.

Se il bug provoca uno "scenario tangente al percorso felice" non riesce e non c'è soluzione alternativa, non spedire con quel bug.

Se un bug è documentato e esiste una soluzione alternativa nota, è probabilmente OK spedire con quel bug.

Dal punto di vista dei consumatori ... Mai. Il mio punto è fintanto che sai che c'è un grosso bug nel software, quindi non dovresti mai spedirlo. Tuttavia, le forze della natura (business) prevalgono su questo se il ciclo di produzione del software è ora nella fase in cui può danneggiare il modello di business e sono piccoli bug che non: (i) compromettono la sicurezza del software (ii) influiscono sull'usabilità

Come hanno detto le persone, è una domanda molto ampia. In realtà mi porta in una prospettiva interessante: i cosiddetti "bug" che affermi sono solo i difetti che sono stati scoperti dai tuoi tester. Potrebbero esserci infinite scappatoie. Ho appena ricordato una storia interessante che ho sentito da un professore rispettato in un seminario di laurea: quando le persone in uno dei paesi scandinavi usavano una macchina per il voto di tipo "riconoscibile per la calligrafia", alcune persone hanno violato l'intero sistema scrivendo codice SQL dannoso (che il il sistema ha assunto come input normale).

C'è qualcosa chiamato FMEA (modalità Failure e analisi degli effetti) che è molto utile per decidere quando un bug noto è importante o non basato su:

1. avvenimento
2. Gravità
3. rivelazione

Un altro fattore decisivo può essere il modo in cui il difetto si riferisce all'ultima versione. Se il bug fa parte di una nuova funzionalità, ma non funzionante, la non funzionalità non rappresenta una regressione della funzionalità. Vai avanti e spedisci.

D'altra parte, se il difetto causa una perdita di funzionalità esistente che è nota per essere utile ai clienti esistenti, deve bloccare il rilascio. Tale rilascio sarebbe un downgrade per i tuoi clienti e non servirebbe né i tuoi interessi né i loro.

In questo possono esserci sfumature di grigio. Una regressione nella funzionalità di base non dovrebbe mai uscire dalla porta. Qualche regressione nelle funzionalità periferiche potrebbe rivelarsi utile per guidare gli utenti se la versione contiene anche nuove funzionalità per le quali hanno espresso interesse. Un oscuro difetto che non rischia di incidere su molti clienti può andare in una versione, a condizione che venga fornita una soluzione quando influenza quei clienti. Difetti nelle funzionalità altamente sperimentali che sono disattivati ​​di default comunque non dovrebbero mai ritardare il rilascio.