Uno dei progetti su cui lavoro è misurato in base al numero di problemi. La gestione ha dato misurazioni arbitrarie (per quanto posso dire) che abbiamo bisogno di avere non più di X numero di bug e numero di caratteristiche Y nel nostro sistema di tracciamento dei problemi.
Questo sembra un approccio fuorviante, ma non riesco a trovare alcun testo sull'argomento.
No, tali metriche sono assolutamente controproducenti. Con questo tipo di metrica, le persone trascorrono il tempo a giocare la metrica, piuttosto che pensare a come fare bene il proprio lavoro.
In realtà ho visto una situazione, in cui c'era un contratto sul numero massimo di bug in sospeso. L'effetto è stato che la maggior parte delle segnalazioni di bug sono state immediatamente chiuse con una risoluzione fasulla.
Non tutti i problemi sono stati creati uguali. Alcuni sono cambiamenti banali e alcuni sono progetti multi-stagionali di più settimane. Un semplice numero di problemi non tiene conto di questi fattori.
Questa è una cosa molto sciocca da fare. Ciò scoraggerà le persone dal segnalare problemi, quindi i problemi saranno ignorati, e tutti faranno finta che le cose vadano bene quando in realtà sono cattive e peggiorano di giorno in giorno. Allora lavorerai intorno al casino. Quando la direzione decide di punire le persone per aver detto la verità, è ora di andare.
Monitorare solo il numero di bug e richieste di funzionalità non mi sembra una buona idea. Per me, dipende da persone che segnalano problemi. Se semplicemente non c'è bisogno di una nuova funzionalità da parte di un utente finale o di un bug trovato nel campo o dal QA, non ci saranno bug rilevati. Potrebbe essere interessante sapere quanti bug o richieste di funzionalità sono in cantiere per provare a stimare la quantità di lavoro. Inoltre, il fraseggio "non più di X bug" o "non più di Y features" mi infastidisce. Cosa succede se ci sono X bug e ne viene scoperto un altro? O funzioni Y e un altro utente o client chiede qualcos'altro? Non dovrebbero essere ignorati fino a quando i bug non vengono chiusi o le funzionalità completate.
Invece, utilizzerei le segnalazioni di bug e le richieste di funzionalità come misurazioni da utilizzare nelle metriche. Ad esempio, tracciamento degli errori segnalati nel tempo. Se i test interni stanno svolgendo il proprio lavoro, il numero di bug segnalati dopo un rilascio non dovrebbe aumentare. Un altro esempio potrebbe tenere traccia del tempo necessario per correggere un bug o creare una funzionalità in quanto ciò fornirebbe alcune informazioni sulla manutenibilità e l'estensibilità del sistema.
Stavo cercando un materiale citato in un corso sulla qualità del prodotto che ho seguito. Anche se non sono riuscito a trovarlo, ho trovato queste note sulle metriche di cambiamento e difetto . Potrebbe essere interessante e offrirti alcune informazioni su come utilizzare i dati sulle richieste di funzionalità e sulle segnalazioni di bug per fornirti informazioni più affidabili e valide su un progetto.
Ho lavorato in un'azienda una volta dove la gestione aveva un sistema molto elaborato per monitorare i progressi e la produttività, quasi interamente basati sul controllo delle modifiche e sugli articoli relativi ai bug. È stato un triste fallimento:
ad es. Potresti avere un programmatore che ha avuto a che fare con un bug molto oscuro e difficile da riprodurre, e come tale ha appena risolto "1 item" per tutta la settimana. Sul rovescio della medaglia, qualcun altro avrebbe potuto lavorare su articoli relativamente facili e ha risolto "20 articoli" nella stessa settimana. Superficialmente sembra che il secondo programmatore fosse "20 volte più produttivo".
Ora, per essere onesti, nessuno di questi è stato direttamente usato per premiare o punire le persone di per sé. La nostra gestione era abbastanza tecnica per capire che lo scenario sopra può accadere. Ma ancora, dato che le metriche sono a posto, tendeva a guardare psicologicamente e a sentirsi male quando spendevi per sempre qualcosa. E alcuni prodotti e codebase dell'azienda tendevano a generare bug più sgradevoli di altri - o il lavoro era più prevedibile che su altri. Alla fine, tutto questo ha fatto sì che le persone diventassero demotivate quando i loro "numeri" non sembravano buoni come quelli di altri gruppi o programmatori.
Il numero di problemi e le tendenze di apertura / chiusura in un sistema di tracciamento possono essere un indicatore di stato ragionevolmente buono del progetto, se presi nel contesto di dati storici per lo stesso team o azienda.
Tuttavia, il rilascio di una direttiva per limitare il numero di problemi invita solo l'abuso. La gente giocherà il sistema, anche senza intenzioni disoneste. I bug non verranno segnalati o risolti in modo errato, le funzionalità saranno saltate o non documentate, aumenterà l'attrito tra i team di test / sviluppatori.
Leggi altre domande sui tag quality defect product-features