Dashboard dei bug (CMMI)

È possibile monitorare l'attività dei bug per un progetto team utilizzando il dashboard dei bug in cui vengono visualizzati i grafici seguenti:

• burn-down dei bug

• frequenza alla quale il team individua, risolve e chiude i bug nel tempo

• conteggio dei bug con priorità nel tempo

• conteggio corrente dei bug attivi assegnati a ogni membro del team

  Nota

  È possibile accedere ai dashboard tramite il portale del progetto team.È possibile accedere al dashboard dei bug solo se il portale è stato abilitato e ne è stato eseguito il provisioning per l'utilizzo di SharePoint Server Enterprise Edition.Per ulteriori informazioni, vedere Dashboard (CMMI).

In questo argomento Dati visualizzati nel dashboard Attività necessarie per tenere traccia dei bug Monitoraggio dei bug attivi e delle tendenze dei bug

È possibile utilizzare questo dashboard per rispondere alle domande seguenti: Con quale velocità il team sta risolvendo e chiudendo i bug? Il team sta correggendo i bug in modo sufficientemente rapido per finire in tempo? Quanti bug al giorno vengono segnalati, risolti e chiusi dal team? Il team sta procedendo alla risoluzione dei bug con priorità 1 prima dei bug con priorità 2 e 3? I membri del team dispongono di un backlog dei bug con priorità 1 che garantisca la redistribuzione? Qual è lo stato della compilazione della notte scorsa? Quali sono state le archiviazioni più recenti?

Autorizzazioni necessarie

Per visualizzare il dashboard, è necessario disporre di autorizzazioni di Lettura per il progetto team in Prodotti SharePoint o appartenere a un gruppo che dispone di tali autorizzazioni. Per modificare, copiare o personalizzare il dashboard, è necessario disporre delle autorizzazioni del gruppo Membri per il progetto team in Prodotti SharePoint o appartenere a un gruppo che dispone di tali autorizzazioni. Per ulteriori informazioni, vedere Aggiungere utenti ai progetti team.

Per modificare un rapporto in Office Excel, è necessario essere membri del ruolo di sicurezza TfsWarehouseDataReaders in SQL Server Analysis Services. È inoltre necessario disporre delle autorizzazioni del gruppo Membri per il progetto team in Prodotti SharePoint o appartenere a un gruppo che dispone di tali autorizzazioni. Per ulteriori informazioni, vedere Concedere l'accesso ai database del data warehouse per Visual Studio ALM.

Per visualizzare un bug o un altro tipo di elemento di lavoro, è necessario essere un membro del gruppo Readers o che l'autorizzazione Visualizza elementi di lavoro in questo nodo sia impostata su Consenti. Per creare o modificare un bug o un altro tipo di elemento di lavoro, è necessario essere un membro del gruppo Contributors o che l'autorizzazione Modifica elementi di lavoro in questo nodo sia impostata su Consenti.

Dati visualizzati nel dashboard

Il team può utilizzare il dashboard dei bug per determinare la capacità del team di individuare, risolvere e chiudere i bug. In particolare, nel dashboard vengono visualizzate le web part mostrate e descritte rispettivamente nell'illustrazione e nella tabella seguenti:

Nota

I grafici dello stato di avanzamento, della tendenza e a barre, nonché i rapporti da a non vengono visualizzati quando non è disponibile il server che ospita Analysis Services per il progetto team.

Per ulteriori informazioni su come interpretare, aggiornare o personalizzare i grafici visualizzati nel dashboard dei bug, vedere gli argomenti elencati nella tabella seguente.

Web part	Dati visualizzati	Argomento correlato
	Rappresentazione grafica del conteggio cumulativo di tutti i bug, raggruppati per stato, per le ultime quattro settimane.	Rapporto Excel Stato di avanzamento bug
	Grafico a linee che mostra la media mobile del numero di bug che il team ha aperto, risolto e chiuso nelle ultime quattro settimane. La media mobile è basata sui sette giorni precedenti la data per la quale è calcolata.	Rapporto Excel Tendenze del bug
	Rappresentazione grafica del conteggio cumulativo di tutti i bug raggruppati per priorità per le ultime quattro settimane.	Rapporto Excel Bug per priorità
	Grafico a barre orizzontale con il totale di bug attivi raggruppati per priorità e assegnati a ogni membro del team.	Rapporto Excel Bug per assegnazione
	Elenco dei bug attivi. L'elenco è derivato da una web part Team Web Access.	Non applicabile
	Elenco di eventi futuri. Elenco derivato da una web part di SharePoint.	Non applicabile
	Conteggio degli elementi di lavoro attivi, risolti e chiusi. È possibile aprire l'elenco di elementi di lavoro selezionando ogni numero. Questo elenco è derivato da una Web part Team Web Access.	Tipi di elemento di lavoro e flusso di lavoro del modello di processo CMMI
	Elenco di compilazioni recenti con relativo stato. Per visualizzare ulteriori dettagli relativi a una compilazione, fare clic su di essa. Questo elenco è derivato da una Web part Team Web Access. Legenda: : Compilazione non avviata : Compilazione in corso : Compilazione completata : Compilazione non riuscita : Compilazione interrotta : Compilazione completata parzialmente	Managing and Reporting on Builds
	Elenco delle archiviazioni più recenti. Per visualizzare ulteriori dettagli relativi a un'archiviazione specifica, fare clic su di essa. Questo elenco è derivato da una Web part Team Web Access.	Sviluppare il codice e gestire le modifiche in sospeso

Attività necessarie per tenere traccia dei bug

Affinché i rapporti visualizzati nel dashboard dei bug risultino utili e accurati, il team deve effettuare le attività seguenti:

• Definire i bug e specificarne i percorsi Iterazione e Area.

• Assegnare ciascun bug al membro del team che si sta occupando di risolverlo o chiuderlo.

• Specificare la Priorità per ogni bug.

• Aggiornare lo Stato di ogni bug a mano a mano che il team corregge, verifica e chiude il bug.

Monitoraggio dei bug attivi e delle tendenze dei bug

I membri del team possono utilizzare il dashboard dei bug per determinare se la gestione dell'elenco dei bug attivi viene svolta in base agli obiettivi del team e alle procedure Agile stabiliti. L'esecuzione di unit test per ogni incremento di codice prima dell'archiviazione consente al team di ridurre il numero complessivo di bug da individuare. Un team che concentra la propria attenzione sulla consegna di ogni singolo incremento di codice rimuove in modo incrementale gli errori e riduce al minimo il numero di bug in corso.

Il dashboard dei bug consente al team di rispondere alle domande seguenti:

• Il numero di bug attivi è accettabile in base agli obiettivi del team? Il team sta posticipando troppi bug?

• Il team sta individuando, correggendo e chiudendo i bug abbastanza rapidamente da soddisfare le aspettative e a una frequenza pari a quella dei cicli di sviluppo precedenti?

• Il team sta risolvendo i bug con priorità alta prima dei bug con priorità bassa?

• Vi sono membri del team che necessitano di supporto nella risoluzione dei bug?

Indicatori dello stato di avanzamento dei bug

Indicatore	Domande
La banda per i bug attivi sta diventando più ampia. Se la larghezza della banda dei bug attivi del team sta aumentando, il backlog dei bug è in aumento. Il team sta individuando più bug di quanti ne possa risolvere o chiudere. Una banda dei bug attivi in ampliamento potrebbe indicare che un collo di bottiglia sta compromettendo la capacità del team di risolvere e chiudere i bug.	I membri del team sono stati riallocati su altre attività non prioritarie? Esistono altre problematiche che impediscono al team di risolvere e correggere i bug?
Il numero di bug attivi non sta cambiando. Una tendenza piatta nel numero di bug attivi indica che il team non sta individuando bug.	Il code coverage del test è sufficiente? Esistono altre problematiche che impediscono al team di individuare i bug?
Il numero dei bug risolti o chiusi non sta cambiando. Quando il numero di bug risolti o chiusi dal team rimane invariato per lunghi periodi di tempo, i membri del team potrebbero non essere in grado di risolvere o chiudere i bug.	Le priorità del team sono state impostate correttamente? I membri del team sono sovrallocati per altre attività? I membri del team stanno tenendo traccia in modo corretto dello stato dei rispettivi bug?

Indicatori di tendenza dei bug

Indicatore	Domande
Il team risolve numerosi bug in ogni periodo di tempo. Una frequenza di risoluzione elevata indica in genere che il team sta lavorando in modo efficace.	Il team chiude immediatamente i bug che risolve? La frequenza di chiusura deve essere simile alla frequenza di risoluzione. Il team riattiva i bug con una frequenza accettabile?
Il team risolve rapidamente i bug ma non li chiude. I membri del team assegnati alla verifica delle correzioni potrebbero non essere sufficienti oppure altre priorità potrebbero impedire al team di chiudere i bug risolti.	Le risorse di test sono sovrallocate? Il team deve rivedere le priorità di test? Per ulteriori informazioni su queste metriche, vedere Dashboard di test (CMMI).
Il team trova pochi bug in ogni periodo di tempo. Il team potrebbe incontrare difficoltà a trovare i bug in una soluzione di alta qualità o se utilizza test inefficaci.	Le metriche per il code coverage, la varianza del codice o lo stato di avanzamento del test indicano un problema di codice o di test? Per ulteriori informazioni su queste metriche, vedere Dashboard di qualità (CMMI)
Il team sta trovando più o meno lo stesso numero di bug in periodi di tempo successivi. Se il team trova lo stesso numero di bug in più settimane o iterazioni successive, potrebbe essere utile esaminarne la causa sottostante. All'inizio del ciclo di test, i test potrebbero non essere sufficientemente rigorosi o avanzati da consentire l'individuazione di molti bug. Nelle prime iterazioni, questa situazione è prevedibile. Tuttavia, a mano a mano che il prodotto matura, i test devono esercitare scenari e integrazioni più ampi.	I test sono adatti a testare i requisiti che il team sta sviluppando? I test sono diventati obsoleti o stanno verificando la funzionalità errata? Il team che si occupa del test sta testando scrupolosamente ogni requisito? Per ulteriori informazioni su queste metriche, vedere Dashboard di test (CMMI).
Il team trova numerosi bug in ogni periodo di tempo. Il team potrebbe individuare con facilità bug in codice approssimativo, in codice appena integrato, effettuando test efficaci oppure durante un evento specifico, come ad esempio un bug bash.	Le metriche per il code coverage, la varianza del codice o lo stato di avanzamento del test indicano un problema di codice o di test? Per ulteriori informazioni su queste metriche, vedere Dashboard di qualità (CMMI).

Priorità e distribuzione dei bug

Indicatore	Domande
Il numero di bug attivi con priorità più alta è maggiore del numero di bug attivi con priorità inferiore. Quando il numero di bug con priorità alta e molto più elevato del numero di bug con priorità più bassa, è possibile che il team stia concentrando la propria attenzione innanzitutto sugli elementi con priorità più bassa.	Il team sta correggendo i bug nell'ordine di priorità impostato dal team? Sono presenti problemi che impediscono al team di correggere i bug con priorità più alta?
Le assegnazioni dei bug non vengono distribuite in modo uniforme. Il team potrebbe valutare la possibilità di riassegnare lavoro quando molti bug vengono assegnati a uno o due membri del team e solo alcuni ad altri membri del team.	Il team deve bilanciare il carico di lavoro riassegnando i bug?