Informationen zu Standardprozessen und Prozessvorlagen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Azure Boards bietet verschiedene Prozesse zur Auswahl für die Verwaltung von Arbeitselementen. Die Auswahl des richtigen Prozesses ist entscheidend, um den Workflow zu optimieren und den Erfolg eines Projekts sicherzustellen. In diesem Artikel untersuchen wir die verschiedenen Prozesse, die Azure Boards verfügbar sind, und geben Anleitungen zur Auswahl des am besten geeigneten Für Ihr Projekt.

Wenn Sie ein Projekt erstellen, wählen Sie eine Prozess- oder Prozessvorlage basierend auf dem Prozessmodell aus, für das Ihre organization 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 In den Standardprozessen und Prozessvorlagen enthaltenen Arbeitsverfolgungsobjekte –Basic, Agile, Capability Maturity Model Integration (CMMI) und Scrum – sind identisch und werden in diesem Artikel zusammengefasst.

Tipp

Bei Azure DevOps Server können Sie zwischen dem geerbten Prozessmodell oder dem lokalen XML-Prozessmodell wählen. Weitere Informationen finden Sie unter Anpassen der Arbeitsnachverfolgung, 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:

Standardprozesse

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

Basic ist das leichteste und befindet sich in einer selektiven Vorschau. Scrum ist das nächstleichteste. Agile unterstützt viele Agile-Methodenbegriffe, und CMMI bietet die meiste Unterstützung für formale Prozesse und das Change Management.

Hinweis

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

Grundlegend

Wählen Sie Basic aus, wenn Ihr Team das einfachste Modell verwenden möchte, das Issues, Tasks und Epics zum Nachverfolgen der Arbeit verwendet.

Aufgaben unterstützen die Nachverfolgung verbleibender Arbeit.

Grundlegende Arbeitselementtypen

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 funktioniert 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-Arbeitselementtypen

Scrum

Wählen Sie Scrum aus, wenn Ihr Team Scrum praktiziert. Dieser Prozess eignet sich hervorragend zum Nachverfolgen von Product Backlog Items (PBIs) und Fehlern auf dem Kanban-Board. Sie können PBIs und Fehler auch in Aufgaben auf dem Taskboard aufteilen.

Dieser Prozess unterstützt die Im Scrum-organization definierte Scrum-Methodik.

Aufgaben unterstützen nur die Nachverfolgung der verbleibenden Arbeit.

Scrum-Arbeitsaufgabentypen

CMMI

Wählen Sie CMMI aus, wenn Ihr Team formalere Projektmethoden befolgt, 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 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-Arbeitsaufgabentypen

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

Hauptunterschiede 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 das Projekt dann anpassen.

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

Nachverfolgungsbereich

Basic

Agilität

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)

Verwaltung des Fehlerbacklogs (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. Das Produktbacklog zeigt eine einzelne Ansicht des aktuellen Arbeitsbacklogs an, die dynamisch neu geordnet und gruppiert werden können. Produktbesitzer können arbeit schnell priorisieren und Abhängigkeiten und Beziehungen skizzieren.
    Außerdem kann jedes Team konfigurieren, wie Fehler in seinen 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 Portfoliobacklogs für die Verwendung angezeigt werden.
  3. Sie können Aufgaben aus dem Sprintbacklog und taskboard definieren. Mit der Kapazitätsplanung können Teams schnell ermitteln, ob die Kapazität für einen Sprint über- oder unterschritten wird.

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 Zustandsübergang. Sie können diese Workflows anpassen, um einige Übergänge einzuschränken. Weitere Informationen finden Sie unter Anpassen von Arbeitsnachverfolgungsobjekten zur Unterstützung der Prozesse Ihres Teams.

Außerdem können Sie die unterstützten Workflowübergänge für jeden Arbeitselementtyp anzeigen, indem Sie die Markeplace-Erweiterung für die Zustandsmodellvisualisierung 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 die typische Vorwärtsentwicklung der 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-Workflowstatus, Agiler Prozess

Funktion

Featureworkflowstatus, Agiler Prozess

Epic

Epische Workflowzustände, Agiler Prozess

Bug

Fehlerworkflowstatus, Agiler Prozess

Aufgabe

Aufgabenworkflowstatus, Agiler Prozess

Die meisten WITs, die von Agile-Tools verwendet werden, die in Backlogs und Boards angezeigt werden, unterstützen Übergänge von beliebiger zu beliebiger Seite. Sie können die status eines Arbeitselements mithilfe des Kanban-Boards oder des Taskboards aktualisieren, indem Sie es 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 Arbeitsnachverfolgung.

Arbeitselementzustände

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

  • Closed / Done: Arbeitselemente in diesem Zustand werden nicht auf den Seiten portfoliobacklog und backlog angezeigt. Sie werden jedoch auf den Sprint-Backlogseiten, im Kanban-Board und im Taskboard angezeigt. Wenn Sie die Portfolio-Backlogansicht so ändern, dass Backlogelemente angezeigt werden, z. B. um Features in Product Backlog Items anzuzeigen, werden Arbeitselemente im Zustand geschlossen und fertig angezeigt.
  • Removed: Arbeitselemente in diesem Zustand werden in keinem Backlog oder Board angezeigt.

Ihr Projekt verwaltet Arbeitselemente, solange das Projekt aktiv ist. Auch wenn Sie Arbeitselemente auf Closed, Doneoder Removedfestlegen, behält der Datenspeicher einen Datensatz bei. 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 (etwa ein halbes Jahr) ist. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn sie in einem Backlog oder Board angezeigt werden sollen, können Sie eine geringfügige Änderung daran vornehmen, wodurch die Uhr zurückgesetzt wird.

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 in einem Backlog oder Board angezeigt werden sollen, können Sie eine geringfügige Änderung daran vornehmen, wodurch die Uhr zurückgesetzt wird.

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

ALLEN Prozessen hinzugefügte WITs

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

Arbeitselementtypen, die von Test Plans, Microsoft Test Managern, Meine Arbeit und Feedback verwendet werden

Ihr Team kann diese Typen mit dem entsprechenden Tool erstellen und damit arbeiten:

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überprüfung Code Review Request, Code Review Response

Arbeitselemente aus diesen Typdefinitionen sollen nicht manuell erstellt und dann der Hidden Types Kategorie hinzugefügt werden. Arbeitselementtypen, die der Hidden Types Kategorie hinzugefügt wurden, werden nicht in den Menüs angezeigt, die neue Arbeitselemente erstellen.

WITs, welche die Test-Erfahrung unterstützen

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

Test der Verwaltung von Arbeitsaufgabentypen

Über das Webportal oder Microsoft Test Manager können Sie anzeigen, welche Testfälle für eine Testsuite definiert sind und welche Testsammlungen für einen Testplan definiert sind. Diese Objekte sind jedoch nicht über Linktypen miteinander verbunden. Passen Sie diese WITs wie jedes andere WIT an. 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 Abfrage basierend auf Build- und Testintegrationsfeldern.