medie del settore per il tempo dedicato alla manutenzione

16

Un manager ha recentemente annunciato che stavano spendendo troppo tempo per sistemare i bug. Suppongo che pensi che dovremmo scrivere sempre un codice perfetto (pur continuando a colpire quelle scadenze impossibili, ovviamente!) E mi ha fatto chiedere quale sia stata la media del tempo impiegato nel correggere i bug per la scrittura di un nuovo codice.

Quindi qualcuno ha qualche metrica sul tempo impiegato a correggere i bug contro il nuovo sviluppo del codice? O c'è qualche analisi empirica sui tempi di correzione dei bug per l'industria nel suo insieme? Il 50% ha speso bug risolti troppo o giusto? Che ne dici del 20% o 33%?

Sono felice di accettare prove aneddotiche derivanti dall'esperienza personale in quanto farebbero parte di alcune statistiche che potrei confrontare la nostra prestazione con quella.

    
posta gbjbaanb 10.02.2012 - 15:23
fonte

4 risposte

13

A manager recently announced that were were spending far too much time fixing bugs.

Sopra i suoni molto ignoranti. Lettura suggerita per casi del genere: Fatti e errori dell'ingegneria del software di Robert L. Glass, in particolare " Fatto 43. La manutenzione è una soluzione, non un problema. "

l'articolo di Wikipedia menziona l'80% degli sforzi spesi per la manutenzione del software.

my manager makes Dilbert's PHB look like a genius :)

Hm dato sopra vorrei anche fare qualche sforzo per analizzare se tutte le richieste che fai sono bug .

Nella mia esperienza è stato troppo spesso che le richieste di miglioramenti o nuove funzionalità sono state presentate come bug. I bravi manager coinvolgono i loro programmatori nel scoprirlo - i cattivi manager, beh, continua a lamentarsi di troppo tempo per sistemare i bug .

    
risposta data 10.02.2012 - 18:21
fonte
9

La prima domanda da porsi è se il tuo "bug fixing" sta effettivamente correggendo bug di codifica o qualcos'altro. Nella maggior parte dei casi, la correzione dei bug effettivi del codice dovrebbe essere relativamente piccola, purché si disponga di una buona base di codice. Se lavori con una base di codice scadente, è inevitabile un vasto bug fixing.

Tuttavia, durante la messa in produzione di un programma, troverai requisiti non documentati, attività utente inaspettata, anomalie dei dati, incompatibilità hardware, problemi di installazione e altri problemi che non sono strettamente bug di codice. Spesso i gestori e gli utenti considerano questi problemi di supporto / manutenzione della produzione come bug, poiché in genere richiedono modifiche al codice.

Ho anche incontrato manager che raggruppavano quelle che avrebbero dovuto essere chiamate richieste di miglioramento minori come bug. Spesso questi vengono inseriti in un bug tracking o in un sistema di segnalazione dei problemi e questo può rendere le statistiche del "bug" più alte di quanto non siano realmente.

    
risposta data 10.02.2012 - 16:13
fonte
8

Dipende da quanti codici hai, da quanto tempo è rimasto là fuori, ecc.

Il tempo dedicato alla correzione dei bug nel software dovrebbe essere caricato frontalmente per i primi 6-12 mesi di rilascio, tuttavia con l'avvicinarsi del tempo all'infinito, il tempo dedicato alla manutenzione rispetto al tempo impiegato per lo sviluppo iniziale supererà il 100% - è solo il modo in cui funzionano le cose.

Anche se non ho alcuna statistica difficile (il codice completo lo fa, ma non posso dire esattamente quale pagina / sezione), nella mia esperienza circa il 40% dello sviluppo (a volte fino al 60%) viene speso per Manutenzione. È ovvio che più codice si rilascia, più tempo di manutenzione si avrà. I bug non sono sempre funzionali e sono il risultato di incertezze in quanto sono difetti programmatici.

    
risposta data 10.02.2012 - 15:37
fonte
0

se usi un buon Ticket Tracker (come Jira da Atlasian) e hai passato del tempo a inserire correttamente tutte le diverse categorie, user story, livelli di urgenza e con l'accordo dei tuoi compagni di squadra, quindi calcoli questi parametri ( e altro) sono incredibilmente facili.

In un precedente progetto, abbiamo utilizzato Jira per gestire le nostre liste bug / task / todo e alla fine ci ha mostrato che la principale causa di ritardi e problemi si è rivelata una gestione inefficiente.

Stranamente, quando queste informazioni sono uscite, abbiamo improvvisamente detto che non avremmo più utilizzato Jira e che sarebbe stato introdotto un nuovo prodotto per sostituirlo.

Nel frattempo, tutte le richieste di dati da passare attraverso Jira dovevano essere inviate al team di gestione e abbiamo rimosso il nostro accesso diretto.

Ciò che non è stato notato è che, come parte del calcolo delle statistiche, il team di sviluppo aveva Jira che faceva i dati su un gancio Web e questo gancio Web veniva utilizzato per trasferire i dati a un endpoint su alcuni server interni, dove avevamo codice che ha creato questi rapporti automaticamente.

Abbiamo iniziato a monitorare il web hook e abbiamo scoperto che anche se dicevamo che Jira non era più utilizzata, è rimasta molto viva per un considerevole lasso di tempo più lungo (6+ mesi per l'esattezza) e l'abuso da parte di la gestione superiore era semplice e semplice con un uso scorretto.

Naturalmente, non deve essere qualcosa di complesso come Jira.

Se desideri una soluzione a basso rendimento, puoi utilizzare un foglio di calcolo di google-docs e l'API di notifica GDocs per tenere traccia delle attività / ticket / bug / richieste di funzionalità ecc.

GDocs stesso ora può rilasciare web-hook e ogni sorta di cose.

Accoppialo con Git e / o Github e alcuni hook che si attivano quando il codice è impegnato nel tuo repository e hai un sistema di homebrew ragionevolmente efficiente, in grado di registrare una quantità sorprendente di dati.

In generale, tuttavia, per il 100% della vita naturale di un prodotto, la suddivisione tra dev e manutenzione è in genere 20/80, la maggior parte del costo del ciclo ALM (Application Lifetime Management) è occupata da manutenzione e supporto i costi.

Non c'è niente come passare troppo tempo a correggere i bug, perché è semplicemente impossibile scrivere codice senza errori.

I buoni test e le politiche di integrazione continue ridurranno il problema, ma non lo sradicheranno mai completamente.

Chiunque crede diversamente (IMHO) non ha abbastanza conoscenza per esprimere un giudizio accurato, o è cieco (il caso più comune) per quanto sia davvero difficile scrivere software.

Se il tuo manager ce l'ha, e alcuni di loro lo sono, allora potresti suggerirti di metterti in ombra per un giorno, in modo che possa vedere esattamente cosa fai e come lo fai.

Iv'e ha lavorato in alcune aziende in cui questo tipo di lavoro è stato attivamente incoraggiato, con il personale di livello superiore che si occupa dello staff di livello inferiore e viceversa, può essere un'esperienza di apprendimento davvero buona per entrambe le parti coinvolte.

    
risposta data 09.07.2014 - 22:16
fonte

Leggi altre domande sui tag