Windows-informazioni riservate: Al bando la burocrazia
Un aspetto importante dello sviluppo intelligente dei prodotti è rendersi conto che alcune fasi di una procedura potrebbero essere superflue.
Raymond Chen
Come un prodotto si avvicina alla spedizione, che si tratti di una versione non definitiva come un'anteprima del consumatore o la final release to manufacturing (RTM), ogni cambiamento subisce maggiore controllo per assicurare che il restante limitato sforzo di ingegneria è focalizzato sulle questioni importanti. Questo esame è destinato anche a verificare che ogni modifica approvata non avrà conseguenze impreviste che rendono la cura peggiore del male.
Sviluppo di prodotti software non solo è non lineare, è discontinuo. Una perturbazione di minore in una parte del codice può ingrandire in un grande cambiamento da qualche altra parte. Che a sua volta può cascata in un fallimento catastrofico.
Nelle prime fasi del processo di rilascio, esame arriva a livello locale. Caratteristica proprietari guardare oltre ogni richiesta di modifica e decidono quali accettare, che a rinviare e a respingere. Ad esempio, se il problema solo colpisce un piccolo numero di persone, o ha una soluzione facilmente scoperta, è più probabile essere rinviato o respinto.
Supponendo che la modifica proposta passa gli ostacoli dell'utente impatto e rilevanza, il codice per implementare il cambiamento è scritto e testato. Poi il team della funzionalità sarà rivedere le modifiche proposte e accettarla o respingerla basato su diversi criteri, quali il livello di rischio associato a tale modifica. Questo non è un processo discreto. Valutazione si verifica continuamente, ma queste due fasi (accettazione iniziale e revisione finale) sono solitamente le più controverse.
Come si avvicina la scadenza, c'è spesso un ulteriore livello di revisione aggiunti a livello di squadra. Ogni cambiamento che incontra l'approvazione dei proprietari caratteristica quindi deve essere presentato per il team manager generale. Il team manager può scegliere di rifiutare una modifica che i proprietari caratteristica accettati.
Di solito è a questo livello che persone iniziare chiedendo domande imbarazzanti. Quanto tempo ha questo bug stato lì? Questo stesso bug esiste ovunque altrove? Come è stato introdotto questo bug? Chi ha firmato sul cambiamento che ha introdotto il bug? Perché non prova trova questo bug prima?
Queste domande non sono destinate a mettere in imbarazzo i proprietari di funzionalità. (Che non è loro unico scopo, almeno.) Team Manager bisogno di sapere queste risposte perché corretto un bug che spediti nella versione precedente di Windows può presentare un problema di compatibilità. Un bug con anzianità si trasforma spesso in un vincolo di compatibilità. Un bug presente in molteplici versioni di anteprima che è andato da scoprire fino a poco tempo potrebbe anche non essere la pena il rischio di fissaggio.
Ancora più vicino al cliente spedizione, estendere ulteriormente fino alla catena. In primo luogo, essi stai urtati fino al gruppo di livello, poi finalmente per l'intero team di prodotto di Windows. In queste fasi finali, ogni modifica proposta al prodotto è preso nella stanza di nave di Windows. Qui è necessario rappresentare il cambiamento e spiegare perché si ritiene che dovrebbe essere accettato nella release.
Windows 8 ha seguito questo processo, proprio come suo padre e suo nonno. Poi è successo qualcosa di interessante.
Dopo una delle versioni preliminari di Windows 8 spediti, la gente di sala nave Windows è andato attraverso il loro record di tutte le correzioni proposte ha portate per l'approvazione di Windows nave camera durante quel ciclo preliminare. Ogni bug è stato presentato, sono state poste domande imbarazzanti, i rischi sono stati bilanciati contro il vantaggio e si scopre che ognuno alla fine è stata accettata.
La gente che correva la stanza della nave Windows ha concluso che questo significava che le camere a livello di gruppo nave stavano facendo un buon lavoro di decidere quali bug fix e che rinviare o rifiutare. L'esame supplementare della stanza nave Windows non era aggiunta di qualsiasi valore, perché esso mai ha annullato una decisione della corte inferiore.
Come risultato di questa analisi post-mortem, il team di gestione di rilascio semplicemente rinviato il processo Windows nave camera per un po'. Hanno rispettato le decisioni delle camere a livello di gruppo nave. Camera nave Windows indefinitamente non era sciolto, ma dopo aver riconosciuto che non era una parte essenziale del processo, chiudendo per un po' lascia tutti ottenere poche ore di vita.
.jpg)
Raymond Chen Raymond Chen, The Old New Thing e identicamente intitolato libro (Addison-Wesley, 2007) trattare con Windows storia e programmazione di Win32. Non deve essere preso internamente.