XML-Elementreferenz für die Prozesskonfiguration

Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Die Prozesskonfiguration definiert die Standardkonfigurations- und Funktionsfunktionen, auf die Ihre Teams mit den Agile-Tools des Webportals zugreifen können. Diese Tools umfassen den Produktrückstand, Sprint-Backlogs, Kanban-Board und Task Board und sind für jedes Team, das Sie zu Projekt hinzufügen, anpassbar.

Die Konfigurationselemente geben die Arbeitselementtypen (WITs), die Standardspalten, die von den Tools verwendeten Felder und andere Elemente an. Die Hauptkonfigurationen bestimmt, welche Elemente für die Portfolio-, Produkt- und Sprint-Backlogs angezeigt werden, indem sie die Abschnitte PortfolioBacklog, AnforderungBacklog und TaskBacklog der XML-Definitionsdatei für die Prozesskonfiguration definieren. Darüber hinaus definiert die Prozesskonfiguration die Workflowzuordnung der Status-zu-Zustandskategorie für alle WITs, die zuordnung erfordern.

Prozesskonfigurations-XML-Elemente

Eine Zusammenfassung der Möglichkeiten, die Sie über die Benutzeroberfläche konfigurieren können, finden Sie unter Anpassen der Arbeitsnachverfolgung, Hinzufügen von Teams und Konfigurieren ihrer Scrum- und Kanban-Tools.

Bereiche, die Sie über ProcessConfiguration anpassen können:

Hinweis

  1. Elemente, die mit einem Sternchen notiert wurden, legen einen Standardwert für das Projekt fest. Diese Elemente können für jedes Team über Teameinstellungen geändert werden.
  2. Unterstützt für gehostetes XML und für lokales XML für TFS 2015.2 oder höher.
  3. Unterstützt für gehostetes XML und für lokales XML für TFS 2017.2 oder höher.

Wichtig

Wenn Sie Ihr Projekt anpassen möchten, um benutzerdefinierte Arbeitsaufgabentypen hinzuzufügen, die in Ihren Backlogs oder Boards angezeigt werden sollen, oder fügen Sie benutzerdefinierte Portfolio-Backlogs hinzu, lesen Sie "Hinzufügen eines Arbeitselementtyps" zu einem Backlog und "Board " und "Hinzufügen von Portfolio-Backlogs".

Aktualisieren der Prozesskonfiguration

Hinweis

Um auf die neueste Version der Prozessvorlagen zuzugreifen, installieren Sie die neueste Version von TFS, und laden Sie die Vorlagen mithilfe des Prozessvorlagen-Managers herunter.

Um die Prozesskonfiguration für ein Projekt zu aktualisieren, exportieren Sie die XML-Definitionsdatei, bearbeiten Sie sie, und importieren Sie die Datei. Sie exportieren diese Dateien entweder, indem Sie einen Prozess exportieren oder die Prozesskonfigurationsdefinitionsdatei exportieren.

Exportieren der ProzessConfig-DefinitionsdateiBearbeiten der XML-DefinitionsdateiImportieren von WIT-DefinitionsdateiAktualisieren und Überprüfen von Änderungen

Tipp

Mit witadmin können Sie Definitionsdateien importieren und exportieren. Andere Tools, die Sie verwenden können, umfassen den Prozess-Editor (erfordert, dass Sie eine Version von Visual Studio installiert haben). Installieren Sie den Prozessvorlagen-Editor aus dem Visual Studio Marketplace.

Alternativ können Sie auch den TFS Team Project Manager verwenden, einen Open-Source-Client, der über GitHub verfügbar ist.

Tipp

Mit witadmin können Sie Definitionsdateien importieren und exportieren. Andere Tools, die Sie verwenden können, umfassen den Prozess-Editor (erfordert, dass Sie eine Version von Visual Studio installiert haben). Installieren Sie den TFS-Prozessvorlagen-Editor aus dem Visual Studio Marketplace. Sie können diese Version des Prozess-Editors verwenden, um die Formulare der alten Arbeitsaufgabe zu ändern. Sie können es nicht verwenden, um Formulare zu bearbeiten, die mit den neuen Webformularen verknüpft sind.

Alternativ können Sie auch den TFS Team Project Manager verwenden, einen Open-Source-Client, der über GitHub verfügbar ist.

Konfigurieren eines Backlogs

Sie können die folgenden Elemente für das Product Backlog, die Sprint-Backlogs und die Portfolio Backlogs anpassen:

  • Statuskategoriezuordnungen: Zuordnen von Workflowzuständen zu Statuskategorien (zuvor als Metastate bezeichnet). Diese Zuordnungen unterstützen die Anzeige aller Agile-Planungstools, einschließlich des Kanban-Boards und des Task Boards.

  • Schnell-Add-Bereich: Geben Sie die WITs- und Arbeitselementfelder an, die zum schnellen Hinzufügen von Elementen zum Backlog angezeigt werden.

    Um die Arbeitsaufgabentypen, die als Backlog Items oder Aufgaben betrachtet werden, zu ändern, fügen Sie sie der entsprechenden Kategorie hinzu. Ein Beispiel finden Sie unter "Hinzufügen von Fehlern zum Task Board" oder "Backlog".

  • Spaltenfelder: Definieren Sie die Standardfelder und die Spaltensequenz.

Sie konfigurieren Backlogs in den XML-Abschnitten, die im folgenden Beispiel angezeigt werden:

<PortfolioBacklogs>
      <PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic" workItemCountLimit="1000">
. . . 
      </PortfolioBacklog>
      <PortfolioBacklog category="Microsoft.FeatureCategory" pluralName="Features" singularName="Feature" parent="Microsoft.EpicCategory" workItemCountLimit="1000">
. . . 
      </PortfolioBacklog>
</PortfolioBacklogs>
<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="User Story" workItemCountLimit="1000">
. . . 
</RequirementBacklog>
<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="1000">
. . . 
</TaskBacklog>

Hinweis

Je nach dem Prozess, der Ihrer ProcessConfiguration-Datei zugeordnet ist – Agile, Scrum oder CMMI – entspricht Stories dies pluralNameRequirementCategory (Agile), Backlog Items (Scrum) oder Requirements (CMMI). Alle drei sind ähnlich: Sie beschreiben den Kundenwert für die Lieferung und die zu erledigende Arbeit.

Syntax für PortfolioBacklogs-Elemente

Element

Beschreibung

PortfolioBacklogs

Optional. Containerelement für Portfoliobacklogs.

PortfolioBacklog

Optional. Bis zu fünf Instanzen.

Containerelement, das die Statuskategoriezuordnungen, Standardspalten und den schnell hinzugefügten Bereich für einen Portfolio-Backlog definiert.

<PortfolioBacklog category="PortfolioCategory" parent="ParentCategory"  
pluralName="PluralName" singularName="SingleName" workItemCountLimit="MaximumLimit>  
<States> . . . </States>  
<Columns> . . . </Columns>  
<AddPanel> . . . </ AddPanel>  
</PortfolioBacklog >  

Weisen Sie den Attributen wie beschrieben Werte zu:

  • kategorie: Geben Sie den Namen einer Kategorie an, die Sie in der Kategoriendefinitionsdatei für das Projekt definiert haben, das die WITs enthält, die diesem Backlogtyp zugeordnet werden sollen.

  • parent: Geben Sie den Namen der Kategorie an, die den übergeordneten Portfolio-Backlog innerhalb der Hierarchie darstellt.

  • pluralName: Geben Sie die plurale Bezeichnung an, die beim Verweisen auf die WITs verwendet werden soll, die diesem Backlogtyp zugeordnet sind. Beispiel: Stories, Ziele, Initiativen oder Epen.

  • singularName: Geben Sie die singulare Bezeichnung an, die beim Verweisen auf die WITs verwendet werden soll, die diesem Backlogtyp zugeordnet sind. Beispiel: Story, Ziel, Initiative oder Epos.

  • workItemCountLimit: Geben Sie eine ganze Zahl an. Der Standard ist 1000. Backlogs und Boards schränken die Anzahl der angezeigten Elemente basierend auf diesem Grenzwert ein.

RequirementBacklog

Erforderlich. Nur eine Instanz.

Containerelement, das die Statuskategoriezuordnungen, Standardspalten und schnell hinzugefügten Bereich für den Produktrückstand definiert. Der Produktrückstand zeigt alle aktiven Elemente im Backlog des Teams an.

<RequirementBacklog category="RequirementCategory"  
pluralName="PluralName" singularName="SingleName"   
workItemCountLimit="MaximumLimit" >  
<States> . . . </States>
<Columns> . . . </Columns>
<AddPanel> . . . </ AddPanel>
</RequirementBacklog >

TaskBacklog

Erforderlich. Nur eine Instanz.

Containerelement, das verwendet wird, um das Layout der Sprint-Backlogs anzupassen.

<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" 
singularName="Task workItemCountLimit="MaximumLimit">
. . . 
</TaskBacklog > 

Hinweise zur Implementierung

  • Standardmäßig ist jeder Backlog auf insgesamt 1000 Arbeitsaufgaben beschränkt. Sie können diesen Grenzwert ändern, indem Sie einen Wert für das workItemCountLimit Attribut angeben.
  • Die dem CategoryName zugewiesenen Werte müssen einer Kategoriegruppe entsprechen, die für das Projekt definiert ist. Sie geben Kategoriegruppen in der Definitionsdatei für Kategorien an.
  • Sie verwenden Portfolio-Backlogs , um Ihren Backlog zu organisieren, das Rollup von Backlog-Elementen auf niedrigeren Ebenen anzuzeigen und den Fortschritt in mehreren Teams anzuzeigen. Neue und aktualisierte Projekte enthalten zwei Portfolio-Backlog-Ebenen: Features und Epics. Sie können bis zu drei zusätzliche Ebenen hinzufügen. Nur der Portfolio-Backlog auf oberster Ebene gibt keine übergeordnete Kategorie an.
  • Ihr Produktrückstand entspricht Ihrem Projektplan, der Roadmap für die Bereitstellung Ihres Teams. Arbeitselemente, deren WITs zur Anforderungskategorie gehören, werden aufgeführt. Um unterschiedliche WITs zu verwalten als die von Ihrem Standardprojekt bereitgestellten, können Sie WITs zur Kategorie "Anforderungen" hinzufügen und den Workflowstatus statuskategorien zuordnen.
  • Ihre Sprint- oder Iterations-Backlogs zeigen sowohl die Anforderungen an, die Sie als auch Ihr Team in einem bestimmten Sprintzyklus und den Aufgaben, die Sie mit diesen Anforderungen verknüpft haben. Mithilfe des untergeordneten Linktyps verknüpfen Sie Aufgaben mit Anforderungen. Da die WITs, die auf diesen Backlogs angezeigt werden, den gleichen Typen entsprechen, die auf dem Product Backlog angezeigt werden, geht es bei den Anpassungen für den Product Backlog hauptsächlich darum, die Funktionalität des Sprint-Backlogs zu definieren.

Zuordnen von WIT-Kategorie-Workflowzuständen zu Statuskategorien

Mehrere WITs erfordern, dass ihre Workflowzustände einer Statuskategorie zugeordnet werden. Workflowstatus definieren den Fortschritt einer Arbeitsaufgabe von der ersten Aktivierung oder Erstellung bis zum Abschluss. Die für das Scrum-Produkt-Backlog-Element definierten Zustände definieren beispielsweise einen Fortschritt von vier Zuständen, von "Neu", "Genehmigt", "Commit", " Fertig", und enthält auch einen fünften Zustand, der entfernt wurde, um einen Zustand zu berücksichtigen, der aus dem Backlog entfernt wurde, ohne implementiert zu werden. Workflowzustände sind dem value Attribut zugeordnet.

Statuskategorien bestimmen dagegen, wie die Agile-Planungstools jeden Workflowstatus behandeln. Die primären Statuskategorien, die vom Backlog und der Task Board verwendet werden, sind "Vorgeschlagen", "InProgress" und "Complete". Statuskategorien sind dem type Attribut zugeordnet. Weitere Informationen finden Sie unter Workflowstatus und Statuskategorien.

Indem sie jeden Workflowstatus einer Statuskategorie zuordnen, wissen die Hintergrundvorgänge, die zum Anzeigen des Backlogs ausgeführt wurden, und Taskboards wissen, wie der Status jeder Arbeitsaufgabe richtig interpretiert wird. Die folgenden Zuordnungen sind z. B. für den Product Backlog in Scrum definiert.

<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Backlog items" singularName="Backlog item">
      <States>
      <State value="New" type="Proposed" />
      <State value="Approved" type="Proposed" />
      <State value="Committed" type="InProgress" />
      <State value="Done" type="Complete" />
      </States>
 . . .
</RequirementBacklog>

Es gibt drei Gruppen von Statuskategorien: Agile, Bug und Feedback. In der folgenden Tabelle sind die Zuordnungsattribute und -werte beschrieben.

Syntax für Staatenelemente (WIT-Kategorie)

Element

Beschreibung

State

Erforderlich. Weist einen Workflowstatus einer Statuskategorie zu.

<State value="ValueName" type="TypeName" />

Gültige Werte für ValueName entsprechen einem Wert, der einem ZUSTAND innerhalb des WORKFLOW-Abschnitts dieser WITs zugewiesen ist, die der Kategoriegruppe zugewiesen sind.

Gültige Werte für TypeName entsprechen einem der folgenden aufgezählten Werte:

  • Agile: Kann für alle Arbeitselementtypen verwendet werden.
  • Vorgeschlagen: Gibt Arbeitselemente an, die noch nicht übernommen wurden oder noch nicht bearbeitet werden.
  • InProgress: Gibt Arbeitselemente an, die übernommen wurden oder aktiv bearbeitet werden.
  • Abgeschlossen: Gibt Arbeitselemente an, die implementiert wurden. Damit die Kanban-Tafel gültig ist, muss genau ein Workflowstatus der Kategorie "Vollständiger Zustand" zugeordnet werden. Wenn zusätzliche Workflowzustände dargestellt werden müssen, können sie der Kategorie "Aufgelöster Zustand" zugeordnet werden.
    Sobald ein Workflowstatus zu einem Zustand wechselt, der dem Vollständigen Metastate zugeordnet ist, fällt das zugeordnete Arbeitselement vom Produktrückgang ab. Sie wird jedoch weiterhin in der letzten Spalte auf der Kanban-Tafel aufgeführt sein.

    Arbeitselemente in einem Workflowstatus, die keiner der Statuskategorien zugeordnet sind, werden nicht im Backlog oder Board angezeigt.
  • Fehler: Wird nur für Arbeitsaufgabentypen verwendet, die in der Fehlerkategorie gruppiert werden. Zusätzlich zu den Agile-Statuskategorien enthält die Kategorie "Aufgelöster Zustand", die Fehler angibt, die behoben wurden.

Hinweis

Sie können nur der Kategorie "Aufgelöster Zustand" einen Workflowstatus zuweisen, der unter dem BugWorkItems-Element angegeben ist.

  • Feedback: Wird nur für Arbeitsaufgabentypen verwendet, die in der Feedbackanforderungs- oder Feedbackantwortkategorie gruppiert werden. Angefordert, empfangen, überprüft und abgelehnt.

Status

Gibt eine Auflistung von Statuselementen an, die WIT-Workflowzustände mit Statuskategorien zuordnen.

Erforderliches Element für die folgenden übergeordneten Elemente:

  • BugWorkItems
  • PortfolioBacklog
  • RequirementBacklog
  • TaskBacklog
  • TestPlanWorkItems
  • TestSuiteWorkItems
  • FeedbackRequestWorkItems
  • FeedbackResponseWorkItems

Festlegen von Standardspalten

Geben Sie an, welche Felder in jedem Backlog im Abschnitt "Spalten " angezeigt werden sollen. Änderungen, die Sie über das Dialogfeld "Spaltenoptionen" vornehmen, bleiben erhalten, bis Sie sie erneut ändern.

Standardspalten und -sequenz für Backlogseite

Dies ist die Standardkonfiguration, die von der Scrum-Prozessvorlage für den Produktbacklog definiert ist.

<Columns>
      <Column refname="Microsoft.VSTS.Common.Priority" width="400" />
      <Column refname="System.Title" width="400" />
      <Column refname="System.State" width="100" />
      <Column refname="Microsoft.VSTS.Scheduling.Effort" width="50" />
      <Column refname="System.IterationPath" width="200" />
</Columns>

Syntax für Spaltenelemente

Element

Beschreibung

Spalten

Gibt eine Auflistung von Column-Elementen an. Erforderliches Element für die Backlogelemente: PortfolioBacklog, RequirementBacklog und TaskBacklog.

Spalte

Gibt ein Feld an, das als Spalte auf einem Backlog angezeigt wird.

<Column refname="FieldReferenceName"  width="FieldWidth" />

Task Board-Spaltenüberschriften

Die auf dem Task Board angezeigten Spaltenüberschriften entsprechen den Workflowstatus, die dem standardmäßigen Arbeitsaufgabentyp zugewiesen sind, der wiederum der Aufgabenkategorie zugewiesen ist. Die Spaltenreihenfolge entspricht dem logischen Fortschritt der Workflowübergänge von links nach rechts. Zum Ändern des Spaltenlayouts ändern Sie den Workflow für den Arbeitsaufgabentyp, der der Aufgabenkategorie zugewiesen ist. Die für den Standardaufgabentyp in der Vorgangskategorie definierten Workflowzustände müssen einer gültigen Statuskategorie zugewiesen werden, wie in Kartenstatuskategorien für eine Kategorie von Arbeitsaufgabentypen beschrieben.

Anpassen des Bereichs zum schnellen Hinzufügen

Sie können jeden Bereich zum schnellen Hinzufügen Felder hinzufügen. Im folgenden Beispiel wird z. B. " Business Value " zum Produktrückmeldebereich hinzugefügt.

Backlogbereich mit hinzugefügtem Feld für Geschäftswert

Im Bereich werden nur Felder angezeigt, die im Abschnitt "FIELDS" der WIT-Definition für das ausgewählte WIT enthalten sind. Wenn Sie z. B. den Fehler WIT auswählen, wird nur "Titel" angezeigt, da der Geschäftswert nicht für Fehler definiert ist. Um dem Bereich weitere WIT hinzuzufügen, fügen Sie es der Kategorie "Anforderungen" hinzu, wie unter " Hinzufügen eines Arbeitselementtyps" zu einem Backlog und einer Tafel beschrieben.

Der folgende Code entspricht den Standardzuweisungen, die in Visual Studio Scrum und MSF für Agile-Prozessvorlagen definiert sind.

<AddPanel>
      <Fields>
      <Field refname="System.Title" />
      </Fields>
</AddPanel>

Syntax für AddPanel-Elemente

Element

Beschreibung

AddPanel

Containerelement, das zum Angeben der Benutzeroberfläche "Schnelles Hinzufügen" verwendet wird, werden die Felder innerhalb des Bereichs angezeigt, in dem neue Backlogelemente definiert sind.

Fields

Gibt eine Auflistung von Field-Elementen an.

Feld

Gibt ein Arbeitsaufgabenfeld an, das im Bereich für den Product Backlog angezeigt wird.

<Field refname="FieldReferenceName"/>

Das gleiche Feld sollte im Arbeitselementformular jedes Arbeitselementtyps angezeigt werden, der in der Kategorie für den Backlog enthalten ist.

Festlegen der Anzahl der Arbeitsaufgaben

Aus Leistungsgründen zeigt das Task Board maximal 1.000 Arbeitsaufgaben an. Wenn Sie das Task Board öffnen, werden alle Arbeitselemente in den Cache geladen. Durch Beschränkung der Anzahl von Arbeitselementen kann die Ladezeit verkürzt werden. Sie können diesen Grenzwert ändern, indem Sie einen Wert für das workItemCountLimit Attribut des TaskBacklog-Elements angeben.

Sie können beispielsweise den Grenzwert verringern, indem Sie Folgendes angeben workItemCountLimit="800":

<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" >
. . .
</TaskBacklog>

Zuordnen von Statuskategorien für toolspezifische Arbeitselementtypen

Statuskategoriezuordnungen werden für zusätzliche WIT-Kategorien definiert. Dazu zählen Zuordnungen für die Feedbackanforderungs- und -antwortkategorien für die Scrum-Prozessvorlage. Bei MSF Agile- und CMMI-Prozessvorlagen beinhaltet dies auch Zuordnungen für die Fehlerkategorie. (Scrum enthält Fehler in der Anforderungskategorie und definiert daher die Statuskategoriezuordnungen im Abschnitt "RequirementBacklog ".)

<FeedbackRequestWorkItems category="Microsoft.FeedbackRequestCategory" pluralName="Feedback Requests" singularName="Feedback Request">
      <States>
      <State value="Active" type="InProgress" />
      <State value="Closed" type="Complete" />
      </States>
</FeedbackRequestWorkItems>
<FeedbackResponseWorkItems category="Microsoft.FeedbackResponseCategory" pluralName="Feedback Responses" singularName="Feedback Response">
      <States>
      <State value="Active" type="InProgress" />
      <State value="Closed" type="Complete" />
      </States>
</FeedbackResponseWorkItems>

In der folgenden Tabelle werden die zusätzlichen Elemente beschrieben, die zum Definieren der Statuskategoriezuordnungen für toolspezifische Arbeitselementtypen verwendet werden. Informationen zum Zuweisen der tatsächlichen Statuswerte und -typen finden Sie in den Zuordnungsstatuskategorien für eine Kategorie von Arbeitselementtypen . Der CategoryName muss einer Kategorie entsprechen, die für das Projekt definiert ist.

Syntax für toolspezifische Statuskategoriezuordnungselemente

Element

Beschreibung

BugWorkItems

Optional. Containerelement, das die Statuskategoriezuordnungen für Arbeitsaufgabentypen definiert, die der Fehlerkategorie zugewiesen sind. Zusätzlich dazu, wie diese Zuordnungen in der Anzeige von Agile-Tools verwendet werden, steuern sie auch, wie das Feature "Meine Arbeit" im Team-Explorer den Fehlerstatus aktualisiert, während Entwickler Fehler mithilfe von "Meine Arbeit" verschieben. Weitere Informationen finden Sie unter "Abrufen des überprüften Codes (TFVC)".

<BugWorkItems category="CategoryName"  
pluralName="PluralName" singularName="SingleName">
<States>
. . .
</States>
</BugWorkItems>

FeedbackRequestWorkItems

Erforderlich. Wird nicht angepasst. Containerelement, das die Statuskategoriezuordnungen für Arbeitsaufgabentypen definiert, die der Feedbackanforderungskategorie zugewiesen sind.

<FeedbackResponseWorkItems category="CategoryName"  
pluralName="PluralName" singularName="SingleName">
<States>
. . .
</States>
</FeedbackRequestWorkItems>

FeedbackResponseWorkItems

Erforderlich. Wird nicht angepasst. Containerelement, das die Statuskategoriezuordnungen für Arbeitsaufgabentypen definiert, die der Feedbackantwortkategorie zugewiesen sind.

<FeedbackResponseWorkItems category="CategoryName"  
pluralName="PluralName" singularName="SingleName">
<States>
. . .
</States>
</FeedbackResponseWorkItems>```

TestPlanWorkItems

Nur erforderlich, wenn Sie den Workflowstatus für Testplan anpassen und Verbindungen mit dem Projekt von Versionen des Test-Managers unterstützen, die mit Visual Studio 2013.2 oder früheren Versionen installiert sind.

Containerelement, das die Statuskategoriezuordnungen für Arbeitsaufgabentypen definiert, die der Kategorie "Testplan" zugewiesen sind. Zum Beispiel:

<TestPlanWorkItems category="Microsoft.TestPlanCategory"  
pluralName="Test Plans" singularName="Test Plan">
<States>
<State type="InProgress" value="Design" />
<State type="InProgress" value="Testing" />
<State type="Complete" value="Signed Off" />
</States>
</TestPlanWorkItems>

TestSuiteWorkItems

Nur erforderlich, wenn Sie den Workflowstatus für Test Suite anpassen und Verbindungen mit dem Projekt von Versionen des Test-Managers unterstützen, die mit Visual Studio 2013.2 oder früheren Versionen installiert sind.

Containerelement, das die Statuskategoriezuordnungen für Arbeitsaufgabentypen definiert, die der Test Suite-Kategorie zugewiesen sind. Zum Beispiel:

<TestSuiteWorkItems  
category="Microsoft.TestSuiteCategory"  
pluralName="Test Suites" singularName="Test Suite">
<States>
<State type="Proposed" value="Authoring" />
<State type="InProgress" value="Testing" />
<State type="Complete" value="Completed" />
</States>
</TestSuiteWorkItems>

Hinweis

Featureverfügbarkeit: Um Statuskategorien für TestPlanWorkItems oder TestSuiteWorkItemszuzuordnen, müssen Sie den Server auf Anwendungsebene auf TFS 2013.3 oder höher aktualisieren. Anschließend können Sie den Workflowstatus von Testplänen und Testsammlungen anpassen. Weitere Informationen finden Sie unter "Testplan" und "Test Suite"-Features.

Zuweisen von Agile-Toolfeldern

Sie können die Arbeitselementfelder ändern, die beim Berechnen der Kapazität, der Burndown Diagramme, der Vorhersagen und der Geschwindigkeit verwendet werden. Alle Änderungen, die Sie an einer der Standardzuweisungen vornehmen, sollten auch an dem Arbeitsaufgabentyp vorgenommen werden, der zum Definieren und Erfassen der Informationen für diesen Wert verwendet wird.

Wenn Sie beispielsweise das refname zugewiesene Feld ändern, sollten Sie dasselbe Feld in die WIT-Definition einschließen, die der Vorgangskategorie zugewiesen type="Activity" ist, die die Aktivitätsinformationen erfasst.

<TypeFields>
    <TypeField refname="System.AreaPath" type="Team" />
    <TypeField refname="Microsoft.VSTS.Scheduling.RemainingWork" type="RemainingWork" format="format h" />
    <TypeField refname=" Microsoft.VSTS.Common.BacklogPriority" type="Order" />
    <TypeField refname="Microsoft.VSTS.Scheduling.Effort" type="Effort" />
    <TypeField refname="Microsoft.VSTS.Common.Activity" type="Activity" />
    <TypeField refname="Microsoft.VSTS.Feedback.ApplicationStartInformation" type="ApplicationStartInformation" />
    <TypeField refname="Microsoft.VSTS.Feedback.ApplicationLaunchInstructions" type="ApplicationLaunchInstructions" />
    <TypeField refname="Microsoft.VSTS.Feedback.ApplicationType" type="ApplicationType">
        <TypeFieldValues>
            <TypeFieldValue value="Web application" type="WebApp" />
            <TypeFieldValue value="Remote machine" type="RemoteMachine" />
            <TypeFieldValue value="Client application" type="ClientApp" />
        </TypeFieldValues>
    </TypeField>
</TypeFields>

Syntax für TypeFields-Elemente

Element

Beschreibung

TypeFields

Erforderlich. Gibt eine Auflistung von TypeField-Elementen an.

TypeField

Erforderlich. Gibt den Verweisnamen eines Felds an, dessen Wert einen Aktivitätstyp für einen Funktionsbereich unterstützt. Die angegebenen Felder sollten den Feldern entsprechen, die Sie innerhalb der Arbeitsaufgabentypen verwenden, mit denen die Funktionsinformationen erfasst werden.

<TypeField refname="FieldReferenceName"  
type="NameOfType" [format="{0} TimeUnitString"] / >

Geben Sie das Format nur an, wenn type="RemainingWork". Sie können eine beliebige Textzeichenfolge für die TimeUnitString angeben, die auf den Kapazitätsleisten im aktuellen Sprint-Backlog und im Task board angezeigt werden soll.

Für Agile-Tools:

  • Aktivität: Wird verwendet, um das Feature "Kapazität nach Aktivität" zu unterstützen. Geben Sie das gleiche Feld an, das im Arbeitsaufgabentyp verwendet wird, der der Aufgabenkategorie zugewiesen ist.

Hinweis

Die vom Kapazitätstool angezeigten Werte spiegeln eine Union aller Werte wider, die für das Feld in allen Projekten innerhalb der Projektsammlungsinstanz definiert sind. Um die Werte einzuschränken, die für Sprintkapazität angezeigt werden, müssen Sie daher die Werte in allen Projekten für das Feld übereinstimmen, dem das Feld zugewiesen type="Activity"ist.

  • Aufwand: Wird verwendet, um die Teamgeschwindigkeit zu berechnen. Geben Sie das gleiche Feld an, das im der Anforderungskategorie zugewiesenen Arbeitsaufgabentyp verwendet wird, mit dem der geschätzte Aufwand, die Storypunkte oder die Größe für den Arbeitsaufwand erfasst werden, der zur Implementierung eines Backlog Items erforderlich ist.

  • Reihenfolge: Wird verwendet, um die Sortierreihenfolge für Elemente in den Backlogs und Boards zu definieren. Das System führt Arbeitsaufgaben in aufsteigender Reihenfolge auf, wie durch das Feld für diesen Typ definiert.

Hinweis

Sie können Elemente verschieben, indem Sie sie in der Liste auf einem Backlog oder Board nach oben oder nach unten ziehen. Während Sie Elemente verschieben, aktualisiert ein Hintergrundprozess das Feld, das der type="Order"Datei zugewiesen ist.

  • RemainingWork: Wird verwendet, um verbleibende Arbeit und Burndowndiagramme zu berechnen. Geben Sie das gleiche Feld an, das im der Aufgabenkategorie zugewiesenen Arbeitsaufgabentyp verwendet wird, mit dem die Stunden, Tage oder andere Maßeinheiten erfasst werden, die zur Fertigstellung einer Aufgabe noch verbleiben.
    Der Wert, den Sie für das Format angeben, wird in den Sprint-Backlogs und Taskboards verwendet, wo verbleibende Arbeit gemeldet wird. Beispiel: Beim Angeben von Kapazität nach Aktivität oder Kapazität pro Teammitglied oder neben der Spaltenüberschrift für die Aufgabenzustände im Task Board.
    Geben Sie für TimeUnitString eine beliebige Textzeichenfolge an, die Sie verwenden möchten, um den Zeitwert wie Stunden oder Tage widerzuspiegeln.
    Die folgenden Werte sind z. B. gültig:
    format="{0} h"
    format="{0} hours"
    format="hours {0}"
    format="time {0}"
  • Team: Wird verwendet, um die Backlogs einem Team zuzuordnen. Der Standardwert lautet System.AreaPath. Um Teams von Bereichspfaden zu entkoppeln, können Sie ein anderes Feld angeben, wie in " Teamfelder verwenden" anstelle von Bereichspfaden zur Unterstützung von Teams beschrieben.
    Für das Feedbackanforderungsformular:

Hinweis

Sie sollten die Standardzuweisungen für die folgenden TypeField-Elemente nicht ändern müssen. Diese Zuweisungen entsprechen den Feldern, die zum Erfassen der entsprechenden Informationen im Arbeitsaufgabentyp verwendet werden, der der Feedbackanforderungskategorie zugewiesen ist.

  • ApplicationStartInformation: Wird verwendet, um den Pfad zu erfassen, um die Anwendung auszuführen.

  • ApplicationLaunchInstructions: Wird zum Erfassen von Startanweisungen verwendet.

  • ApplicationType: Wird verwendet, um den Anwendungstyp zu erfassen. Die aufgeführten Typen entsprechen den zulässigen Werten, die in der Definition des Arbeitsaufgabentyps für die Feedbackanforderung angegeben sind.

TypeFieldValues

Erforderlich für typeFieldValue , wenn type="ApplicationType". Gibt eine Auflistung von TypeFieldValue-Elementen an, die im Feedbackanforderungsformular verwendet werden.

TypeFieldValue

Erforderlich. Wird nicht angepasst. Gibt den Namen eines Anwendungstyps an, der im Feedbackanforderungsformular angezeigt wird.

<TypeFieldValue value="ApplicationTypeName" type="TypeApp"/>

Die Standardzuweisungen entsprechen den zulässigen Werten, die in der Typdefinition für das Feedbackanforderungsformular angegeben sind.

<TypeFieldValues>
<TypeFieldValue value="Web application" type="WebApp" />
<TypeFieldValue value="Remote machine" type="RemoteMachine" />
<TypeFieldValue value="Client application" type="ClientApp" />
</TypeFieldValues>

Hinweise zur Implementierung

  • Wenn Sie ein Feld im Abschnitt "TypeFields " ändern, sollten Sie die entsprechende Änderung in der WIT-Definition vornehmen. Wenn Sie beispielsweise die Felder ändern, die der Erfassung von Arbeitsaufwand zugewiesen sind, sollten Sie dieselbe Änderung in den WIT-Definitionen für das Produktrücklogelement und -fehler (für Scrum) vornehmen.

  • Sie können den Verweisnamen für ein Feld mithilfe dieses Indexes nachschlagen.

Festlegen von Arbeitstagen

Arbeitsfreie Tage werden aus Berechnungen entfernt, die vom Kapazitätsplanungstool und Burndowndiagrammen vorgenommen werden. Standardprozesse – Agile, Scrum oder CMMI – geben Samstag und Sonntag als Arbeitstage an. Nachdem Sie ein Projekt erstellt haben, kann jedes Team seine spezifischen Arbeitstage festlegen.

<Weekends>
   <DayOfWeek>Saturday</DayOfWeek>
   <DayOfWeek>Sunday</DayOfWeek>
</Weekends>

Syntax für Weekends-Elemente

Element

Beschreibung

DayOfWeek

Erforderliches untergeordnetes Element des Weekends-Elements .

Gibt einen Wochentag an, der einem arbeitsfreien Tag entspricht.

<DayOfWeek>NameOfADay</DayOfWeek>

Gültige Namen entsprechen den englischen Tagen der Woche: Sonntag, Montag, Dienstag, Mittwoch, Donnerstag, Freitag und Samstag.

Hinweis

Sie müssen den Wochentag in Englisch angeben, unabhängig davon, in welcher Sprache der lokale TFS installiert ist.

Wochenenden

Optional. Containerelement, das zum Angeben der arbeitsfreien Tage verwendet wird.

Geben Sie arbeitsfreie Tage an, wenn diese bei der Berechnung der Kapazitätsdiagramme und Burndown Diagramme berücksichtigt werden sollen.

Ändern der Farbe für einen Arbeitselementtyp

Auf einen Blick können Sie WITs unterscheiden, wenn Sie ein Abfrageergebnis oder Backlog basierend auf der Farbe und dem Symbol anzeigen, das dem WIT zugewiesen ist. Das System wendet die Farbe an, die für den Arbeitselementtyp definiert ist, auf das für das WIT angegebene Symbol.

Abfrageergebnisse mit Wit-Farbe, Symbol und Zustandsfarbe

Die Scrum-Prozessvorlage definiert die folgenden Farbzuweisungen. Ähnliche Zuweisungen werden für die Agile- und CMMI-Vorlagen vorgenommen.

<WorkItemColors>
      <WorkItemColor primary="FF009CCC" secondary="FFD6ECF2" name="ProductBacklogItem" />
      <WorkItemColor primary="FF773B93" secondary="FFEEE2F2" name="Feature" />
   <WorkItemColor primary="FFFF7B00" secondary="FFFFD7B5" name="Epic" />
      <WorkItemColor primary="FFF2CB1D" secondary="FFF6F5D2" name="Task" />
      <WorkItemColor primary="FFCC293D" secondary="FFFAEAE5" name="Bug" />
      <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Code Review Request" />
      <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Code Review Response" />
      <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Feedback Request" />
      <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Feedback Response" />
      <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Impediment" />
      <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Shared Step" />
      <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Test Case" />
   <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Test Plan" />
   <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Test Suite" />
   <WorkItemColor primary="FFFF9D00" secondary="FFFCEECF" name="Shared Parameter" />
</WorkItemColors>

Syntax für WorkItemColors-Elemente

Element

Beschreibung

WorkItemColors

Optional. Containerelement zum Angeben der Farben für Arbeitselementtypen.

WorkItemColor

Gibt die Farben an, die zum Anzeigen eines Arbeitsaufgabentyps im Webportal verwendet werden. Die primäre Farbe wird in Listenanzeigen verwendet. Die sekundäre Farbe wird nicht mehr verwiesen, sie muss jedoch für die Syntax angegeben werden, die überprüft werden soll.

Wenn Sie die Farbe angeben, präfixen Sie immer den sechsstelligen Hex-Farbcode mit FF , der angibt, dass die Farbe vollständig sichtbar sein sollte.

<WorkItemColor primary="HexColorCode" secondary="HexColorCode"  
name="witName" />

Angeben von Eigenschaften und Verhaltensweisen

Die ersten beiden Eigenschaften, die Sie festlegen können, BugsBehavior und HiddenBacklogs legen Sie den Standardwert für ein Projekt fest. Jedes Team kann das Verhalten jedoch über die Teameinstellungen ändern. Die dritte Eigenschaft StateColors definiert die Farben, die den Workflowzuständen für alle WITs zugeordnet sind. Die von Ihnen festgelegten Werte werden für alle Teams in einem Projekt verwendet.

Beispielkonfiguration Properties :

 <Properties>  
      <Property name="BugsBehavior" value="AsTasks" />  
      <Property name="HiddenBacklogs" value="Microsoft.EpicCategory" />  
      <Property name="StateColors" value="Active=#FF00FF00,Resolved=#FFFF0000" />
      <Property name="WorkItemTypeIcons" value="Epic=Icon_Crown,Feature=Icon_Trophy,User Story=icon_book,
        Task=icon_clipboard,Bug=icon_insect,Issue=icon_traffic_cone,
        Test Plan=icon_test_plan,Test Suite=icon_test_suite,Test Case=icon_test_case,Shared Steps=icon_test_step,
        Shared Parameter=icon_test_parameter" />  
  </Properties>  

Die BugsBehavior Eigenschaft bestimmt, wie Fehler und andere WITs in der Fehlerkategorie definiert sind, auf Backlogs und Boards angezeigt werden. Grundsätzlich können Sie konfigurieren, ob Fehler als Anforderungen oder als Aufgaben behandelt werden, oder dass diese nicht auf Backlogs und Boards angezeigt werden. Ausführliche Informationen finden Sie unter Anzeigen von Fehlern auf Backlogs und Board.

Die HiddenBacklogs Eigenschaft bestimmt, welche Backlogs/Portfolio-Backlogs standardmäßig angezeigt werden. Der Standard besteht darin, nur den Produktbacklog und einen Portfolio-Backlog anzuzeigen, den Features-Backlog. Teams kann bestimmen, ob sie den Epics-Backlog aktivieren oder andere Änderungen vornehmen möchten. Ausführliche Informationen finden Sie unter "Organisieren Ihres Backlogs", aktivieren Sie Backlogebenen für Ihr Team.

Syntax für Eigenschaftenelemente

Element

Beschreibung

Eigenschaften

Optional. Containerelement zum Angeben von Standardeigenschaften und Verhaltensweisen.

Eigenschaft

Gibt die Standardzuweisung an neue Teams oder vorhandene Teams beim Aktualisieren eines Projekts mit neuen Features an. Teams können das gewünschte Verhalten in ihren Teameinstellungen konfigurieren.

Gültige Eigenschaftennamen sind:

  • BugsBehavior legt die Standardeinstellung für die Fehler anzeigen auf Backlogs und Board fest. Zulässige Werte entsprechen:
  • AsRequirements – Fehler werden auf Backlogs und Boards ähnlich wie Anforderungen (Standard für Scrum-Prozess) angezeigt.
  • AsTasks – Fehler werden auf Backlogs und Boards ähnlich wie Aufgaben angezeigt (Standard für Agile- und CMMI-Prozesse)
  • Deaktiviert – Fehler werden nicht auf Backlogs oder Boards angezeigt.
  • HiddenBacklogs gibt den Backlog an, der standardmäßig inaktiv ist.
  • StateColors legt die Farbwerte für Workflowzustände fest. (Erfordert TFS 2017 oder höher Version)
    Der Wert für die Eigenschaft ist eine durch Komma getrennte Liste von Statusnamen und Hexfarben. Präfix des sechsstelligen Hex-Farbcodes mit FF, der angibt, dass die Farbe vollständig sichtbar sein sollte.
    <Property name="StateColors" value="stateName1=color1, stateName2=color2,..." />

Hinweis

Featureverfügbarkeit: Sie können Workflowstatusfarben angeben, wenn Sie gehostete XML verwenden oder für lokale XML-Dateien auf TFS 2015.2 oder höher aktualisiert haben.
Weitere Details finden Sie im nächsten Abschnitt: Angeben von Workflowstatusfarben.

  • WorkItemTypeIcons definiert das Symbol, das für jeden Arbeitselementtyp angezeigt werden soll. Das Symbol wird in Listen von Arbeitselementen und in Arbeitselementformularen angezeigt. Der Standardeintrag für den Agile-Prozess ist wie dargestellt. Sie können nur ein Symbol aus der unterstützten Liste der Symbole angeben.

<Property name="WorkItemTypeIcons" 
value="Epic=Icon_Crown,Feature=Icon_Trophy,  
User Story=icon_book,Task=icon_clipboard,Bug=icon_insect,  
Issue=icon_traffic_cone,Test Plan=icon_test_plan,Test Suite=icon_test_suite,  
Test Case=icon_test_beaker,Shared Steps=icon_test_step,Shared Parameter=icon_test_parameter" />

Hinweis

Featureverfügbarkeit: Sie können die Symbole anpassen, die für Arbeitselementtypen verwendet werden, wenn Sie gehostete XML verwenden oder für lokale XML-Dateien auf TFS 2017.2 oder höher aktualisiert haben.

Angeben von Workflowstatusfarben

Hinweis

Featureverfügbarkeit: Um Workflowstatusfarben anzugeben, müssen Sie auf TFS 2015.2 oder höher aktualisieren.

Die Farbe, die Sie ihrem Arbeitselementstatus zuordnen, wird im gesamten Produkt angezeigt. Dies umfasst die folgenden Bereiche:

Hier zeigen wir, wie sie im Arbeitselementformular angezeigt wird:

Fehler des Arbeitselement-Formularkopfs, Statusfarbe angezeigt

Hinweis

Es werden keine Farben im Clientarbeitselementformular oder innerhalb des alten Links-Steuerelements im Clientformular angezeigt.

Details:

  • Sie müssen die Farbe als achtstellige Hexadezimalwert angeben, ähnlich wie für die für eine WIT definierte Farbe
  • Um Farben hinzuzufügen oder zu bearbeiten, importieren Sie einfach Ihre Prozesskonfiguration mit der aktualisierten Eigenschaft
  • Zustandsfarben werden durch Namen in allen Arbeitselementtypen definiert, d. h., es gibt keine Möglichkeit, eine Farbe für die Benutzergeschichte und eine andere Farbe für Fehler zu haben.
  • Nicht zugeordnete Farben werden zur Laufzeit basierend auf ihrer Metastatuszuordnung standardmäßig festgelegt.
  • Zustände ohne Farbe definiert, und keine Metastatuszuordnung zeigt einen leeren Kreis an.

Angeben von WIT-Symbolen

Hinweis

Featureverfügbarkeit: Sie können die Symbole anpassen, die für Arbeitselementtypen verwendet werden, wenn Sie gehostete XML verwenden oder für lokale XML-Dateien auf TFS 2017.2 oder höher aktualisiert haben.

Die unterstützte Gruppe von Symbolen, die Sie für einen Arbeitselementtyp angeben können, werden unten angezeigt.

icon_airplane, icon_asterisk, icon_book, icon_car, icon_chart, icon_chat_bubble, icon_check_box, icon_clipboard, icon_code_response, icon_code_review icon_palette, icon_crown, icon_database_storage, icon_diamond, icon_flame, icon_gavel, icon_gear, icon_gift, icon_government, icon_headphone icon_insect, icon_key, icon_list, icon_megaphone, icon_paint_brush,  icon_parachute, icon_response, icon_review, icon_ribbon, icon_sticky_note icon_star, icon_test_beaker, icon_test_parameter, icon_test_plan icon_test_step, icon_test_suite, icon_traffic_cone, icon_trophy

Hinweis

Symbole, die mit einem Stern gekennzeichnet sind, werden auf Azure DevOps Services und TFS 2017.3 und höherer Versionen unterstützt.

Das System wendet die für den Arbeitselementtyp definierte Farbe auf das Symbol an. Farben und Symbole werden im Webportal angezeigt, in dem immer Arbeitselemente angezeigt werden. Dazu gehören unter "Verwandte Arbeiten " in PRs, Liste der Links , Projektseiten sowie Arbeitsrückgänge , Boards, Abfragen und Pläne.

Hier sehen Sie beispielsweise eine Listenansicht...

Webportal, Liste der Arbeitselemente mit Symbolen

und hier wird das Symbol im Arbeitselementformular angezeigt.

Fehler beim Formularkopf des Arbeitselements, Symbol

Erfahren Sie mehr über das Webarbeitselementformular und wie Sie sie aus diesen zusätzlichen Themen anpassen:

Wenn Sie ein benutzerdefiniertes WIT hinzugefügt haben und dies entweder dem Backlog oder dem Taskboard hinzufügen möchten, können Sie diese hinzufügen. Sie können sie nur nicht an beiden Stellen anzeigen. Erfahren Sie, wie Sie Arbeitselementtypen zu Backlogs und Boards hinzufügen.