La risposta a questa domanda dipende molto dagli obiettivi di business, nonché dal cliente.

Enterprise :

Se stai facendo affari con un cliente di livello enterprise che è ben stabilito nel mercato, è meno flessibile e non può adattarsi alle modifiche più rapidamente. Pertanto, la stabilità è un requisito assoluto nella maggior parte dei casi. Ci sono delle eccezioni per la ricerca e lo sviluppo e l'inserimento di nuovi verticali. In alcuni casi, la finitura più veloce viene prima.

Questi tipi di clienti generalmente capiscono che un buon software richiede del tempo per svilupparsi e lavorerà con voi per cercare di raggiungere gli obiettivi.

startup :

Per una nuova startup, le regole sono drasticamente differenti. Come startup, devi sapere subito se il prodotto che stai costruendo soddisferà davvero un bisogno come previsto dalla tua ricerca di mercato. Per una startup, ottenere un prototipo sul mercato il più velocemente possibile può raccogliere molti preziosi feedback sulla direzione in cui il prodotto dovrebbe andare.

Può anche stabilirti come leader del mercato, aiutandoti ad acquisire una preziosa quota di mercato in un nuovo verticale prima che diventi saturo di concorrenza.

Poiché le startup sono piccole, flessibili e possono adattarsi rapidamente ai cambiamenti, questo modello funziona meglio per loro.

In sintesi, ci sono altri fattori da considerare, ma l'idea principale è che ogni progetto è diverso e avrà diversi obiettivi di qualità e tempo per il mercato. Spetta alla dirigenza esecutiva stabilire una strategia aziendale efficace che includa un'analisi approfondita dei costi opportunità della scelta di un metodo rispetto a un altro.

o ... 3. Taglia funzionalità non essenziali

A volte, a causa delle caramelle tecniche o delle caratteristiche di caramelle richieste dal cliente, le scadenze sono difficili da soddisfare e intrinsecamente sorgono un numero maggiore di bug. È KISS e YAGNI principi applicati.

Citando da questo libro , "Rilavorazione", l'essenziale / core / epicentro del tuo software è ciò che il il business deve funzionare, così come un hot dog stand può essere un hot dog senza condimenti, quello che non puoi tagliare sono gli hot dog.

rinegoziare

Una delle cose più difficili da imparare è come rendere felici i clienti, e nella mia esperienza, questo può essere più facilmente realizzato con iterazioni di prodotto più piccole.

A volte le scadenze richiedono che il software funzioni a un livello di produzione elevato sin dal primo giorno. I manager / clienti non sempre sanno (che è la maggior parte delle volte) ciò di cui hanno effettivamente bisogno per il software. Quindi cerca di tagliare funzionalità non essenziali e mantenere la qualità. Alla fine dipende da quanto sarà critico l'ambiente di produzione, ma cercherà di tagliare le caratteristiche extra e fornire qualità. Ripetendo da "Rework":

Fare in un secondo momento significa anche fare meglio

... e anche rispettare le scadenze con meno errori

Bene, puoi inquadrarlo in questo modo: vuoi pagare la qualità ora o più tardi? O prenditi il tempo per farlo bene in primo luogo, o dedica del tempo più tardi a risolvere tutti i problemi. Direi che questa fase di risoluzione dei bug post-sviluppo potrebbe essere più costosa perché può anche essere più rischiosa e più incline alle soluzioni hacky poiché il codice esistente è già presente e probabilmente non ha una qualità sufficientemente elevata.

Rispetta la scadenza e presenta un elenco di problemi conosciuti .

Le persone odiano trovare bug, ma se sono stati informati in anticipo, tendono ad essere molto più indulgenti.

Questo dipende interamente dalla situazione ....

Ci sono molti fattori da considerare:

1. Quanto è facile implementare le patch?
2. È possibile rilasciare una versione base, ridotta e poi applicare nuove funzionalità (caso limite) nel tempo?
3. Qual è la cultura generale dell'industria cliente per un prodotto del genere? Si aspettano versioni perfette una tantum o sono abituati all'idea di un sistema in evoluzione che potrebbe essere bacato quando viene rilasciato per la prima volta?
4. Quanto pesa il rischio per l'azienda in una versione iniziale buggy, invece di far scadere la scadenza?

In breve, non c'è una risposta in bianco e nero a questo. Ad esempio: per qualcosa come un sistema embedded che è difficile e costoso da distribuire ai dispositivi sul campo, potrebbe essere meglio provare ad attendere (rinegoziare le scadenze, se possibile) e farlo uscire senza errori il più possibile. D'altra parte, per qualcosa come un grande sistema di portali web (scritto come app web) che può essere facilmente aggiornato in qualsiasi momento, tirando fuori le correzioni mentre escono, potrebbe essere più sensato rilasciare una versione inizialmente dubbia, e poi aggiorna i problemi (e la funzionalità del caso limite) quando arrivi ad esso.

Ma alla fine della giornata, nella mia esperienza questa è stata più una decisione commerciale che una decisione tecnologica. Se ti trovi in una situazione in cui mancare la scadenza è un grosso problema, mentre non hai una versione iniziale buggata (o viceversa), ti consigliamo di valutare queste cose quando prendi la decisione.

NOTA: Come programmatore, ovviamente preferisco l'idea di lucidare un prodotto il più possibile prima di scatenarlo (diamine, preferirei non avere mai scadenze, mai) ). Ma realisticamente, questo non è possibile nella vita reale. Spesso, una versione iniziale ridotta è una buona soluzione di medio livello.

Ho visto molti PM temere di dire al cliente che non possiamo rispettare il programma e insistere che spediamo con bug noti. Posso dirti che ogni volta che dicono al cliente, di solito è molto più interessato a meno bug e ad una scadenza spostata. Garantisco che ricorderanno gli errori più della scadenza mancata a meno che la scadenza non sia assolutamente irrealizzabile (come l'inizio della stagione di presentazione delle tasse quando si sta facendo software fiscale) o influenzerà alcune altre cose che saranno molto costose da spostare (IMHO Il 98% di tutte le scadenze non soddisfa questi criteri).

Penso che dipenda dal bug. Vuoi ritardare una versione per correggere un bug in cui l'app si arresta nel momento in cui viene avviata su un qualsiasi computer? Sì, sicuramente. Hai bisogno di correggere un bug che si verifica solo su Windows ME mentre c'è la luna piena? Questo probabilmente può aspettare.

Se si tratta di un bug critico, è preferibile eseguire il numero 2 con le mani in giù. Il motivo è che costa in modo esponenziale più difficoltà se devi rimandare la correzione in un aggiornamento.

Per gli aggiornamenti meno importanti, puoi rilasciare un aggiornamento in bundle che riduce in parte il costo.

In caso di dubbi, ti dico che vai con il n. 2, ma non sarei sorpreso di ottenere un respingimento dalla dirigenza con questo approccio. Ho il sospetto che i manager tendano a essere giudicati in base a quanto sono bravi a rispettare le scadenze rispetto a quando non causano inutili aggiornamenti critici.

Nessuno dei due. Perché non infornare la qualità con il tuo codice? Essere in grado di rispettare le scadenze con un codice di qualità? Puoi spingere meno funzioni, ma se la qualità è integrata nel processo puoi ottenerle entrambe.

Ciò che accade ora è che avrai bisogno di un responsabile di team potenziato o di un responsabile di sviluppo che possa respingere l'attività e avere una conversazione attorno a 2 cose:

1. Qualità trasformata in codice = 2 funzioni in meno per build
2. Assegnazione di priorità alle funzionalità più necessarie da parte degli stakeholder su ciò di cui hanno VERAMENTE bisogno.

Quindi puoi concentrarti sulle funzionalità di valore più elevato e spingerle fuori con eccellenza.

Per quanto riguarda i test, non finisce mai. è finita ma non è mai finita.

Vai per il lancio con bug con severità e più priorità disattivate.

Rispettare la scadenza con molti bug ti rende povero nel settore e il cliente non verrà più da te. Puoi parlare con il cliente per ottenere il ritardo di due o tre giorni.

Se guardi questo da un utente finale, sarei piuttosto messo da parte se qualcuno ti ha promesso di fare qualcosa per lunedì e quando ho provato a usarlo non funziona, o è tutto buggato.

Ma se guardi al lato "procedurale", significa che l'applicazione ha bisogno di più test e fa parte della vita naturale del software.

Il mio approccio migliore è cercare di far funzionare le cose nel modo in cui dovrebbero funzionare (se si tratta di un modulo importante, non prestare attenzione ai dettagli, login nel modulo dovrebbe accedere ma nessuno verrà visualizzato se non si visualizzano le notifiche in seguito) .

Questa è una domanda a cui solo tu puoi rispondere. Dipende dal tipo di prodotto, dal cliente, dal cliente, ecc. Non è possibile per noi fornire una semplice risposta "a o b". È completamente dipendente dalla situazione.

Ma ti ricorderò che il costo della correzione di un bug dopo è molto più alto di quello che è stato risolto prima di . Quindi, prendilo in considerazione quando decidi se attendere o meno fino al post-release per correggere un bug, perché spenderai più tempo / sforzi / soldi su di esso.