In un mondo ideale è preferibile rispettare la scadenza con meno bug. Ma dalla tua esperienza che è più preferibile / accettabile:

1. Rispetta la scadenza ma presenta numerosi bug perché gli sviluppatori si precipitano nelle cose
2. Meno bug ma non rispettano abbastanza la scadenza perché lo sviluppatore è molto rigoroso nello scrivere il codice

La risposta a questa domanda dipende fortemente dagli obiettivi aziendali e dal cliente.

Azienda :

Se stai intrattenendo rapporti commerciali con un cliente di livello aziendale ben consolidato sul mercato, questi sono meno flessibili e non possono adattarsi ai cambiamenti con la stessa rapidità. Pertanto, la stabilità è un requisito assoluto nella maggior parte dei casi. Ci sono eccezioni per la ricerca e lo sviluppo e l'inserimento di nuovi verticali. Più veloce finisce prima in alcuni casi.

Questi tipi di clienti generalmente comprendono che un buon software richiede tempo per svilupparsi e lavoreranno con voi per cercare di raggiungere gli obiettivi.

Startup :

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

Può anche affermarti come leader di mercato, aiutandoti a guadagnare preziose quote di mercato in una nuova verticale prima che si satura 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à obiettivi di qualità e time-to-market diversi. Spetta alla leadership esecutiva determinare un'efficace strategia aziendale che includa un'analisi approfondita dei costi opportunità della scelta di un metodo rispetto a un altro.

oppure ... 3. Tagliare funzionalità non essenziali

A volte, a causa delle caramelle tecniche o delle funzionalità delle caramelle richieste dal cliente, le scadenze sono difficili da rispettare e, di conseguenza, sorgono molti più bug. Sono i principi KISS e YAGNI applicati.

Citando questo libro , "Rework", l'essenziale / core / epicentro del tuo software è ciò che l'azienda deve funzionare, proprio come un supporto per hot dog può essere un supporto per hot dog senza condimenti, ciò 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 realizzato più facilmente con iterazioni di prodotti più piccole.

A volte le scadenze richiedono che il software funzioni a un livello di produzione pesante sin dal primo giorno. I gestori / i clienti non sempre sanno (che è il più 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 cerca di ritagliare funzionalità extra e offrire qualità. Citando di nuovo da "Rielaborazione":

Fare in seguito significa anche fare meglio

... e anche rispettare le scadenze con meno bug

Bene, puoi inquadrarlo in questo modo: vuoi pagare per la qualità ora o più tardi? O prenditi il ​​tempo per farlo bene in primo luogo, o trascorri il tempo in seguito a risolvere tutti i problemi. Direi che questa fase di correzione dei bug post sviluppo potrebbe essere più costosa perché può anche essere più rischiosa e più incline a soluzioni confuse poiché il codice esistente è già in atto e probabilmente non di qualità abbastanza elevata.

Rispettare la scadenza e presentare un elenco di problemi noti .

La gente odia trovare i bug, ma se gli è stato detto in anticipo, tendono ad essere molto più indulgenti.

Questo dipende interamente dalla situazione ....

Ci sono molti fattori da considerare:

1. Quanto è facile stendere le patch?
2. È possibile rilasciare una versione di base ridotta e quindi patchare la nuova funzionalità (caso limite) nel tempo?
3. Qual è la cultura generale del settore client per tale prodotto? Si aspettano rilasci perfetti una tantum o sono abituati all'idea di un sistema in evoluzione che potrebbe essere difettoso alla prima pubblicazione?
4. Quanti rischi per l'azienda comporta una versione iniziale con errori, rispetto alla scadenza?

In breve, non esiste una risposta in bianco e nero a questo. Ad esempio: per qualcosa come un sistema incorporato che è difficile e costoso da implementare sui dispositivi sul campo, potrebbe essere meglio provare ad aspettare (rinegoziare le scadenze se possibile) e farlo uscire il più privo di bug possibile. D'altra parte, per qualcosa di simile a un grande sistema di portale Web (scritto come un'app Web) che può essere facilmente aggiornato in qualsiasi momento implementando le correzioni man mano che escono, potrebbe essere più sensato rilasciare una versione inizialmente instabile, e quindi correggi i problemi (e la funzionalità edge case) man mano che ci arrivi.

Ma alla fine, nella mia esperienza, questa è stata più una decisione aziendale che una decisione tecnologica. Se ti trovi in ​​una situazione in cui mancare la scadenza è un grosso problema, mentre non avere una versione iniziale difettosa (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 liberarlo (diamine, preferirei non avere alcuna scadenza, mai;)). Ma realisticamente, questo non è possibile nella vita reale. Spesso, una versione iniziale ridotta è una buona soluzione per la via di mezzo.

Ho visto molti PM impauriti nel dire al cliente che non siamo in grado di rispettare il programma e insistere che spediamo con bug noti. Posso dirti che ogni volta che lo dicono al cliente, di solito è molto più interessato a meno bug e una scadenza spostata. Garantisco che ricorderanno i bug più della scadenza mancata a meno che la scadenza non sia assolutamente inamovibile (come l'inizio della stagione di deposito fiscale quando si esegue il 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 un rilascio per correggere un bug in cui l'app si blocca nel momento in cui viene avviata su qualsiasi computer? Sì, sicuramente. Devi correggere un bug che si verifica solo su Windows ME mentre è in luna piena? Questo probabilmente può aspettare.

Se si tratta di un bug critico, è preferibile eseguire il numero 2 a mani basse. Il motivo è che costa esponenzialmente risolvere di più se è necessario eliminare tale correzione in un aggiornamento.

Per aggiornamenti meno critici, è possibile rilasciare un aggiornamento in bundle che riduce tale costo in una certa misura.

In caso di dubbio, dico che vai con il n. 2, ma non sarei sorpreso di ottenere respingimenti dalla direzione con questo approccio. Ho il sospetto che i manager tendano a essere giudicati più da quanto sono bravi a rispettare le scadenze che non dal causare inutili aggiornamenti critici.

Né. Perché non cuocere la qualità con il tuo codice? Essere in grado di rispettare le scadenze con il codice di qualità? È possibile eliminare meno funzionalità, ma se la qualità viene inserita nel processo è possibile ottenere entrambe.

Quello che succede ora è che avrai bisogno di un team leader abilitato o di un manager di sviluppo in grado di dare all'azienda il respingimento e avere la conversazione su 2 cose:

1. Qualità inserita nel codice = 2 funzionalità in meno per build
2. Dare la priorità alle funzionalità più necessarie da parte degli stakeholder su ciò di cui hanno DAVVERO bisogno.

Quindi puoi concentrarti sulle funzionalità di maggior valore 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 maggiore priorità.

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 abbastanza messo fuori gioco se qualcuno promettesse di fare qualcosa per lunedì e quando ho provato a usarlo non funziona, o è tutto difettoso.

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

Il mio approccio migliore è quello di provare a far funzionare le cose nel modo in cui dovrebbero funzionare (se si tratta di un modulo principale, non prestare attenzione ai dettagli, il login nel modulo dovrebbe effettuare il login ma chiunque verrà cancellato se non mostri una notifica in seguito).

Questa è una domanda a cui solo tu puoi rispondere. Dipende dal tipo di prodotto, da chi è il cliente, da cosa il cliente richiede, ecc. Non c'è modo per noi di dare una semplice risposta "a o b". È completamente dipendente dalla situazione.

Ma ti ricorderò che il costo della correzione di un bug dopo il rilascio è molto più elevato rispetto alla correzione prima del rilascio. In tal modo, quando si decide se attendere o meno il rilascio post per correggere un bug, poiché si impiegherà più tempo / sforzo / denaro su di esso.