Auswählen eines Prozesses

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 – TFS 2013

Jedes Mal, wenn Sie ein Projekt erstellen, müssen Sie einen Prozess oder eine Prozessvorlage basierend auf dem verwendeten Prozessmodell auswählen.

  • Ein 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.
  • Eine Prozessvorlage definiert die Bausteine des Nachverfolgungssystems für Arbeitselemente sowie anderer Untersysteme, auf die Sie über Azure Boards oder einen lokalen Azure DevOps Server oder Team Foundation Server (TFS) zugreifen. Es unterstützt gehostete XML- und lokale XML-Prozessmodelle, die die Anpassung von Projekten durch das Ändern und Importieren von XML-Definitionsdateien unterstützen.

Hinweis

Informationen zum Konfigurieren und Anpassen Ihres Projekts und ihrer Teams, um Ihre geschäftlichen Anforderungen zu unterstützen, finden Sie unter Konfiguration und Anpassung der Azure Boards.

Ausführliche Informationen zum Erstellen eines Projekts mithilfe des Prozesses Ihrer Wahl finden Sie unter Erstellen eines Projekts. Weitere Informationen zu Prozessmodellen finden Sie unter Anpassen ihrer Arbeitsnachverfolgungserfahrung.

Tipp

Mit Azure DevOps Server können Sie zwischen dem geerbten Prozessmodell oder dem lokalen XML-Prozessmodell wählen. Weitere Informationen finden Sie unter Anpassen ihrer Arbeitsnachverfolgungserfahrung, Auswählen des Prozessmodells für Ihre Projektsammlung. So greifen Sie auf die neuesten Versionen der Standardprozesse/Prozessvorlagen zu:

Tipp

So greifen Sie auf die neuesten Versionen der Standardprozessvorlagen zu:

Die in den Standardprozessen und Prozessvorlagen Enthaltenen Arbeitsnachverfolgungsobjekte — Basic, Agile, CMMI und Cms — sind identisch und werden unten zusammengefasst. Der Basic-Prozess ist ab Azure DevOps Server 2019.1 verfügbar. Der Einfachheit halber werden sie als "Prozess" bezeichnet.

Tipp

Informationen zum Anzeigen und Verwalten von geerbten Prozessmodellen finden Sie unter Verwalten von Prozessen.

Basic, Agile, Cms und CMMI

Die Standardprozesse unterscheiden sich hauptsächlich in den Arbeitselementtypen (WITs), die sie für die Planung und Nachverfolgung von Arbeit bereitstellen.

Basic ist der einfachste und befindet sich in einer selektiven Vorschauversion. Das nächstlichteste Ist der Nächstlichter. Agile unterstützt viele Agile-Methodenbegriffe, und CMMI, das für Capability Maturity Model Integration steht, bietet die größte Unterstützung für formale Prozesse und Change Management.

Hinweis

Der grundlegende Prozess ist in Azure DevOps Server 2019 Update 1 und höheren Versionen verfügbar.

Wählen Sie den Prozess aus, der für Ihr Team am besten geeignet ist.

Hinweis

Epics werden auf Azure Boards und TFS 2015 und höher unterstützt. Jedes Team kann die Backlogebenen auswählen, die aktiv sind, wie unter Auswählen von Backlognavigationsebenen für Ihr Team beschrieben.

Grundlegend

Wählen Sie Basic aus, wenn Ihr Team das einfachste Modell verwenden möchte, das Probleme, Aufgaben und Epics zum Nachverfolgen der Arbeit verwendet. Hinweis: Basic befindet sich derzeit in einer selektiven Vorschau für neue Benutzer Azure Boards Benutzer.

Aufgaben unterstützen die Nachverfolgung verbleibender Arbeit.

Basic work item types

Agilität

Wählen Sie Agile aus, wenn Ihr Team Agile-Planungsmethoden verwendet, einschließlich Agile, und verfolgt Entwicklungs- und Testaktivitäten separat nach. Dieser Prozess funktioniert gut, wenn Sie User Storys und (optional) Fehler auf dem Kanban-Board oder Fehler und Aufgaben auf der Taskboard nachverfolgen möchten.

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

Aufgaben unterstützen die Nachverfolgung der ursprünglichen Schätzung, der verbleibenden Arbeit und der abgeschlossenen Arbeit.

Agile work item types

Scrum

Wählen Sie Beim Ansuchen von Practices durch Ihr Team Dies ist Dies der Richtige. Dieser Prozess funktioniert gut, wenn Sie Produktrückstandelemente (Product Backlog Items, PBIs) und Fehler auf dem Kanban-Board nachverfolgen oder PBIs und Fehler in Aufgaben in der Taskboard aufbrechen möchten.

Dieser Prozess unterstützt die Von der Organisation Organization ( ) definierte Methodologie von Methodolog.

Aufgaben unterstützen nur die Nachverfolgung verbleibender Arbeit.

Scrum work item types

CMMI

Wählen Sie CMMI aus, wenn Ihr Team formaleren Projektmethoden folgt, die ein Framework für die Prozessverbesserung und einen überprüfbaren Datensatz von Entscheidungen erfordern. Mit diesem Prozess können Sie Anforderungen, Änderungsanforderungen, Risiken und Überprüfungen nachverfolgen.

Dieser Prozess unterstützt formale Change Management-Aktivitäten. Aufgaben unterstützen die Nachverfolgung der ursprünglichen Schätzung, der verbleibenden Arbeit und der abgeschlossenen Arbeit.

CMMI work item types

Wenn Sie mehr als zwei oder drei Backlogebenen benötigen, können Sie basierend auf dem von Ihnen verwendeten Prozessmodell weitere hinzufügen:

Hauptunterscheidungen zwischen den Standardprozessen

Die Standardprozesse sind so konzipiert, dass sie die Anforderungen der meisten Teams erfüllen. Wenn Ihr Team ungewöhnliche Anforderungen hat und eine Verbindung mit einem lokalen Server herstellt, können Sie einen Prozess anpassen und dann das Projekt erstellen. Alternativ können Sie ein Projekt aus einem Prozess erstellen und dann das Projekt anpassen.

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen den WITs und den Zuständen zusammengefasst, die von den vier Standardprozessen verwendet werden.

Nachverfolgungsbereich Basic agil 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 Hinweis 1)
  • Problem
  • Benutzertextabschnitt
  • Fehler (optional)
  • Product Backlog Item
  • Fehler (optional)
  • Anforderung
  • Fehler (optional)
Portfoliobacklogs (2)
  • Epic
  • Epic
  • Funktion
  • Epic
  • Funktion
  • Epic
  • Funktion
Aufgaben- und Sprintplanung (3)
  • Aufgabe
  • Aufgabe
  • Fehler (optional)
  • Aufgabe
  • Fehler (optional)
  • Aufgabe
  • Fehler (optional)
Fehlerbacklogverwaltung (1)
  • Problem
  • Bug
  • Bug
  • Bug
Problem- und Risikomanagement
  • Problem
  • Problem
  • Impediment
  • Problem
  • Risiko
  • Überprüfung

Hinweise:

  1. Sie können diese WITs aus dem Produktrückstand oder dem Kanban-Board hinzufügen. Das Produktrückstand zeigt eine einzelne Ansicht des aktuellen Arbeitsrückstands, die dynamisch neu geordnet und gruppiert werden kann. Produktbesitzer können Arbeit schnell priorisieren und Abhängigkeiten und Beziehungen beschreiben.

    Außerdem kann jedes Team konfigurieren, wie Fehler in ihren Backlogs und Boards enthalten sein sollen.

  2. Durch Portfoliobacklogs können Sie eine Hierarchie von Backlogs definieren, um den Arbeitsumfang mehrerer Teams zu verstehen und das Rollup dieser Arbeitsaufgaben in umfassendere Aktivitäten zu prüfen. Jedes Team kann konfigurieren, welche Portfolio-Backlogs für die Verwendung angezeigt werden.

  3. Sie können Aufgaben aus dem Sprint-Backlog und der Taskboard definieren. Mit der Kapazitätsplanung können Teams schnell ermitteln, ob sie für einen Sprint über oder unter der Kapazität sind.

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

Workflowzustände unterstützen die Nachverfolgung des Arbeitszustands eines abgeschlossenen oder fertig gestellten Zustands. 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 Zustand in jeden Zustandsübergang. Sie können diese Workflows anpassen, um einige Übergänge einzuschränken. Weitere Informationen finden Sie unter Anpassen von Arbeitsnachverfolgungsobjekten zurUnterstützung der Prozesse Ihres Teams.

Außerdem können Sie die unterstützten Workflowübergänge für jeden Arbeitselementtyp anzeigen, indem Sie die Erweiterung State Model Visualization Markeplace installieren. Diese Erweiterung fügt einen neuen Hub unter Boards mit der Bezeichnung State Visualizer hinzu. Auf dieser Seite können Sie einen Arbeitselementtyp auswählen und das Workflowzustandsmodell anzeigen.

Die folgenden Diagramme zeigen den typischen Vorwärtsfortschritt dieser WITs, die zum Nachverfolgen 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.

Epic,Issue, Task-Hierarchie

Basic process work item hierarchy

Epic-, Issue-, Taskworkflow

Basic process workflow

Hinweis

Der Basic-Prozess ist verfügbar, wenn Sie ein neues Projekt aus Azure DevOps Services oder Azure DevOps Server 2019.1 erstellen. Wählen Sie für frühere lokale Bereitstellungen den Agile-, Agile- oder CMMI-Prozess aus.

Die meisten WITs, die von Agile-Tools verwendet werden, die in Backlogs und Boards angezeigt werden, unterstützen Any-to-Any-Übergänge. Sie können den Status eines Arbeitselements mithilfe des Kanban-Boards oder der Taskboard aktualisieren, indem Sie es in die entsprechende Statusspalte ziehen.

Sie können den Workflow so ändern, dass er zusätzliche Zustände, Übergänge und Gründe unterstützt. Weitere Informationen finden Sie unter Anpassen ihrer Arbeitsnachverfolgungserfahrung.

Die Zustände Entfernt, Geschlossen und Fertig gestellt

Wenn Sie den Zustand einer Arbeitsaufgabe in Entfernt, Geschlossen oder Fertig gestellt ändern, reagiert das System wie folgt:

  • Geschlossen oder Abgeschlossen: Arbeitselemente in diesem Zustand werden nicht auf den Seiten "Portfoliobacklog" und "Backlog" angezeigt. Sie werden jedoch auf den Sprintbacklogseiten, dem Kanban-Board und dem Taskboard angezeigt. Auch beim Ändern der Portfoliobacklog-Ansicht zur Anzeige von Backlogelementen z. B. zum Anzeigen von Features zu Product Backlog Items, werden Elemente angezeigt, die einen geschlossenen oder fertig gestellten Zustand aufweisen.
  • Entfernt: Arbeitselemente in diesem Zustand werden in keinem Backlog oder Board angezeigt.

Arbeitselemente werden in einem Projekt beibehalten, solange das Projekt aktiv ist. Selbst wenn Sie sie auf geschlossen, fertig gestellt oder entfernt festlegen, wird ein Datensatz im Datenspeicher beibehalten. Sie können einen Datensatz verwenden, um Abfragen und Berichte zu erstellen.

Wenn Sie Arbeitselemente dauerhaft löschen müssen, finden Sie weitere Informationen unter Entfernen oder Löschen von Arbeitselementen.

Allen Prozessen hinzugefügte Arbeitselementtypen

Die folgenden WITs werden allen Prozessen mit Ausnahme des Basic-Prozesses hinzugefügt.

Arbeitselementtypen, die von Test Plans, Microsoft Test Manager, My Work und Feedback verwendet werden

Teams erstellen und arbeiten mit diesen Typen mithilfe des entsprechenden Tools:

  • Testplan, Testsammlung, Freigegebene Testfallschritte und freigegebene Parameter: Microsoft Test Manager.
  • Feedbackanforderung und Feedbackantwort: Feedback anfordern.
  • Codeüberprüfungsanforderung und Codeüberprüfungsantwort: Meine Arbeit (von Team Explorer) und Codeüberprüfungsanforderung.

Arbeitsaufgaben dieser Typdefinitionen sollten nicht manuell erstellt werden und sind daher der ausgeblendeten Typenkategorie hinzugefügt. Arbeitselementtypen, die der Kategorie Ausgeblendete Typen hinzugefügt werden, werden nicht in den Menüs angezeigt, die zum Erstellen neuer Arbeitselemente verwendet werden.

Hinweis

Wenn Sie Ihr Projekt von TFS 2013 oder einer früheren Version auf eine höhere Version von TFS aktualisiert haben, müssen Sie möglicherweise WITs hinzufügen, die in früheren Versionen nicht vorhanden waren. Weitere Informationen finden Sie unter Konfigurieren von Features nach einem TFS-Upgrade.

Die folgenden WITs wurden mit der angegebenen TFS-Version hinzugefügt:

  • Mit TFS 2013.2 hinzugefügte freigegebene Parameter
  • Testplan und Testsuite mit TFS 2013.3 hinzugefügt

WITs, welche die Test-Erfahrung unterstützen

WITs, die die Testerfahrung unterstützen und mit Test Manager und dem Webportal arbeiten, werden mithilfe der in der folgenden Abbildung gezeigten Linktypen miteinander verknüpft.

Test der Verwaltung von Arbeitsaufgabentypen

Im Webportal oder Microsoft Test Manager können Sie anzeigen, welche Testfälle für eine Testsammlung und welche Testsammlungen für einen Testplan definiert sind. Diese Objekte sind jedoch nicht über Linktypen miteinander verbunden. Sie können diese WITs wie alle anderen WITs anpassen. Weitere Informationen finden Sie unter Anpassen von Arbeitsnachverfolgungsobjekten 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 Abfragen basierend auf Den Feldern für die Build- und Testintegration.

Sie können einen Prozess vor oder nach dem Erstellen eines Projekts anpassen, das den Prozess verwendet. Welche Methoden Sie verwenden, hängt vom prozessweisen Modell ab, das Sie verwenden. Weitere Informationen finden Sie unter Anpassen ihrer Arbeitsnachverfolgungserfahrung.

Wenn Sie weitere Fragen haben, besuchen Sie Azure DevOps Supportseite.