Informationen zu Standardprozessen und Prozessvorlagen
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 für die Optimierung des Workflows und die Sicherstellung des Erfolgs eines Projekts. In diesem Artikel untersuchen wir die verschiedenen Prozesse, die in Azure Boards verfügbar sind, und bieten Anleitungen zur Auswahl des am besten für Ihr Projekt geeigneten.
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 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 (Basic, Agile, CMMI (Capability Maturity Model Integration) und Scrum) enthaltenen Objekte für die Arbeitsnachverfolgung sind identisch und werden in diesem Artikel zusammengefasst.
Tipp
Bei Azure DevOps Server können Sie zwischen der Verwendung des geerbten Prozessmodells und des lokalen XML-Prozessmodells wählen. Weitere Informationen finden Sie unter Anpassen Ihrer Erfahrung für die Arbeitsnachverfolgung, Auswählen des Prozessmodells für Ihre Projektsammlung. So greifen Sie auf die neuesten Versionen der Standardprozesse/-prozessvorlagen zu
- Für das geerbte Prozessmodell: Öffnen Sie die Seite „Prozess“ aus den Organisationseinstellungen. Weitere Informationen finden Sie unter Verwalten von Prozessen.
- Für das lokale XML-Prozessmodell:
- Installieren oder Upgraden auf die neueste Version von Azure DevOps Server
- Laden Sie die gezippte Vorlagendatei mithilfe des Prozessvorlagen-Managers herunter. Sie müssen eine Version von Visual Studio verwenden, die sich auf derselben Versionsebene wie Azure DevOps Server befindet. Sie können die neueste Version von Visual Studio Community kostenlos installieren.
- Sie können auf die neuesten Versionen der Standardprozessvorlagen zugreifen, 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.
Tipp
So greifen Sie auf die neuesten Versionen der Standardprozessvorlagen zu
- Installieren oder Upgraden auf die neueste Version von TFS.
- Laden Sie die gezippte Vorlagendatei mithilfe des Prozessvorlagen-Managers herunter. Sie müssen eine Version von Visual Studio verwenden, die sich auf derselben Versionsebene wie TFS befindet. Sie können die neueste Version von Visual Studio Community kostenlos installieren.
- Sie können auf die neuesten Versionen der Standardprozessvorlagen zugreifen, die auf TFS 2018 installiert sind, z. B.:
%programfiles%/TFS 16.0/Tools/Deploy/ProcessTemplateManagerFiles/1033
. Beschreibungen der einzelnen Dateien und Ordner finden Sie unter Übersicht der Prozessvorlagendateien.
Standardprozesse
Die Standardprozesse unterscheiden sich hauptsächlich hinsichtlich der Arbeitselementtypen (Work Item Types, WITs), die sie für die Planung und Nachverfolgung der Arbeit bereitstellen.
Basic ist der schlankste Prozess und befindet sich in einer selektiven Vorschauphase. Scrum ist der nächst schlankere Prozess. Agile unterstützt viele Agile-Methodenbegriffe, und CMMI bietet die umfangreichste 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 Probleme, Aufgaben und Epics zum Nachverfolgen 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 funktioniert hervorragend, wenn Sie User Storys und (optional) Fehler im Kanban-Board oder Fehler und Aufgaben im Taskboard nachverfolgen möchten.
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 Nachverfolgung von Product Backlog Items (PBIs) und Fehlern im Kanban-Board. Unterteilen Sie außerdem PBIs und Bugs in Aufgaben auf dem Taskboard.
Dieser Prozess unterstützt die von der Scrum-Organisation definierte Scrum-Methodik.
Aufgaben unterstützen nur die Nachverfolgung 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. Verfolgen Sie mit diesem Prozess Anforderungen, Änderungswünsche, Risiken und Überprüfungen.
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 Backlogebenen benötigen, fügen Sie basierend auf dem von Ihnen verwendeten Prozessmodell weitere hinzu:
- Vererbung: Anpassen Ihrer Backlogs oder Boards für einen Prozess
- Gehostetes XML oder lokales XML: Hinzufügen von Portfolio Backlogs
Hauptunterschiede zwischen den Standardprozessen
Die Standardprozesse wurden entworfen, um die Anforderungen der meisten Teams zu erfüllen. Wenn Ihr Team ungewöhnliche Anforderungen hat und eine Verbindung mit einem lokalen Server herstellt, passen Sie einen Prozess an, und erstellen Sie dann das Projekt. Oder erstellen Sie ein Projekt aus einem Prozess, und passen Sie das Projekt dann an.
In der folgenden Tabelle werden die Hauptunterschiede zwischen den WITs und den Zuständen zusammengefasst, die von den vier Standardprozessen verwendet werden.
Nachverfolgungsbereich
Standard
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)
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
- Fügen Sie Arbeitsaufgaben aus dem Produkt-Backlog oder Kanban-Board hinzu. Das Produkt-Backlog zeigt eine einzelne Ansicht des aktuellen Arbeitsrückstands an, die dynamisch neu angeordnet und gruppiert werden kann. Produktbesitzer können Arbeit schnell priorisieren und Abhängigkeiten und Beziehungen darstellen. Außerdem kann jedes Team konfigurieren, wie Fehler in seinen 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 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 Übergang zwischen Zuständen. Passen Sie diese Workflows an, um einige Übergänge einzuschränken. Weitere Informationen finden Sie unter Anpassen der Objekte für die Arbeitsnachverfolgung zur Unterstützung der Prozesse Ihres Teams.
Sehen Sie sich außerdem die unterstützten Workflow-Übergänge für jeden Arbeitselementtyp an, indem Sie die Marketplace-Erweiterung State Model Visualization installieren. Diese Erweiterung fügt einen neuen Hub unter Boards mit der Bezeichnung Zustandsvisualisierung (State Visualizer) hinzu. Wählen Sie auf dieser Seite einen Arbeitsaufgabentyp aus und zeigen Sie das Workflowzustandsmodell an.
In den folgenden Diagrammen wird der typische Fortschritt von WITs dargestellt, die zum Nachverfolgen von Arbeit 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
Funktion
Epic
Bug
Task
Die meisten WITs, die von Agile-Tools verwendet werden und die in Backlogs und Boards angezeigt werden, unterstützen beliebige Übergänge zwischen WITs. Aktualisieren Sie den Status einer Arbeitsaufgabe mithilfe des Kanban-Boards oder des Taskboards, indem Sie es in die entsprechende Statusspalte ziehen.
Ändern Sie den Workflow, um andere Zustände, Übergänge und Gründe zu unterstützen. Weitere Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.
Arbeitselementzustände
Wenn Sie den Zustand eines Arbeitselements in Removed
, Closed
oder Done
ändern, reagiert das System wie folgt:
Closed
/Done
: Arbeitselemente in diesem Zustand werden nicht auf Portfolio Backlog- oder Backlogseiten angezeigt. Allerdings werden sie auf den Sprint Backlog-Seiten, im Kanban-Board und im Taskboard angezeigt. Auch beim Ändern der Portfolio Backlog-Ansicht zur Anzeige von Backlog Items z. B. zum Anzeigen von Features zu Product Backlog Items, werden Arbeitselemente angezeigt, die den Zustand „Geschlossen“ oder „Fertig“ aufweisen.Removed
: Arbeitselemente in diesem Zustand werden in keinem Backlog oder Board angezeigt.
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. Verwenden Sie einen Datensatz, um Abfragen oder Berichte zu erstellen.
Hinweis
Abgeschlossene oder geschlossene Arbeitselemente werden in den Backlogs und auf den Boards nicht angezeigt, sobald deren Änderungsdatum mehr als 183 Tage (ungefähr ein halbes Jahr) zurück liegt. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn Sie möchten, dass sie in einem Backlog oder Board angezeigt werden, können Sie eine geringfügige Änderung an ihnen vornehmen, um die Uhr zurückzusetzen.
Hinweis
Abgeschlossene oder geschlossene Arbeitselemente werden in den Backlogs und auf den Boards nicht angezeigt, sobald deren Änderungsdatum mehr als ein Jahr zurück liegt. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn Sie möchten, dass sie in einem Backlog oder Board angezeigt werden, können Sie eine geringfügige Änderung an ihnen vornehmen, um die Uhr zurückzusetzen.
Wenn Sie Arbeitselemente endgültig löschen müssen, finden Sie Informationen hierzu unter Entfernen oder Löschen von Arbeitselementen.
Allen Prozessen hinzugefügte WITs
Die folgenden WITs werden allen Prozessen mit Ausnahme des Basic-Prozesses hinzugefügt.
Ihr Team kann diese Typen mithilfe des jeweils entsprechenden Tools erstellen und mit ihnen 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 Review | Code Review Request , Code Review Response |
Arbeitselemente dieser Typdefinitionen sollten nicht manuell erstellt werden und werden dann der Kategorie Hidden Types
hinzugefügt.
Arbeitselementtypen, die der Kategorie Hidden Types
hinzugefügt werden, werden nicht in den Menüs angezeigt, mit denen neue Arbeitsaufgaben erstellt werden.
WITs, welche die Test-Erfahrung unterstützen
WITs, die die Test-Erfahrung unterstützen und mit Test Manager sowie dem Webportal arbeiten, sind mit den in der folgenden Abbildung gezeigten Linktypen verknüpft.
Zeigen Sie im Webportal oder in Microsoft Test Manager an, welche Testfälle für eine Testsammlung definiert sind, und zeigen Sie an, welche Testsammlungen für einen Testplan definiert sind. Diese Objekte sind jedoch nicht miteinander durch Linktypen verknüpft. Passen Sie diese WITs wie alle anderen WITs an. Weitere Informationen finden Sie unter Anpassen der Objekte für die Arbeitsnachverfolgung 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.
Verwandte Artikel
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter:Einreichen und Feedback anzeigen für