Agiler Workflow in Azure Boards

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

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 WITs definiert haben, können Sie das Kanban-Board verwenden, um den Fortschritt nachzuverfolgen, indem Sie den Status dieser Elemente aktualisieren.

Conceptual image of Agile process, work item types used to plan and track work.

Um Einblicke in ein Portfolio von Features, Szenarien oder Benutzererfahrungen zu erhalten, ordnen Produktbesitzer und Programmmanager User StoriesFeatures 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.

Screenshot of User Story work item form.

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“

Verwenden Sie den Abschnitt Diskussion, um Kommentare zur durchgeführten Arbeit hinzuzufügen und zu überprüfen.

Screenshot showing the Discussion section within a work item form.

Die Symbolleiste des Rich-Text-Editors wird unterhalb des Texteingabebereichs angezeigt. Sie wird angezeigt, wenn Sie ein Textfeld auswählen, das die Textformatierung unterstützt.

Screenshot of Discussion section, Rich Text Editor toolbar.

Hinweis

Es gibt kein Arbeitselementfeld Diskussion. Zum Abfragen von Arbeitselementen mit Kommentaren, die im Bereich „Diskussion“ eingegeben wurden, filtern Sie die Elemente nach dem Feld Verlauf. Der gesamte Inhalt des in das Textfeld „Diskussion“ eingegebenen Texts wird dem Feld „Verlauf“ hinzugefügt.

Erwähnen einer Person, einer Gruppe, eines Arbeitselements oder eines Pull Requests

Um ein Menü der zuletzt vorgenommenen Einträge zu öffnen, die Sie erstellt haben, um eine Person zu erwähnen oder ein Arbeitselement oder einen Pull Request zu verknüpfen, wählen Sie , aus, oder geben Sie @, # oder ! ein.

Screenshot of Discussion section, at-mention drop-down menu.

Geben Sie einen Namen oder eine Nummer ein, und die Menüliste wird nach Ihrem Eintrag gefiltert. Wählen Sie den Eintrag aus, den Sie hinzufügen möchten. Um eine Gruppe in die Diskussion zu bringen, geben Sie @ und den 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, das Aktionssymbol und dann Löschen aus.

Screenshot of Discussion section, Edit, Delete actions.

Hinweis

Zum Bearbeiten und Löschen von Kommentaren ist Azure DevOps Server 2019 Update 1 oder höher erforderlich.

Wählen Sie nach dem Aktualisieren des Kommentars 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.

Verwenden Sie das Steuerelement @erwähnen, um ein anderes Teammitglied über die Diskussion zu benachrichtigen. Geben Sie @ und den Namen des Teammitglieds ein. Um auf ein Arbeitselement zu verweisen, verwenden Sie das Steuerelement #ID. Geben Sie # ein. Daraufhin wird eine Liste der Arbeitselemente angezeigt, auf die Sie zuletzt verwiesen haben, und Sie können in der Liste eine Auswahl treffen.

Um auf ein Arbeitselement zu verweisen, verwenden Sie das Steuerelement #ID. Geben Sie # ein. Daraufhin wird eine Liste der Arbeitselemente angezeigt, auf die Sie zuletzt verwiesen haben, und Sie können in der Liste eine Auswahl treffen.

Sie können Kommentare nicht bearbeiten oder löschen, nachdem Sie sie eingegeben haben.

Wichtig

Bei einer lokalen Azure DevOps Server-Bereitstellung müssen Sie einen SMTP-Server konfigurieren, damit Teammitglieder Benachrichtigungen erhalten.

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.

Screenshot of Discussion control, Add reactions to a comment.

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.

Screenshot of Discussion section, save comment.

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.

Screenshot of Bug work item form, header area.

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
Conceptual image of User Story workflow states, Agile process. Conceptual image of Bug workflow states, Agile process. Conceptual image of Task workflow states, Agile process.

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 Kanban- oder Taskboards

Teams können auf dem Kanban-Board den Status von Anforderungen und auf dem Sprint-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.

Screenshot of Track progress on the Kanban board.

Sie können das Kanban-Board anpassen, um weitere Swimlanes oder Spalten zu schaffen. 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.

Screenshot of Sprint backlog, add task.

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

Screenshot of Agile task work item form.

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.

Screenshot of Test plan web portal.

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.

Screenshot of test case form.

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.

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 des lokalen XML-Prozessmodells.

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.

Screenshot of Add work item from a New work item widget.

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.