"Il punto in cui realizzare progetti di più breve orari, minimo sforzo, e più elevati livelli di soddisfazione degli utenti" Capers Jones, Misurazione del Software Applicata: Assicurare la produttività e qualità, 1991.
La maggior parte delle squadre non avvicinarsi al punto ottimale. Ma puntando al di là di questo, verso il 100% perfezione, fa sì che i costi alle stelle, si raggiunge rapidamente il punto dei rendimenti decrescenti. Rendimenti decrescenti nel perseguimento del software perfetto è esplorata ulteriormente da Andy Boothe in Economia del software perfetto :
"Per esempio, immaginate un programma dispone di 100 bug, e sappiamo che ci vorranno 100 unità di sforzo per trovare e risolvere tutti i 100 di questi insetti. La legge dei rendimenti decrescenti ci dice che le prime 40 unità di sforzo avrebbe trovato i primi 70 bug, il prossimo 30 unità di sforzo avrebbe trovato i prossimi 20 bug, e il successivo 30 unità di sforzo avrebbe trovato gli ultimi 10 bug. Ciò significa che i primi 70 bug (il bug poco profonde) sono a buon mercato da trovare e da squash, a soli 40 / 70 = 0,571 unità di lavoro per ogni bug (in media). Il prossimo 20 bug (il bug di profondità) sono molto più costosi a 30 / 20 = 1,5 unità di sforzo per bug, e la finale 10 bug (il bug davvero profondo) sono astronomicamente costoso a 30 / 10 = 3 unità di sforzo per bug . Gli ultimi 10 bug sono più di 5 volte nel tempo e più alta intensità di capitale per eliminare ogni bug che i primi 70 bug. In termini di sforzo, la differenza tra eliminando la maggior parte i bug (diciamo 70% -90%) e tutti i bug è enorme, per la somma di una differenza 2x dello sforzo e costo. E nella vita reale è davvero peggio. Perché non sai quando hai ucciso il bug ultima - non c'è alcun segno di conto alla rovescia, come abbiamo avuto nel nostro esempio - si deve continuare a cercare più bug, anche quando sono tutti morti solo per assicurarsi che siano tutti morti. Se davvero si vuole uccidere tutti i bug, è necessario pianificare che costano troppo ".
C'è un costo per costruire un buon software
C'è un costo per mettere in atto i necessari controlli e le pratiche, i controlli ed equilibri, e per costruire attenzione della squadra e l'impegno e la disciplina, e mantenere questa nel tempo. Per costruire la giusta cultura, le giuste competenze, e il giusto livello di supervisione. E c'è un costo per dire no al cliente: a tagli sulle caratteristiche, o chiedendo in anticipo il tempo più, o ritardare un rilascio a causa di rischi tecnici. È inoltre necessario tener conto dei costi opportunità. Kent Beck e Martin Fowler hanno costruito le loro carriere sulla scrittura di software di alta qualità e insegnare agli altri come fare questo. Nella pianificazione Extreme Programming rendono chiaro che è importante scrivere un buon software, ma:
"Per la maggior parte del software, però, in realtà non vuole bug zero. Qualsiasi difetto, una volta lì, richiede tempo e impegno da rimuovere. Che il tempo e lo sforzo si terrà lontano da sforzo speso per mettere in funzionalità. Quindi devi decidere cosa fare. "
È per questo che mi riguarda da esigenze tecniche destro del suono per la tolleranza zero bug. Questa decisione non è una tecnica che può essere fatto dagli sviluppatori o tester o project manager ... o consulenti. E 'più grande di tutti loro.Non è solo una decisione tecnica - è anche una decisione di business.
Long Tail di Bugs
Come molti spazi altro problema, l'idea della Long Tail vale anche per i bug . Ci sono bug che devono essere fissi e può essere fissato al momento. Ma ci sono altri bug che non avere mai bisogno di essere fissato, o bug che il cliente non può mai vedere: bug minori in alcune parti del sistema che non vengono utilizzati spesso, o problemi che si verificano in configurazioni improbabile o stringhe insolita di eventi, o solo in fase di test di stress estremo. Bug nel codice che viene riscritta comunque, o in una parte del sistema che sta per essere smantellati al più presto. Piccoli problemi estetici:. Se non ci fosse niente di meglio da fare, sicuro che ci pulire questo, ma bisogna fare qualcosa di meglio, in modo da farlo qualcosa di meglio, invece ci sono bug che non siete sicuri sono in realtà i bug, dove si non riescono ad accordarsi su ciò che il comportamento corretto dovrebbe essere. E ci sono bug che può essere costoso e richiede tempo per rintracciare e riprodurre e riparare. Condizioni di gara che richiede molto tempo per trovare - e può prendere una riprogettazione per risolvere veramente. Intermittente heisenbugs che scompaiono quando li guardi, non deterministici problemi che non hanno le informazioni o di tempo per fissare questo momento. WTF e bug che non capiscono e non sanno come risolvere ancora, o la correzione solo tu puoi pensare è più spaventosa che la situazione che si è già in poi ci sono bug che non puoi risolvere, bug nella tecnologia di base o di librerie di terze parti o sistemi di partner che si deve vivere con o aggirare per ora. E ci sono bug che non avete ancora trovato e non trova a meno che non continui a guardare. Ea un certo punto bisogna smettere di guardare. Tutti questi insetti sono le fonti di rischio. Ma questo non significa necessariamente che essi devono essere fissati al momento. Come spiega Eric Sink nella mia vita come un economista codice , ci sono diverse questioni che devono essere risolte per determinare se un bug è necessario fissare: In primo luogo ci sono le domande dei clienti, le domande di base circa l'importanza di un bug per il business:
· Livello di gravità: quando succede questo bug, quanto male è l'impatto? E 'visibile a un gran numero di clienti?Potremmo perdere i dati, o perdere il servizio ai clienti importanti o partner? Quali sono gli effetti a valle: quello che gli altri sistemi o partner potrebbero venire influenzati, e quanto velocemente il problema potrebbe essere contenuta o riparato? Questo potrebbe violare i livelli di servizio, o di requisiti normativi o di conformità?
· Frequenza: quante volte questo bug potrebbe accadere in produzione?
Poi ci sono le domande di sviluppo, le questioni tecniche su ciò che deve essere fatto per risolvere il bug:
· Costo: quanto lavoro è necessario per riprodurre, correggere e testare questo bug - tra cui i test di regressione? Che dire RCA, quanto lavoro dobbiamo fare a scavare più profondo e di fissaggio la causa principale?
· Rischio: qual è il rischio tecnico di far peggiorare le cose, cercando di risolvere il problema? Come ben capisco il codice? Quanto refactoring devo fare per assicurarsi che il codice e la correzione, è chiaro? È il codice protetto da una buona serie di test?
Per alcuni bug, la decisione è morto semplice: semplice, gli errori stupidi che voi o qualcun altro appena fatto come parte di un cambiamento o un altro fix, gli errori che si trovano subito in fase di test o di rassegna, e deve essere risolto immediatamente. Tu sai cosa fare, non perdere tempo: si risolvere il problema e si passa. Ma per altri insetti, specialmente bug scoperto nel codice esistente, è a volte non così facile. Tolleranza zero bug assume ingenuamente che è sempre bene, è sempre di destra, per correggere un bug. Ma la fissazione di un bug non è sempre la cosa giusta da fare, perché con tutte le correzioni si corre il rischio di introdurre nuovi problemi:
"Gli insetti si sa sono meglio di introdurre nuovi bug"
Fred Brooks ha innanzitutto ricordato il problema della regressione in The Mythical Man Month :
"... La fissazione di un difetto ha una sostanziale (20-50%) possibilità di introdurre un altro. Quindi l'intero processo è due passi avanti e uno indietro. "
Il rischio di introdurre un bug quando si cerca di risolvere un altro bug potrebbe essere sceso dal momento Fred Brooks '. In Problemi Geriatria of Aging Software Capers Jones fornisce alcuni numeri meno paura
"Circa il 7 per cento di tutte le riparazioni difetto conterrà un difetto nuovo che prima non c'era. Per applicazioni molto complesse e scarsamente strutturate, queste iniezioni fissare cattivi hanno superato il 20 per cento ".
Ma il costo ei rischi sono ancora reale, e devono essere contabilizzate.
Bar e finestre rotte
Tu, la squadra, il cliente tutte le necessità di concordare su quanto alto per impostare la barra, che tipo di bug e dei rischi può essere accolto. E poi bisogna capire che cosa controlli, le verifiche, pratiche, strumenti, competenze, e quanto più tempo è necessario per colpire costantemente quel bar. Quanto verrà a costare. Se si sta costruendo sistemi safety-critical come il software di comando per la navetta spaziale
(quello che abbiamo intenzione di utilizzare come esempio quando le navette spaziali smettere di volare?), il bar è estremamente alta, e così, naturalmente, sono i costi. Se sei un social avvio Internet media, a corto di denaro e tempo e grande opportunità, poi il bar è il più basso lo si può permettere. Per il resto di noi il bar è nel mezzo. ottengo quello che c'è dietro Bug Tolleranza Zero. Capisco il "No Broken Windows" principio nello sviluppo di software: che se lasciamo un bug attraverso allora cosa per fermare il successivo, e quello successivo e quello dopo ancora. Ma non è così semplice.Nessun Broken Windows è di avere la disciplina per fare un lavoro professionale. Si tratta di non essere sciatto o imprudente o irresponsabile. E non c'è niente irresponsabile di fare scelte difficili e informato su ciò che può e deve essere risolto. Sapere quando smettere di correggere i bug, quando hai raggiunto il punto dei rendimenti decrescenti, quando si dovrebbe concentrarsi su attività più importanti, non è facile. Sapendo che per risolvere i bug e quali no troppo, o che quelli che non possono o non dovrebbero fissare ora, non è facile. E sarete sbagliato a volte. Qualche piccolo problema che non pensavo fosse abbastanza importante da indagare ulteriormente, alcuni bug che non si poteva giustificare il tempo per inseguire, potrebbe tornare a mordere. Imparerai e, auspicabilmente, prendere decisioni migliori in futuro. Questa è la vita reale. Nella vita reale dobbiamo fare questo tipo di decisioni difficili per tutto il tempo. Purtroppo, non possiamo contare su risposte semplici e 100% a problemi reali.
Corso Java - Corsi Java - Corsi programmazione Java
Corso programmazione Android - Certificazione Android
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.