Wählen Sie eine Prozessfluss- oder Prozessvorlage aus, die in Azure Boards

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 für Ihre Organisation oder Sammlung ausgewählten Prozessmodell auswählen. 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 verwendet wird, um Projekte zu unterstützen, die für eine Organisation (Azure DevOps Services) oder Projektsammlung (Azure DevOps Server) erstellt wurden. Es wird jeweils nur ein Prozessmodell für eine Organisation oder Sammlung unterstützt. Ein Vergleich der drei Prozessmodelle – Vererbung, lokales XML und gehostetes XML – wird in der Anpassung der Arbeitsnachverfolgung 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 anderer 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 XML-Definitionsdateien für Prozessvorlagen ändern und importieren.

Hinweis

Anleitungen zum Konfigurieren und Anpassen Ihres Projekts und Ihrer Teams zur Unterstützung Ihrer geschäftlichen Anforderungen, überprüfen Sie die Konfiguration und Anpassung von 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 Arbeitsverfolgungserfahrung.

Tipp

Mit Azure DevOps Server können Sie zwischen der Verwendung des geerbten Prozessmodells oder des lokalen XML-Prozessmodells wählen. Ausführliche Informationen finden Sie unter Anpassen der Arbeitsverfolgungserfahrung, 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 Arbeitsnachverfolgungsobjekte, die in den Standardprozessen und Prozessvorlagen enthalten sind – 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. Einfachheit halber 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 Arbeitsaufgabentypen (WITs), die sie für die Planung und Nachverfolgung von Arbeiten bereitstellen.

Basic ist der einfachste und ist 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 Change Management.

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 die Arbeit nachzuverfolgen.

Aufgaben unterstützen die Nachverfolgung verbleibender Arbeit.

Basic work item types


Agile Softwareentwicklung

Wählen Sie Agile aus, wenn Ihr Team Agile-Planungsmethoden verwendet, einschließlich Scrum, und verfolgt Entwicklungs- und Testaktivitäten separat. Dieser Prozess eignet sich hervorragend, wenn Sie Benutzergeschichten und (optional) Fehler auf dem 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 Nachverfolgung der ursprünglichen Schätzung, der verbleibenden Arbeit und der abgeschlossenen Arbeit.

Agile work item types


Scrum

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

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

Aufgaben unterstützen nur die Nachverfolgung der verbleibenden Arbeit.

Scrum work item types


CMMI

Wählen Sie CMMI aus, wenn Ihr Team formalere Projektmethoden folgt, die ein Framework zur Verbesserung der Prozesse und einen auditierbaren Datensatz von Entscheidungen erfordern. Mit diesem Prozess können Sie Anforderungen, Änderungsanforderungen, Risiken und Rezensionen nachverfolgen.

Dieser Prozess unterstützt formale Änderungsverwaltungsaktivitä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 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 Unterschiede zwischen den WITs und Zuständen zusammengefasst, 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 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)

Fehlerbacklogverwaltung (1)

  • Problem
  • Bug
  • Bug
  • Bug

Problem- und Risikomanagement

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

Hinweis

  1. Sie können diese WITs aus dem Produktbacklog oder Kanban-Board hinzufügen. Der Produktbacklog zeigt eine einzelne Ansicht des aktuellen Arbeitsrückstands, der dynamisch neu angeordnet und gruppiert werden kann. Produktbesitzer können Arbeiten und Beziehungen schnell priorisieren und gliederungen.
    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 bestimmen, 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 alle Statusübergänge zu jedem Zustandsübergang. Sie können diese Workflows anpassen, um einige Übergänge einzuschränken. Weitere Informationen finden Sie unter Anpassen von Arbeitsverfolgungsobjekten, 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 beschrifteten Zustandsvisualisierer 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

User story workflow states, Agile process

Komponente

Feature workflow states, Agile process

Epic

Epic workflow states, Agile process

Bug

Bug workflow states, Agile process

Aufgabe

Task workflow states, Agile process

Die meisten WITs, die von agilen Tools verwendet werden, die auf Backlogs und Boards angezeigt werden, unterstützen alle Übergänge. Sie können den Status eines Arbeitselements mithilfe des Kanban-Boards 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 dem Portfolio-Backlog- und Backlog-Seiten angezeigt. Sie werden jedoch auf den Sprint-Backlogseiten, Kanban-Board und Taskboard angezeigt. Wenn Sie auch die Portfolio-Backlog-Ansicht ändern, um Backlogelemente anzuzeigen, z. B. zum Anzeigen von Features auf Produktbacklogelemente, werden Arbeitselemente im geschlossenen und fertigen Zustand angezeigt.
  • Entfernt: Arbeitselemente in diesem Zustand werden nicht auf einem 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.

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden nicht auf den Backlogs und Boards 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 kleine Änderung an ihnen vornehmen, die die Uhr zurücksetzt.

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden nicht auf den Backlogs und Boards 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 kleine Änderung an ihnen vornehmen, die die Uhr zurücksetzt.

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

Arbeitselementtypen, die allen Prozessen hinzugefügt wurden

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

Work item types used by Test Plans, Microsoft Test Managers, My Work, and Feedback

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

  • Testplan, Test Suite, Testfall freigegebene Schritte 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 zur Kategorie "Ausgeblendete Typen" hinzugefügt werden. Arbeitselementtypen, die der Kategorie "Ausgeblendete Typen" hinzugefügt wurden, werden in den Menüs nicht angezeigt, die neue Arbeitselemente erstellen.

WITs, welche die Test-Erfahrung unterstützen

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

Test management work item types

Im Webportal oder Microsoft Test Manager können Sie anzeigen, welche Testfälle für eine Test suite definiert sind. Und Sie können anzeigen, welche Testsuiten für einen Testplan definiert sind. Diese Objekte sind jedoch nicht über Linktypen miteinander verbunden. Passen Sie diese WITs wie alle anderen WIT an. Weitere Informationen finden Sie unter Anpassen von Arbeitsverfolgungsobjekten, 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 methoden, die Sie verwenden, hängen von dem prozessmodell ab, das Sie verwenden. Weitere Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.

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