Quanto velocemente è possibile ottenere un bug risolto in produzione?

Question

Sto lavorando con 2 applicazioni molto diverse.

L'app n. 1 è un'app Web in cui ho accesso diretto all'FTP, quindi correggere i bug è abbastanza semplice. I bug di Cat A vengono di solito risolti entro il giorno successivo. Nessun problema qui.

L'app n. 2 è un'app di controllo dei documenti relativi alle attività petrolifere, in cui dobbiamo passare attraverso due fasi di test di accettazione: test degli utenti finali e test del sistema. Eventuali bug rilevati dopo questa fase verranno conservati fino alla versione successiva, in genere 2-3 mesi. Ogni nuovo pacchetto di rilascio ha un costo enorme. È davvero difficile spiegare agli utenti finali che devono convivere con alcuni dei bug fino alla prossima versione.

Come ti relazioni con i bug critici che non possono essere corretti immediatamente?

Answer 1

A mio avviso personale, la tua situazione descritta è un problema strutturale molto profondo e avrebbe dovuto essere affrontato prima dell'inizio del progetto. Ogni programmatore dovrebbe conoscere almeno una persona per spingere direttamente i cambiamenti se necessario e la procedura per questo deve essere chiara. Sinceramente che dire dei problemi di sicurezza o di database con potenziale perdita di dati? Voglio dire, ovviamente, se non riesci a risolverlo, informa direttamente lo staff e digli di " per favore, non farlo " ma onestamente il modo migliore è quello di far uscire questo problema dal mondo al più presto. Ho avuto un caso simile in un'applicazione terminale in cui un programma ha semplicemente smesso di funzionare dopo aver premuto due volte un pulsante. La correzione era banale, ma a nessuno era permesso di ripararla e costava letteralmente ore per tutte le persone a seconda di questa cosa da eseguire. Richiedi una scorciatoia per modifiche importanti!

Answer 2

Più veloce correggo i bug, più bug trovo che devo correggere.

Answer 3

La velocità con cui la gestione ti consente di correggere un bug è direttamente correlata alla gestione dei costi fino a quando il bug non verrà risolto.

Sono una squadra di 1 uomo. Nulla si frappone tra me e i miei bug :)

Answer 4

Dipende davvero da una combinazione di dimensioni dell'organizzazione, dimensioni del sistema, importanza del sistema e amp; impatto del bug, ad esempio:

One Man Shop o sistema a basso impatto (il più veloce - App n. 1 sopra)

Tempo per correggere bug = tempo per trovare bug + tempo per correzione codice + tempo per distribuire in produzione

Organizzazione di grandi dimensioni o sistema importante (il più lungo - App n. 2 sopra)

Tempo per correggere bug = tempo per trovare bug + tempo per document & amp; dare la priorità al bug + tempo per stimare il costo + tempo per approvare il lavoro sulla correzione + tempo per progettare la correzione + tempo per correzione documento + tempo per correzione codice + tempo per piano test documenti + tempo per correzione test + tempo per regressione test + tempo per test prestazioni / carico + tempo per programma e amp; approvare la distribuzione + tempo per distribuire correzione

Modifica : Quanti I dipendenti Microsoft ci vogliono per cambiare una lampadina? è una lettura interessante sull'argomento.

1 : vedi http://blogs.msdn.com/ericlippert/archive/2003/10/ 28 / 53298.aspx

Answer 5

La risposta sarebbe un rapporto tra quanto si ha accesso all'ambiente di produzione alla quantità di vite o denaro in gioco.

Answer 6

Soluzioni alternative.

Ho avuto esperienze precedenti in cui un utente ha ritenuto che una funzionalità fosse morta a causa di un bug, ci ha notificato fino all'esaurimento del bug, quindi ci ha detto che durante i tempi di inattività di quella sezione stavano inserendo informazioni nella loro vecchia versione excel dell'applicazione (migrazione Oracle APEX da Excel) e poi ci ha chiesto gentilmente di cambiare tempo inserendo dinamicamente i dati dalla loro applicazione Excel. La svolta è stata più lunga del tempo di inattività del bug originale.