Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
In Ihrem Projekt verfügen Sie derzeit über zwei vordefinierte Portfolio-Backlogs: Features und Epics. Wenn Für Ihr Projekt mehr Portfolio-Backlogs erforderlich sind, können Sie diese erstellen.
Wichtig
Das Vererbungsprozessmodell ist für Projekte verfügbar, die für die Unterstützung des Modelltyps konfiguriert sind. Wenn Sie eine ältere Sammlung verwenden, überprüfen Sie die Prozessmodellkompatibilität. Wenn Ihre lokale Auflistung für die Verwendung des lokalen XML-Prozessmodells konfiguriert wurde, können Sie nur dieses Prozessmodell zur Anpassung der Arbeitsverfolgung verwenden. Weitere Informationen finden Sie unter Prozessanpassung auf Organisationsebene.
Vorteile von Portfolio-Backlogs:
- Organisieren der Arbeit: Portfolio-Backlogs ermöglichen Ihnen, Arbeit basierend auf Geschäftsinitiativen, Benutzerszenarien oder anderen relevanten Kriterien zu organisieren.
- Hierarchische Ansicht: Durch die Strukturierung von Backlogs in Portfolios erhalten Sie eine hierarchische Ansicht der Arbeit, die Elemente aus untergeordneten Backlogs wie User Stories, Features oder Aufgaben umfasst.
- Teamübergreifende Transparenz: Programmmanager können den Status von Backlog-Elementen in mehreren Teams nachverfolgen. Sie können einen Drilldown ausführen, um sicherzustellen, dass alle Arbeiten angemessen repräsentiert sind.
Weitere Informationen finden Sie unter Informationen zur Prozessanpassung und geerbten Prozessen.
Im folgenden Beispiel haben wir einen Portfolio-Backlog auf dritter Ebene mit der Bezeichnung "Initiativen" hinzugefügt, der den benutzerdefinierten Arbeitsaufgabentyp "Initiative" nachverfolgt. Dazu haben wir den Produkt-Backlog zu Storys und Tickets umbenannt, um anzugeben, dass wir nicht nur User Storys, sondern auch Kundentickets im Produkt-Backlog nachverfolgen.
Unterstützte Anpassungen
Backlogs und Boards sind wichtige Agile-Tools zum Erstellen und Verwalten der Arbeit für ein Team. Die von Systemprozessen geerbten Standardprodukt-, Iterations- und Portfolio-Backlogs können vollständig angepasst werden. Sie können auch benutzerdefinierte Portfolio-Backlogs bis zu insgesamt fünf Portfolio-Backlogs hinzufügen.
Weitere Informationen zum Anpassen geerbter und benutzerdefinierter Portfolio-Backlogs finden Sie in den folgenden Ressourcen:
Übernommene Backlogs
- Hinzufügen eines benutzerdefinierten Arbeitselementtyps (Work Item Type, WIT)
- Hinzufügen eines übernommenen Arbeitselementtyps
- Ändern des standardmäßigen Arbeitselementtyps
- Umbenennen eines Backlogs
Benutzerdefinierte Portfolio-Backlogs
- Hinzufügen eines benutzerdefinierten Portfolio-Backlogs zum Anzeigen benutzerdefinierter Arbeitsaufgabentypen (WITs)
- Bearbeiten oder Umbenennen eines benutzerdefinierten Portfoliobacklogs
- Löschen des benutzerdefinierten Portfolio-Backlogs der obersten Ebene
Einschränkungen
- Sie können eine geerbte Portfolioebene nicht aus einem Produkt entfernen. Sie können die Ebene umbenennen oder WITs deaktivieren, um zu verhindern, dass Teams neue Arbeitsaufgaben dieser Typen erstellen.
- Sie können keine neue benutzerdefinierte Backlog-Ebene innerhalb der vorhandenen Gruppe definierter Backlogs einfügen. Die vordefinierten Backlogebenen sind in der Regel festgelegt, z. B. Epics, Features, User Stories und Tasks.
- Sie können die Backlog-Ebenen nicht neu anordnen. Sie folgen in der Regel einer vordefinierten Hierarchie, und das Ändern der Reihenfolge wird nicht unterstützt.
- Man kann ein WIT nicht zu zwei verschiedenen Backlogebenen hinzufügen. Jeder WIT kann nur zu einer Backlog-Ebene gehören.
- Sie können keine benutzerdefinierte task-spezifische Backlogebene erstellen, aber Sie können dem Backlog der Iteration weiterhin benutzerdefinierte WITs hinzufügen. Sie können z. B. ein benutzerdefiniertes WIT namens "Enhancement " oder "Maintenance " erstellen und dem Iterationsbacklog zuordnen.
- Der Bug WIT gehört standardmäßig nicht zu einer bestimmten Backlog-Ebene. Jedes Team kann entscheiden, wie sie Fehler verwalten möchten. Sie können auswählen, dass Fehler auf Backlogs und Boards angezeigt oder separat behandelt werden. Weitere Informationen finden Sie unter Anzeigen von Fehlern in Backlogs.
Hinzufügen eines System-Arbeitselementtyps zu einem Backlog
Wenn Sie Probleme oder Hindernisse oder andere geerbte Arbeitsaufgabentypen (WIT) in einem Backlog oder Board nachverfolgen möchten, bearbeiten Sie den entsprechenden Backlog. In der folgenden Tabelle sind die verfügbaren WITs aufgeführt, die Sie einem Backlog hinzufügen können.
| Prozess | Arbeitselementtypen |
|---|---|
| Agile | Problem |
| Scrum | Impediment |
| CMMI | Änderungsanforderung, Problem, Überprüfung, Risiko |
Jedes Dialogfeld Backlogebene bearbeiten enthält automatisch übernommene und benutzerdefinierte Arbeitselementtypen, die keinen anderen Backlogebenen zugewiesen sind. Beispielsweise werden nicht zugewiesene Agile-Arbeitsaufgabentypen unter den Typen "Andere Arbeitsaufgaben" aufgeführt.
Diese gleichen WITs werden zusammen mit allen benutzerdefinierten Arbeitsaufgabentypen im Dialogfeld "Backlog-Ebene bearbeiten " aller Backlogebenen angezeigt, bis sie einer bestimmten Backlogebene zugewiesen werden.
Hinweis
Sie können den standardmäßig geerbten Arbeitsaufgabentyp nicht aus jeder Backlog-Ebene entfernen, aber Sie können das entsprechende WIT deaktivieren. Beispielsweise können Sie das User Story WIT für den agilen Anforderungs-Backlog deaktivieren, solange Sie einen weiteren Arbeitselementtyp hinzugefügt haben, um diesen Backlog zu unterstützen.
Felder, die Arbeitselementtypen hinzugefügt wurden
Wenn Sie einer Backlogebene einen WIT hinzufügen, werden bestimmte Felder der WIT-Definition automatisch als ausgeblendete Felder hinzugefügt. Diese Felder werden nicht im Arbeitselementformular angezeigt, sondern sind für die Unterstützung bestimmter Agile-Toolfeatures unerlässlich.
| Backlog-Ebene | Hinzugefügte Felder | Beschreibung |
|---|---|---|
| Portfoliobacklog |
-
Stack Rank (Agile, CMMI) - Backlog-Priorität (Scrum) |
Die Felder „Stapelrang“ und „Backlog-Priorität“ erfassen die relative Priorität von Arbeitselementen, wenn sie in einem Backlog oder Board neu angeordnet werden. Weitere Informationen finden Sie unter Hintergrundinformationen: das Feld „Backlog Priority“ oder „Stapelrang“. |
| Anforderungsbacklog |
-
Stack Rank, Story Points (Agile) - Stapelrang, Größe (CMMI) - Backlog-Priorität, Aufwand (Scrum) |
In den Feldern „Story Points“, „Size“ und „Effort“ wird die relative Arbeit erfasst, die zum Abschließen eines WIT erforderlich ist, der dem Requirement-Backlog zugewiesen ist. Dieser Wert wird zum Berechnen der Geschwindigkeit verwendet. |
| Iterationsbacklog |
-
Aktivität, Verbleibende Arbeit, Stapelrang (Agile) - Disziplin, Verbleibende Arbeit, Rangordnung (CMMI) - Aktivität, Verbleibende Arbeit, Backlog Priority (Scrum) |
Verbleibende Arbeit wird in Sprint-Burndown- und Kapazitätsdiagrammen genutzt. |
Voraussetzungen
Anleitungen zum Anpassen von Azure Boards zur Anpassung an Ihre spezifischen Geschäftsanforderungen finden Sie unter Konfigurieren und Anpassen von Azure Boards.
| Kategorie | Anforderungen |
|---|---|
| Berechtigungen | – So erstellen, löschen oder bearbeiten Sie einen Prozess: Mitglied der Gruppe Projektsammlungsadministrator oder spezifische Berechtigungen auf Sammlungsebene – Prozess erstellen, Prozess löschen, Prozess bearbeiten oder Feld aus Organisation löschen – auf Zulassen gesetzt. Weitere Informationen finden Sie unter Anpassen eines geerbten Prozesses. - Zum Aktualisieren von Boards: Teamadmin oder Mitglied der Gruppe Projektadministrierende. |
| Zugriff | – Selbst wenn Sie über den Einfachen oder niedrigeren Zugriff verfügen, können Sie einen Prozess weiterhin ändern, wenn Ihnen jemand die Berechtigung erteilt. – Aktualisieren von Arbeitselementen und Ändern des Typs: Mitglied des Projekts. |
| Projektprozessmodell | – Verwenden Sie das Vererbungsprozess-Modell für die Projektsammlung, die das Projekt enthält. – Verwenden Sie den Team Foundation Server-Datenbankimportdienst, um Daten zu Azure DevOps Services zu migrieren. |
| Wissen | - Vertrautheit mit den Anpassungs- und Prozessmodellen. |
Hinweis
Wenn Sie einen geerbten Prozess anpassen, spiegeln alle Projekte, die den Prozess verwenden, automatisch die Anpassungen wider. Um einen reibungslosen Übergang sicherzustellen, empfiehlt es sich, einen Testprozess und ein Projekt zu erstellen, um Ihre Anpassungen zu testen, bevor Sie sie organisationsweit implementieren. Weitere Informationen finden Sie unter Erstellen und Verwalten geerbter Prozesse.
Hinzufügen oder Bearbeiten von Portfoliobacklogs
Die Agile-, Scrum- und CMMI-Systemprozesse definieren zwei Standardportfolio-Backlogs, Epics und Features. Jeder davon ist den entsprechenden Arbeitselementtypen, Epic und Feature, zugeordnet. Der Basic-Prozess definiert nur den Backlog „Epics“ und Arbeitselementtyp „Epic“. Weitere Informationen finden Sie unter Standardprozesse und Prozessvorlagen.
Sie können ein benutzerdefiniertes Arbeitselement hinzufügen oder eines auswählen, das Sie zuvor hinzugefügt haben. Beachten Sie, dass nur Arbeitselemente, die keiner anderen Backlog-Ebene zugeordnet sind, für die Auswahl angezeigt werden.
Hinzufügen eines Portfolio Backlogs
Sie können mit den folgenden Schritten einen Portfolio-Backlog und einen benutzerdefinierten Arbeitselementtyp hinzufügen.
Melden Sie sich bei Ihrer Organisation an (
https://dev.azure.com/{Your_Organization}).Wählen Sie "Organisationseinstellungen" aus.
Wählen Sie Prozess aus.
Melden Sie sich bei Ihrer Sammlung an (
https://dev.azure.com/{Your_Collection}).Wählen Sie Sammlungseinstellungen oder Administratoreinstellungen aus.
Wählen Sie Prozess aus.
Wählen Sie auf der Seite " Backlog levels " die Option +Neuer Portfolio-Backlog der obersten Ebene aus.
Benennen Sie die Backlogebene, wählen Sie die Farbe der Backlogebene aus, und fügen Sie den Arbeitselementtyp hinzu, der dieser Ebene zugeordnet werden soll; wählen Sie dann Hinzufügen aus.
Wenn Sie nur einen Arbeitselementtyp dem Backlog zuordnen, wählen Sie Speichern aus, um Ihre Änderungen zu speichern. Andernfalls können Sie bei Bedarf weitere Arbeitselementtypen hinzufügen.
Bearbeiten, Umbenennen oder Löschen eines Portfolio-Backlogs
Wählen Sie auf der Seite Backlogebenen das Kontextmenü 
eines zu bearbeitenden Portfolio-Backlogs, um ihn zu bearbeiten, umzubenennen oder zu löschen.
Durch das Löschen einer Backlogebene werden der Backlog und das Board entfernt, die der Ebene für alle Teams zugeordnet sind, einschließlich daran vorgenommener Anpassungen. Die mit den zugehörigen Arbeitselementtypen definierten Arbeitselemente werden in keiner Weise gelöscht oder dadurch beeinflusst.
Hinweis
Sie können den standardmäßig geerbten Arbeitsaufgabentyp nicht aus den Portfolio-Backlogs von Epics oder Features entfernen. Sie können diese Arbeitselementtypen jedoch deaktivieren und diese effektiv von der Benutzeroberfläche entfernen.
Bearbeiten oder Umbenennen des Anforderungsbacklogs
Der Backlog „Requirement“, der auch als Product Backlog bezeichnet wird, definiert die Arbeitselementtypen, die im Product Backlog und Board angezeigt werden. Der standardmäßige Arbeitselementtyp für Agile ist User Story, für Basic ist er Issue, für Scrum Product Backlog Item und für CMMI Requirement.
Sie können den Backlog umbenennen, die Farbe ändern, Arbeitselementtypen hinzufügen und den standardmäßigen Arbeitselementtyp ändern. Öffnen Sie das Dialogfeld „Backlog bearbeiten“ im Kontextmenü für den Anforderungsbacklog.
Im folgenden Beispiel haben wir den Backlog umbenannt, Customer Ticket und Issue hinzugefügt und den Standardtyp in Customer Ticket geändert. Aktivieren Sie die Kontrollkästchen der Arbeitselementtypen, die in den Backlog aufgenommen werden sollen.
Hinweis
Sie können den standardmäßig geerbten Arbeitsaufgabentyp nicht aus der Anforderungsliste entfernen. Sie können den Arbeitselementtyp jedoch deaktivieren und ihn damit effektiv von der Benutzeroberfläche entfernen.
Bearbeiten des Iterationsbacklogs
Der Iterationsbacklog, auch als Sprint-Backlog bezeichnet, definiert die Arbeitselementtypen, die in den Sprint-Backlogs und Taskboards angezeigt werden. Der standardmäßige Arbeitselementtyp für alle Prozesse ist „Aufgabe“.
Für den Iterationsbacklog können Sie Arbeitselementtypen hinzufügen und den standardmäßigen Arbeitselementtyp ändern. Öffnen Sie das Dialogfeld „Backlog bearbeiten“ im Kontextmenü für den Iterationsbacklog.
Im folgenden Beispiel haben wir den Arbeitselementtyp Ticket hinzugefügt, der zusammen mit Aufgaben nachverfolgt wird.
Hinweis
Sie können den standardmäßig geerbten Arbeitsaufgabentyp nicht aus dem Iterations-Backlog entfernen. Sie können den Arbeitselementtyp jedoch deaktivieren und ihn damit effektiv von der Benutzeroberfläche entfernen.