Hinzufügen von Fehlern zum Backlog oder Task Board
Einige Teams mögen das Nachverfolgen von Fehlern als Backlogelemente wie Product Backlog Items, User Storys oder Anforderungen. Für andere Geschäftsprozesse ist möglicherweise die Nachverfolgung von zusätzlichen Arbeitsaufgabentypen (Work Item Types, WITs) im Backlog oder Task Board erforderlich.
Wenn Sie ein Scrum-Projekt verwenden, werden Fehler bereits im Backlog angezeigt. Wenn Ihr Teamprojekt jedoch mithilfe einer anderen Prozessvorlage wie Agile oder CMMI erstellt wurde, werden Fehler weder im Backlog noch im Task Board angezeigt.
Zum Hinzufügen von Fehlern oder anderen WITs können Sie Teameinstellungen konfigurieren oder Ihr Teamprojekt so anpassen, dass es diese Auswahlmöglichkeiten unterstützt:
Bereitstellung |
Auswahlmöglichkeiten |
|---|---|
Visual Studio Online |
|
Lokale Version mit TFS 2013.4-Update |
|
Lokale Version ohne TFS 2013.4-Update |
|
Wenn Sie auf einem lokalen TFS arbeiten, können Sie Ihr Teamprojekt anpassen, damit Fehler oder andere WITs entweder im Backlog oder im Task Board, aber nicht in beiden angezeigt werden.
Wenn Sie Änderungen an in TFS 2012 definierten Teamprojekten vornehmen, sehen Sie sich die Visual Studio 2012-Version dieses Themas an.
Option A: Teams die Auswahl ermöglichen, ob Fehler im Backlog nachverfolgt werden sollen (Visual Studio Online oder TFS 2013.4)
Jedes Team kann auswählen, Fehler im jeweiligen Backlog nachzuverfolgen. Wenn Sie eine Verbindung mit einem lokalen TFS herstellen, muss er auf TFS 2013.4 aktualisiert worden sein. (Siehe Microsoft Visual Studio 2013 Update 4.
Wenn Sie kein Teamadministrator sind, lassen Sie sich die entsprechende Berechtigung zuweisen.
Öffnen Sie auf der Verwaltungsseite des Teams Einstellungen, und aktivieren Sie das Kontrollkästchen zum Nachverfolgen von Fehlern.
.png "Seite mit Teameinstellungen, Nachverfolgen von Fehlern im Backlog")
Wenn die Option nicht angezeigt wird, müssen Sie die Prozesskonfiguration für Ihr Teamprojekt aktualisieren.
Öffnen oder aktualisieren Sie die Backlogseite des Teams, um Änderungen anzuzeigen.
Aktualisieren der Prozesskonfiguration zum Unterstützen der Nachverfolgung von Fehlern im Backlog (lokaler TFS)
Wenn die Option für das Nachverfolgen von Fehlern im Backlog auf der Seite für die Teameinstellungen deaktiviert ist, überprüfen oder aktualisieren Sie die folgenden XML-Definitionsdateien für Ihr Teamprojekt. Sie müssen ein Mitglied der Gruppe "Projektadministratoren" sein, um diese Objekte aktualisieren zu können.
Kategorien: "Anforderungskategorie" sollte nur diese mit den Backlogelementen verknüpften WITs enthalten. "Fehlerkategorie" sollte nur diese mit Fehlern verknüpften WITs enthalten. Insbesondere darf "Anforderungskategorie" keinen Eintrag für "Fehler" enthalten.
Beispielsweise sind diese Definitionen richtig:
<CATEGORY name="Bug Category" refname="Microsoft.BugCategory"> <DEFAULTWORKITEMTYPE name="Bug" /> </CATEGORY> <CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory"> <DEFAULTWORKITEMTYPE name="Product Backlog Item" /> </CATEGORY>Und diese Definitionen sind falsch, da der WIT des Fehlers in "Anforderungskategorie" enthalten ist:
<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>Informationen zum Aktualisieren von Kategorien finden Sie unter Importieren und Exportieren von Kategorien [witadmin].
ProcessConfiguration: Enthält das "Fehlerkategorie" definierende BugWorkItems-Element und ordnet die Fehlerworkflowzustände den Metazuständen zu. Beispiel:
<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>Zusätzlich müssen Metazustandszuordnungen unter RequirementWorkItems und BugWorkItems konsistent sein. Beispielsweise kann Active nicht zu Proposed unter einem und zu InProgress unter einem anderen zugeordnet werden.
Informationen zum Aktualisieren von ProcessConfiguration finden Sie unter Importieren und Exportieren der Prozesskonfiguration [witadmin].
WIT-Definitionen: In "Fehlerkategorie" enthaltene WITs müssen über die folgenden definierten Felder verfügen:
Zum Nachverfolgen des Aufwands verwendetes Feld (type=Effort in der Datei "ProcessConfiguration"), beispielsweise "Storypunkte" ("Microsoft.VSTS.Scheduling.StoryPoints") oder "Größe" ("Microsoft.VSTS.Scheduling.Size") auf Grundlage, ob die Agile- oder CMMI-Prozessvorlage zum Erstellen des Teamprojekts verwendet wurde.
Zum Nachverfolgen der Backlogpriorität verwendetes Feld (type=Order in der Datei "ProcessConfiguration"), beispielsweise "Stapelrang" ("Microsoft.VSTS.Common.StackRank").
Für ein Teamprojekt auf der Basis von MSF für CMMI, das Feld "Anforderungstyp" (Microsoft.VSTS.CMMI.RequirementType), da ist es in dem Bereich zum schnellen Hinzufügen für die Prozesskonfiguration enthalten ist.
Informationen zum Aktualisieren von WIT-Definitionen finden Sie unter Importieren, Exportieren und Verwalten von Arbeitsaufgabentypen [witadmin].
Überprüfen oder Aktualisieren der Kanban-Board-Spaltenzuordnungen
Öffnen Sie sie Seite Product Backlog (Kanban-Board).
Wenn eine Meldung angezeigt wird, die besagt, dass die Spaltenkonfigurationen nicht gültig sind, müssen Sie die Spaltenzuordnungen anpassen.
.png "Die Fehlermeldung weist darauf hin, dass die Spalten angepasst werden müssen")
Öffnen Sie "Spalten anpassen" und ordnen Sie die Fehlerworkflowzustände für jede Spalte zu, die Sie definiert haben.
Ordnen Sie beispielsweise jede Spalte wie dargestellt zu:
.png "Anpassen von Spalten für das Kanban-Board")
Option B: Alle Teams verfolgen Fehler oder andere WITs im Backlog nach
WITs, die Sie "Anforderungskategorie" hinzufügen, werden auf den Backlogseiten angezeigt. Damit Fehler auf der Backlogseite "User Storys" (Agile) oder "Anforderungen" (CMMI) angezeigt werden, nehmen Sie die folgenden Änderungen an Ihrem lokalen TFS-Teamprojekt vor:
Fügen Sie das zum Schätzen des Aufwands für den Fehler verwendete Fed oder eine andere WIT-Definition hinzu: "Storypunkte" (Agile) oder "Größe" (CMMI).
Fügen Sie "Anforderungskategorie" den Fehler oder andere WITs hinzu.
Prüfen Sie die Metazustandszuordnungen in der Prozesskonfiguration.
Im Folgenden erfahren Sie, wie Sie den Fehler-WIT für ein Teamprojekt hinzufügen, das auf der MSF for Agile-Prozessvorlage basiert.
Hinzufügen des Felds "Storypunkt"
Exportieren Sie die Fehler-WIT-Definition.
witadmin exportwitd /collection:" CollectionURL" /p:MyProject /n:bug /f:DirectoryPath/bug.xmlFügen Sie das Feld Storypunkte hinzu.
<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>Fügen Sie für ein Teamprojekt auf der Basis von MSF für CMMI Größe und Anforderungstyp hinzu.
<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>Fügen Sie Storypunkte zum Formularlayout hinzu.
<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>Fügen Sie ein CMMI-basiertes Teamprojekt Größe und Anforderungstyp zum FORM-Abschnitt hinzu.
<Control Type="FieldControl" FieldName="Microsoft.VSTS.Scheduling.Size" Label="Size" LabelPosition="Left" /> <Control Type="FieldControl" FieldName="Microsoft.VSTS.CMMI.RequirementType" Label="Type" LabelPosition="Left" />Importieren Sie die aktualisierte Fehlerdefinition.
witadmin importwitd /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/bug.xml"
Hinzufügen eines Fehler-WITs zu "Anforderungskategorie"
Exportieren Sie die Kategoriedefinition. Wenn Sie keine TFS-Administratorberechtigungen haben, rufen Sie diese ab.
witadmin exportcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"Hinzufügen des Fehlerarbeitsaufgabentyps zur Anforderungskategorie.
<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category"> <DEFAULTWORKITEMTYPE name="User Story" /> <WORKITEMTYPE name="Bug" /> </CATEGORY>Importieren Sie die Kategoriedatei.
witadmin importcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"
Prüfen Sie die Metazustandszuordnungen in der Prozesskonfiguration.
Exportieren Sie die Prozesskonfigurationsdefinition.
witadmin exportprocessconfig /collection:"CollectionURL" /p:MyProject /f: "DirectoryPath/ProcessConfiguration.xml"Prüfen Sie, ob der Zustand "Gelöst" im Abschnitt RequirementBacklog definiert ist.
<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>Wenn Sie den Fehler für das Hinzufügen weiterer Status angepasst haben, fügen Sie Zuordnungen für jeden hinzugefügten Status hinzu. Orden Sie den letzten Status type="Complete" immer mit einem Vorwärts-Übergang zu.
Importieren Sie die Prozesskonfigurationen.
witadmin importprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"
Bestätigen, dass dem Product Backlog Fehler hinzugefügt werden können
Öffnen Sie die Product Backlog-Seite, oder aktualisieren Sie diese, wenn sie bereits geöffnet ist.
Das Dropdownmenü für die Arbeitsaufgabe Typ sollte angezeigt werden.
.png "Aktualisierter Bereich mit Fehlerarbeitsaufgaben-Typ wurde hinzugefügt")
Anpassen des Kanban-Boards, sodass Fehlerzustände Verantwortlichkeitsbereichen zugeordnet werden
Öffnen Sie sie Seite Product Backlog (Kanban-Board).
Wenn Sie den Fehlerarbeitsaufgabentyp oder irgendeinen anderen Arbeitsaufgabentyp eben hinzugefügt haben, dann sehen Sie eine Meldung, dass die Spaltenkonfigurationen ungültig sind.
Öffnen Sie "Spalten anpassen" und ordnen Sie die Fehlerworkflowzustände für jede Spalte zu, die Sie definiert haben.
Ordnen Sie beispielsweise jede Spalte wie dargestellt zu:
.png "\"Map Bug\" Workflowzustand für jede Spalte")
Option C: Alle Teams verfolgen Fehler oder andere WITs auf dem Task Board nach
WITs, die Sie zu "Aufgabenkategorie" hinzufügen, werden im Task Board und auf den Iterationsbacklogseiten angezeigt. Damit Fehler oder Aufgaben im Task Board angezeigt werden, müssen Sie sie mit einem übergeordneten Product Backlog Item (Scrum), einer User Story (Agile) oder Anforderung (CMMI) verknüpfen.
Nehmen Sie für den lokalen TFS diese Änderungen vor, um Fehler als Aufgaben nachzuverfolgen:
Fügen Sie der Fehler-WIT-Definition erforderliche Felder hinzu.
Fügen Sie "Aufgabenkategorie" den Fehler-WIT hinzu.
Fügen Sie die erforderlichen Metazustandszuordnungen zur Prozesskonfiguration hinzu.
Im Folgenden wird gezeigt, wie Sie dazu in einem Teamprojekt vorgehen, das auf der MSF for Agile-Prozessvorlage basiert.
Hinzufügen erforderlicher Felder
Wenn Sie nicht über Administratorberechtigungen für Ihr Teamprojekt verfügen, lassen Sie sich als ein Projektadministrator hinzufügen.
Öffnen Sie ein Eingabeaufforderungsfenster auf dem Computer, auf dem entweder Visual Studio oder Team Explorer installiert ist, und geben Sie Folgendes ein:
cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDEErsetzen Sie bei einer 64-Bit-Windows-Edition %programfiles% durch %programfiles(x86)%. Sie können Team Explorer kostenlos herunterladen.
Exportieren Sie die Definition des Fehlerarbeitsaufgabentyps.
witadmin exportwitd /collection:"CollectionURL" /p:MyProject /n:bug /f: "DirectoryPath/bug.xml"Ein Beispiel für eine CollectionURL ist http://MyServer:8080/tfs/TeamProjectCollectionName.
Fügen Sie das Feld Aktivität hinzu. Wenn Sie dies nicht tun, ist die Konfiguration nicht gültig. Optional können Sie Planungsfelder hinzufügen, um verbleibende und abgeschlossene Arbeit nachzuverfolgen. Die Microsoft.VSTS.Scheduling.XXX-Felder werden in Standardberichten verwendet, jedoch nicht in den Agile-Planungstools. Wenn Ihr Team diese Felder nicht verwendet, müssen Sie sie nicht hinzufügen.
<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>In einen Teamprojekt, das auf MSF for CMMI basiert, würden Sie die Felder "Disziplin" und "Planung" hinzufügen.
<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>Fügen Sie die Felder "Aktivität" und "Planung" zum Arbeitsaufgabenformular hinzu. Sie können einfach die Groups kopieren, die in Arbeitsaufgabenelementtyp definiert wurde und die Groups ersetzen, die vorhanden ist.
<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>Importieren Sie die aktualisierte Fehlerdefinition.
witadmin importwitd /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/bug.xml"
Hinzufügen des Fehler-WITs zu "Aufgabenkategorie"
Exportieren Sie die Kategoriedefinition.
witadmin exportcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"Fügen Sie den Fehler zur Aufgabenkategorie hinzu.
<CATEGORY refname="Microsoft.TaskCategory" name="Task Category"> <DEFAULTWORKITEMTYPE name="Task" /> <WORKITEMTYPE name="Bug" /> </CATEGORY>Hinweis
Der Fehlerarbeitsaufgabentyp kann zu zwei Kategorien gehören: zur Fehlerkategorie und zur Aufgabenkategorie.
Importieren Sie die Kategoriedatei.
witadmin importcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"
Fügen Sie die Metazustandszuordnung zur Prozesskonfiguration hinzu.
Exportieren Sie die Prozesskonfigurationsdefinition.
witadmin exportprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"Fügen Sie eine Metazustandszuordnung zum Zustand "Aufgelöst" im Abschnitt TaskBacklog hinzu.
<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>Wenn Sie den Fehler für das Hinzufügen weiterer Status angepasst haben, fügen Sie Zuordnungen für jeden hinzugefügten Status hinzu. Orden Sie den letzten Status type="Complete" immer mit einem Vorwärts-Übergang zu.
Importieren Sie die Prozesskonfigurationen.
witadmin importprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"
Bestätigen, dass Fehler zum Task Board hinzugefügt werden können
Öffnen Sie die Task Board-Seite, oder aktualisieren Sie diese, wenn sie bereits geöffnet ist.
Sie sollten in der Lage sein, Aufgabe oder Fehler als verknüpfte Arbeitsaufgabe für eine User Story auszuwählen.
.png "Taskboard mit Fehlerarbeitsaufgaben-Typ wurde hinzugefügt")
Um vorhandene Fehler zum Task Board hinzuzufügen, öffnen Sie eine User Story. In diesem Beispiel lautet der Titel der User Story Bug debt. Wählen Sie auf der Registerkarte ALLE LINKS die Fehler aus, die im Sprint enthalten sein sollen.
.png "Mehrere Fehler mit einer User Story verknüpfen")
Möglicherweise müssen Sie das Task Board aktualisieren, damit die Fehler angezeigt werden.
Tipp
Das Hinzufügen von Fehlern über die Registerkarte Implementierung ist nicht möglich, da diese auf Aufgaben beschränkt sind.Um das Hinzufügen von Fehlern über die Registerkarte Implementierung zu unterstützen, ändern Sie den FORM-Abschnitt des Arbeitsaufgabentyps der User Story so, dass der Filter für Fehler enthalten ist.
Ziehen Sie auf dem Task Board einen Fehler oder eine Aufgabe, um seinen bzw. ihren Status zu aktualisieren. Sie werden bemerken, dass Sie ein Element nicht zu einer Spalte ziehen können, deren Zustand ungültig ist. Beispielsweise können Sie einen Fehler nicht in den Zustand "Neu" ziehen, oder es ist auch nicht möglich, eine Aufgabe in einen aufgelösten Zustand zu ziehen. Wenn Sie diese Zustände verwenden möchten, fügen Sie sie zur Workflowdefinition für die entsprechende WIT-Definition hinzu.
Fragen und Antworten
F: Welche andere Tools kann ich für die Bearbeitung von XML-Definitionsdateien verwenden?
A: Mit dem witadmin-Befehlszeilentool können Sie Definitionsdateien importieren und exportieren, wie dies in diesem Thema beschrieben ist. Andere Tools, die Sie für diese Aufgabe verwenden können, sind der Prozess-Editor, der mit dem Download von TFS Power Tools oder TFS Team Project Manager erhältlich ist – ein auf CodePlex verfügbares Communityressourcenprojekt. Mit dem TFS Team Project Manager können Sie schnell XML-Definitionsdateien importieren, bearbeiten und exportieren, ohne die Befehlszeilenschnittstelle verwenden zu müssen.
F: Was passiert, wenn ich den Fehler-WIT aus "Anforderungskategorie" für mein Scrum-basiertes Teamprojekt entferne?
A: Vordefinierte und benutzerdefinierte Abfrage, die die "Anforderungskategorie" referenzieren, geben keine Ergebnisse mehr zurück, die Fehler-WITs umfassen. Sie möchten diese Abfragen möglicherweise aktualisieren.
Wenn Sie eine anforderungsbasierte Testauflistung erstellen, gehören die abgerufenen Arbeitsaufgaben zudem zu "Anforderungskategorie". Scrum-Teams, die Testpläne für Fehler erstellen möchten, müssen die Abfrage dahingehend aktualisieren, dass die Fehlerkategorie enthalten ist.
F: Was muss ich über Metazustandszuordnungen wissen?
A: Die Prozeduren beschreiben in Option B und Option C, wie Änderungen an Ihrem Teamprojekt vorgenommen werden, das auf den von TFS 2013 bereitgestellten Agile- und CMMI-Prozessvorlagen basiert. Das Zustandsmodell für die WITs, die Sie hinzufügen, muss an den Metazustandszuordnungen ausgerichtet sein, die in der "ProcessConfiguration"-Datei angegeben sind. Wenn das Zustandsmodell und die Metazustandszuordnungen nicht aneinander ausgerichtet sind, müssen Sie zusätzliche Definitionen erstellen, wie hier beschrieben.
F: Wie kann ich den Fehler auf der Aufgabenbacklog- und Boardseite für Scrum anzeigen?
A: Wenn das Teamprojekt auf der Scrum-Prozessvorlage beruht und Sie möchten, dass Fehler Peers mit Aufgaben und nicht Product Backlog Items sind, folgen Sie diesen Schritten:
Bearbeiten Sie die Fehlerarbeitsaufgaben-Definition: Fügen Sie den Abschnitten FIELDS und FORM die Felder "Aktivität" und "Verbleibende Arbeit" hinzu.
Bearbeiten Sie die Kategoriedefinition: Fügen Sie "Aufgabenkategorie" die Option "Fehler" hinzu, und entfernen Sie es von der Kategorie "Anforderungen".
Bearbeiten Sie die Prozesskonfigurationsdefinition: Ordnen Sie den Zustand "Aufgelöst" der Aufgabenkategorie hinzu, und entfernen Sie diese aus "Anforderungskategorie".
F: Warum werden nicht alle Fehler und Aufgaben, die ich einen Sprint zugewiesen habe, im Sprintbacklog angezeigt?
A: Es ist möglich, Aufgaben einer Iteration zuzuweisen, die nicht mit einem übergeordneten Backlogelement verknüpft sind. Diese Elemente werden in der erstellten Abfrage angezeigt, nicht aber im Task Board selbst. TFS führt die Abfrage durch und wendet dann einige Hintergrundaufgaben an, ehe die Task Board-Elemente angezeigt werden.
Diese drei Gründe können dazu führen, dass zur Aufgabenkategorie gehörende Arbeitsaufgaben weder in einem Sprintbacklog noch im Task Board angezeigt werden.
Die Aufgabe wurde nicht mit einem übergeordneten Backlogelement verknüpft. Es werden nur die Fehler und Aufgaben auf der Sprint-Backlogseite angezeigt, die Sie mit dem übergeordneten Backlogelement (Scrum), der User Story (Agile) oder Anforderung (CMMI) verknüpft wurden, dessen Iterationspfad auf den Sprint festgelegt wurde.
Die Aufgabe ist ein übergeordnetes Element einer anderen Aufgabe. Wenn Sie eine Aufgabenhierarchie erstellt haben, werden nur die untergeordneten Aufgaben unten in der Hierarchie angezeigt.
Das verknüpfte übergeordnete Element der Aufgabe entspricht einem Backlogelement, das für ein anderes Team definiert wurde. Oder der Bereichspfad des übergeordneten Backlogelements der Aufgabe weicht vom Bereichspfad der Aufgabe ab.
F: Wie werden die Felder "Backlog Priorität" und "Stapelrang" verwendet?
A: Die Backlog- und Board-Seiten verwenden die Felder "Backlog Priorität" (Scrum) und "Stapelrang" (Agile und CMMI) zum Verwalten der Sortierreihenfolge von Arbeitsaufgaben. Diese Felder sollten für alle WITs für ein Teamprojekt definiert werden. Sie müssen allerdings nicht im Arbeitsaufgabenformular enthalten sein. Dieses Felder müssen mit dem Feld übereinstimmen, das dem Order-Typ in der ProcessConfigurations-Definitionsdatei zugewiesen ist.