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.