medie del settore per il tempo dedicato alla manutenzione


17

Un manager ha recentemente annunciato che stavano impiegando troppo tempo a correggere i bug. Immagino che lui pensi che dovremmo scrivere un codice perfetto tutto il tempo (pur rispettando quelle scadenze ovviamente!) E mi ha fatto chiedermi quale fosse la media del settore del tempo trascorso a correggere i bug v scrivere nuovo codice.

Qualcuno ha qualche metrica sul tempo impiegato a correggere i bug contro lo sviluppo di nuovo codice? Oppure esiste un'analisi empirica dei tempi di correzione dei bug per l'intero settore? Il 50% del bug speso è stato risolto troppo o è giusto? Quanto circa il 20% o il 33%?

Sono felice di accettare prove aneddotiche dall'esperienza personale in quanto ciò farebbe parte di alcune statistiche qui con cui potrei confrontare le nostre prestazioni.


9
il tuo manager sembra molto ignorante. Letture consigliate 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
moscerino del

3
Qual è il vero problema? Hai un problema di qualità? Il tuo processo è davvero inefficiente? O il tuo manager desidera solo che il software non sia costato così tanto?
Kevin Cline,

@gnat: il tuo commento è la risposta migliore
kevin cline,


La manutenzione non riguarda solo la correzione di bug (difetti) e la sua quantità varia notevolmente per i singoli progetti (= nessuna risposta definita). A me sembra che tu abbia problemi di qualità.
MaR,

Risposte:


13

Un manager ha recentemente annunciato che stavano impiegando troppo tempo a correggere i bug.

Sopra suona molto ignorante. Letture consigliate 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.

il mio manager fa sembrare il genio di Dilbert un genio :)

Detto sopra, mi impegnerei anche ad analizzare se tutte le richieste che fai sono davvero dei bug .

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


2
Correzione bug! = Manutenzione! La correzione di errori significa che hai codificato i guasti nel sistema e devono essere corretti per ripristinare la corretta funzionalità . Per manutenzione intendo tutte le attività come correzioni di bug, miglioramenti della scalabilità, migrazione dell'hardware e miglioramenti delle prestazioni, ecc. Direi che oltre il 25-30% del tempo dedicato alle correzioni di bug richiede immediatamente una chiamata di governance. Fino al 40-50% dello sforzo speso per la manutenzione complessiva sembra ragionevole per un sistema aziendale di medie dimensioni.
Apoorv Khurasia,

Hai delle cifre per le diverse classi di bug? Ovviamente se stai ottenendo un gran numero di priorità, bug di "show stopper" potrebbero esserci dei casi in cui il processo di sviluppo ha bisogno di un po 'di lavoro per determinare la fonte, ma se è tutta roba piccola non è un grosso problema. Inoltre, come dice gnat, molti di loro possono essere richieste di miglioramento.
Stevetech,

La tua citazione dell'articolo di Wikipedia è sbagliata! Dice che "l'80% dello sforzo di manutenzione viene utilizzato per azioni non correttive" , ma non dice nulla sui tempi di manutenzione rispetto alla progettazione, alla codifica o ad altri lavori.
Tobias Knauss,

9

La prima domanda da porsi è se il tuo "bug fixing" sta effettivamente risolvendo bug di codifica o qualcos'altro. La correzione di errori di codice reali dovrebbe essere relativamente piccola nella maggior parte dei casi, purché si disponga di una buona base di codice. Se stai lavorando con una base di codice scadente, la correzione di bug estesa è inevitabile.

Tuttavia, nel corso della messa in produzione di un programma, troverai requisiti non documentati, attività dell'utente imprevista, anomalie dei dati, incompatibilità hardware, problemi di installazione e altri problemi che non sono strettamente bug del codice. Spesso i manager e gli utenti considereranno 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 definite come piccole richieste di miglioramento come bug. Spesso questi vengono inseriti in un sistema di tracciamento dei bug o di segnalazione dei problemi e questo può rendere le statistiche dei "bug" più alte di quanto non siano in realtà.


Quello che descrivi è ciò che abbiamo, ma ciò non cambia nulla :(
gbjbaanb

8

Dipende da quanto codice hai là fuori, da quanto tempo è là fuori, ecc.

Il tempo impiegato per correggere i bug nel software dovrebbe essere caricato in anticipo nei primi 6-12 mesi di rilascio, tuttavia quando il tempo si avvicina all'infinito, il tempo impiegato per la manutenzione rispetto al tempo impiegato per lo sviluppo iniziale supererà il 100% - questo è solo il modo in cui le cose opera.

Anche se non ho statistiche complesse (Code Complete fa, ma non posso dirti esattamente quale pagina / sezione), nella mia esperienza circa il 40% dello sviluppo (a volte fino al 60%) viene speso per la manutenzione. È ovvio che più codice rilasci, più tempo di manutenzione avrai. I bug non sono sempre funzionali e sono tanto il risultato dell'incertezza quanto i difetti programmatici.


0

se stai utilizzando un buon tracker di biglietti (come Jira di Atlasian) e hai trascorso del tempo a inserire tutte le diverse categorie, storie utente, livelli di urgenza correttamente e con l'accordo dei compagni di squadra, quindi a calcolare effettivamente queste metriche (e altro) sono incredibilmente facili.

In un precedente progetto, abbiamo usato Jira per gestire i nostri elenchi di bug / attività / todo e alla fine ci ha mostrato che la principale causa di ritardi e problemi si è rivelata essere pratiche di gestione inefficienti.

Stranamente, quando queste informazioni sono state rese note, all'improvviso ci è stato detto che non avremmo più utilizzato Jira e che sarebbe stato introdotto un nuovo prodotto per sostituirlo.

Nel frattempo, tutte le richieste di trasmissione dei dati attraverso Jira dovevano essere inviate al team di gestione e il nostro accesso diretto è stato rimosso.

Ciò che non è stato notato è che, come parte del calcolo delle statistiche, il team di sviluppo ha fatto in modo che Jira colpisse i dati su un hook web, e questo hook web è stato usato per passare i dati a un punto finale su alcuni server interni, dove avevamo il codice che ha creato questi rapporti automaticamente.

Abbiamo iniziato a monitorare l'hook web e abbiamo scoperto che, anche se ci era stato detto che Jira non era più utilizzata, è rimasta molto viva per un considerevole periodo di tempo (6+ mesi per l'esattezza) e l'abuso all'ingrosso da parte dell'alta direzione era semplicemente dilagante con un uso errato.

Certo, non deve essere qualcosa di complesso come Jira.

Se si desidera una soluzione a basso rendimento, è possibile utilizzare un foglio di calcolo Google-Docs e l'API di notifica GDocs per tenere traccia di attività / ticket / bug / richieste di funzionalità ecc.

Lo stesso GDocs ora può emettere web-hook e ogni genere di cose.

Abbinalo a Git e / o Github e ad alcuni hook che si innescano quando il codice viene impegnato nel tuo repository e hai un sistema di brew home ragionevolmente efficiente, che può registrare una quantità sorprendente di dati.

In generale, tuttavia, al di fuori del 100% della vita naturale di un prodotto, la suddivisione tra sviluppo greenfield e manutenzione è generalmente di 20/80, la maggior parte dei costi nel ciclo ALM (Application Lifetime Management) è sostenuta dai costi di manutenzione e supporto.

Non c'è niente come passare troppo tempo a correggere i bug, perché semplicemente non è possibile scrivere codice privo di bug.

Buoni test e politiche di integrazione continua ridurranno il deficit, ma non lo sradicherai mai completamente.

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

Se il tuo manager è pronto, e alcuni di loro lo sono, allora potresti voler suggerire che ti oscura 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 oscura il personale di livello inferiore e viceversa, può essere un'esperienza di apprendimento davvero molto buona per entrambe le parti coinvolte.


2
"Non c'è niente di meglio che passare troppo tempo a riparare i bug" - che schifo. Se passi abbastanza tempo a correggere i bug che la tua azienda subisce perché non potrebbe rimanere competitiva sul mercato (perché stavi correggendo i bug anziché fare cose), hai speso troppo tempo a correggere i bug ...
Telastyn,

E l'alternativa? - Non passi abbastanza tempo a correggere i bug e la tua app si arresta in modo anomalo, brucia e il tuo concorrente prende tutta la tua abitudine, spingendoti efficacemente fuori dal mercato. Il trucco (e la parte più difficile di tutto questo) è in realtà trovare un equilibrio accettabile.
Shawty

1
No, sono d'accordo, ma questa è la mia opinione che arriva lì, perché credo davvero in questi tempi, l'arte del debugging corretto sta diventando un'arte perduta. Troppi di noi si affidano troppo a cose come i unit test, che IMHO fornisce troppa falsa sicurezza. Non sto dicendo che il test unitario dovrebbe essere abolito, ma sto dicendo che non c'è più abbastanza pratiche di debug e correzione dei bug eseguite a causa di ciò. Questa svolta porta i manager (come descritto sopra) a credere che la correzione dei bug non sia necessaria, e di conseguenza non lo facciamo (di nuovo IMHO).
shawty

2
unit test e debugging sono arti diverse utilizzate per problemi diversi. Sebbene risolvere il problema "è il nostro codice corretto" previene meglio il problema "perché il mio codice è rotto". A parità di condizioni, preferirei che le persone fossero brave a fare il codice corretto piuttosto che identificare le cause alla radice.
Telastyn,

1
Ora quel punto hai il mio pieno consenso. È un fatto triste che nell'industria di oggi molti programmatori lo trattino come un altro lavoro dalle 9 alle 5, in cui effettuano il clock, eseguono il bangout del codice fino all'ora di casa e si disconnettono. Ai giorni nostri, gli sviluppatori erano immensamente orgogliosi di scrivere un codice valido, solido e ben collaudato e hanno trascorso del tempo a pensarci prima di avvicinarsi a una tastiera, in questi tempi si vede molto poco.
shawty
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.