Aggiungere bug al backlog o alla lavagna delle attività
Alcuni team preferiscono tenere traccia dei bug come elementi backlog, ad esempio elementi backlog di prodotto, storie utente o requisiti. Altri processi aziendali possono richiedere che si tenga traccia di altri tipi di elemento di lavoro nel backlog o nella lavagna delle attività.
Se si usa un progetto Scrum, i bug sono già visualizzati nel backlog. Tuttavia, se il progetto team è stato creato usando altri modelli di processo come Agile o CMMI, i bug non verranno visualizzati nella lavagna delle attività né nel backlog.
Per aggiungere bug o altri tipi di elemento di lavoro, è possibile configurare le impostazioni del team o personalizzare il progetto team per supportare le scelte seguenti:
Distribuzione |
Scelte |
|---|---|
Visual Studio Online |
|
Istanza locale con l'aggiornamento TFS 2013.4 |
|
Istanza locale senza l'aggiornamento TFS 2013.4 |
|
Se si lavora in un'istanza locale di TFS, è possibile personalizzare il progetto team in modo che i bug o gli altri tipi di elemento di lavoro siano visualizzati nella lavagna delle attività o nel backlog, ma non in entrambi.
Se si stanno apportando modifiche a progetti team definiti in TFS 2012, vedere la versione per Visual Studio 2012 di questo argomento.
Opzione A: consentire ai team di tenere traccia dei bug nel backlog (Visual Studio Online or TFS 2013.4)
Ogni team può scegliere di tenere traccia dei bug nel proprio backlog. Se si effettua la connessione a un'istanza locale di TFS, sarà necessario eseguire l'aggiornamento a TFS 2013.4. (Vedere Microsoft Visual Studio 2013 Update 4.
Se non si è un amministratore del team, è necessario ottenere le autorizzazioni relative.
Aprire Impostazioni dalla pagina di amministrazione del team e selezionare la casella di controllo per la traccia dei bug.
.png "Pagina Impostazioni team, tenere traccia dei bug nel backlog")
Se l'opzione non viene visualizzata, sarà necessario aggiornare la configurazione del processo per il progetto team.
Per vedere le modifiche, aprire o aggiornare la pagina di backlog del team.
Aggiornare la configurazione del processo per supportare il rilevamento dei bug nel backlog (istanze locali di TFS)
Se l'opzione per tenere traccia dei bug nel backlog è disabilitata nella pagina delle impostazioni del team, verificare o aggiornare i seguenti file di definizione XLS per il proprio progetto team. È necessario essere membri del gruppo Project Administrators per poter aggiornare questi oggetti.
Categorie: la categoria requisiti deve contenere unicamente tipi di elemento di lavoro associati a elementi backlog. La categoria Bug deve contenere unicamente tipi di elemento di lavoro associati ai bug. La categoria requisiti, ad esempio, non deve contenere una voce relativa a un bug.
Le seguenti categorie di esempio sono corrette:
<CATEGORY name="Bug Category" refname="Microsoft.BugCategory"> <DEFAULTWORKITEMTYPE name="Bug" /> </CATEGORY> <CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory"> <DEFAULTWORKITEMTYPE name="Product Backlog Item" /> </CATEGORY>Mentre quelle indicate di seguito non sono corrette perché la categoria requisiti include un tipo di elemento di lavoro Bug.
<CATEGORY name="Bug Category" refname="Microsoft.BugCategory"> <DEFAULTWORKITEMTYPE name="Bug" /> </CATEGORY> <CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory"> <DEFAULTWORKITEMTYPE name="Product Backlog Item" /> <WORKITEMTYPE name="Bug" /> </CATEGORY>Per aggiornare le categorie, vedere Importare ed esportare categorie [witadmin].
ProcessConfiguration: contiene l'elemento BugWorkItems che definisce la categoria Bug e mappa gli stati del flusso di lavoro relativo ai bug ai metastati. Ad esempio:
<BugWorkItems category="Microsoft.BugCategory" pluralName="Bugs" singularName="Bug"> <States> <State value="Active" type="InProgress" /> <State value="Resolved" type="Resolved" /> <State value="Closed" type="Complete" /> </States> </BugWorkItems>Inoltre, le mappature dei metastati devono essere coerenti in RequirementWorkItems e BugWorkItems. Ad esempio, Active non può essere mappato a Proposed da una parte e a InProgress dall'altra.
Per aggiornare ProcessConfiguration, vedere Importare ed esportare la configurazione del processo [witadmin].
Definizioni del tipo di elemento di lavoro: i tipi di elemento di lavoro inclusi nella categoria Bug devono avere i seguenti campi definiti:
Campo per tenere traccia del lavoro richiesto (type=Effort nel file ProcessConfiguration), ad esempio Punti della storia (Microsoft.VSTS.Scheduling.StoryPoints) o Dimensione (Microsoft.VSTS.Scheduling.Size) a seconda del modello usato (Agile o CMMI) per creare il progetto team.
Campo usato per tenere traccia della priorità del backlog (type=Order nel file ProcessConfiguration), ad esempio Ordine di priorità (Microsoft.VSTS.Common.StackRank).
Per un progetto team basato su MSF for CMMI, il campo Tipo di requisito (Microsoft.VSTS.CMMI.RequirementType) perché è incluso nel pannello di aggiunta rapida per la configurazione processo.
Per aggiornare le definizioni dei tipi di elemento di lavoro, vedere Importare, esportare e gestire tipi di elemento di lavoro [witadmin].
Verificare o aggiornare i mapping di colonne della bacheca Kanban
Aprire la pagina dell'area del backlog di prodotto (bacheca Kanban).
Se viene visualizzato un messaggio che indica che le configurazioni di colonna non sono valide, sarà necessario regolare i mapping delle colonne.
.png "Messaggio di errore che indica la necessità di personalizzare le colonne")
Aprire Personalizza colonne e mappare gli stati del flusso di lavoro dei bug per ogni colonna che è stata definita.
È ad esempio possibile mappare ogni colonna come illustrato di seguito:
.png "Personalizzare le colonne per la bacheca Kanban")
Opzione B: tutti i team tengono traccia dei bug o di altri tipi di elemento di lavoro nel backlog
I tipi di elemento di lavoro aggiunti alla categoria requisiti vengono visualizzati nelle pagine di backlog. Affinché i bug vengano visualizzati nella pagina di backlog delle storie utente (Agile) o dei requisiti (CMMI), apportare le modifiche seguenti al progetto team nell'istanza locale di TFS:
Aggiungere il campo usato per la stima del lavoro richiesto al bug o a un altro tipo di elemento di lavoro: Punti della storia (Agile) o Dimensione (CMMI).
Aggiungere il bug o un altro tipo di elemento di lavoro alla categoria requisiti.
Verificare i mapping di metastati nella configurazione del processo.
Di seguito viene illustrato come aggiungere il tipo di elemento di lavoro Bug per un progetto team basato sul modello di processo MSF for Agile.
Aggiungere il campo Punti della storia
Esportare la definizione del tipo di elemento di lavoro Bug.
witadmin exportwitd /collection:" CollectionURL" /p:MyProject /n:bug /f:DirectoryPath/bug.xmlAggiungere il campo Punti della storia.
<FIELDS> . . . . <FIELD name="Story Points" refname="Microsoft.VSTS.Scheduling.StoryPoints" type="Double" reportable="measure" formula="sum"> <HELPTEXT>The size of work estimated for implementing the bug.</HELPTEXT> </FIELD> . . . . </FIELDS>Per un progetto team basato su MSF for CMMI, aggiungere Dimensione e Tipo di requisito.
<FIELD name="Size" refname="Microsoft.VSTS.Scheduling.Size" type="Double" reportable="measure" formula="sum" > <HELPTEXT>The size of work estimated for implementing this requirement</HELPTEXT> </FIELD> <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension"> <REQUIRED /> <ALLOWEDVALUES> <LISTITEM value="Scenario" /> <LISTITEM value="Quality of Service" /> <LISTITEM value="Functional" /> <LISTITEM value="Operational" /> <LISTITEM value="Interface" /> <LISTITEM value="Security" /> <LISTITEM value="Safety" /> <LISTITEM value="Business Objective" /> <LISTITEM value="Feature" /> </ALLOWEDVALUES> <DEFAULT from="value" value="Functional" /> </FIELD>Aggiungere Punti della storia al layout del form.
<FORM> . . . <Column PercentWidth="33"> <Group Label="Planning"> <Column PercentWidth="100"> <Control FieldName="Microsoft.VSTS.Scheduling.StoryPoints" Type="FieldControl" Label="Story Points" LabelPosition="Left" /> <Control FieldName="Microsoft.VSTS.Common.StackRank" Type="FieldControl" Label="Stack Rank" LabelPosition="Left" NumberFormat="DecimalNumbers" MaxLength="10" EmptyText="<None>" /> <Control FieldName="Microsoft.VSTS.Common.Priority" Type="FieldControl" Label="Priority" LabelPosition="Left" /> <Control FieldName="Microsoft.VSTS.Common.Severity" Type="FieldControl" Label="Severity" LabelPosition="Left" /> </Column> </Group> </Column> . . . </FORM>Per un progetto team basato su CMMI, aggiungere Dimensione e Tipo di requisito alla sezione FORM.
<Control Type="FieldControl" FieldName="Microsoft.VSTS.Scheduling.Size" Label="Size" LabelPosition="Left" /> <Control Type="FieldControl" FieldName="Microsoft.VSTS.CMMI.RequirementType" Label="Type" LabelPosition="Left" />Importare la definizione di bug aggiornata.
witadmin importwitd /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/bug.xml"
Aggiungere il tipo di elemento di lavoro Bug alla Categoria requisiti
Esportare la definizione di categorie. Se le autorizzazioni di amministratore non sono disponibili, richiederle ora.
witadmin exportcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"Aggiungere il tipo di elemento di lavoro bug alla categoria requisiti.
<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category"> <DEFAULTWORKITEMTYPE name="User Story" /> <WORKITEMTYPE name="Bug" /> </CATEGORY>Importare il file delle categorie.
witadmin importcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"
Verificare i mapping di metastati nella configurazione del processo
Esportare la definizione della configurazione del processo.
witadmin exportprocessconfig /collection:"CollectionURL" /p:MyProject /f: "DirectoryPath/ProcessConfiguration.xml"Verificare che lo stato risolto sia definito nella sezione RequirementBacklog.
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="User Story"> <States> <State value="New" type="Proposed" /> <State value="Active" type="InProgress" /> <State value="Resolved" type="InProgress" /> <State value="Closed" type="Complete" /> </States>. . . </RequirementBacklog>Se si è personalizzato il bug per l'aggiunta di stati aggiuntivi, aggiungere i mapping per ogni stato aggiunto. Mappare sempre l'ultimo stato all'interno di una transizione di avanzamento a type="Complete".
Importare la configurazione del processo.
witadmin importprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"
Verificare che sia possibile aggiungere bug al backlog di prodotto
Aprire la pagina di backlog di prodotto o aggiornare la pagina se è già aperta.
Verrà visualizzato un menu a discesa per l'elemento di lavoro Tipo.
.png "Pannello aggiornato con l'aggiunta del tipo di elemento di lavoro bug")
Personalizzare la bacheca Kanban per il mapping degli stati dei bug alle corsie
Aprire la pagina dell'area del backlog di prodotto (bacheca Kanban).
Se si è appena aggiunto il tipo di elemento di lavoro bug o un altro tipo di elemento di lavoro, verrà visualizzato un messaggio che indica che le configurazioni delle colonne non sono valide.
Aprire Personalizza colonne e mappare gli stati del flusso di lavoro dei bug per ogni colonna che è stata definita.
È ad esempio possibile mappare ogni colonna come illustrato di seguito:
.png "Mapping degli stati del flusso di lavoro del bug per ciascuna colonna")
Opzione C: tutti i team tengono traccia dei bug o di altri tipi di elemento di lavoro nella lavagna delle attività
I tipi di elemento di lavoro che si aggiungono alla categoria attività vengono visualizzati nella lavagna delle attività e nelle pagine di backlog interazione. Affinché bug e attività vengano visualizzati nella lavagna delle attività, è necessario collegarli a un elemento padre che può essere un elemento backlog di prodotto (Scum), una storia utente (Agile) o un requisito (CMMI).
Per un'istanza locale di TFS, apportare le modifiche seguenti per tenere traccia di bug e attività:
Aggiungere i campi obbligatori alla definizione del tipo di elemento di lavoro bug.
Aggiungere il tipo di elemento di lavoro Bug alla categoria attività.
Aggiungere i mapping di metastati alla configurazione del processo.
Di seguito viene illustrato come eseguire questa operazione per un progetto team basato sul modello di processo MSF for Agile.
Aggiungere i campi obbligatori
Se non si hanno le autorizzazioni di amministratore per il proprio progetto team, è necessario ottenerle.
Aprire una finestra del prompt dei comandi nel computer in cui è installato Visual Studio o Team Explorer e immettere:
cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDEIn una versione a 64 bit di Windows sostituire %programfiles% con %programfiles(x86)%. È possibile scaricare Team Explorer gratuitamente.
Esportare la definizione di tipo di elemento di lavoro bug.
witadmin exportwitd /collection:"CollectionURL" /p:MyProject /n:bug /f: "DirectoryPath/bug.xml"Un esempio di CollectionURL è "https://Server:8080/tfs/NomeRaccoltaProgettiTeam".
Aggiungere il campo relativo all'attività. Se non si esegue questo passaggio, la configurazione non sarà valida. Facoltativamente, aggiungere i campi di pianificazione in modo da tenere traccia del lavoro rimanente e di quello completato. I campi Microsoft.VSTS.Scheduling.XXX vengono usati nei report predefiniti, ma non negli strumenti di pianificazione Agile. Se il team non usa questi campi, non è necessario aggiungerli.
<FIELDS> . . . <FIELD name="Activity" refname="Microsoft.VSTS.Common.Activity" type="String" reportable="dimension"> <HELPTEXT>Type of work involved</HELPTEXT> <SUGGESTEDVALUES> <LISTITEM value="Development"/> <LISTITEM value="Testing"/> <LISTITEM value="Requirements"/> <LISTITEM value="Design"/> <LISTITEM value="Deployment"/> <LISTITEM value="Documentation"/> </SUGGESTEDVALUES> </FIELD> <FIELD name="Remaining Work" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure" formula="sum"> <HELPTEXT>An estimate of the number of units of work remaining to complete this task</HELPTEXT> </FIELD> <FIELD name="Original Estimate" refname="Microsoft.VSTS.Scheduling.OriginalEstimate" type="Double" reportable="measure" formula="sum"> <HELPTEXT>Initial value for Remaining Work - set once, when work begins</HELPTEXT> </FIELD> <FIELD name="Completed Work" refname="Microsoft.VSTS.Scheduling.CompletedWork" type="Double" reportable="measure" formula="sum"> <HELPTEXT>The number of units of work that have been spent on this task</HELPTEXT> </FIELD> <FIELD name="Start Date" refname="Microsoft.VSTS.Scheduling.StartDate" type="DateTime" reportable="dimension"> <HELPTEXT>The date to start the task</HELPTEXT> </FIELD> <FIELD name="Finish Date" refname="Microsoft.VSTS.Scheduling.FinishDate" type="DateTime" reportable="dimension"> <HELPTEXT>The date to finish the task</HELPTEXT> </FIELD> . . . </FIELDS>Per un progetto team basato su MSF for CMMI, aggiungere i campi relativi a disciplina e pianificazione.
<FIELD name="Discipline" refname="Microsoft.VSTS.Common.Discipline" type="String" reportable="dimension"> <ALLOWEDVALUES> <LISTITEM value="Analysis" /> <LISTITEM value="User Experience" /> <LISTITEM value="User Education" /> <LISTITEM value="Development" /> <LISTITEM value="Test" /> </ALLOWEDVALUES> <HELPTEXT>The discipline to which the task belongs</HELPTEXT> </FIELD>Aggiungere i campi relativi ad attività e pianificazione al form elemento di lavoro. È anche sufficiente copiare i Groups definiti nel tipo elemento di lavoro attività e sostituire i Groups esistenti.
<FORM> . . . <Group Margin="(10,0,0,0)"> <Column PercentWidth="30"> <Group Label="Status"> <Column PercentWidth="100"> <Control FieldName="System.AssignedTo" EmptyText="<No one>" Type="FieldControl" Label="Assi&gned To" LabelPosition="Left" /> <Control FieldName="System.State" Type="FieldControl" Label="Stat&e" LabelPosition="Left" /> <Control FieldName="System.Reason" Type="FieldControl" Label="Reason" LabelPosition="Left" /> </Column> </Group> </Column> <Column PercentWidth="20"> <Group Label="Planning"> <Column PercentWidth="100"> <Control FieldName="Microsoft.VSTS.Common.StackRank" Type="FieldControl" Label="Stack Rank" LabelPosition="Left" NumberFormat="DecimalNumbers" MaxLength="10" EmptyText="<None>" /> <Control FieldName="Microsoft.VSTS.Common.Priority" Type="FieldControl" Label="Priority" LabelPosition="Left" /> <Control FieldName="Microsoft.VSTS.Common.Activity" Type="FieldControl" Label="Activity" LabelPosition="Left" EmptyText="<None>" /> </Column> </Group> </Column> <Column PercentWidth="30"> <Group Label="Classification"> <Column PercentWidth="100"> <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&Area" LabelPosition="Left" /> <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&ration" LabelPosition="Left" /> </Column> </Group> </Column> <Column PercentWidth="20"> <Group Label="Effort (Hours)"> <Column PercentWidth="100"> <Control FieldName="Microsoft.VSTS.Scheduling.OriginalEstimate" Type="FieldControl" Label="Original Estimate" LabelPosition="Left" /> <Control FieldName="Microsoft.VSTS.Scheduling.RemainingWork" Type="FieldControl" Label="Remaining" LabelPosition="Left" /> <Control FieldName="Microsoft.VSTS.Scheduling.CompletedWork" Type="FieldControl" Label="Completed" LabelPosition="Left" /> </Column> </Group> </Column> </Group> . . . </FORM>Importare la definizione di bug aggiornata.
witadmin importwitd /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/bug.xml"
Aggiungere il tipo di elemento di lavoro Bug alla categoria attività
Esportare la definizione di categorie.
witadmin exportcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"Aggiungere bug alla categoria attività.
<CATEGORY refname="Microsoft.TaskCategory" name="Task Category"> <DEFAULTWORKITEMTYPE name="Task" /> <WORKITEMTYPE name="Bug" /> </CATEGORY>Nota
Un tipo di elemento di lavoro bug può appartenere a due categorie, la categoria bug e la categoria attività.
Importare il file delle categorie.
witadmin importcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"
Aggiungere il mapping di metastati alla configurazione del processo
Esportare la definizione della configurazione del processo.
witadmin exportprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"Aggiungere il mapping di metastati per lo stato Risolto alla sezione TaskBacklog.
<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task"> <States> <State value="New" type="Proposed" /> <State value="Active" type="InProgress" /> <State value="Resolved" type="InProgress" /> <State value="Closed" type="Complete" /> </States> . . . </TaskBacklog>Se si è personalizzato il bug per l'aggiunta di stati aggiuntivi, aggiungere i mapping per ogni stato aggiunto. Mappare sempre l'ultimo stato all'interno di una transizione di avanzamento a type="Complete".
Importare la configurazione del processo.
witadmin importprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"
Verificare che sia possibile aggiungere bug alla lavagna delle attività
Aprire la pagina della lavagna delle attività o aggiornare la pagina se è già aperta.
È possibile selezionare l'attività o il bug come elemento di lavoro collegato a una storia utente.
.png "Area attività con l'aggiunta del tipo di elemento di lavoro bug")
Per aggiungere bug esistenti alla lavagna delle attività, aprire una storia utente. In questo esempio la storia utente è intitolata Bug debt. Nella scheda Tutti i collegamenti scegliere i bug da includere nello sprint.
.png "Collegare diversi bug a una storia utente")
Potrebbe essere necessario aggiornare la lavagna delle attività per visualizzare i bug.
Suggerimento
Non è possibile aggiungere i bug nella scheda Implementazione perché sono limitati alle attività.Per supportare l'aggiunta di bug alla scheda Implementazione, modificare la sezione FORM del tipo di elemento di lavoro storia utente per includere il filtro per i bug.
Nella lavagna delle attività, trascinare un bug o un'attività per aggiornarne lo stato. Si noterà che non è possibile trascinare un elemento in una colonna che presenta uno stato non valido. Ad esempio, non è possibile trascinare un bug nello stato Nuovo o un'attività nello stato Risolto. Se si vogliono usare questi stati, aggiungerli alla definizione del flusso di lavoro per la definizione del tipo di elemento di lavoro corrispondente.
Domande e risposte
D: Quali altri strumenti è possibile usare per modificare i file di definizione XML?
R: Con lo strumento da riga di comando witadmin, è possibile importare ed esportare file di definizione come descritto in questo argomento. Altri strumenti che è possibile usare per questa attività sono Editor di processo, disponibile con il download di Power Tools di TFS o Gestione progetti team di TFS, un progetto di risorse della community disponibile in CodePlex. Usando Gestione progetti team di TFS, è possibile esportare, modificare e importare file di definizione XML in modo rapido e senza dover usare l'interfaccia della riga di comando.
D: Cosa succede se si rimuove il tipo di elemento di lavoro Bug dalla categoria requisiti da un progetto team basato su Scrum?
R: Le query pronte per l'uso e personalizzate che fanno riferimento alla categoria requisiti non restituiranno più risultati che includono il tipo di elemento di lavoro Bug. Potrebbe essere necessario aggiornare tali query.
Quando si crea un gruppo di test basato sui requisiti, gli elementi di lavoro recuperati appartengono alla categoria requisiti. Per i team che vogliono creare piani di test per bug, sarà necessario aggiornare la query per includere la categoria bug.
D: Che cosa è necessario sapere riguardo ai mapping di metastati?
R: Le procedure indicate nelle opzioni B e C descrivono come modificare il progetto team basato sui modelli di processo Agile e CMMI disponibili in TFS 2013. Il modello di stato per i tipi di elemento di lavoro aggiunto deve corrispondere ai mapping di metastati specificati nel file ProcessConfiguration. Se il modello di stato e i mapping di metastati non corrispondono, è necessario apportare le definizioni aggiuntive, come descritto qui.
D: Come fare per visualizzare il bug nelle pagine dell'area e di backlog dell'attività per Scrum?
R: Se il progetto team è basato sul modello di processo Scrum e si vuole fare in modo che i bug siano correlati ad attività e non agli elementi backlog di prodotto, seguire questa procedura:
Modificare la definizione dell'elemento di lavoro bug: aggiungere i campi Attività e Lavoro rimanente alle sezioni FIELDS e FORM.
Modificare la definizione delle categorie: aggiungere Bug alla categoria attività e rimuoverlo dalla categoria requisiti.
Modificare la definizione della configurazione del processo: mappare lo stato Risolto per la categoria attività e rimuoverlo dalla categoria requisiti.
D: Perché non tutti i bug e le attività assegnate a uno sprint vengono visualizzati nel backlog di quest'ultimo?
R: È possibile assegnare attività a un'iterazione, ma non collegarle a un elemento backlog padre. Tali elementi verranno visualizzati nella query creata ma non nella lavagna delle attività vera e propria. TFS esegue la query e quindi applica alcuni processi in background prima di visualizzare gli elementi della lavagna delle attività.
I tre motivi seguenti possono essere causa della mancata visualizzazione di elementi di lavoro appartenenti alla categoria attività in un backlog sprint o in una lavagna delle attività:
L'attività non è stata collegata a un elemento di backlog padre. Nella pagina di backlog sprint verranno visualizzati solo i bug e le attività che sono stati collegati a un elemento del backlog di prodotto padre (Scrum), a una storia utente (Agile) o a un requisito (CMMI) e il cui percorso di iterazione è impostato sullo sprint stesso.
L'attività è l'elemento padre di un'altra attività. Se si è creata una gerarchia di attività, vengono visualizzate solo le attività di livello figlio in fondo alla gerarchia.
L'elemento padre collegato dell'attività corrisponde a un elemento backlog definito per un altro team. Oppure, il percorso area dell'elemento backlog padre dell'attività è diverso dal percorso area dell'attività.
D: Come vengono usati i campi Priorità backlog od Ordine di priorità?
R: Le pagine dell'area e di backlog usano i campi Priorità backlog (Scrum) e Ordine di priorità (Agile e CMMI) per gestire l'ordinamento degli elementi di lavoro. Questi campi devono essere definiti per tutti i tipi di elemento di lavoro di un progetto team. Non è tuttavia necessario includerli nel form dell'elemento di lavoro. Questi campi devono corrispondere al campo assegnato al tipo Order nel file di definizione ProcessConfiguration.