Teilen über

Informationen zu Standardprozessen und Prozessvorlagen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Azure Boards bietet verschiedene Prozesse zur Auswahl für die Verwaltung von Arbeitselementen. Die Wahl des richtigen Prozesses ist entscheidend für die Optimierung eines Projektablaufs und die Sicherstellung seines Erfolgs. In diesem Artikel untersuchen wir die verschiedenen Prozesse, die mit Azure Boards verfügbar sind. Dieser Artikel enthält auch Hinweise zur Auswahl des für Ihr Projekt am besten geeigneten Verfahrens.

Wenn Sie ein Projekt erstellen, wählen Sie einen Prozess oder eine Prozessvorlage basierend auf dem Prozessmodell aus, für das Ihre Organisation oder Sammlung erstellt wurde. Bevor Sie einen Prozess für Ihr Projekt auswählen, sollten Sie sich mit den folgenden Begriffen vertraut machen.

Begriff Beschreibung
Prozessmodell Bezieht sich auf das Modell, das verwendet wird, um Projekte zu unterstützen, die für eine organization- oder Projektsammlung erstellt wurden. Für ein Projekt wird jeweils nur ein Prozessmodell unterstützt.
Prozess Definiert die Bausteine des Arbeitselementnachverfolgungssystems und unterstützt das Vererbungsprozessmodell für Azure Boards. Dieses Modell unterstützt die Anpassung von Projekten über eine WYSIWYG-Benutzeroberfläche (What You See Is What You Get).
Prozessvorlage Definiert die Bausteine des Arbeitselementnachverfolgungssystems und anderer Subsysteme, auf die Sie über Azure DevOps zugreifen. Prozessvorlagen werden nur mit den Gehosteten XML- und lokalen XML-Prozessmodellen verwendet. Sie können Projekte anpassen, indem Sie XML-Definitionsdateien für Prozessvorlagen ändern und importieren.

Die Arbeitsverfolgungsobjekte, die in den Standardprozessen und Prozessvorlagen enthalten sind, nämlich Basic, Agile, Capability Maturity Model Integration (CMMI) und Scrum, sind identisch. Sie sind in diesem Artikel zusammengefasst.

Tipp

Bei Azure DevOps Server können Sie zwischen der Verwendung des geerbten Prozessmodells und des lokalen XML-Prozessmodells wählen. Weitere Informationen finden Sie im Abschnitt Wählen Sie das Prozessmodell für Ihre Projektsammlung in Passen Sie Ihre Arbeitsverfolgung an. So greifen Sie auf die neuesten Versionen der Standardprozesse/-prozessvorlagen zu

Standardprozesse

Die Standardprozesse unterscheiden sich hauptsächlich in den Arbeitselement-Typen, die sie für die Planung und Verfolgung der Arbeit bereitstellen. Die Standardprozesse sind:

  • Basic: Ist die leichteste und befindet sich in einer selektiven Vorschau.
  • Scrum: Ist das nächste Leichtgewicht.
  • Agile: Unterstützt viele Begriffe der Agile-Methode.
  • CMMI: Bietet die meiste Unterstützung für formale Prozesse und Änderungsmanagement.

Hinweis

Der Basic-Prozess ist mit Azure DevOps Server 2019 Update 1 und höheren Versionen verfügbar.

Grundlegend

Wählen Sie Basic, wenn Ihr Team das einfachste Modell wünscht, das die Arbeitselement-Typen Issue, Task und Epic zur Verfolgung der Arbeit verwendet.

Aufgaben unterstützen die Nachverfolgung der verbleibenden Arbeit.

Basic-Arbeitselementtypen

Agile Softwareentwicklung

Wählen Sie Agile aus, wenn Ihr Team Agile-Planungsmethoden einschließlich Scrum verwendet und Entwicklungs- und Testaktivitäten separat nachverfolgt. Dieses Verfahren eignet sich hervorragend für die Verfolgung von User Stories und (optional) Fehlern auf dem Kanban-Board. Sie können Bugs und Aufgaben auch auf dem Taskboard verfolgen.

Weitere Informationen zu Agile-Methoden finden Sie unter Agile Alliance.

Aufgaben unterstützen die Nachverfolgung von „Ursprüngliche Schätzung“, „Verbleibende Arbeit“ und „Abgeschlossene Arbeit“.

Agile-Arbeitselementtypen

Scrum

Wählen Sie Scrum aus, wenn Ihr Team Scrum praktiziert. Dieses Verfahren eignet sich hervorragend für die Verfolgung von Produktrückständen und Fehlern auf dem Kanban-Board. Sie können auch Produktrückstände und Fehler in Aufgaben auf dem Taskboard aufteilen.

Dieser Prozess unterstützt die von der Scrum-Organisation definierte Scrum-Methodik.

Aufgaben unterstützen nur die Verfolgung der verbleibenden Arbeit.

Scrum-Arbeitsaufgabentypen

CMMI

Wählen Sie CMMI aus, wenn Ihr Team formalere Projektmethoden einsetzt, die ein Framework für die Prozessverbesserung und eine überprüfbare Aufzeichnung von Entscheidungen erfordern. Mit diesem Prozess können Sie Anforderungen, Änderungsanforderungen, Risiken und Überprüfungen (Reviews) nachverfolgen.

Dieser Prozess unterstützt formale Change Management-Aktivitäten. Aufgaben unterstützen die Nachverfolgung von „Ursprüngliche Schätzung“, „Verbleibende Arbeit“ und „Abgeschlossene Arbeit“.

CMMI-Arbeitsaufgabentypen

Wenn Sie mehr als zwei oder drei Rückstandsebenen benötigen, fügen Sie je nach dem von Ihnen verwendeten Prozessmodell weitere hinzu:

Hauptunterschiede zwischen den Standardprozessen

Die Standardprozesse wurden entworfen, um die Anforderungen der meisten Teams zu erfüllen. Wenn Ihr Team ungewöhnliche Anforderungen hat und eine Verbindung zu einem lokalen Server herstellt, passen Sie einen Prozess an und erstellen Sie dann das Projekt. Sie können auch ein Projekt aus einem Prozess erstellen und dann das Projekt anpassen.

Die folgende Tabelle fasst die Hauptunterschiede zwischen den Arbeitselement-Typen und -Status zusammen, die von den vier Standardprozessen verwendet werden.

Nachverfolgungsbereich

Grundlegend

Agile Softwareentwicklung

Scrum

CMMI

Workflowzustände

  • Aufgabenplanung
  • Ausführen
  • Fertig
  • Neu
  • Aktiv
  • Gelöst
  • Geschlossen
  • Entfernt
  • Neu
  • Genehmigt
  • Committet
  • Fertig
  • Entfernt
  • Proposed
  • Aktiv
  • Gelöst
  • Geschlossen

Produktplanung (siehe Anmerkung 1)

  • Problem
  • User Story
  • Fehler (optional)
  • Product Backlog Item
  • Fehler (optional)
  • Anforderung
  • Fehler (optional)

Rückstände im Portfolio (siehe Anmerkung 2)

  • Epic
  • Epic
  • Funktion
  • Epic
  • Funktion
  • Epic
  • Funktion

Aufgaben- und Sprintplanung (siehe Anmerkung 3)

  • Aufgabe
  • Aufgabe
  • Fehler (optional)
  • Aufgabe
  • Fehler (optional)
  • Aufgabe
  • Fehler (optional)

Verwaltung des Bug-Backlogs (siehe Anmerkung 1)

  • Abgang
  • Bug
  • Bug
  • Bug

Problem- und Risikomanagement

  • Problem
  • Problem
  • Impediment
  • Problem
  • Risiko
  • Überprüfung

Hinweise:

  1. Fügen Sie Arbeitsaufgaben aus dem Produkt-Backlog oder Kanban-Board hinzu. Das Produkt-Backlog zeigt eine einzelne Ansicht des aktuellen Arbeitsrückstands an, die dynamisch neu angeordnet und gruppiert werden kann. Produktbesitzer können Arbeit schnell priorisieren und Abhängigkeiten und Beziehungen darstellen. Außerdem kann jedes Team konfigurieren, wie Fehler in seinen Backlogs und Boards angezeigt werden sollen.
  2. Definieren Sie eine Hierarchie von Portfolio-Backlogs, um den Arbeitsumfang über mehrere Teams hinweg zu verstehen und zu sehen, wie diese Arbeit in umfassendere Initiativen umgewandelt wird. Jedes Team konfiguriert, welche Portfolio-Backlogs für ihre Verwendung angezeigt werden.
  3. Definieren Sie Aufgaben aus dem Sprint-Backlog und dem Taskboard. Mit der Kapazitätsplanung können Teams schnell feststellen, ob sie für einen Sprint über- oder unterkapazitär sind.

Workflowzustände, Übergänge und Gründe

Workflow-Zustände unterstützen die Verfolgung des Status der Arbeit, wenn sie von einem New-Status in einen Closed- oder einen Done-Status übergeht. Jeder Workflow besteht aus einem Satz von Zuständen, den gültigen Übergängen zwischen den Zuständen und den Gründen für den Übergang der ausgewählten Arbeitsaufgabe in den ausgewählten Zustand.

Wichtig

Für Azure DevOps Services und Azure DevOps Server 2019 unterstützen die Standardworkflowübergänge jeden Übergang zwischen Zuständen. Passen Sie diese Workflows an, um einige Übergänge einzuschränken. Weitere Informationen finden Sie unter Anpassen der Objekte für die Arbeitsnachverfolgung zur Unterstützung der Prozesse Ihres Teams.

Sehen Sie sich außerdem die unterstützten Workflow-Übergänge für jeden Arbeitselementtyp an, indem Sie die Marketplace-Erweiterung State Model Visualization installieren. Diese Erweiterung fügt einen neuen Hub unter Boards mit der Bezeichnung State Visualizer hinzu. Wählen Sie auf dieser Seite einen Arbeitselement-Typ und sehen Sie sich das Workflow-Statusmodell an.

Die folgenden Diagramme zeigen den typischen Vorwärtsverlauf der Arbeitselement-Typen, die zur Verfolgung von Arbeits- und Codefehlern für die drei Standardprozesse verwendet werden. Sie zeigen außerdem Regressionen früher Zustände und Übergänge zu entfernten Zuständen. Jedes Bild zeigt nur den Standardgrund, der mit dem Übergang verknüpft ist.

User Story

Screenshot, der die User Story-Workflow-Zustände bei Verwendung des Agile-Prozesses zeigt.

Funktion

Screenshot, der den Status des Feature-Workflows bei Verwendung des Agile-Prozesses zeigt.

Epic

Screenshot, der den Status des Epic-Workflows bei Verwendung des Agile-Prozesses zeigt.

Bug

Screenshot, der den Status des Bug-Workflows bei Verwendung des Agile-Prozesses zeigt

Aufgabe

Screenshot, der den Status des Aufgaben-Workflows bei Verwendung des Agile-Prozesses zeigt

Die meisten von Agile-Tools verwendeten Arbeitselement-Typen, die in Backlogs und Boards erscheinen, unterstützen Any-to-Any-Übergänge. Aktualisieren Sie den Status eines Arbeitselements mit Hilfe des Kanban-Boards oder des Taskboards, indem Sie es in die entsprechende Statusspalte ziehen.

Ändern Sie den Workflow, um andere Zustände, Übergänge und Gründe zu unterstützen. Weitere Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.

Arbeitselementzustände

Wenn Sie den Zustand eines Arbeitselements in Removed, Closed oder Done ändern, reagiert das System wie folgt:

  • Closed/Done: Arbeitselemente in diesem Zustand werden nicht auf Portfolio Backlog- oder Backlogseiten angezeigt. Sie erscheinen auf den Sprint-Backlog-Seiten, dem Kanban-Board und dem Taskboard. Wenn Sie die Portfolio-Backlog-Ansicht in Backlog-Elemente anzeigen ändern, um z. B. Features zu Produkt-Backlog-Elementen anzuzeigen, werden Arbeitsaufgaben im Status Closed und Done angezeigt.
  • Removed: Arbeitselemente in diesem Zustand werden in keinem Backlog oder Board angezeigt.

Ihr Projekt behält Arbeitselemente, solange das Projekt aktiv ist. Selbst wenn Sie Arbeitselemente auf Closed, Done oder Removed festlegen, behält der Datenspeicher einen Datensatz bei. Verwenden Sie einen Datensatz, um Abfragen oder Berichte zu erstellen.

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden in den Backlogs und Boards nicht mehr angezeigt, wenn ihr Changed Date-Wert größer als 183 Tage (etwa ein halbes Jahr) ist. Sie können diese Elemente dennoch mit einer Abfrage auflisten. Wenn Sie möchten, dass sie in einem Rückstand oder einer Tafel erscheinen, können Sie eine kleine Änderung an ihnen vornehmen, wodurch die Uhr zurückgesetzt wird.

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden in den Backlogs und Boards nicht mehr angezeigt, wenn der Wert Changed Date mehr als ein Jahr alt ist. Sie können diese Elemente dennoch mit einer Abfrage auflisten. Wenn Sie möchten, dass sie in einem Rückstand oder einer Tafel erscheinen, können Sie eine kleine Änderung an ihnen vornehmen, wodurch die Uhr zurückgesetzt wird.

Wenn Sie Arbeitselemente endgültig löschen müssen, finden Sie Informationen hierzu unter Entfernen oder Löschen von Arbeitselementen.

Arbeitselement-Typen für alle Prozesse hinzugefügt

Die folgenden Arbeitselement-Typen werden zu allen Prozessen außer dem Basicprozess hinzugefügt.

Die Abbildung zeigt die von Testplänen, Microsoft Test Managers, Meine Arbeit und Feedback verwendeten Arbeitselement-Typen.

Ihr Team kann diese Typen mit Hilfe des entsprechenden Tools erstellen und bearbeiten.

Tool Arbeitsaufgabentypen
Microsoft Test Manager Test Plan, Test Suite, Test Case Shared Steps, Shared Parameters
Feedback anfordern Feedback Request, Feedback Response
„Meine Arbeit“ (aus Team Explorer), Code Review Code Review Request, Code Review Response

Arbeitselemente dieser Typdefinitionen sollten nicht manuell erstellt werden und werden dann der Kategorie Hidden Types hinzugefügt. Arbeitselement-Typen, die der Kategorie Hidden Types hinzugefügt wurden, erscheinen nicht in den Menüs, die neue Arbeitselemente erstellen.

Arbeitselementtypen, die die Testumgebung unterstützen

Arbeitselement-Typen, die die Testerfahrung unterstützen und mit Test Manager und dem Webportal zusammenarbeiten, sind durch die in der folgenden Abbildung dargestellten Verknüpfungstypen miteinander verbunden.

Bildschirmsymbol, das die Arbeitselement-Typen des Testmanagements zeigt.

Zeigen Sie im Webportal oder in Microsoft Test Manager an, welche Testfälle für eine Testsammlung definiert sind, und zeigen Sie an, welche Testsammlungen für einen Testplan definiert sind. Diese Objekte sind jedoch nicht miteinander durch Linktypen verknüpft. Passen Sie diese Arbeitselement-Typen wie alle anderen Arbeitselement-Typen an. Weitere Informationen finden Sie unter Anpassen der Objekte für die Arbeitsnachverfolgung zur Unterstützung der Prozesse Ihres Teams.

Wenn Sie den Workflow für den Testplan und die Testsammlung ändern, müssen Sie möglicherweise die Prozesskonfiguration wie hierbeschrieben aktualisieren. Definitionen der einzelnen Testfelder finden Sie unter Abfrage, basierend auf Build- und Testintegrationsfeldern.