Rilascio anticipato / rilascio spesso per software commerciale? [chiuso]

Question

C'è qualcuno con esperienze / esempi sul rilascio anticipato / rilascio frequente di software commerciale? Funziona?

Stavo pensando a VMware in cui sono state rilasciate molte revisioni tra ciascuna versione principale. E l'esperienza di installazione è stata terribile, a volte interrompevano le macchine virtuali esistenti e altre volte gli strumenti VMware all'interno dei sistemi operativi guest non funzionavano correttamente o non venivano installati. È semplicemente orribile.

E stavo pensando anche alle distribuzioni ClickOnce, poiché con ClickOnce quando aggiorni il tuo software, tutti i client vengono automaticamente informati della versione e con un clic vengono aggiornati alla nuova versione. Se il tuo software ha dei bug, verranno automaticamente "aggiornati" per ottenere anche quei bug.

Hai esperienza \ esempio \ suggerimento di applicare il principio di rilascio anticipato / rilascio spesso al software commerciale?

Sto cercando di applicarlo a uno.

Answer 1

Kenny ha ragione: dipende.

Lavoriamo su software Enterprise, in cui un cliente può eseguire un progetto interno di 3+ ??mesi per eseguire l'aggiornamento a una nuova versione. In quell'ambiente i rilasci frequenti non funzionano . I clienti rimarranno su una versione precedente per anni e dobbiamo continuare a supportarli, quindi più versioni sono attive più lavoro di supporto.

All'altro estremo stavo eseguendo Google Chrome e ho letto di un aggiornamento beta. Sono andato a vedere come ottenerlo e ho scoperto che Chrome si era già aggiornato. Se ci sono state delle notifiche mi sono perso, e per me va bene.

La domanda principale è quanto sia dirompente una nuova versione . Ad esempio, se MS rilasciasse nuove versioni di Visual Studio ogni 3 mesi con una nuova versione .NET, runtime C, ecc., Passeremmo buona parte del nostro tempo a occuparci dell'aggiornamento, il che non sarebbe positivo. Ma se vogliono rilasciare nuove versioni di Windows Media Player con alcuni nuovi widget che vanno bene per me, basta che il processo di download / installazione sia il più semplice possibile.

Answer 2

Penso che dipenderà sempre dal tuo mercato o dalla tua base di clienti. Cambiare / aggiornare il software è sempre doloroso e ancor più doloroso in alcuni ambienti e aziende. Cicli di rilascio rapidi possono essere di disturbo. Queste interruzioni spesso si estendono anche alle operazioni interne, a seconda di quanto bene il creep di funzionalità sia gestito dal marketing / gestione.

Quindi, la classica risposta sempre vera "dipende" squilla di nuovo.

Se stai davvero aggiungendo valore al prodotto, quindi i clienti, specialmente quelli nuovi, lo vorranno. Il caso migliore è rimuovere il dolore del cambiamento di aggiornamento, come in, funziona allo stesso modo, ma meglio in modi ovvi. Grande.

Answer 3

Presta attenzione all'uomo dietro il sipario. :
La cosa che Release Early - Release Spesso la pratica vuole che tu faccia è fallire presto e velocemente invece che alla fine del progetto, quando è troppo tardi. Ti dà più opportunità di mostrare ciò che stai costruendo al cliente finale, ottenere feedback preziosi e adattarti a un costo inferiore. La persona nel ruolo di "cliente" deve essere in grado di ottenere facilmente l'ultima versione; giocaci e rispondi con feedback costruttivi il più regolarmente possibile.

Nel caso in cui stai costruendo qualcosa di critico, ad es. qualcosa che monitora o controlla una centrale elettrica, probabilmente vorresti stare attento con questa pratica. Non vuoi che le persone con le torce escano come feedback per la tua nuova versione. In questi casi, ha senso distribuire regolarmente su un banco di prova, guardarlo per X giorni (secondo il tuo livello di confidenza) e poi andare LIVE! Puoi dare ai tuoi clienti l'accesso a questo banco di prova per giocare e costruire il suo misuratore di fiducia.
Se si tratta di un'applicazione non critica e hai avuto un buon record storico di buone versioni, fai qualcosa come ClickOnce .. ma assicurati anche che sia altrettanto facile eseguire il rollback per il cliente.

Answer 4

Se hai intenzione di farlo, assicurati che quando le persone acquistano il tuo prodotto otterranno aggiornamenti gratuiti alle nuove versioni per un anno o qualche altro periodo di tempo in modo che non si sentano come se fossero stati derubati quando esce una nuova versione 2 mesi dopo aver acquistato una copia. Inoltre, assicurati di supportare le vecchie versioni in modo che coloro che non vogliono aggiornare, vogliono solo correzioni di bug possano farlo senza rischiare di interrompere le loro installazioni attuali con nuove versioni del software. Personalmente penso che sarà più lavoro, ma finirai con un prodotto migliore e consentirai alle persone che usano il tuo software di sfruttare più rapidamente le nuove funzionalità se lo desiderano.

Answer 5

Eseguiamo un'applicazione SaaS, quindi in linea di principio può essere aggiornata tutte le volte che vogliamo.

D'altra parte, in pratica, ottiene solo poche versioni principali all'anno (in genere vengono rilasciate versioni di patch più piccole ogni poche settimane).

La ragione di ciò è che le versioni creano interruzioni per il personale operativo; a volte è necessario rimuovere parte dell'applicazione. Ogni volta che si tratta di modifiche non rivolte ai clienti, c'è molto lavoro che in realtà si occupa di fare il rilascio invece di fare l'ingegneria.

Quindi, mentre StackOverflow sembra aggiornarsi ogni pochi giorni, non facciamo nulla del genere. Diversi bug possono essere corretti in un giorno, ma sono stati corretti in una versione successiva che si presenta come un "big bang". O qualcosa del genere.

Answer 6

Dipende dalle tue risorse. Se sei MicroSoft, puoi rilasciare anticipatamente un POS pieno di bug che fa rima con Sista e fare affidamento sul tuo potere di marketing per far dimenticare alle persone le loro prime esperienze con il prodotto.

Se speri in un buon passaparola, rilasciare una versione anticipata non è una buona idea (a meno che tu non abbia intenzione di cambiare il nome o qualcosa prima della versione finale).