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.