Se ci sono & # 8220; problemi noti & # 8221; perché rilasciare? [chiuso]

Question

Ho visto molte API che elencano i dettagli sui problemi noti? Se ci sono problemi noti, perché rilasciarlo al pubblico prima di risolverli?

Qual è il motivo? Linee morte? O la correzione che può rompere qualcos'altro?

Nota: non sono sicuro che questa domanda appartenga qui. Quindi sentiti libero di chiudere se questa non è una domanda valida.

Answer 1

Il software non è perfetto e in attesa che ogni problema sia risolto per rilasciare qualcosa si tradurrà in un mondo senza software.

Answer 2

Perché il software è utilizzabile e utile, anche con i problemi, e perché gli utenti preferirebbero averlo prima di attendere il rilascio. Perché i suoi sviluppatori vogliono il feedback che fornirà il rilascio anticipato.

Answer 3

Ci sono sempre noti problemi noti. Se non rilasci fino a quando non ci sono più problemi noti, non rilascerai mai. A volte è meglio ottenere una versione per lo più funzionante fuori dalla porta con avvisi su alcuni problemi non critici.

Answer 4

Spesso il software più recente è ancora migliore rispetto alle versioni precedentemente disponibili, anche con i problemi noti. Soprattutto quando hanno a che fare con le biblioteche, i clienti preferiscono spesso ricevere codice prima che presenti problemi piuttosto che attendere problemi che non si preoccupano di risolvere.

Answer 5

Profit.

I software del mondo reale di qualsiasi complessità non saranno mai perfetti. C'è un certo punto in cui è " abbastanza buono " tuttavia, ed è allora che è il momento di spedire.

I veri dibattiti si verificano quando si decide quale livello di qualità soddisfa il "abbastanza buono" bar.

Answer 6

I problemi noti spesso riguardano un numero limitato di utenti e tutti gli altri potrebbero davvero utilizzare i miglioramenti della nuova versione. Inoltre, potrebbero esistere gli stessi problemi con la versione esistente, nel qual caso non vengono forniti agli utenti nuovi bug (noti). Quindi, è davvero una vittoria.

Alcuni problemi potrebbero anche richiedere molto tempo per essere risolti.

Answer 7

A volte non riesci proprio a risolvere questi problemi.

Immagina di avere uno script JS e alcuni bug in un browser che non puoi evitare. Non rilasceresti la tua libreria fino a quando quel browser non sarà riparato, vero? Oppure potresti semplicemente aggiungere un " problemi noti " nota sui problemi di un browser e rilascialo.

Answer 8

Altrimenti non rilasceresti mai.

Answer 9

I problemi noti vanno bene. Sono i problemi sconosciuti che causano il problema.

Answer 10

Perché il software è stabile . Se ci sono alcuni problemi noti che non influiscono direttamente sull'uso quotidiano del software e che possono essere risolti in patch, perché non rilasciarlo?

Inoltre ci sono scadenze e costi da considerare, ma ovviamente quest'ultimo non si applica all'Open Source.

Answer 11

Il motivo principale è IL TEMPO DI MERCATO

Answer 12

A volte il vantaggio di rilasciare qualcosa che funziona è più importante dei problemi che solo alcuni utenti saranno colpiti.

I bug possono essere minori o critici: S

Answer 13

Se ha un basso impatto (interessa pochi utenti o forse è interno), probabilmente quello è un motivo. Altri possono essere grandi parrucche che vogliono roba fuori e sul mercato al più presto, quindi a volte le cose devono essere lasciate incomplete sulla base di una serie di fattori.

Answer 14

Soprattutto con progetti open-source, questo consente alla maggior parte degli utenti di ottenere il prodotto senza problemi e aumenta anche la consapevolezza dei bug in modo che gli utenti possano contribuire al codice.

Answer 15

Se un problema noto interessa solo una piccola percentuale di potenziali utenti, probabilmente vale la pena rilasciarlo.

Answer 16

Un'API è un contratto tra l'implementatore dell'API e il programmatore che utilizza l'API. Anche se l'implementazione presenta problemi noti, è bene rilasciare la documentazione dell'API, in modo che i programmatori siano in grado di iniziare a sviluppare codice in grado di sfruttare l'API. Resta inteso che il fornitore dell'implementazione soddisferà (eventualmente) la fine del contratto, portando l'implementazione in piena conformità con l'API. Se l'API fosse rilasciata solo quando l'implementazione fosse perfetta, gli sviluppatori dell'applicazione sarebbero stati costretti a perdere un'enorme quantità di tempo di sviluppo in cui potevano essere produttivi, anche se si basava solo sui documenti API e non potevano effettivamente testare ancora il codice.

Answer 17

" Impegno " ;.

Questo è più importante.

Una volta finalizzata (impegnata) la data di consegna, il prodotto deve essere rilasciato se è in "Accettabile" livello. La differenza tra " Perfezione " e " Accettazione " è " Problemi noti "

Answer 18

La maggior parte delle aziende ha un criterio di rilascio che potrebbe sembrare-

La versione del software potrebbe contenere alcuni bug minori il cui conteggio è impostato su un limite - Tali problemi potrebbero essere minori problemi dell'interfaccia utente.

La versione del software potrebbe presentare alcuni bug importanti il ??cui conteggio è impostato su un limite: vengono fatti tentativi per liberare la versione da tali bug, ma se continuano a sfuggire (a causa di motivi diversi), non dovrebbero rompere il prodotto e lì è disponibile qualche soluzione per aggirarli.

La versione del software non dovrebbe presentare alcun bug critico: il software non verrebbe spedito se venisse rilevato un bug critico. Tali bug rompono il prodotto senza soluzioni alternative di intrattenimento.

Anche in questo caso le suddette classificazioni potrebbero essere fuori target e dipendono dalla società e dai relativi processi coinvolti.

applausi

Answer 19

Consulta i vantaggi della politica di rilascio anticipato / rilascio frequente, ad es. l'inestimabile feedback dei tuoi utenti.