Se aspetti che tutti i possibili bug vengano scoperti, aspetti per sempre. Voltaire lo ha scritto per primo:
Le mieux est l'ennemi du bien.
(tradotto: "Il migliore è il nemico del bene.")
Significa che cercare di creare la perfezione significa che in realtà non produrrà mai nulla di buono; continuerai a non essere finito perché non sei abbastanza perfetto. Devi smettere e rilasciare. Poiché sai che in realtà non stai tentando di produrre la perfezione (basta fare abbastanza bene, bilancia il costo di non correggere un bug contro il costo di non rilasciare a causa del ritardo aggiuntivo) perché preoccuparsi che le cose non siano perfette?
Ciò che tende ad accadere è che le persone producono versioni alfa del software mentre stanno lavorando sulle funzionalità principali; questi potrebbero essere solo interni, o rilasciati solo a un gruppo molto selezionato di persone esterne, e probabilmente saranno piuttosto rotti in altri modi. Quindi, una volta che le cose principali sono a posto e grosso modo lavorando insieme, una beta viene creata e inviata a un gruppo più ampio di persone. Questo è il punto in cui il QA entra davvero in gioco, scovando tutti i tipi di bug minori, e dove le persone che sono molto interessate a ottenere le nuove funzionalità - abbastanza da tollerare il fatto che il software sia conosciuto essere buggy - può ottenere l'accesso anticipato. Potrebbero esserci anche alcuni cicli beta, dal momento che gli errori vengono risolti (compresi eventualmente tutti gli stopper, si spera).
Una volta che il costo della correzione dei bug sta superando il costo di lasciarli non corretti, è il momento per il rilascio completo. Se non ti piacciono i bug, è quello che dovresti aspettare. (Il più conservatore aspetterà anche le prime patch ufficiali che escono, così che anche le cose veramente oscure si schiacciano.) Ma alcune persone sono semplicemente più entusiaste di ottenere quelle caratteristiche: sono quelle a cui puntano le beta (e alfa sono di solito per le persone che sono abbastanza vicino al processo di sviluppo solo, in quanto di solito mancano funzionalità chiave).
I processi agili cercano di accorciare le cose mantenendo la quantità di tempo in cui le cose sono infrante veramente limitate e mettendo il cliente vicino allo sviluppo, ma non è adatto a tutto il software. Qualunque cosa miri ad avere un rilascio veramente ampio (ad es. Prodotti commerciali) semplicemente non può avere tutti i clienti lì; ciò impone il tipo di strategia di rilascio sopra delineata.