Standardprozesse und Prozessvorlagen

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

Azure Boards bietet mehrere Prozesse zum Verwalten von Arbeitsaufgaben. Wenn Sie den richtigen Prozess auswählen, können Sie Ihren Projektworkflow optimieren und Ihr Team für den Erfolg einrichten. In diesem Artikel werden die prozesse beschrieben, die in Azure Boards verfügbar sind, und hilft Ihnen bei der Auswahl der Prozesse, die zu Ihrem Projekt passen.

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 einen visuellen Editor im Azure DevOps-Webportal.
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 Standardprozesstypen sind Basic, Agile, Capability Maturity Model Integration (CMMI) und Scrum. Die Arbeitsverfolgungsobjekte in den Standardprozessen und Prozessvorlagen sind identisch. In diesem Artikel werden sie zusammengefasst.

Tipp

Mit Azure DevOps Server können Sie entweder das geerbte Prozessmodell oder das lokale XML-Prozessmodell auswählen. Weitere Informationen finden Sie unter Auswählen des Prozessmodells für Ihre Projektsammlung. So greifen Sie auf die neuesten Versionen der Standardprozesse oder Prozessvorlagen zu:

Vererbtes Prozessmodell: Öffnen Sie die Verarbeitet Seite. Weitere Informationen finden Sie unter Verwalten von Prozessen.
Lokales XML-Prozessmodell:
- Installieren oder aktualisieren Sie auf die neueste Version von Azure DevOps Server.
- Laden Sie die komprimierte Vorlagendatei mit dem Prozessvorlagen-Manager herunter. Verwenden Sie eine Version von Visual Studio auf derselben Versionsebene wie Azure DevOps Server. Sie können die neueste Version von Visual Studio Community kostenlos installieren.
- Greifen Sie auf die neuesten Standardprozessvorlagen zu, die auf Azure DevOps Server installiert sind, z. B.: %programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033. Beschreibungen der einzelnen Dateien und Ordner finden Sie unter Übersicht der Prozessvorlagendateien.

Standardprozesse

Die Standardprozesse unterscheiden sich hauptsächlich in den Arbeitsaufgabentypen, die sie für die Planung und Nachverfolgung von Arbeiten bereitstellen. Verwenden Sie den folgenden Leitfaden, um den Prozess auszuwählen, der Ihrem Team entspricht:

Wählen Sie Basic für den einfachsten Einstieg – verfolgen Sie Arbeit als Epics, Issues und Tasks.
Wählen Sie Agile aus, wenn Ihr Team Agile-Methoden verwendet und Sie User Stories mit separaten Entwicklungs- und Testaktivitäten nachverfolgen möchten.
Wählen Sie Scrum aus, wenn Ihr Team nach Scrum arbeitet und Produktrückstandselemente und Fehler nachverfolgt.
Wählen Sie CMMI aus, wenn Ihr Team formales Änderungsmanagement, einen auditierbaren Datensatz von Entscheidungen und die Nachverfolgung für Anforderungen, Änderungsanforderungen, Risiken und Rezensionen benötigt.

Auswählen des richtigen Prozesses

Wenn Sie nicht sicher sind, welcher Prozess zu Ihrem Team passt, verwenden Sie die folgenden Szenarien als Ausgangspunkt:

Scenario	Empfohlener Prozess	Warum?
Sie sind neu bei Azure Boards oder möchten die leichteste Nachverfolgung.	Basic	Drei Arbeitsaufgabentypen (Epic, Issue, Task) und ein einfacher `To Do` / `Doing` / `Done` Workflow.
Ihr Team praktiziert Agile, verfolgt Benutzergeschichten und trennt die Entwicklung von der Testarbeit.	Agile Softwareentwicklung	Benutzerberichte mit separater Fehlerverfolgung; erweiterte Status (`New`, `Active`, `Resolved`, `Closed`, `Removed`).
Ihr Team praktiziert Scrum mit Sprints, Produktrückstandselementen und Hindernissen.	Scrum	Produkt-Backlog-Elemente und Bugs auf dem Board; Status `Approved` und `Committed` sind direkt Scrum-Zeremonien zugeordnet.
Sie arbeiten in einer regulierten Umgebung, die eine formale Änderungskontrolle, einen überprüfbaren Datensatz von Entscheidungen sowie risiko- und überprüfungsnachverfolgung erfordert.	CMMI	Fügt Anforderungs-, Änderungsanforderungs-, Risiko- und Überprüfungsaufgabentypen hinzu und unterstützt formale Change-Management-Aktivitäten.

Wichtig

Sie können den Basisprozess eines Projekts nach dem Erstellen des Projekts nicht mehr ändern. Sie können einen geerbten Prozess anpassen , um Felder, Zustände und Arbeitsaufgabentypen hinzuzufügen, oder Sie können ein neues Projekt für einen anderen Prozess erstellen und Arbeitsaufgaben zwischen Projekten verschieben.

Hinweis

Zum Auswählen oder Anpassen eines Prozesses ist eine Mitgliedschaft in der Gruppe Project Sammlungsadministratoren erforderlich. Weitere Informationen finden Sie in der Kurzübersicht zu Standardberechtigungen.

Prozess	Arbeitsaufgabenhierarchie
Basic 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.
Agile Softwareentwicklung Wählen Sie Agile aus, wenn Ihr Team Agile-Planungsmethoden einschließlich Scrum verwendet und Entwicklungs- und Testaktivitäten separat nachverfolgt. Dieser Prozess eignet sich hervorragend zum Nachverfolgen von User Stories und optional zum Bearbeiten von Fehlern auf dem 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“.
Scrum Wählen Sie Scrum aus, wenn Ihr Team Scrum praktiziert. Dieser Prozess eignet sich hervorragend für die Verfolgung von Produkt Rückstand Items und Bugs auf dem 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.
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“.

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

Vererbung: Passen Sie Ihre Backlogs oder Boards für einen Prozess an
Gehostetes XML oder ortsfestes XML: Portfolio-Rückstände hinzufügen

Hauptunterschiede zwischen den Standardprozessen

Die Standardprozesse erfüllen die Anforderungen der meisten Teams. 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	Scrum	CMMI
Workflowstatus	– Zu erledigen – Wird ausgeführt -Fertig	- Neu - Aktiv - Aufgelöst - Abgeschlossen - Entfernt	- Neu -Genehmigt – Committet -Fertig - Entfernt	- Vorgeschlagen - Aktiv - Aufgelöst - Abgeschlossen
Produktplanung (siehe Hinweis 1)	-Problem	- Benutzererzählung - Fehler (optional)	– Produkt-Backlog-Element - Fehler (optional)	-Anforderung - Fehler (optional)
Portfolio-Backlogs (siehe Hinweis 2)	- Epik	- Epik -Feature	- Epik -Feature	- Epik -Feature
Aufgaben- und Sprintplanung (siehe Hinweis 3)	-Aufgabe	-Aufgabe - Fehler (optional)	-Aufgabe - Fehler (optional)	-Aufgabe - Fehler (optional)
Verwaltung des Bug-Backlogs (siehe Hinweis 1)	-Problem	-Fehler	-Fehler	-Fehler
Problem- und Risikomanagement	-Problem	-Problem	-Hindernis	- Änderungsanforderung -Problem -Risiko -Bewertung

Hinweis

Hinzufügen von Workitems aus dem Produkt-Rückstand oder Brett. Der Produktrückstand zeigt eine einzelne Ansicht des aktuellen Arbeitsbestands an, den Sie dynamisch neu anordnen und gruppieren können. Product Owner können Arbeit priorisieren und Abhängigkeiten und Beziehungen gliedern. Jedes Team kann konfigurieren, wie Fehler in ihren Backlogs und Boards angezeigt werden sollen.
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.
Definieren Sie Aufgaben aus dem Sprint-Backlog und dem Taskboard. Mit der Kapazitätsplanung können Teams ermitteln, ob sie während eines Sprints überkapazitiert oder unterkapazitiert 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

Workflowübergänge: Die Standardworkflows in Azure DevOps unterstützen Übergänge von jedem Zustand in jeden anderen Zustand. Sie können diese Workflows anpassen, um bestimmte Übergänge basierend auf den Anforderungen Ihres Teams einzuschränken. Weitere Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.

Visualisieren von Workflows: Um die unterstützten Workflowübergänge für jeden Arbeitsaufgabentyp anzuzeigen, installieren Sie die Erweiterung State Model Visualization Marketplace. Diese Erweiterung fügt unter Boards einen State Visualizer-Hub hinzu, in dem Sie einen Arbeitsaufgabentyp auswählen und das vollständige Workflowstatusmodell anzeigen können.

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.

Benutzerstory

Diagramm, das User Story-Workflowzustände mithilfe des Agile-Prozesses zeigt.

Funktion

Diagramm, das die Workflow-Zustände von Features im Agile-Vorgehen zeigt.

Epic

Diagramm, das Epic-Workflowzustände mithilfe des Agile-Prozesses zeigt.

Bug

Diagramm, das Fehlerworkflowzustände mithilfe des Agile-Prozesses zeigt.

Aufgabe

Diagramm, das Aufgabenworkflowzustände mithilfe 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 einer Arbeitsaufgabe mithilfe der Tafel oder des Taskboards. Ziehen Sie ein Workitem in die entsprechende Statusspalte.

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

Verhalten der Status "Entfernt", "Geschlossen" und "Fertig" bei Backlogs

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

Closed oder Done: Arbeitselemente in diesem Zustand werden nicht auf Portfolio-Backlog- oder Backlogseiten angezeigt, aber sie werden auf den Sprint-Backlog-Seiten, -Board- und -Taskboards angezeigt. Wenn Sie die Portfolio-Backlog-Ansicht in Backlogelemente anzeigen ändern – beispielsweise, um Features neben Product Backlog-Elementen anzuzeigen –, werden auch Arbeitselemente in den Zuständen Closed und Done angezeigt.
Removed: Arbeitsaufgaben in diesem Status erscheinen nicht in einem Rückstand oder Board.

Hinweis

Der CMMI-Standard-Workflow enthält keinen Status Removed. Um ein CMMI-Arbeitselement aus der aktiven Nachverfolgung herauszunehmen, setzen Sie seinen Status auf Closed und wählen Sie einen geeigneten Grund aus (z. B. Zurückgestellt oder Abgelehnt). Sie können einen geerbten Prozess anpassen , um einen Removed Zustand hinzuzufügen, wenn Ihr Team einen benötigt.

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. Sie können diesen Datensatz verwenden, 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.

Diagramm, das Arbeitsaufgabentypen zeigt, die von Testplänen, Microsoft Test Manager, Meine Arbeit und Feedback verwendet werden.

Ihr Team kann diese Typen mit Hilfe des entsprechenden Tools erstellen und bearbeiten. Diese Arbeitsaufgabentypen verbleiben im Schema, um die Verlaufskompatibilität zu gewährleisten. Microsoft Test-Manager und der Team Explorer Meine Arbeitserfahrung sind ältere Tools, die größtenteils durch das Webportal ersetzt werden.

Tool	Arbeitsaufgabentypen
Microsoft Test Manager (veraltet)	`Test Plan` `Test Suite` `Test Case Shared Steps` `Shared Parameters`
Feedback anfordern	`Feedback Request`, `Feedback Response`
My Work (aus Team Explorer, Legacy), Codeüberprüfung	`Code Review Request`, `Code Review Response`

Sie können Arbeitsaufgaben nicht manuell aus diesen Typdefinitionen erstellen. Sie werden der Hidden Types Kategorie 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

Die Linktypen, die in der folgenden Abbildung gezeigt werden, verbinden Arbeitsaufgabentypen, die die Testerfahrung unterstützen und mit Test-Manager und dem Webportal arbeiten.

Diagramm, das Testverwaltungsaufgabentypen zeigt.

Im Webportal oder Microsoft Test-Manager können Sie anzeigen, welche Testfälle für eine Testsuite definiert sind und welche Testsuiten 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 Ihrer Arbeitsverfolgungserfahrung.

Wenn Sie den Workflow für den Testplan und die Testsuite ändern, müssen Sie möglicherweise die Prozesskonfiguration aktualisieren, wie in diesem Artikel beschrieben. Definitionen der einzelnen Testfelder finden Sie unter Erstellen einer Abfrage basierend auf Build- und Testintegrationsfeldern.