Share via


XML-Elementreferenz für die Prozesskonfiguration

Prozesskonfiguration definiert die Standardkonfiguration und die funktionalen Funktionen, die Ihre Teams mit der agilen Planungstools erreichen können. Diese Tools, die Sie über das Webportal anzeigen, enthalten den Product Backlog, die Sprint-Backlogs, das Kanban-Board und das Task Board. Diese Tools sind verfügbar, wenn Sie ein Teamprojekt entweder in Visual Studio Online oder auf einem lokalen Team Foundation Server (TFS) erstellen.

Die Konfigurationselemente geben die Arbeitsaufgabentypen (WITs), die Standardspalten, die von den Tools verwendeten Felder und andere Elemente an. Die wichtigsten vorgenommenen Konfigurationen bestimmen, welche Elemente für den Portfolio-Backlog, den Product Backlog und den Sprint-Backlog durch die Definition der Abschnitte PortfolioBacklog, RequirementBacklog und TaskBacklog der XML-Definitionsdatei der Prozesskonfiguration angezeigt werden. Darüber hinaus werden in der Prozesskonfiguration die Zuordnungen von Workflowstatus zu Metazuständen für alle WITs definiert, für die eine Zuordnung erforderlich ist.

Prozesskonfigurations-XML-Elemente

Mithilfe von Configure and customize Agile tools for a team project wird zusammengefasst, was Sie mit der Benutzeroberfläche konfigurieren können und wofür eine Konfiguration durch die Definition der ProcessConfiguration-Datei erforderlich ist.

Bereiche, die Sie mit ProcessConfiguration anpassen:

Konfigurieren eines Backlogs

  • Zuordnen von Metazuständen für eine Kategorie von Arbeitsaufgabentypen

  • Anpassen der Standardspalten und der Spaltenreihenfolge

  • Anpassen des Bereichs zum schnellen Hinzufügen

  • Ändern der Anzahl von Arbeitsaufgaben, die auf dem Task Board angezeigt werden können

  • Zuordnen von Metazuständen für toolspezifische Arbeitsaufgabentypen

  • Zuweisen von Feldern, die in agilen Planungstools und Diagrammen verwendet werden

  • Angeben von Wochenendtagen

  • Ändern der Farbe für einen Arbeitsaufgabentyp

  • Angeben von Eigenschaften und Verhaltensweisen

Zum Aktualisieren der Prozesskonfiguration exportieren Sie die XML-Definitionsdatei, bearbeiten diese und importieren dann die Datei. Mit dem Befehlszeilentool witadmin können Sie die Datei importieren und exportieren.

Prozess zum Anpassen eines WIT-Objekts

Hinweis

Die in diesem Thema enthaltenen Syntaxbeispiele entsprechen den Standardzuweisungen, die in der Scrum-Prozessvorlage definiert sind.Um auf die neueste Version der Prozessvorlagen zuzugreifen, installieren Sie die aktuelle Version von TFS, und laden Sie die Vorlagen mit dem Prozessvorlagen-Manager herunter.

Konfigurieren eines Backlogs

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

  • Metazustandszuordnungen: Dient zum Zuordnen von Workflowstatus zu Metazuständen. Diese Zuordnungen unterstützen die Anzeige aller Agile-Planungstools, einschließlich des Kanban-Boards und des Task Boards.

  • Bereich zum schnellen Hinzufügen: Hier geben Sie die Arbeitsaufgabentypen und die Arbeitsaufgabenfelder an, die für das schnelle Hinzufügen von Elementen zum Backlog angezeigt werden.

    Um die Arbeitsaufgabentypen, die als Backlogelemente 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: Hier definieren Sie die standardmäßigen Felder und die Spaltenreihenfolge.

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>

Element

Beschreibung

PortfolioBacklogs

Dies ist optional. Containerelement für Portfoliobacklogs.

PortfolioBacklog

Dies ist optional. Bis zu fünf Instanzen.

Containerelement, das die Metazustandszuordnungen, Standardspalten und den Bereich zum schnellen Hinzufügen für einen 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 Kategoriedefinitionsdatei für das Teamprojekt definiert haben, die die Arbeitsaufgabentypen enthält, die diesem Backlogtyp zugeordnet werden sollen.

  • parent: Geben Sie den Namen der Kategorie an, die den übergeordneten Portfoliobacklog in der Hierarchie darstellt.

  • pluralName: Geben Sie die Bezeichnung im Plural an, die verwendet werden soll, wenn auf die diesem Backlogtyp zugeordneten Arbeitsaufgabentypen verwiesen wird. Beispiel: Stories, Ziele, Initiativen oder Epen.

  • singularName: Geben Sie die Bezeichnung im Singular an, die verwendet werden soll, wenn auf die diesem Backlogtyp zugeordneten Arbeitsaufgabentypen verwiesen wird. 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 Metazustandszuordnungen, Standardspalten und den Bereich zum schnellen Hinzufügen für den Product Backlog definiert. Der Product Backlog 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 Attribut workItemCountLimit angeben.

  • Die CategoryName zugewiesenen Werte müssen einer für das Teamprojekt definierten Kategoriegruppe entsprechen. Kategoriegruppen werden in der Definitionsdatei für Kategorien angegeben.

  • Mit Portfoliobacklogs organisieren Sie den Backlog, zeigen Sie den Rollup von Backlogelementen auf unteren Ebenen und den Fortschritt für mehrere Teams an. Neue und aktualisierte Teamprojekte enthalten zwei Portfoliobacklogebenen: Features und Epics. Sie können bis zu drei zusätzliche Ebenen hinzufügen. Nur das Portfoliobacklog auf oberster Ebene gibt keine übergeordnete Kategorie an.

    Hinweis

    Möglicherweise benötigen Sie erweiterten Zugriff, um einige der Portfoliobacklogfunktionen auszuführen.

  • Ihr Product Backlog entspricht Ihrem Projektplan, der Roadmap, auf die Ihr Team zuarbeitet. Arbeitsaufgaben, deren WITs zur Anforderungskategorie gehören, werden aufgeführt. Um verschiedene WITs als die vom Standardteamprojekt bereitgestellten zu verwalten, können Sie der Anforderungskategorie WITs hinzufügen und die Workflowstatus zu Metazuständen zuordnen.

  • Die Sprint- oder Iterationsbacklogs zeigen jeweils die Anforderungen an, deren Erfüllung in einem bestimmten Sprint-Zyklus Sie und Ihr Team zugesichert haben, sowie 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 Workflowstatus zu Metazuständen

Die meisten Arbeitsaufgabentypen erfordern die Zuordnung ihrer Workflowstatus zu einem Metazustand. Workflowstatus definieren den Fortschritt einer Arbeitsaufgabe von der ersten Aktivierung oder Erstellung bis zum Abschluss. Die für das Scrum Product Backlog Item definierten Zustände definieren z. B. eine Abfolge von vier Status, von Neu, Bestätigt, Zugesichert zu Fertig. Darüber hinaus gibt es einen fünften Zustand, Entfernt, wenn das Backlogelement nicht implementiert wird.

Metazustände hingegen bestimmen, wie die Agile-Planungstools die einzelnen Workflowstatus behandeln. Die primären Metazustände, die vom Backlog und vom Task Board verwendet werden, sind Proposed, InProgress und Complete.

Durch das Zuordnen jedes Workflowstatus zu einem Metazustand können die Hintergrundprozesse, die zum Anzeigen des Backlogs und der Task Boards ausgeführt werden, den Status jeder Arbeitsaufgabe richtig interpretieren. 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 Kategorien von Metazuständen: Agile, Fehler und Feedback. In der folgenden Tabelle sind die Zuordnungsattribute und -werte beschrieben.

Element

Beschreibung

State

Erforderlich. Weist einen Workflowstatus zu einem Metazustand zu.

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

Gültige Werte für TypeName entsprechen einem Wert, der einem STATE im WORKFLOW-Abschnitt der Arbeitsaufgabentypen zugewiesen ist, die der Kategoriegruppe zugewiesen sind.

Gültige Werte für ValueName entsprechen einem der folgenden Enumerationswerte:

  • Agile: Kann für alle Arbeitsaufgabentypen verwendet werden.

    • Proposed: Gibt Arbeitsaufgaben an, die neu oder noch nicht zugesichert sind oder an denen noch nicht gearbeitet wurde.

    • InProgress: Gibt Arbeitsaufgaben an, die zugesichert wurden oder an denen aktiv gearbeitet wird.

    • Complete: Gibt Arbeitsaufgaben an, die implementiert wurden. Damit das Kanban-Board gültig ist, muss mindestens ein Workflowstatus zum Complete-Metazustand zugewiesen werden.

      Sobald ein Workflowstatus in einen Status übergeht, dem der Complete-Metazustand zugeordnet ist, wird die zugeordnete Arbeitsaufgabe vom Product Backlog entfernt. Sie wird jedoch nach wie vor im Kanban-Board aufgeführt.

    Arbeitsaufgaben in einem Workflowstatus, die keinen unterstützten Metazuständen zugeordnet sind, werden nicht auf dem Backlog oder Board angezeigt.

  • Fehler: Wird nur für Arbeitsaufgabentypen verwendet, die in der Fehlerkategorie gruppiert werden. Umfasst zusätzlich zu den Agile-Metazuständen den Metazustand Resolved, der Fehler angibt, die behoben wurden.

    Hinweis

    Sie können den Resolved-Metazustand nur einem Workflowstatus zuweisen, der unter dem BugWorkItems-Element angegeben ist.

  • Feedback: Wird nur für Arbeitsaufgabentypen verwendet, die in der Feedbackanforderungs- oder Feedbackantwortkategorie gruppiert werden. Requested, Received, Reviewed und Declined.

States

Gibt eine Auflistung von State-Elementen an, die Workflowstatus von Arbeitsaufgabentypen zu Metazuständen zuordnen.

Erforderliches Element für die folgenden übergeordneten Elemente:

  • BugWorkItems

  • PortfolioBacklog

  • RequirementBacklog

  • TaskBacklog

  • TestPlanWorkItems

  • TestSuiteWorkItems

  • FeedbackRequestWorkItems

  • FeedbackResponseWorkItems

Anpassen der Standardspalten und der Spaltenreihenfolge

Geben Sie an, welche Felder auf den einzelnen Backlogs im Columns-Abschnitt angezeigt werden sollen. Änderungen, die Sie im Dialogfeld Spaltenoptionen vornehmen, bleiben bis zur erneuten Vornahme von Änderungen bestehen.

Standardspalten und -sequenz für Backlogseite

Dies ist die Standardkonfiguration, die durch die Scrum-Prozessvorlage für den Product Backlog 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>

Element

Beschreibung

Columns

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

Column

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 Workflowstatus, die für den Standardaufgabentyp in der Aufgabenkategorie definiert sind, müssen einem gültigen Metazustand zugewiesen werden, wie in Zuordnen von Metazuständen 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. Mit dem folgenden Beispiel wird z. B. Geschäftswert zum Product Backlog-Bereich hinzugefügt.

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

Der Bereich zeigt nur Felder an, die im Abschnitt FIELDS der Definition des Arbeitsaufgabentyps für den ausgewählten Arbeitsaufgabentyp enthalten sind. Wenn Sie z. B. den Arbeitsaufgabentyp "Fehler" auswählen, wird nur der "Titel" anzeigt, da der "Geschäftswert" für Fehler nicht definiert ist. Um dem Bereich einen weiteren Arbeitsaufgabentyp hinzuzufügen, fügen Sie ihn wie hier beschrieben der Anforderungskategorie hinzu.

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>

Element

Beschreibung

AddPanel

Containerelement zur Angabe des Bereichs zum schnellen Hinzufügen und der Felder, die in dem Bereich angezeigt werden, in dem neue Backlogelemente definiert werden.

Fields

Gibt eine Auflistung von Field-Elementen an.

Field

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

<Field refname="FieldReferenceName"/>

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

Ändern der Anzahl von Arbeitsaufgaben, die auf dem Task Board angezeigt werden können

Aus Leistungsgründen zeigt das Task Board maximal 1.000 Arbeitsaufgaben an. Wenn Sie das Task Board öffnen, werden alle Arbeitsaufgaben in den Cache geladen. Durch Beschränkung der Anzahl von Arbeitsaufgaben 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.

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

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

Zuordnen von Metazuständen für toolspezifische Arbeitsaufgabentypen

Metazustandszuordnungen werden für zusätzliche Kategorien von Arbeitsaufgabentypen 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 schließt Fehler in der Anforderungskategorie ein und definiert die Metazustandszuordnungen daher 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 sind die zusätzlichen Elemente beschrieben, die zum Definieren der Metazustandszuordnungen für toolspezifische Arbeitsaufgabentypen verwendet werden. Informationen zum Zuweisen der tatsächlichen Zustandswerte und -typen finden Sie unter Zuordnen von Metazuständen für eine Kategorie von Arbeitsaufgabentypen. Der CategoryName muss einer Kategorie entsprechen, die für das Teamprojekt definiert ist.

Element

Beschreibung

BugWorkItems

Dies ist optional. Containerelement, das die Metazustandszuordnungen für Arbeitsaufgabentypen definiert, die der Fehlerkategorie zugewiesen sind. Zusätzlich zur Verwendung dieser Zuordnungen in der Anzeige von Agile-Tools steuern sie auch, wie die Funktion Meine Arbeit in Team Explorer den Fehlerzustand aktualisiert, wenn Entwickler Fehler mit Meine Arbeit verschieben. Weitere Informationen dazu finden Sie unter Ein Tag im Leben eines ALM-Entwicklers: Schreiben von Code für eine User Story.

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

FeedbackRequestWorkItems

Erforderlich. Wird nicht angepasst.

Containerelement, das die Metazustandszuordnungen 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 Metazustandszuordnungen 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 den Testplan anpassen und Verbindungen mit dem Teamprojekt aus Versionen von Test Manager unterstützen, die mit Visual Studio 2013.2 oder früheren Versionen installiert sind.

Containerelement, das die Metazustandszuordnungen für Arbeitsaufgabentypen definiert, die der Testplankategorie 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 die Testsammlung anpassen und Verbindungen mit dem Teamprojekt aus Versionen von Test Manager unterstützen, die mit Visual Studio 2013.2 oder früheren Versionen installiert sind.

Containerelement, das die Metazustandszuordnungen für Arbeitsaufgabentypen definiert, die der Testsammlungskategorie 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>

Um Metazustände für TestPlanWorkItems oder TestSuiteWorkItems zuzuordnen, müssen Sie ein Upgrade Ihrer Anwendungsebenenserver auf TFS 2013.3 durchführen. Anschließend können Sie den Workflowstatus von Testplänen und Testsammlungen anpassen.

Weitere Informationen finden Sie unter Importieren und Exportieren der Prozesskonfiguration.

Zuweisen von Feldern, die in agilen Planungstools und Diagrammen verwendet werden

Sie können die Arbeitsaufgabenfelder ä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 den refname-Wert ändern, der type="Activity" zugewiesen ist, sollten Sie das gleiche Feld auch in die Definition des der Aufgabenkategorie zugewiesenen Arbeitsaufgabentyps einschließen, mit dem die Aktivitätsinformationen erfasst werden.

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

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 Folgendes gilt: type="RemainingWork". Sie können eine beliebige Textzeichenfolge für TimeUnitString angeben, die in den Kapazitätsleisten auf dem aktuellen Sprint-Backlog und auf dem Task Board angezeigt werden soll.

Für Agile-Tools:

  • Activity: Wird zur Unterstützung der Funktion "Kapazität nach Aktivität" verwendet. Geben Sie das gleiche Feld an, das im Arbeitsaufgabentyp verwendet wird, der der Aufgabenkategorie zugewiesen ist.

    Hinweis: Die vom Kapazitätentool angezeigten Werte sind eine Vereinigung aller Werte, die für das Feld in allen Teamprojekten innerhalb der Projektauflistungsinstanz definiert sind. Um die für die Sprint-Kapazität angezeigten Werte einzuschränken, müssen die Werte in allen Teamprojekten für das type="Activity" zugewiesene Feld übereinstimmen.

  • Effort: Wird zum Berechnen der Geschwindigkeit des Teams verwendet. 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 Backlogelements erforderlich ist.

  • Order: Wird zum Definieren der Sortierreihenfolge für Elemente auf den Backlogs und Boards verwendet. 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.Wenn Sie Elemente verschieben, aktualisiert ein Hintergrundprozess das Feld, das type="Order" zugewiesen ist.

  • RemainingWork: Wird zum Berechnen der verbleibenden Arbeit und der Burndown Diagramme verwendet. 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 format angeben, wird auf den Sprint-Backlogs und Task Boards verwendet, wenn verbleibende Arbeit angegeben 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 zum Anzeigen des Zeitwerts verwenden möchten, 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 zum Zuordnen der Backlogs zu einem Team verwendet. Der Standardwert lautet System.AreaPath. Um Teams von Bereichspfaden zu entkoppeln, können Sie ein anderes Feld angeben, wie in Verwenden von Teamfeldern anstelle von Bereichspfaden zur Unterstützung von Teams beschrieben.

Für das Feedbackanforderungsformular:

Hinweis

Sie sollten die Standardzuweisungen, die für die folgenden TypeField-Elemente vorgenommen wurden, 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 zum Erfassen des Pfads zum Ausführen der Anwendung verwendet.

  • ApplicationLaunchInstructions: Wird zum Erfassen der Startanweisungen verwendet.

  • ApplicationType: Wird zum Erfassen des Anwendungstyps verwendet. Die aufgeführten Typen entsprechen den zulässigen Werten, die in der Definition des Arbeitsaufgabentyps für die Feedbackanforderung angegeben sind. Informationen zum Anpassen dieser Liste finden Sie unter Anpassen einer Auswahlliste.

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 auch in der Definition des Arbeitsaufgabentyps vornehmen. Wenn Sie z. B. die Felder ändern, die zugewiesen wurden, um den Effort an Arbeit zu erfassen, sollten Sie die gleiche Änderung auch in den Definitionen der Arbeitsaufgabentypen für das Product Backlog Item und den Fehler (für Scrum) vornehmen.

  • Sie können den Verweisnamen für ein Feld mit diesem Index suchen.

Zuweisen von arbeitsfreien Tagen

Arbeitsfreie Tage werden aus den vom Tool zur Kapazitätsplanung und den Burndown Diagrammen durchgeführten Berechnungen entfernt. Standardmäßige Visual Studio Online-Prozesse und TFS-Prozessvorlagen geben Samstag und Sonntag als arbeitsfreie Tage an. Nach der Erstellung eines Teamprojekts kann jedes Team bestimmte arbeitsfreie Tage festlegen.

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

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: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday und Saturday.

Hinweis

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

Weekends

Dies ist 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 Arbeitsaufgabentyp

Anhand der den Arbeitsaufgabentypen zugewiesenen Farben können Sie diese auf den ersten Blick unterscheiden, wenn Sie ein Abfrageergebnis oder einen Backlog anzeigen.

Farbzuweisungen zu verschiedenen Arbeitsaufgabentypen

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>

Element

Beschreibung

WorkItemColors

Dies ist optional. Containerelement zum Angeben der Farben für Arbeitsaufgabentypen.

WorkItemColor

Gibt die Farben an, die zum Anzeigen eines Arbeitsaufgabentyps im Webportal verwendet werden. Die primäre Farbe wird in den Listenanzeigen verwendet, und die sekundäre Farbe wird in Boardanzeigen wie dem Task Board oder dem Kanban-Board verwendet.

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

Angeben von Eigenschaften und Verhaltensweisen

Es gibt nur eine Eigenschaft, die Sie zu diesem Zeitpunkt angeben können. Die BugsBehavior-Eigenschaft definiert die Standardkonfiguration, wie Fehler und andere in der Fehlerkategorie definierte Arbeitsaufgabentypen 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. Nach der Erstellung eines Teamprojekts kann jedes Team das gewünschte Verhalten festlegen.

<Properties>
   <Property name="BugsBehavior" value="AsTasks" />
   <Property name="HiddenBacklogs" value="Microsoft.EpicCategory" />
</Properties>

Element

Beschreibung

Properties

Dies ist optional. Containerelement zum Angeben von Standardeigenschaften und Verhaltensweisen.

Property

Gibt die Standardzuordnung für neue oder vorhandene Teams an, die durchgeführt wird, wenn ein Teamprojekt mit neuen Funktionen aktualisiert wird. Teams können das gewünschte Verhalten in ihren Teameinstellungen konfigurieren. BugsBehavior legt den Standardwert für Anzeigen von Fehlern in Backlogs oder auf Boards fest. HiddenBacklogs gibt die Kategorie des inaktiven Backlogs für das Team an.

Die zulässigen Werte für BugsBehavior entsprechen:

  • AsRequirements – Fehler werden ähnlich wie Anforderungen auf Backlogs und Boards angezeigt.

  • AsTasks – Fehler werden ähnlich wie Aufgaben auf Backlogs und Boards angezeigt.

  • Off – Fehler werden nicht auf Backlogs oder Boards angezeigt.

Fragen und Antworten

F: Wie passe ich andere Funktionen des Agile-Tools an?

A: Einige Anpassungen können über die Benutzeroberfläche ausgeführt werden. Andere erfordern die Bearbeitung der Prozesskonfiguration oder anderer Teamprojektobjekte. Eine Übersicht finden Sie unter Configure and customize Agile tools for a team project.

F: Möchten Sie die WITs hinzufügen oder ändern, die im Task Board oder im Product Backlog angezeigt werden?

A: Wenn Sie einen benutzerdefinierten WIT hinzugefügt haben und diesen entweder dem Backlog oder dem Task Board hinzufügen möchten, können Sie das tun. Sie können nur nicht an beiden Stellen angezeigt werden. Wie Sie dazu vorgehen, erfahren Sie unter Hinzufügen von Arbeitsaufgabentypen zu Backlogs und Boards.