Arbeitsaufgabentypen und Workflow für Agile-Prozessvorlagen

Artikel
06/10/2015

Teams verwenden die Arbeitsaufgabentypen (WITs), die mit der MSF for Agile Software Development 2013 (Agile)-Prozessvorlage bereitgestellt werden, um den Fortschritt von Softwareprojekten zu planen und nachzuverfolgen. Teams definieren User Storys zur Verwaltung des Arbeitsbacklogs und verwenden dann das Kanban-Board, um diese nachzuverfolgen, indem sie den Status aktualisieren.

Agile 7.0-Arbeitsaufgabentypen

Um Einblick in ein Portfolio von Funktionen, Szenarien oder Benutzeroberflächen zu erhalten, können Produktbesitzer und Programmmanager User Storys Funktionen zuordnen. Wenn Teams in Sprints arbeiten, werden Aufgaben definiert, die automatisch mit User Storys verknüpft werden.

Mithilfe von Microsoft Test-Manager und dem Team Web Access (TWA) können Tester Testfälle erstellen und ausführen. Fehler und Probleme werden verwendet, um Codefehler und Blockierungsprobleme nachzuverfolgen.

Definieren von User Stories und Einschätzen des Aufwand mithilfe von User Stories

Über User Stories werden Anwendungen, Anforderungen und Elemente definiert, die Teams erstellen müssen. In der Regel wird das Definieren und Priorisieren der User Stories durch die Produktbesitzer durchgeführt. Das Team schätzt dann den erforderlichen Arbeitsaufwand zur Bereitstellung der Elemente mit der höchsten Priorität.

Erstellen Sie User Stories im Bereich zum schnellen Hinzufügen auf der Product Backlog-Seite.

Bereich zum schnellen Hinzufügen, Backlogseite für Stories

Später können Sie jede User Story öffnen, um weitere Informationen bereitzustellen und Storypunkte zu schätzen.

Arbeitsaufgabenformular für eine User Story

Durch Definieren der Storypunkte können Teams anhand der Vorhersagefunktion und Geschwindigkeitsdiagramme zukünftige Sprints oder den Arbeitsaufwand einschätzen. Durch Priorisieren der User Stories auf der Backlog-Seite (die im Feld "Stapelrang" erfasst werden) können Produktbesitzer angeben, welchen Elementen höhere Priorität zugewiesen werden soll.

Verwenden Sie den folgenden Leitfaden, wenn Sie das Formular ausfüllen. Pflichtfelder sind entsprechend angegeben.

Feld/Registerkarte	Verwendung
Storypunkte	Schätzen Sie den Arbeitsaufwand zum Fertigstellen einer User Story in der vom Team bevorzugten Maßeinheit ab, ob T-Shirt-Größe, Storypunkte oder Zeit. Von flexiblen Geschwindigkeitsdiagrammen und Vorhersagetools wird auf die Werte in diesem Feld verwiesen. Dies ist ein Pflichtfeld zum Generieren des Geschwindigkeitsberichts. Weitere Anleitungen finden Sie im Whitepaper Schätzung.
Risiko	Eine subjektive Bewertung der relativen Ungewissheit im Hinblick auf den erfolgreichen Abschluss einer User Story. Zulässige Werte sind: 1: Hoch 2: Mittel 3: Niedrig Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste.
Details (User Stories)	Geben Sie für User Stories genug Details zur Einschätzung des Arbeitsaufwands an, der zum Implementieren der Story erforderlich ist. Konzentrieren Sie sich auf die vorgesehenen Anwender der Funktion: Was soll erreicht werden, und weshalb? Beschreiben Sie nicht, wie die Funktion entwickelt werden soll. Stellen Sie ausreichende Informationen bereit, damit das Team Aufgaben und Testfälle schreiben kann, um das Element zu implementieren. Reproduktionsschritte (Fehler) Zeichnen Sie bei Fehlern ausreichende Informationen auf, sodass andere Teammitglieder sowohl die vollständigen Auswirkungen des Problems verstehen als auch sicherstellen können, dass der Fehler behoben wurde. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens. Überlegen Sie auch, was "Fertig" bedeutet, beschreiben Sie die zu verwendenden Kriterien, die dann vom Team zum Überprüfen verwendet werden können, ob die User Story oder die Fehlerkorrektur vollständig implementiert wurde. Vor dem Umsetzen einer User Story oder eines Fehlers sollten die Kriterien für Kundenakzeptanz so eindeutig wie möglich definiert werden. Durch Gespräche zwischen dem Team und den Kunden zur Bestimmung der Akzeptanzkriterien wird ein allgemeines Verständnis der Kundenerwartungen im Team sichergestellt. Die Akzeptanzkriterien können als Grundlage für Akzeptanztests verwendet werden, damit das Team effektiver auswerten kann, ob ein Element zufriedenstellend abgeschlossen wurde.

Storypunkte

Schätzen Sie den Arbeitsaufwand zum Fertigstellen einer User Story in der vom Team bevorzugten Maßeinheit ab, ob T-Shirt-Größe, Storypunkte oder Zeit.

Von flexiblen Geschwindigkeitsdiagrammen und Vorhersagetools wird auf die Werte in diesem Feld verwiesen. Dies ist ein Pflichtfeld zum Generieren des Geschwindigkeitsberichts.

Weitere Anleitungen finden Sie im Whitepaper Schätzung.

Risiko

Eine subjektive Bewertung der relativen Ungewissheit im Hinblick auf den erfolgreichen Abschluss einer User Story. Zulässige Werte sind:

1: Hoch
2: Mittel
3: Niedrig

Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste.

Details (User Stories)

Geben Sie für User Stories genug Details zur Einschätzung des Arbeitsaufwands an, der zum Implementieren der Story erforderlich ist. Konzentrieren Sie sich auf die vorgesehenen Anwender der Funktion: Was soll erreicht werden, und weshalb? Beschreiben Sie nicht, wie die Funktion entwickelt werden soll. Stellen Sie ausreichende Informationen bereit, damit das Team Aufgaben und Testfälle schreiben kann, um das Element zu implementieren.

Reproduktionsschritte (Fehler)

Zeichnen Sie bei Fehlern ausreichende Informationen auf, sodass andere Teammitglieder sowohl die vollständigen Auswirkungen des Problems verstehen als auch sicherstellen können, dass der Fehler behoben wurde. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens.

Überlegen Sie auch, was "Fertig" bedeutet, beschreiben Sie die zu verwendenden Kriterien, die dann vom Team zum Überprüfen verwendet werden können, ob die User Story oder die Fehlerkorrektur vollständig implementiert wurde.

Vor dem Umsetzen einer User Story oder eines Fehlers sollten die Kriterien für Kundenakzeptanz so eindeutig wie möglich definiert werden. Durch Gespräche zwischen dem Team und den Kunden zur Bestimmung der Akzeptanzkriterien wird ein allgemeines Verständnis der Kundenerwartungen im Team sichergestellt. Die Akzeptanzkriterien können als Grundlage für Akzeptanztests verwendet werden, damit das Team effektiver auswerten kann, ob ein Element zufriedenstellend abgeschlossen wurde.

Nachverfolgen des Fortschritts

Teams können mithilfe des Kanban-Board den Status von User Stories und mithilfe des Sprint-Task Board den Status von Aufgaben nachverfolgen. Durch Ziehen von Elementen zu einer neuen Zustandsspalte werden die Felder Zustand und Grund aktualisiert.

Kanban-Board mit Storyaktualisierung

Sie können Kanban-Board anpassen, um weitere Verantwortlichkeitsbereiche oder Spalten zu unterstützen. Sie können auch den Workflow für die User Story und die Aufgaben-WITs anpassen, wodurch die Standardspaltenüberschriften geändert werden.

Eine typische Workflowprogression für eine User Story:

Der Produktbesitzer erstellt eine User Story im Status Neu mit dem Standardgrund Neue User Story.
Der Status wird vom Team auf Aktiv aktualisiert, wenn die Entscheidung getroffen wird, die Arbeiten im Sprint abzuschließen.
Eine User Story wird auf Gelöst gesetzt, wenn das Team alle zugeordneten Aufgaben abgeschlossen hat und Komponententests für die Story erfolgreich abgeschlossen wurden.
Eine User Story wird auf den Status Geschlossen gesetzt, wenn der Produktbesitzer zustimmt, dass die Story gemäß den Akzeptanzkriterien implementiert wurde und die Akzeptanztests erfolgreich waren.

Durch das Aktualisieren des Workflows erhalten die Teams Informationen darüber, welche Elemente neu sind, sich in Bearbeitung befinden oder abgeschlossen wurden. Die meisten WITs unterstützen den Übergang von jedem Workflowzustand vor- und rückwärts.

Zuordnen von User Stories zu Funktionen

Wenn Sie eine Gruppe von Produkten oder Benutzererfahrungen verwalten, sollten Sie den Umfang und den Status der Arbeit für das Produktportfolio anzeigen. Definieren Sie dazu Funktionen und ordnen Sie diesen Funktionen User Stories zu.

Auf der Funktions-Backlog-Seite können Sie Funktionen genauso schnell hinzufügen wie User Stories.

Bereich zum schnellen Hinzufügen, Backlogseite für Funktionenportfolio

Die Funktionsarbeitsaufgabe enthält ähnliche Felder, die für User Stories bereitgestellt werden, und umfasst weitere Felder, wie in der folgenden Tabelle beschrieben.

Funktionsarbeitsaufgabenformular für Agile

Die Registerkarte Implementierung erfasst die Links zu zugeordneten User Stories.

Feld	Verwendung
Priorität	Eine subjektive Bewertung der Funktion und ihrer Auswirkungen auf das Geschäft. Zulässige Werte sind: 1: Das Produkt darf nicht ohne die Funktion ausgeliefert werden. 2: Das Produkt darf nicht ohne die Funktion ausgeliefert werden, muss jedoch nicht unmittelbar behandelt werden. 3: Die Implementierung der Funktion ist optional und hängt von den Ressourcen, der Zeit und dem Risiko ab. Informationen zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste (Dropdownmenü) [umgeleitet].
Geschäftswert	Geben Sie eine Zahl an, die den relativen Wert einer Funktion im Vergleich mit anderen Funktionen darstellt. Je größer die Zahl, desto größer ist der Geschäftswert.
Zieldatum	Geben Sie das Datum an, bis zu dem die Funktion implementiert werden soll.

Priorität

Eine subjektive Bewertung der Funktion und ihrer Auswirkungen auf das Geschäft. Zulässige Werte sind:

1: Das Produkt darf nicht ohne die Funktion ausgeliefert werden.
2: Das Produkt darf nicht ohne die Funktion ausgeliefert werden, muss jedoch nicht unmittelbar behandelt werden.
3: Die Implementierung der Funktion ist optional und hängt von den Ressourcen, der Zeit und dem Risiko ab.

Informationen zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste (Dropdownmenü) [umgeleitet].

Geschäftswert

Geben Sie eine Zahl an, die den relativen Wert einer Funktion im Vergleich mit anderen Funktionen darstellt. Je größer die Zahl, desto größer ist der Geschäftswert.

Zieldatum

Geben Sie das Datum an, bis zu dem die Funktion implementiert werden soll.

Ziehen Sie von der Backlog-Seite mit aktivierter Zuordnungsfunktion User Stories zu der Funktion, die sie implementieren.

User Story einer Funktion zuordnen

Diese Zuordnung erstellt Links zwischen übergeordneten und untergeordneten Daten von der Funktion zu User Stories, was auf der Registerkarte Implementierung aufgezeichnet wird.

Mithilfe von Portfolio-Backlogs können Sie einen Drilldown zwischen Backlogs durchführen, um den gewünschten Detailgrad anzuzeigen. Außerdem können Sie Portfoliobacklogs verwenden, um einen Rollup der in Bearbeitung befindlichen Aufgaben für mehrere Teams anzeigen, wenn Sie eine Hierarchie für die Teams festlegen.

Definieren der Aufgaben, die erforderlich sind, um User Stories zu implementieren und Teamkapazität und Burndown nachzuvollziehen

Wenn das Team die Arbeiten in Sprints verwaltet, können sie die Sprint-Backlog-Seite verwenden, um die Arbeit in verschiedene Aufgaben zu untergliedern.

Link für das Hinzufügen einer Aufgabe auf einer Sprint-Backlogseite

Geben Sie der Aufgabe einen Namen und schätzen Sie die dafür erforderliche Arbeit.

Arbeitsaufgabenformular für Aufgabe

Mit Agile-Prozessen planen die Teams die Arbeit und definieren die Aufgaben zu Beginn jedes Sprints. Dabei führt jedes Teammitglied einen Teil dieser Aufgaben aus. Zu Aufgaben zählen Entwicklung, Tests und andere Arbeitsschritte. Zum Beispiel kann ein Entwickler Aufgaben definieren, um User Stories zu implementieren, und ein Tester kann Aufgaben definieren, um Testfälle zu schreiben und auszuführen.

Wenn der Aufwand in Stunden oder Tagen geschätzt wird, definieren die Teams Aufgaben sowie die optionalen Felder Verbleibende Arbeit und Aktivität.

Feld/Registerkarte	Verwendung
Ursprüngliche Schätzung (siehe Hinweis 1)	Der geschätzte Arbeitsaufwand, der zum Abschluss einer Aufgabe erforderlich ist. In der Regel wird dieses Feld nicht geändert, nachdem es zugewiesen ist.
Verbleibende Arbeit	Der Arbeitsaufwand, der zum Abschluss einer Aufgabe noch erforderlich ist. Aktualisieren Sie dieses Feld im Verlauf der Arbeit. Anhand dieses Felds werden Kapazitätsdiagramme, das Sprint-Burndown Diagramm und die folgenden Berichte berechnet bzw. erstellt: Burndown und Durchsatz, Verbleibende Arbeit und Status für alle Iterationen. Wenn Sie eine Aufgabe in Unteraufgaben unterteilen, geben Sie Stunden nur für die Unteraufgaben an. Sie können die Arbeit in einer die oft ausgegebene Befehlszeilen Maßeinheit angeben, ganz nach Wunsch des Teams.
Abgeschlossene Arbeit	Der Arbeitsaufwand, der zum Implementieren einer Aufgabe erforderlich war.
Aktivität	Wählen Sie den Aktivitätstyp aus, den diese Aufgabe darstellt, wenn das Team die Sprintkapazität nach Aktivität schätzt. Informationen zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste.
Implementierung	Diese Registerkarte erfasst die Links zwischen übergeordneten und untergeordneten Daten, die zwischen User Stories und Aufgaben erstellt werden. Wenn Sie einer User Story mit dem Sprint Task Board Aufgaben hinzufügen, werden automatisch Verknüpfungen zur Story erstellt. Mithilfe von Aufgaben können Sie den Fortschritt der Arbeit nachverfolgen, die zum Abschließen der Story angefallen ist. Diese Aktivität unterstützt auch verschiedene Berichte, wie Bericht "Übersicht über Storys" (Agile) und Bericht "Anforderungsstatus" (CMMI).

Hinweise:

Sie können die Arbeit in Stunden oder in Tagen angeben. Es gibt keine inhärenten Zeiteinheiten, die diesem Feld zugeordnet sind.

Wenn Sie Microsoft Project verwenden, um Ressourcen zuzuweisen und einen Zeitplan nachzuverfolgen, können Sie diese Felder mithilfe von Project aktualisieren.

Nachverfolgen des Teststatus von User Stories und Erfassen von Codefehlern

Testen von User Stories

Über Test Manager oder TWA können Sie Testfälle erstellen, die automatisch mit einer User Story oder einem Fehler verknüpft sind.

Testauflistung auswählen und einen Testfall hinzufügen

Der Testfall enthält mehrere Felder, von denen viele automatisiert und in Test Manager und im Buildprozess integriert sind. Eine Beschreibung jedes Felds finden Sie unter Feldverweis für Build- und Testintegration.

Arbeitsaufgabenformular für Testfall

Die Registerkarte Getestete User Stories führt alle User Stories und Fehler in einem Testfall auf. Durch das Verknüpfen von User Stories und Fehlern mit Testfällen kann das Team den Fortschritt der Tests nachverfolgen, die für jedes Element ausgeführt werden. Das Definieren dieser Links liefert Informationen für den Bericht "Übersicht über Storys" (Agile)-Bericht.

Nachverfolgen von Codefehlern

Sie können Fehler über TWA, Visual Studio erstellen oder beim Testen mit Test Manager.

Fehlerarbeitsaufgabe für Agile-Prozessvorlage

Feld/Registerkarte	Verwendung
Reproduktionsschritte	Zeichnen Sie ausreichende Informationen auf, sodass andere Teammitglieder sowohl die vollständigen Auswirkungen des Problems verstehen als auch sicherstellen können, dass der Fehler behoben wurde. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens. Beschreiben Sie die Kriterien, die das Team verwenden soll, um zu überprüfen, dass der Fehler behoben ist.
Schweregrad	Eine subjektive Bewertung der Auswirkungen eines Fehlers auf das Projekt. Zulässige Werte sind: 1: Kritisch 2: Hoch 3: Mittel 4: Niedrig Informationen zum Ändern der Menüauswahl finden Sie unter Definieren einer Auswahlliste.
Systeminfo In Build gefunden In den Build integriert	Wenn Test Manager Fehler erstellt, werden die Felder Systeminfo und In Build gefunden mit Informationen über die Softwareumgebung und den Build, in dem der Fehler auftrat, automatisch ausgefüllt. Mehr über das Definieren der Softwareumgebung erfahren Sie unter Einrichten von Testcomputern zum Ausführen von Tests oder Sammeln von DatenGeben Sie beim Beheben des Fehlers unter In den Build integriertden Namen des Builds ein, der den Code enthält, mit dem der Fehler korrigiert wird. Wenn Sie mit einem Dropdownmenü auf alle Builds zugreifen möchten, die ausgeführt wurden, können Sie die FIELD-Definitionen für "In Build gefunden" und "In Build integriert" aktualisieren, sodass diese auf eine globale Liste verweisen. Die globale Liste wird jedes Mal automatisch aktualisiert, wenn der Build ausgeführt wird. Weitere Informationen dazu finden Sie unter Felder, die die Integration in die Test-, Build- und Versionskontrolle unterstützen. Weitere Informationen zum Definieren von Buildnamen finden Sie unter Verwenden von Buildnummern, um abgeschlossene Builds mit aussagekräftigen Namen zu versehen.

Reproduktionsschritte

Zeichnen Sie ausreichende Informationen auf, sodass andere Teammitglieder sowohl die vollständigen Auswirkungen des Problems verstehen als auch sicherstellen können, dass der Fehler behoben wurde. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens.

Beschreiben Sie die Kriterien, die das Team verwenden soll, um zu überprüfen, dass der Fehler behoben ist.

Schweregrad

Eine subjektive Bewertung der Auswirkungen eines Fehlers auf das Projekt. Zulässige Werte sind:

1: Kritisch
2: Hoch
3: Mittel
4: Niedrig

Informationen zum Ändern der Menüauswahl finden Sie unter Definieren einer Auswahlliste.

Systeminfo

In Build gefunden

In den Build integriert

Wenn Test Manager Fehler erstellt, werden die Felder Systeminfo und In Build gefunden mit Informationen über die Softwareumgebung und den Build, in dem der Fehler auftrat, automatisch ausgefüllt. Mehr über das Definieren der Softwareumgebung erfahren Sie unter Einrichten von Testcomputern zum Ausführen von Tests oder Sammeln von DatenGeben Sie beim Beheben des Fehlers unter In den Build integriertden Namen des Builds ein, der den Code enthält, mit dem der Fehler korrigiert wird.

Wenn Sie mit einem Dropdownmenü auf alle Builds zugreifen möchten, die ausgeführt wurden, können Sie die FIELD-Definitionen für "In Build gefunden" und "In Build integriert" aktualisieren, sodass diese auf eine globale Liste verweisen. Die globale Liste wird jedes Mal automatisch aktualisiert, wenn der Build ausgeführt wird. Weitere Informationen dazu finden Sie unter Felder, die die Integration in die Test-, Build- und Versionskontrolle unterstützen.

Weitere Informationen zum Definieren von Buildnamen finden Sie unter Verwenden von Buildnummern, um abgeschlossene Builds mit aussagekräftigen Namen zu versehen.

Definieren allgemeiner Felder und Registerkarten von Arbeitsaufgaben

In den meisten Arbeitsaufgabenformularen werden folgende Felder und Registerkarten angezeigt. Auf jeder Registerkarte werden bestimmte Informationen nachverfolgt, z. B. Verlauf, Links oder Anlagen. Auf diesen drei Registerkarten werden jeweils der Änderungsverlauf, eine Ansicht der verknüpften Arbeitsaufgaben sowie die Möglichkeit zum Anzeigen und Anfügen von Dateien bereitgestellt.

Das einzige Pflichtfeld für alle WITs ist Titel. Beim Speichern der Arbeitsaufgabe wird dieser vom System eine eindeutige ID zugewiesen. Andere Pflichtfelder werden gelb hervorgehoben.

Feld/Registerkarte	Verwendung
Titel [erforderlich]	Geben Sie eine höchstens 255 Zeichen lange Beschreibung ein. Sie können den Titel später jederzeit ändern.
Zugewiesen an	Weisen Sie die Arbeitsaufgabe dem für die Bearbeitung zuständigen Teammitglied zu. Ja nach dem Kontext der Arbeiten werden im Dropdownmenü nur Teammitglieder oder am Teamprojekt Mitwirkende aufgeführt.
Zustand	Wenn die Arbeitsaufgabe erstellt wird, wird für den Zustand standardmäßig der erste Zustand im Workflow festgelegt. Aktualisieren Sie den Wert im Verlauf der Arbeit mit dem aktuellen Zustand. Informationen zum Ändern der Dropdownliste mit Zuständen finden Sie unter Ändern des Workflows für einen Arbeitsaufgabentyp.
Grund	Verwenden Sie zunächst die Standardeinstellung. Aktualisieren Sie den Wert bei Zustandsänderungen. Jeder Zustand ist einem Standardgrund zugeordnet. Informationen zum Ändern der Dropdownliste mit Gründen finden Sie unter Ändern des Workflows für einen Arbeitsaufgabentyp.
Bereich	Wählen Sie den zum Produkt oder Team gehörenden Bereichspfad aus, oder lassen Sie dieses Feld leer, bis ein entsprechender Pfad bei einer Planungsbesprechung zugewiesen wird. Informationen zum Ändern der Dropdownliste mit Bereichen finden Sie unter Hinzufügen und Ändern von Bereichs- und Iterationspfaden.
Iteration	Wählen Sie den Sprint oder die Iteration aus, in dem bzw. der die Arbeit abgeschlossen werden soll, oder lassen Sie dieses Feld leer, und legen Sie es später bei einer Planungsbesprechung fest. Informationen zum Ändern der Dropdownliste mit Iterationen finden Sie unter Hinzufügen und Ändern von Bereichs- und Iterationspfaden.
Alle Links	Fügen Sie beliebige Linktypen hinzu, z. B. Hyperlinks, Changesets, Quelldateien usw. Auf dieser Registerkarte werden außerdem sämtliche für die Arbeitsaufgabe definierten Links aufgeführt, einschließlich der Links von anderen Registerkarten zur Linksteuerung.
Attachments	Geben Sie ausführlichere Informationen frei, indem Sie der Arbeitsaufgabe Dateien hinzufügen, z. B. E-Mail-Threads, Dokumente, Bilder, Protokolldateien oder andere Dateitypen.
Versionsgeschichte	Überprüfen Sie den vom System erfassten Audit-Trail, und zeichnen Sie zusätzliche Informationen auf. Bei jeder Aktualisierung der Arbeitsaufgabe werden dem Verlauf Informationen hinzugefügt. Der Verlauf enthält das Datum der Änderung, die Person, die die Änderung vorgenommen hat, sowie die geänderten Felder. Sie können dem Verlaufsfeld auch formatierten Text hinzufügen.

Informationen zu anderen Feldern finden Sie im Index von Arbeitsaufgabenfeldern.

Mit dem Nachverfolgen der Arbeit beginnen

Damit Sie mit dem Nachverfolgen der Arbeit beginnen können, benötigen Sie erst ein Teamprojekt. Hier können Sie eines erstellen.

Wenn Sie ein Teamprojekt haben, beginnen Sie mit dem Nachverfolgen der Arbeit:

Hier können Sie sich mit häufigen Aufgaben bei Arbeitsaufgaben vertraut machen: Erste Schritte mit Arbeitsaufgaben.
Verwenden Sie TWA zum Erstellen eines Backlogs. Siehe Erstellen Ihres Backlogs.
Verwenden Sie Project oder Excel zum Erstellen einer Arbeitsablaufstruktur.
Weitere Informationen dazu finden Sie unter Auswählen des Team Foundation-Clients zur Unterstützung Ihrer Aufgaben.

Fragen und Antworten

F: Wie kann ich den Geschäftswert nachverfolgen?

A: Sie können das Prioritätsfeld verwenden, um den Wert verschiedener Storys zu unterscheiden. Oder Sie fügen ein benutzerdefiniertes Feld zu User Story WIT hinzu, dass den relativen Wert der Storys nachverfolgt. Weitere Informationen finden Sie unter Ändern oder Hinzufügen eines benutzerdefinierten Felds.

F: Welche Workflowzustände unterstützt Agile?

A: Diese Diagramme zeigen die wichtigsten Fortschritts- und Regressionszustände von Funktion, User Story, Fehler und Aufgabe. Den Workflow können Sie hier anpassen.

Funktion

User Story

Benutzertext-Workflowstatus, Agile-Prozessvorlage

Fehler

Aufgabe

F: Wie behebe ich einen Fehler als Duplikat?

A: Legen Sie den Status auf "Entfernt" fest, und geben Sie bei Grund "Duplikat" an.

F: Wie erstelle ich eine Verknüpfung zu einem vorhandenen Fehler im Test Runner?

A: Informationen finden Sie unter Aktualisieren eines vorhandenen Fehlers während der Verwendung von Test Runner.