Quando va bene spedire un prodotto con un bug noto?
Suppongo tu stia parlando di un bug "noto" (la domanda non ha significato altrimenti). Bene, la risposta dipende da questi fattori:
1) Chi è l'utente e come accetterà il bug nel caso in cui venga trovato?
2) Qual è il potenziale impatto (danno) del bug?
3) È possibile ritardare la spedizione del software per correggere il bug?
4) La cosa più importante: cosa ti aspetti dal tuo software? Time-to-market? Qualità? Vuoi vedere se i tuoi clienti usano il software abbastanza a lungo da trovare il bug?
È un giudizio. Ricorda, un bug può essere molte cose. Se si tratta di una funzionalità importante che non funziona, allora la aggiusti prima. Se è qualcosa di minore che ha un impatto reale minimo o nullo sugli utili del programma, potresti lasciarlo scivolare.
Quindi guardalo da un punto di vista costi / benefici.
Spedisci prodotti con bug noti quando il costo totale e il rischio di correggere il bug superano qualsiasi problema e l'impatto negativo potrebbe derivare dal bug in circolazione.
Quindi, se hai un periodo di test di 2 settimane prima del rilascio, e viene trovato un piccolo bug, la domanda è ... sta correggendo quel bug che valeva le 2 settimane aggiuntive che un team potrebbe ora spendere per ri-testare il applicazione e installazione (un passaggio spesso dimenticato nella creazione di software)? Quali sono i costi per la reputazione o le 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 fornita in tempo.
I rischi includono il rischio di introdurre un nuovo problema, non solo nel correggere il bug, ma anche le cose che potrebbero sorgere dalla creazione di una nuova installazione.
L'impatto negativo è sia il tempo che gli sforzi per gestire i clienti che segnalano il bug e cose come il danno alla reputazione.
I bug hanno diverse gravità. In qualsiasi azienda di software in cui ho lavorato, abbiamo classificato i bug in ordine di priorità da P0 a P4.
P0 Il software non funziona / va in crash e potrebbe causare danni al business dei clienti. P1 Non funziona come progettato e si blocca in modo coerente nelle funzionalità di base P2 Si blocca di tanto in tanto e alcune funzionalità secondarie potrebbero non funzionare. P3 Alcuni elementi del software non funzionano come previsto / previsto P4 Problema cosmetico.
Ho lavorato in luoghi in cui i P4 non vengono corretti perché hanno un così piccolo effetto sul software.
Direi che va bene spedire se il tuo software ha conosciuto problemi di P3 / P4, metterei questo nelle note di rilascio e tieni presente che sono stati elaborati.
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. Spediscono tutti prodotti con bug, sia noti che sconosciuti. Cerca di ridurli al minimo, ma non aspettare la perfezione. Spedisci velocemente, spedisci spesso.
Non puoi spedire software senza bug. Il consiglio che posso dare è che è sempre meglio dire al tuo cliente: "Questa versione non può fare questo e quello, ma stiamo andando a risolvere questo" rispetto alla situazione in cui il cliente ti dice che hai un bug.
quando è una "caratteristica"! ;)
Su una nota seria, a meno che tu non sia un programmatore perfetto con una perfetta configurazione di test, per testare perfettamente ogni singolo percorso di codice e alla fine che potrebbe potenzialmente esistere, è improbabile che spedirai un prodotto privo di bug.
Pertanto, sii pragmatico, se tutto ciò che hai riscontrato nei tuoi test è stato corretto, qualsiasi cosa extra dovrebbe essere risolta in base alle necessità.
Se sei onesto con i tuoi clienti, puoi spedire con bug. Raccontare loro di tutti i bug esistenti mostra loro che hai una buona conoscenza del tuo software, e che è davvero ben collaudato (se lo è ..). :)
Ovviamente la cosa migliore è evitare le spedizioni con errori.
Spesso è meglio avere una spedizione del prodotto in tempo, con un elenco di problemi noti, che non spedire affatto.
Una delle cose nel mondo della programmazione che dà sicurezza alle persone in un progetto è se hanno rilasciato pianificato e se la pianificazione contiene .
Questo è il motivo per cui Ubuntu viene rilasciata ogni semestre, anche se ci sono ancora problemi aperti.
Direi che una buona regola empirica è, "questo bug è uno showstopper?"
Se il bug causa il fallimento di uno "scenario percorso felice", allora assolutamente non viene spedito con quel bug.
Se il bug causa il fallimento di uno "scenario tangente verso il percorso felice" e non c'è una soluzione alternativa, non spedire con quel bug.
Se un bug è documentato e c'è una soluzione nota, allora è probabilmente OK spedire con quel bug.
Dal punto di vista dei consumatori ... Mai. Il mio punto è che finché sai che c'è un grosso problema nel software, 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 bug minori che non saranno: (i) compromettere la sicurezza del software (ii) impatto sull'usabilità
Come hanno detto le persone, è una domanda molto ampia. In realtà mi porta a una prospettiva interessante: i cosiddetti "bug" che si sostiene sono solo i difetti che sono stati scoperti dai tester. Ci potrebbero essere infinite altre scappatoie. Ho appena ricordato una storia interessante che ho ascoltato da un rispettato professore in un seminario di laurea: quando le persone in uno dei paesi scandinavi utilizzavano una macchina per il voto di tipo "riconoscibile per la scrittura a mano", alcune persone hackeravano l'intero sistema scrivendo codice SQL malevolo (che il sistema ha preso come input normale).
Un altro fattore decisivo può essere il modo in cui il difetto si riferisce alla tua ultima versione. Se il bug fa parte di una funzione nuova, ma rotta, la non funzionalità non rappresenta una regressione delle funzionalità. Vai avanti e spedisci.
D'altra parte, se il difetto causa una perdita di funzionalità esistente che è nota per essere utilizzata dai clienti esistenti, allora deve bloccare la versione. Tale versione sarebbe un downgrade per i tuoi clienti e non servirebbe né i tuoi interessi né i loro.
Ci possono essere sfumature di grigio in questo. Una regressione nella funzionalità di base non dovrebbe mai uscire dalla porta. Alcune regressioni nelle funzionalità periferiche potrebbero essere utilizzate per guidare gli utenti se il rilascio contiene anche nuove funzionalità a cui hanno espresso interesse. Un oscuro difetto che probabilmente non influirà su molti clienti può essere rilasciato, a condizione che venga fornita una soluzione quando incide su quei clienti. I difetti nelle funzionalità altamente sperimentali che sono disattivati di default comunque non dovrebbero mai causare il ritardo della pubblicazione.