Wählen Sie einen Prozessfluss oder eine Prozessvorlage aus, die in Azure Boards funktionieren soll.

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Wenn Sie ein Projekt erstellen, müssen Sie eine Prozess- oder Prozessvorlage basierend auf dem Prozessmodell auswählen, das für Ihre Organisation oder Auflistung ausgewählt ist. Beim Auswählen eines Prozesses für Ihr Projekt ist es wichtig, die folgenden Begriffe zu verstehen:

  • Ein Prozessmodell bezieht sich auf das Modell, das zum Unterstützen von Projekten verwendet wird, die für eine Organisation (Azure DevOps Services) oder Projektsammlung (Azure DevOps Server) erstellt wurden. Es wird nur ein Prozessmodell für ein Projekt gleichzeitig unterstützt. Ein Vergleich der drei Prozessmodelle – Vererbung, lokale XML und gehostete XML – wird in der Anpassung der Arbeitsverfolgung bereitgestellt.
  • Ein Prozess definiert die Bausteine des Arbeitselementverfolgungssystems 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 Arbeitselementverfolgungssystems und andere Subsysteme, auf die Sie über Azure DevOps zugreifen. Prozessvorlagen werden nur mit den gehosteten XML- und lokalen XML-Prozessmodellen verwendet. Sie passen Projekte an, indem Sie Prozessvorlagen-XML-Definitionsdateien ändern und importieren.

Hinweis

Anleitungen zum Konfigurieren und Anpassen Ihres Projekts und Teams, um Ihre Geschäftlichen Anforderungen zu unterstützen, Konfiguration und Anpassung von Azure Boards zu überprüfen.

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 Arbeitsverfolgungserfahrung.

Tipp

Mit Azure DevOps Server können Sie zwischen der Verwendung des Erbenprozessmodells oder des lokalen XML-Prozessmodells wählen. Ausführliche Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungsumgebung, Wählen Sie das Prozessmodell für Ihre Projektsammlung aus. 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 Arbeitsverfolgungsobjekte – Basic, Agile, CMMI und Scrum – sind identisch und werden unten zusammengefasst. Der Grundlegende Prozess ist von Azure DevOps Server 2019.1 und höher verfügbar. Für Einfachheit werden sie als "Prozess" bezeichnet.

Tipp

Informationen zum Anzeigen und Verwalten geerbter Prozessmodelle finden Sie unter "Verwalten von Prozessen".

Wählen Sie einen grundlegenden, agilen, Scrum- und CMMI-Prozess aus.

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

Basic ist das einfachste und befindet sich in einer selektiven Vorschau. Scrum ist das nächste leichtste. Agile unterstützt viele Agile-Methodenbegriffe und CMMI, die für die Integration von Capability Maturity Model steht, bietet die meisten Unterstützung für formale Prozesse und Änderungsverwaltung.

Hinweis

Der Grundlegende Prozess ist mit Azure DevOps Server 2019 Update 1 und höher verfügbar.

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

Grundlegend

Wählen Sie "Basic " aus, wenn Ihr Team das einfachste Modell möchte, das Probleme, Aufgaben und Epics verwendet, um arbeit zu verfolgen.

Aufgaben unterstützen die Nachverfolgung der verbleibenden Arbeit.

Grundlegende Arbeitselementtypen


Agile Softwareentwicklung

Wählen Sie Agile aus, wenn Ihr Team agile Planungsmethoden verwendet, einschließlich Scrum, und verfolgt Entwicklung und Testaktivitäten separat. Dieser Prozess funktioniert hervorragend, wenn Sie Benutzergeschichten und (optional) Fehler im Kanban-Board nachverfolgen oder Fehler und Aufgaben auf dem Taskboard nachverfolgen möchten.

Weitere Informationen zu agilen Methoden finden Sie in der Agile Alliance.

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

Agile-Arbeitselementtypen


Gedränge

Wählen Sie Scrum aus, wenn Ihr Team Scrum praktiziert. Dieser Prozess funktioniert hervorragend, wenn Sie Produkt-Backlog-Elemente (PBIs) und Fehler im Kanban-Board nachverfolgen oder PBIs und Fehler in Aufgaben auf dem Taskboard aufteilen möchten.

Dieser Prozess unterstützt die Scrum-Methode gemäß der Definition der Scrum-Organisation.

Aufgaben unterstützen nur die Nachverfolgung der verbleibenden Arbeit.

Scrum-Arbeitsaufgabentypen


CMMI

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

Dieser Prozess unterstützt formale Änderungsverwaltungsaktivitäten. Aufgaben unterstützen die Verfolgung der ursprünglichen Schätzung, der verbleibenden Arbeit und der abgeschlossenen Arbeit.

CMMI-Arbeitsaufgabentypen


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

Hauptunterschiede zwischen den Standardprozessen

Die Standardprozesse sind so konzipiert, dass die Anforderungen der meisten Teams erfüllt werden. 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. Oder Sie können ein Projekt aus einem Prozess erstellen und dann das Projekt anpassen.

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

Nachverfolgungsbereich

Grundlegend

Agile Softwareentwicklung

Gedränge

CMMI


Workflowzustände

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

Produktplanung (siehe Hinweis 1)

  • Problem
  • Benutzertextabschnitt
  • Fehler (optional)
  • Product Backlog Item
  • Fehler (optional)
  • Anforderung
  • Fehler (optional)

Portfolio-Backlogs (2)

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

Aufgaben- und Sprintplanung (3)

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

Fehlerrückmeldeverwaltung (1)

  • Problem
  • Bug
  • Bug
  • Bug

Problem- und Risikomanagement

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

Hinweis

  1. Sie können diese WITs aus dem Produktrücklog oder Kanban-Board hinzufügen. Der Produktrückstand zeigt eine einzelne Ansicht des aktuellen Arbeitsrückstands an, der dynamisch neu sortiert und gruppiert werden kann. Produktbesitzer können Arbeits- und Gliederungsabhängigkeiten und Beziehungen schnell priorisieren.
    Außerdem kann jedes Team konfigurieren, wie Fehler auf ihren Backlogs und Boards angezeigt werden 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 ihre Verwendung angezeigt werden.
  3. Sie können Aufgaben aus dem Sprint-Backlog und taskboard definieren. Mit der Kapazitätsplanung können Teams schnell ermitteln, ob sie über oder unter kapazität für einen Sprint 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 zu jedem Zustandsübergang. Sie können diese Workflows anpassen, um einige Übergänge einzuschränken. Weitere Informationen finden Sie unter Anpassen von Arbeitsnachverfolgungsobjekten, um die Prozesse Ihres Teams zu unterstützen.

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 Workflowstatusmodell anzeigen.

Die folgenden Diagramme zeigen die typische Vorwärtsentwicklung 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.

Benutzertextabschnitt

Workflowzustände für Benutzergeschichten, Agile-Prozess

Funktion

Featureworkflowzustände, Agile-Prozess

Epic

Epische Workflowzustände, Agile-Prozess

Bug

Fehlerworkflowzustände, Agile-Prozess

Aufgabe

Aufgabenworkflowzustände, Agile-Prozess

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

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

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 fertig: Arbeitselemente in diesem Zustand werden nicht auf den Portfolio-Backlog- und Backlogseiten angezeigt. Sie werden jedoch auf den Sprint-Backlog-Seiten, Kanban-Board und Taskboard angezeigt. Wenn Sie auch die Portfolio-Backlog-Ansicht ändern, um Backlogelemente anzuzeigen, z. B. zum Anzeigen von Features für Produktbacklogelemente, werden Arbeitselemente im geschlossenen und abgeschlossenen Zustand angezeigt.
  • Entfernt: Arbeitselemente in diesem Zustand werden in keinem Backlog oder Board angezeigt.

Arbeitselemente werden in einem Projekt verwaltet, 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.

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden nicht auf den Backlogs und Tafeln angezeigt, sobald ihr Geändertes Datum größer als 183 Tage ist (etwa ein halbes Jahr). Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn sie auf einem Backlog oder Board angezeigt werden sollen, können Sie eine geringfügige Änderung an ihnen vornehmen, die die Uhr zurücksetzt.

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden nicht auf den Backlogs und Tafeln angezeigt, sobald ihr geändertes Datum größer als ein Jahr ist. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn sie auf einem Backlog oder Board angezeigt werden sollen, können Sie eine geringfügige Änderung an ihnen vornehmen, die die Uhr zurücksetzt.

Wenn Sie Arbeitselemente endgültig löschen müssen, lesen Sie "Entfernen oder Löschen von Arbeitselementen".

Arbeitselementtypen, die allen Prozessen hinzugefügt wurden

Die folgenden WITs werden allen Prozessen mit Ausnahme des Standardprozesses hinzugefügt.

Arbeitsaufgabentypen, die von Test Plans, Microsoft Test-Managern,

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

  • Testplan, Test Suite, 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.

Arbeitselemente aus diesen Typdefinitionen sollen nicht manuell erstellt werden und dann der Kategorie "Ausgeblendete Typen" hinzugefügt werden. Arbeitselementtypen, die der Kategorie "Ausgeblendete Typen" hinzugefügt wurden, werden nicht in den Menüs angezeigt, in denen neue Arbeitselemente erstellt werden.

WITs, welche die Test-Erfahrung unterstützen

WITs, die die Testerfahrung unterstützen und mit Test-Manager und dem Webportal arbeiten, werden mithilfe der linktypen verknüpft, die in der folgenden Abbildung dargestellt sind.

Test der Verwaltung von Arbeitsaufgabentypen

Im Webportal oder Microsoft Test Manager können Sie anzeigen, welche Testfälle für eine Testsuite definiert sind. Und Sie können anzeigen, welche Testsuiten für einen Testplan definiert sind. Diese Objekte sind jedoch nicht über Verknüpfungstypen miteinander verbunden. Passen Sie diese WITs wie alle anderen WIT an. Weitere Informationen finden Sie unter Anpassen von Arbeitsnachverfolgungsobjekten, um die Prozesse Ihres Teams zu unterstützen.

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

Sie können einen Prozess vor oder nach dem Erstellen eines Projekts anpassen, das den Prozess verwendet. Die von Ihnen verwendeten Methoden hängen vom verwendeten Prozessmodell ab. Weitere Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.

Wenn Sie weitere Fragen haben, lesen Sie die Supportseite von Azure DevOps.