XML-Elementreferenz für die Prozesskonfiguration

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

Die Prozesskonfiguration definiert die Standardkonfiguration und die Funktionsfunktionen, auf die Ihre Teams über die Agile-Tools des Webportals zugreifen können. Diese Tools umfassen das Product Backlog, Sprint Backlogs, Kanban-Board und Taskboard und können für jedes Team, das Sie dem Projekt hinzufügen, angepasst werden.

Die Konfigurationselemente geben die Arbeitselementtypen (WITs), die Standardspalten, die von den Tools verwendeten Felder und andere Elemente an. Die Standard vorgenommenen Konfigurationen bestimmen, welche Elemente für die Portfolio-, Produkt- und Sprint-Backlogs angezeigt werden, indem die Abschnitte PortfolioBacklog, RequirementBacklog und TaskBacklog der XML-Definitionsdatei für die Prozesskonfiguration definiert werden. Darüber hinaus definiert die Prozesskonfiguration die Workflowzuordnung der Status-zu-Zustand-Kategorie für alle WITs, die eine Zuordnung erfordern.

Prozesskonfigurations-XML-Elemente

Eine Zusammenfassung dessen, was 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. Mit einem Sternchen notierte Elemente 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 gehostete XML und für lokale XML für TFS 2015.2 oder höher.
  3. Unterstützt für gehostete XML und für lokale XML für TFS 2017.2 oder höher.

Wichtig

Wenn Sie Ihr Projekt anpassen möchten, um benutzerdefinierte Arbeitselementtypen hinzuzufügen, die in Ihren Backlogs oder Boards angezeigt werden, oder benutzerdefinierte Portfoliobacklogs hinzufügen möchten, lesen Sie Hinzufügen eines Arbeitselementtyps zu einem Backlog und einem Board und Hinzufügen von Portfoliobacklogs.

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, und importieren Sie dann die Datei. Sie exportieren diese Dateien entweder, indem Sie einen Prozess oderdie Prozesskonfigurationsdefinitionsdatei exportieren.

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

Tipp

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

Tipp

Mit witadmin können Sie Definitionsdateien importieren und exportieren. Weitere Tools, die Sie verwenden können, sind der 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 Arbeitselementformulare im alten Stil zu ändern. Sie können damit keine Formulare bearbeiten, die den neuen Webformularen zugeordnet sind.

Alternativ können Sie 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: Ordnen Sie Workflowzustände Zustandskategorien zu (zuvor als Metastate bezeichnet). Diese Zuordnungen unterstützen die Anzeige aller Agile-Planungstools, einschließlich des Kanban-Boards und des Task Boards.

  • Bereich "Schnell hinzufügen": Geben Sie die FELDER "WITs" und "Arbeitselemente" 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 Taskboard 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

Abhängig vom Prozess, der Ihrer ProcessConfiguration-Datei zugeordnet ist (Agile, Scrum oder CMMI), entspricht Stories der RequirementCategorypluralName für (Agile), Backlog Items (Scrum) oder Requirements (CMMI). Alle drei sind ähnlich: Sie beschreiben den kundenseitigen Wert 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 Bereich "Schnell hinzufügen" für ein Portfoliobacklog 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:

  • category: 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 das übergeordnete Portfoliobacklog innerhalb der Hierarchie darstellt.

  • pluralName: Geben Sie die Pluralbezeichnung an, die verwendet werden soll, wenn auf die WITs verwiesen wird, die diesem Backlogtyp zugeordnet sind. Beispiel: Stories, Ziele, Initiativen oder Epen.

  • singularName: Geben Sie die singulare Bezeichnung an, die verwendet werden soll, wenn auf die WITs verwiesen wird, 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 Statuskategorienzuordnungen, Standardspalten und den Bereich zum Schnellen Hinzufügen für das Produktbacklog definiert. Im Product Backlog werden alle aktiven Elemente im Backlog des Teams angezeigt.

<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 für das Projekt definierten Kategoriegruppe entsprechen. Sie geben Kategoriegruppen in der Definitionsdatei für Kategorien an.
  • Sie verwenden Portfoliobacklogs , um Ihren Backlog zu organisieren, das Rollup von Backlogelementen auf niedrigeren Ebenen anzuzeigen und den Fortschritt in mehreren Teams anzuzeigen. Neue und aktualisierte Projekte enthalten zwei Portfoliobacklogebenen: Features und Epics. Sie können bis zu drei zusätzliche Ebenen hinzufügen. Nur im Portfoliobacklog der obersten Ebene wird keine übergeordnete Kategorie angegeben.
  • Ihr Produktbacklog entspricht Ihrem Projektplan, der Roadmap für das, was Ihr Team zu liefern plant. Arbeitselemente, deren WITs zur Anforderungskategorie gehören, werden aufgeführt. Um andere WITs als die von Ihrem Standardprojekt bereitgestellten zu verwalten, können Sie der Anforderungskategorie WITs hinzufügen und die Workflowzustände Zustandskategorien zuordnen.
  • Ihre Sprint- oder Iterationsbacklogs zeigen sowohl die Anforderungen an, die Sie und Ihr Team in einem bestimmten Sprintzyklus übernommen haben, als auch die 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 Zustandskategorien

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

Zustandskategorien hingegen bestimmen, wie die agilen Planungstools jeden Workflowstatus behandeln. Die primären Zustandskategorien, die vom Backlog und der Taskboard verwendet werden, sind Vorgeschlagen, InProgress und Vollständig. Zustandskategorien sind dem type Attribut zugeordnet. Weitere Informationen finden Sie unter Workflowstatus und Statuskategorien.

Durch das Zuordnen jedes Workflowzustands zu einer Zustandskategorie wissen die Hintergrundvorgänge, die zum Anzeigen des Backlogs ausgeführt werden, und Taskboards, wie die status der einzelnen Arbeitselemente richtig interpretiert werden. 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, Fehler und Feedback. In der folgenden Tabelle sind die Zuordnungsattribute und -werte beschrieben.

Syntax für States-Elemente (WIT-Kategorie)

Element

Beschreibung

State

Erforderlich. Weist einer Statuskategorie einen Workflowstatus zu.

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

Gültige Werte für ValueName entsprechen einem Wert, der einem STATE im Workflow-Abschnitt der 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 neu sind, noch nicht committet wurden oder noch nicht bearbeitet werden.
  • InProgress: Gibt Arbeitselemente an, an denen ein Commit ausgeführt wurde oder aktiv bearbeitet wird.
  • Abgeschlossen: Gibt Arbeitselemente an, die implementiert wurden. Damit das Kanban-Board gültig ist, muss der Statuskategorie Vollständig genau ein Workflowzustand zugeordnet werden. Wenn zusätzliche Workflowzustände dargestellt werden müssen, können sie der Statuskategorie Aufgelöst zugeordnet werden.
    Sobald ein Workflowzustand in einen Zustand übergeht, der dem Metastate Complete zugeordnet ist, fällt das zugeordnete Arbeitselement aus dem Produktbacklog. Es wird jedoch weiterhin in der letzten Spalte auf dem Kanban-Board aufgeführt.

    Arbeitselemente in einem Workflowzustand, 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 Statuskategorie Aufgelöst , die auf behobene Fehler hinweist.

Hinweis

Sie können die Statuskategorie Aufgelöst nur einem Workflowzustand 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 State-Elementen an, die WIT-Workflowzuständen Zustandskategorien 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 für die einzelnen Backlogs 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 das Produktbacklog definiert wird.

<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 Columns-Elemente

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 workflow-Zustände, die für den Standardaufgabentyp in der Vorgangskategorie definiert sind, müssen einer gültigen Zustandskategorie zugewiesen werden, wie unter Zuordnungsstatuskategorien für eine Kategorie von Arbeitselementtypen beschrieben.

Anpassen des Bereichs zum schnellen Hinzufügen

Sie können jeden Bereich zum schnellen Hinzufügen Felder hinzufügen. Im folgenden Beispiel wird beispielsweise dem Bereich "Product Backlog" der Geschäftswert 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. die Fehler-WIT auswählen, wird nur Titel angezeigt, da der Geschäftswert nicht für Fehler definiert ist. Um dem Bereich einen weiteren WIT hinzuzufügen, fügen Sie es der Anforderungskategorie hinzu, wie unter Hinzufügen eines Arbeitselementtyps zu einem Backlog und Board 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 verwendet wird, um die Benutzeroberfläche "Schnelles Hinzufügen" anzugeben, die Felder, die innerhalb des Bereichs angezeigt werden sollen, in dem neue Backlogelemente definiert werden.

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 Taskboardanzahl von Arbeitselementen

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 den Grenzwert beispielsweise verringern, indem Sie angeben workItemCountLimit="800":

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

Zuordnen von Zustandskategorien 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 Zustandskategorienzuordnungen 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 Statuskategorienzuordnungen für toolspezifische Arbeitselementtypen verwendet werden. Informationen zum Zuweisen der tatsächlichen Zustandswerte und -typen finden Sie unter Zuordnungsstatuskategorien für eine Kategorie von Arbeitselementtypen . Der CategoryName muss einer kategorie entsprechen, die für das Projekt definiert ist.

Syntax für toolspezifische Zustandskategorienzuordnungselemente

Element

Beschreibung

BugWorkItems

Optional. Containerelement, das die Statuskategoriezuordnungen für Arbeitselementtypen definiert, die der Fehlerkategorie zugewiesen sind. Zusätzlich zur Verwendung dieser Zuordnungen bei der Anzeige von Agile-Tools steuern sie auch, wie das Feature "Meine Arbeit" in Team Explorer den Fehlerstatus aktualisiert, wenn Entwickler Fehler mithilfe von "Meine Arbeit" verschieben. Weitere Informationen finden Sie unter Get your code review (TFVC).

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

FeedbackRequestWorkItems

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

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

FeedbackResponseWorkItems

Erforderlich. Wird nicht angepasst. Containerelement, das die Statuskategorienzuordnungen für Arbeitselementtypen 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 aus Versionen von Test Manager unterstützen, die mit Visual Studio 2013.2 oder früheren Versionen installiert sind.

Containerelement, das die Statuskategorienzuordnungen für Arbeitselementtypen definiert, die der Testplankategorie zugewiesen sind. 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 aus Versionen von Test Manager unterstützen, die mit Visual Studio 2013.2 oder früheren Versionen installiert sind.

Containerelement, das die Statuskategoriezuordnungen für Arbeitselementtypen definiert, die der Test Suite-Kategorie zugewiesen sind. 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 Zustandskategorien für TestPlanWorkItems oder TestSuiteWorkItemszuordnen zu können, müssen Sie für Ihren Anwendungsebenenserver ein Upgrade auf TFS 2013.3 oder höher durchführen. 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 auf type="Activity" ändern, sollten Sie dasselbe Feld in die WIT-Definition einschließen, die der Aufgabenkategorie zugewiesen 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 den TimeUnitString angeben, der auf den Kapazitätsleisten des aktuellen Sprintbacklogs und auf der Taskboard angezeigt werden soll.

Für Agile-Tools:

  • Aktivität: Wird verwendet, um das Feature "Capacity-by-Activity" 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 Projektsammlung instance definiert sind. Um die Werte einzuschränken, die für sprint Capacity angezeigt werden, müssen Sie daher sicherstellen, dass die Werte in allen Projekten für das Feld übereinstimmen, das zugewiesen ist type="Activity".

  • 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 auf 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. Beim Verschieben von Elementen aktualisiert ein Hintergrundprozess das Feld, das dem type="Order"zugewiesen ist.

  • RemainingWork: Wird verwendet, um verbleibende Arbeits- 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 widerzuspiegeln, z. B. Stunden oder Tage.
    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 unter Verwenden von Teamfeldern anstelle von Bereichspfaden für Supportteams 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 zum Ausführen der Anwendung zu erfassen.

  • 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 die gleiche Änderung in den WIT-Definitionen für das Produktbacklogelement und den Fehler (für Scrum) vornehmen.

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

Festlegen von Arbeitsfreien Tagen

Arbeitsfreie Tage werden aus Berechnungen des Kapazitätsplanungstools und Burndowndiagrammen entfernt. Standardprozesse – Agile, Scrum oder CMMI – geben Samstag und Sonntag als arbeitsfreie Tage an.

<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 Wochentagen: 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 anzeigen, basierend auf der Farbe und dem Symbol, die dem WIT zugewiesen sind. Das System wendet die für den Arbeitselementtyp definierte Farbe auf das für den WIT angegebene Symbol an.

Abfrageergebnisse mit 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ärfarbe wird in Listenanzeigen verwendet. Auf die sekundäre Farbe wird nicht mehr verwiesen. Sie müssen sie jedoch angeben, damit die Syntax überprüft werden kann.

Wenn Sie die Farbe angeben, stellen Sie dem sechsstelligen Hex-Farbcode immer FF voran, was angibt, dass die Farbe vollständig sichtbar sein soll.

<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 den Standardwert für ein Projekt fest. Jedes Team kann das Verhalten jedoch über seine 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 in der Fehlerkategorie definierte WITs in 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 in Backlogs und Board.

Die HiddenBacklogs -Eigenschaft bestimmt, welche Backlogs/Portfoliobacklogs standardmäßig angezeigt werden. Standardmäßig werden nur das Produktbacklog und eine Ebene des Portfoliobacklogs angezeigt, das Featurebacklog. Teams können bestimmen, ob sie das Epics-Backlog aktivieren oder andere Änderungen vornehmen möchten. Ausführliche Informationen finden Sie unter Organisieren Ihres Backlogs, Aktivieren von Backlogstufen 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 an, wenn ein Projekt mit neuen Features aktualisiert wird. Teams können das gewünschte Verhalten in ihren Teameinstellungen konfigurieren.

Gültige Eigenschaftsnamen sind:

  • BugsBehavior legt den Standardwert für die Show bugs on backlogs and board (Fehler auf Backlogs und Board anzeigen) fest. Zulässige Werte entsprechen:
  • AsRequirements – Fehler werden in Backlogs und Boards ähnlich den Anforderungen angezeigt (Standard für den Scrum-Prozess).
  • AsTasks – Fehler werden in Backlogs und Boards angezeigt, die Aufgaben ähneln (Standard für Agile- und CMMI-Prozesse)
  • Aus – Fehler werden nicht in Backlogs oder Boards angezeigt.
  • HiddenBacklogs gibt das Backlog an, das standardmäßig inaktiv ist.
  • StateColors legt die Farbwerte für Workflowzustände fest. (Erfordert TFS 2017 oder höher)
    Der Wert für die Eigenschaft ist eine durch Trennzeichen getrennte Liste von Zustandsnamen und Sechskantfarben. Präfixen Sie den sechsstelligen Hex-Farbcode mit FF, der angibt, dass die Farbe vollständig sichtbar sein soll.
    <Property name="StateColors" value="stateName1=color1, stateName2=color2,..." />

Hinweis

Featureverfügbarkeit: Sie können Workflowzustandsfarben angeben, wenn Sie gehostete XML verwenden oder für lokale XML ein Upgrade auf TFS 2015.2 oder höher durchgeführt haben.
Weitere Details finden Sie im nächsten Abschnitt Angeben von Workflowzustandsfarben.

  • WorkItemTypeIcons definiert das Symbol, das für jeden Arbeitselementtyp angezeigt werden soll. Das Symbol wird in Listen mit Arbeitselementen und in Arbeitselementformularen angezeigt. Der Standardeintrag für den Agile-Prozess ist wie gezeigt. Sie können nur ein Symbol aus der Liste der unterstützten 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 lokales XML ein Upgrade auf TFS 2017.2 oder höher durchgeführt haben.

Angeben von Workflowzustandsfarben

Hinweis

Featureverfügbarkeit: Zum Angeben von Workflowstatusfarben müssen Sie ein Upgrade auf TFS 2015.2 oder höher durchführen.

Die Farbe, die Sie Ihren Arbeitselementzuständen zuordnen, wird im gesamten Produkt angezeigt. Dies umfasst die folgenden Bereiche:

Hier zeigen wir, wie es im Arbeitselementformular angezeigt wird:

Fehler im Arbeitselementformularheader, Angezeigte Zustandsfarbe

Hinweis

In den Clientarbeitselementformularen oder im alten Links-Steuerelement im Clientformular werden keine Farben angezeigt.

Details:

  • Sie müssen die Farbe als achtstelligen Hexadezimalwert angeben, ähnlich dem wert, der für die für eine WIT definierte Farbe verwendet wird.
  • Um Farben hinzuzufügen oder zu bearbeiten, importieren Sie einfach Ihre Prozesskonfiguration mit der aktualisierten Eigenschaft neu.
  • Zustandsfarben werden für alle Arbeitselementtypen durch Den Namen definiert, d. h., es gibt keine Möglichkeit, dass "Aktiv" eine Farbe für User Story und eine andere Farbe für Fehler aufweist.
  • Nicht zugeordnete Farben werden zur Laufzeit standardmäßig basierend auf ihrer Metastatuszuordnung festgelegt.
  • Zustände ohne definierte Farbe und keine Metazustandszuordnung zeigen 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 lokales XML ein Upgrade auf TFS 2017.2 oder höher durchgeführt haben.

Die unterstützten Symbole, die Sie für einen Arbeitselementtyp angeben können, sind unten dargestellt.

icon_airplane, icon_asterisk, icon_book, icon_car, icon_chart, icon_chat_bubble, icon_check_box, icon_clipboard, icon_code_response, icon_code_reviewicon_palette, icon_crown, icon_database_storage, icon_diamond, icon_flame, icon_gavel, icon_gear, icon_gift, icon_government, icon_headphoneicon_insect, icon_key, icon_list, icon_megaphone, icon_paint_brush  icon_parachute, icon_response, icon_review, icon_ribbon, icon_sticky_noteicon_star, icon_test_beaker, icon_test_parameter, icon_test_plan, icon_test_step, icon_test_suite, icon_traffic_cone, icon_trophy

Hinweis

Symbole mit einem Sternchen werden in Azure DevOps Services und TFS 2017.3 und höheren Versionen unterstützt.

Das System wendet die für den Arbeitselementtyp definierte Farbe auf das Symbol an. Farben und Symbole werden im Webportal angezeigt, wo arbeitselemente angezeigt werden. Dies umfasst unter Verwandte Arbeiten in PRs, Liste der Links, die Projektseiten sowie Backlogs , Boards, Abfragen und Pläne.

Hier wird beispielsweise eine Listenansicht angezeigt...

Webportal, Liste der Arbeitselemente mit Symbolen

und hier wird das Symbol im Arbeitselementformular angezeigt.

Bug-Arbeitselementformularheader, Angezeigtes Symbol

Weitere Informationen zum Webarbeitselementformular und dessen Anpassung finden Sie in den folgenden zusätzlichen Themen:

Wenn Sie ein benutzerdefiniertes WIT hinzugefügt haben und diese dem Backlog oder Taskboard hinzufügen möchten, können Sie dies auch. Sie können einfach nicht an beiden Stellen angezeigt werden. Informationen dazu finden Sie unter Hinzufügen von Arbeitselementtypen zu Backlogs und Boards.