Agiler Workflow in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Wenn Sie den Agile-Prozess in Azure Boards verwenden, helfen Ihnen die folgenden Arbeitsaufgabentypen (Work Item Types, WITs) Ihrem Team, den Fortschritt Ihrer Projekte zu planen und nachzuverfolgen: Epics, Features, Benutzergeschichten, Aufgaben, Probleme/Fehler. Nachdem Sie Ihre Arbeitselementtypen definiert haben, können Sie das Board verwenden, um den Fortschritt nachzuverfolgen, indem Sie den Status dieser Elemente aktualisieren.
Um Einblicke in ein Portfolio von Features, Szenarien oder Benutzererfahrungen zu erhalten, ordnen Produktbesitzer und Programmmanager User Stories Features zu. Wenn ein Team in Sprints arbeitet, werden Aufgaben definiert, die automatisch mit User Stories verknüpft werden. Wenn Sie noch nicht mit dem Agile-Prozess vertraut sind, lesen Sie zunächst den Abschnitt Planen und Nachverfolgen der Arbeit mit Agile.
Aus Webportal oder Microsoft Test Manager können Tester Testfälle für Fehler und Probleme erstellen und ausführen, die verwendet werden, um Codefehler zu verfolgen und Probleme zu blockieren.
Definieren von User Storys
Produktbesitzer definieren und sortieren Benutzergeschichten in der Regel, welche die Arbeit für die Entwicklung von Anwendungen, Anforderungen und Elementen beschreiben. Das Team schätzt dann den erforderlichen Arbeitsaufwand zur Bereitstellung der Elemente mit der höchsten Priorität.
Erstellen Sie User Storys im Bereich zum schnellen Hinzufügen auf der Product Backlog-Seite. Auf dieser Seite können Sie Elemente auch per Drag & Drop neu anordnen oder sie Features zuordnen.
Sie können jede User Story öffnen, um weitere Informationen bereitzustellen und Story Points einzuschätzen. Durch Definieren der Story Points kann Ihr Team das Vorhersagefeature und Geschwindigkeitsdiagramme verwenden, um zukünftige Sprints oder Arbeitsaufwände abzuschätzen. Durch Priorisieren der User Storys auf der Backlog-Seite (die im Feld „Stapelrang“ erfasst werden) können Produktbesitzer*innen angeben, welchen Elementen höhere Priorität zugewiesen werden soll.
Verwenden Sie beim Ausfüllen des Formulars die Anleitungen in der folgenden Tabelle und die gemeinsamen Felder, die für Arbeitsaufgabentypen verwendet werden.
Feld/Registerkarte
Verwendung
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.
Geben Sie die Kriterien an, die erfüllt werden müssen, bevor der Fehler oder die User Story geschlossen werden kann. Beschreiben Sie vor Beginn der Arbeit die Kundenakzeptanzkriterien so klar wie möglich. Durch Gespräche zwischen dem Team und den Kunden zur Festlegung der Akzeptanzkriterien wird sichergestellt, dass das Team über die Kundenerwartungen im Bilde ist. Sie können die Akzeptanzkriterien als Grundlage für Akzeptanztests verwenden, um effektiver zu bewerten, ob ein Element zufriedenstellend abgeschlossen ist
Der Bereich des Kundennutzens, der durch das Epic, das Feature, die Anforderung oder das Backlog Item abgedeckt wird. Mögliche Werte:
- Architektonisch: Technische Dienste zur Implementierung von Business-Funktionen zur Lösung
- Geschäft: Dienste, die die Anforderungen von Kund*innen und Projektbeteiligten erfüllen und so direkt einen Mehrwert für Kund*innen schaffen und zur Unterstützung des Unternehmens beitragen (Standardwert)
Geben Sie den geschätzten Arbeitsaufwand zum Abschließen einer User Story in der vom Team bevorzugten numerischen Maßeinheit an.
Agile-Geschwindigkeitsdiagramme und -Vorhersagetools verweisen auf die Werte in diesem Feld. Weitere Informationen finden Sie im Whitepaper zur Schätzung.
Eine subjektive Bewertung der User Story, des Features oder der Anforderung und der Auswirkungen auf das Geschäft. Zulässige Werte sind:
- 1: Das Produkt darf nicht ohne das Feature ausgeliefert werden.
- 2: Das Produkt darf nicht ohne das Feature ausgeliefert werden, das Problem muss jedoch nicht unmittelbar behandelt werden.
- 3: Die Implementierung des Features ist optional und hängt von Ressourcen, Zeit und Risiko ab.
Eine subjektive Bewertung der relativen Ungewissheit im Hinblick auf den erfolgreichen Abschluss einer User Story. Zulässige Werte sind:
- 1: Hoch
- 2 - Medium
- 3 - Low
Erfassen von Kommentaren im Abschnitt „Diskussion“
Im Abschnitt Diskussion können Sie Kommentare zur durchgeführten Arbeit hinzufügen und überprüfen.
Die Symbolleiste des Rich-Text-Editors wird unter dem Texteingabebereich angezeigt, wenn Sie den Cursor in ein Textfeld setzen, das die Textformatierung unterstützt.
Hinweis
Es gibt kein Arbeitselementfeld „Diskussion”. Filtern Sie zum Abfragen von Arbeitselementen mit Kommentaren aus dem Bereich „Diskussion“ nach dem Feld Verlauf. Der gesamte Inhalt des Texts, der in das Textfeld „Diskussion“ eingegeben wurde, wird dem Feld „Verlauf“ hinzugefügt.
Erwähnen einer Person, einer Gruppe, eines Arbeitselements oder eines Pull Requests
Wählen Sie eines der folgenden Symbole aus, um ein Menü der letzten Einträge zu öffnen, in denen Sie jemanden erwähnt, ein Arbeitselement oder einen Pull Request verknüpft haben. Alternativ können Sie dasselbe Menü öffnen, indem Sie @, # oder ! eingeben.
Geben Sie einen Namen oder eine Nummer ein, um die Menüliste nach Ihrem Eintrag zu filtern. Wählen Sie den Eintrag aus, den Sie hinzufügen möchten. Um eine Gruppe in die Diskussion zu bringen, geben Sie @ gefolgt vom Gruppennamen ein (z. B. ein Team oder eine Sicherheitsgruppe).
Bearbeiten oder Löschen eines Kommentars
Um Ihre Diskussionskommentare zu bearbeiten oder zu löschen, wählen Sie 
Bearbeiten oder das Aktionssymbol (
) und dann Löschen aus.
Hinweis
Zum Bearbeiten und Löschen von Kommentaren ist Azure DevOps Server 2019 Update 1 oder höher erforderlich.
Nachdem Sie den Kommentar aktualisiert haben, wählen Sie Aktualisieren aus. Um den Kommentar zu löschen, bestätigen Sie, dass Sie ihn löschen möchten. Auf der Registerkarte Verlauf im Arbeitselementformular wird ein vollständiger Überwachungspfad aller bearbeiteten und gelöschten Kommentare beibehalten.
Wichtig
Bei einer lokalen Azure DevOps Server-Bereitstellung konfigurieren Sie einen SMTP-Server, damit Teammitglieder Benachrichtigungen empfangen.
Hinzufügen einer Reaktion auf einen Kommentar
Fügen Sie einem Kommentar Reaktionen hinzu, indem Sie in der oberen rechten Ecke des Kommentars ein Smileysymbol auswählen. Alternativ können Sie die Symbole am unteren Rand eines Kommentars auswählen, die neben vorhandenen Reaktionen angezeigt werden. Um Ihre Reaktion zu entfernen, wählen Sie die Reaktion unten im Kommentar aus. Die folgende Abbildung zeigt ein Beispiel für das Hinzufügen einer Reaktion und die Anzeige von Reaktionen zu einem Kommentar.
Speichern eines Kommentars ohne Speichern des Arbeitselements
Hinweis
Diese Funktion ist ab Azure DevOps Server 2022.1 verfügbar.
Wenn Sie nur die Berechtigung haben, Kommentare zur Diskussion für ein Arbeitselement hinzuzufügen, können Sie dies tun, indem Sie Kommentare speichern. Diese Berechtigung wird über Bereichspfadknoten und die Berechtigung zum Bearbeiten von Arbeitselementkommentaren in diesem Knoten gesteuert. Weitere Informationen finden Sie unter Festlegen von Berechtigungen für die Arbeitsnachverfolgung – Erstellen untergeordneter Knoten, Ändern von Arbeitselementen unter einem Bereichs- oder Iterationspfad.
Nachdem Sie die Kommentare gespeichert haben, müssen Sie das Arbeitselement nicht mehr speichern.
Hinweis
Wenn Sie Änderungen am Steuerelement Diskussion speichern, wird nur der Kommentar gespeichert. Es werden keine Arbeitselementregeln ausgeführt, die für den Arbeitselementtyp definiert sind.
Nachverfolgen des Status
Im Verlauf der Arbeit ändern Sie das Feld „Zustand“, um den Status zu aktualisieren. Optional können Sie einen Grund angeben. Die Felder „Zustand“ und „Grund“ werden im Kopf des Arbeitselementformulars angezeigt.
Agile-Workflowstatus
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. Diese Diagramme zeigen die wichtigsten Fortschritts- und Regressionszustände der User Story, des Fehlers und der Aufgaben-WITs.
| User Story | Bug | Aufgabe |
|---|---|---|
|
|
|
Eine typische Workflowprogression für eine User Story:
- Produktbesitzer erstellen 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 Arbeit während des Sprints abzuschließen.
- Eine User Story wird auf Fertiggestellt gesetzt, wenn das Team alle zugeordneten Aufgaben abgeschlossen hat und Komponententests für die Story erfolgreich abgeschlossen wurden.
- Eine User Story wird in den Zustand Abgeschlossen verschoben, wenn die jeweiligen Produktbesitzer zustimmen, dass die Story gemäß den Akzeptanzkriterien implementiert wurde und die Akzeptanztests erfolgreich waren.
Aktualisieren des Status mit dem Board oder mit Taskboards
Teams können auf dem Board den Status von Anforderungen und auf dem Taskboard den Status von Aufgaben aktualisieren. Wenn Elemente in eine neue Zustandsspalte gezogen werden, werden sowohl das Feld „Zustand“ als auch das Feld „Grund“ aktualisiert.
Sie können das Board anpassen, um weitere Swimlanes oder Spalten zu unterstützen. Weitere Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.
Zuordnen von User Stories zu Funktionen
Wenn Sie eine Sammlung von Produkten oder Benutzererfahrungen verwalten, sollten Sie den Umfang und den Status der Arbeit für das Produktportfolio anzeigen. Sie können den Umfang und den Fortschritt der Arbeit anzeigen, indem Sie Features definieren und User Storys zu Features zuordnen.
Mithilfe von Portfolio Backlogs können Sie einen Drilldown zwischen Backlogs durchführen, um den gewünschten Detailgrad anzuzeigen. Außerdem verwenden Sie Portfolio Backlogs, um einen teamübergreifenden Rollup der in Bearbeitung befindlichen Aufgaben anzuzeigen, wenn Sie eine Hierarchie von Teams einrichten.
Definieren von Aufgaben
Wenn das Team die Arbeiten in Sprints verwaltet, können sie die Sprint-Backlog-Seite verwenden, um die Arbeit in verschiedene Aufgaben zu untergliedern.
Geben Sie der Aufgabe einen Namen und schätzen Sie die dafür erforderliche Arbeit ab.
Wenn Sie Agile-Prozesse verwenden, prognostizieren Teams die Arbeit und definieren Aufgaben am Anfang jedes Sprints. Jedes Teammitglied führt dann eine Teilmenge dieser Aufgaben aus. Zu Aufgaben zählen Entwicklung, Tests und andere Arbeitsschritte. Zum Beispiel können Entwickler*innen Aufgaben definieren, um User Storys zu implementieren, und Tester*innen können Aufgaben definieren, um Testfälle zu schreiben und auszuführen.
Beim Schätzen des Aufwands in Stunden oder Tagen definieren Teams Aufgaben sowie die optionalen Felder Verbleibende Arbeit und Aktivität.
Feld/Registerkarte
Verwendung
Der geschätzte Arbeitsaufwand, der zum Abschluss einer Aufgabe erforderlich ist. In der Regel wird dieses Feld nicht geändert, nachdem es zugewiesen ist. Sie können die Arbeit in Stunden oder in Tagen angeben. Es gibt keine inhärenten Zeiteinheiten, die diesem Feld zugeordnet sind.
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-Burndowndiagramm und die folgenden SQL Server-Berichte berechnet: 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.
Der Arbeitsaufwand zum Implementieren einer Aufgabe.
Wählen Sie den Aktivitätstyp aus, den diese Aufgabe darstellt, wenn das Team die Sprintkapazität nach Aktivität schätzt.
Die Produktbuildnummer, in der der Code enthalten ist oder ein Fehler behoben wird.
Nachverfolgen des Teststatus
Verfolgen Sie den Testfortschritt anhand von User Stories und Codefehlern nach.
Testen von User Stories
Über das Webportal oder Test Manager können Sie Testfälle erstellen, die automatisch mit einer User Story oder einem Fehler verknüpft werden. Alternativ können Sie eine User Story über die Registerkarte 
Links mit einem Testfall verknüpfen.
Der Testfall enthält mehrere Felder, von denen viele automatisiert und in Test Manager und den Buildprozess integriert sind. Eine Beschreibung der einzelnen Felder finden Sie unter Erstellen einer Abfrage basierend auf Build- und Testintegrationsfeldern.
Auf der Registerkarte „Links“ () werden die Links zu allen User Storys und Fehlern in einem Testfall erfasst. 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. Durch das Definieren dieser Links werden Informationen unterstützt, die im Bericht Übersicht über Storys angezeigt werden.
Nachverfolgen von Codefehlern
Sie können Fehler über das Webportal, Visual Studio oder beim Testen mit Test Manager erstellen.
Definitionen für allgemeine Felder zur Arbeitsnachverfolgung
In den meisten Arbeitselementen werden folgende Felder und Registerkarten angezeigt. Auf jeder Registerkarte werden bestimmte Informationen nachverfolgt, z. B. 
Verlauf, Links oder 
Anhänge. Diese drei Registerkarten enthalten einen Änderungsverlauf, eine Ansicht der verknüpften Arbeitselemente sowie Funktionen zum Anzeigen und Anfügen von Dateien.
Das einzige Pflichtfeld für alle Arbeitselementtypen ist Titel. Wenn Sie eine Arbeitsaufgabe speichern, weist das System ihr eine eindeutige ID zu. Das Pflichtfeld ist im Formular gelb hervorgehoben. Informationen zu allen anderen Feldern finden Sie im Index der Arbeitselementfelder.
Hinweis
Je nach Anpassungen, die Sie an Ihrem Prozess und Projekt vornehmen, gibt es möglicherweise weitere Pflichtfelder.
Feld/Registerkarte
Verwendung
Geben Sie eine höchstens 255 Zeichen lange Beschreibung ein. Sie können den Titel später jederzeit ändern.
Weisen Sie die Arbeitsaufgabe dem für die Bearbeitung zuständigen Teammitglied zu.
Wenn das Arbeitselement 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.
Verwenden Sie zunächst die Standardeinstellung. Aktualisieren Sie den Wert bei Zustandsänderungen. Jeder Zustand ist einem Standardgrund zugeordnet.
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 den Bereichen finden Sie unter Definieren von Bereichspfaden und Zuweisen zu einem Team.
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 den Iterationen finden Sie unter Definieren von Iterationspfaden (Sprints) und Konfigurieren von Teamiterationen.
Überprüfen Sie den vom System erfassten Audit-Trail, und zeichnen Sie zusätzliche Informationen auf.
Bei jeder Aktualisierung des Arbeitselements 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.
Fügen Sie beliebige Linktypen hinzu, z. B. Hyperlinks, Changesets, Quelldateien usw.
Auf dieser Registerkarte werden auch alle Links aufgeführt, die für das Arbeitselement definiert sind.
Geben Sie ausführlichere Informationen frei, indem Sie der Arbeitsaufgabe Dateien hinzufügen, z. B. E-Mail-Threads, Dokumente, Bilder, Protokolldateien oder andere Dateitypen.
Anpassen von Arbeitsaufgabentypen
Bei den meisten Arbeitselementtypen können Sie Felder hinzufügen, den Workflow ändern, benutzerdefinierte Regeln hinzufügen und dem Arbeitselementformular benutzerdefinierte Seiten hinzufügen. Sie können auch benutzerdefinierte Arbeitselementtypen hinzufügen. Weitere Informationen finden Sie unter Anpassen eines Vererbungsprozesses.
Bei den meisten Arbeitselementtypen können Sie Felder hinzufügen, den Workflow ändern, benutzerdefinierte Regeln hinzufügen und dem Arbeitselementformular benutzerdefinierte Seiten hinzufügen. Sie können auch benutzerdefinierte Arbeitselementtypen hinzufügen. Weitere Informationen finden Sie je nach Prozessmodell Ihres Projekts unter Anpassen eines Vererbungsprozesses oder Anpassen des lokalen XML-Prozessmodells.
Verwandte Artikel
- Erstellen eines Projekts
- Hinzufügen von Arbeitsaufgaben zum Verwalten eines Projekts
- Erstellen eines Backlogs
- Verwalten des Zugriffs auf bestimmte Features
- Informationen zu Standardberechtigungen und Zugriffsebenen für Azure Boards
Nachverfolgen von Issues
Issues werden verwendet, um Ereignisse nachzuverfolgen, die den Fortschritt oder den Versand einer User Story blockieren können. Fehler hingegen werden verwendet, um Codefehler nachzuverfolgen. Sie können ein Issue über das Widget „Neues Arbeitselement“, das einem Teamdashboard hinzugefügt wurde, oder über das Menü Neu auf der Seite „Abfragen“ hinzufügen.
Arbeitselemente, die Sie über das Widget hinzufügen, werden automatisch auf den Standardbereich und die Iterationspfade Ihres Teams beschränkt. Informationen zum Ändern des Teamkontexts finden Sie im Artikel zum Wechseln des Teamkontexts.
Nachverfolgen des Geschäftswerts
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. Informationen dazu finden Sie unter Anpassen eines Felds für einen Prozess.
Reihenfolge der Backlogliste
Das Feld Stapelrang wird verwendet, um die relative Rangfolge von User Storys nachzuverfolgen, wird jedoch standardmäßig nicht im Arbeitselementformular angezeigt. Die Reihenfolge der Elemente auf der Backlogseite richtet sich danach, wo die Elemente auf der Seite hinzugefügt bzw. wohin sie verschoben wurden. Wenn Sie Elemente durch Ziehen verschieben, aktualisiert ein Hintergrundprozess dieses Feld.