Freigeben über

Informationen zur Prozessanpassung und geerbten Prozessen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Um das Arbeitsverfolgungssystem anzupassen, passen Sie einen geerbten Prozess über die Administrative Benutzeroberfläche für die Organisation an . Alle Projekte, die einen geerbten Prozess verwenden, erhalten die anpassungen, die an diesem Prozess vorgenommen wurden. Andererseits konfigurieren Sie Ihre Agile-Tools – Backlogs, Sprints, Boards und Taskboards – für jedes Team.

Wichtig

Informationen zum Anpassen eines lokalen Projekts oder Aktualisieren von XML-Definitionsdateien zur Unterstützung der Anpassung finden Sie unter lokales XML-Prozessmodell. Dieser Artikel gilt nur für Azure DevOps Services und Azure DevOps Server 2019.

Es gibt eine Reihe von Anpassungen, die Sie vornehmen können. Die hauptsache sind das Hinzufügen von benutzerdefinierten Arbeitsaufgabentypen (WITs) oder das Ändern eines vorhandenen WIT zum Hinzufügen von benutzerdefinierten Feldern, zum Ändern des Layouts oder zum Ändern des Workflows.

Hinweis

Überprüfen Sie änderungen, die an einem geerbten Prozess über das Überwachungsprotokoll vorgenommen wurden. Weitere Informationen finden Sie unter Access, Export und Filtern von Überwachungsprotokollen.

Unten finden Sie einen Index für diese Aufgaben, die Sie ausführen können, um einen geerbten Prozess anzupassen. Einige Optionen von geerbten Elementen sind gesperrt und können nicht angepasst werden.

System im Vergleich zu geerbten Prozessen

Es werden zwei Arten von Prozessen angezeigt:

  • Gesperrtes Symbol Systemprozesse – Agile, Basic, Scrum und CMMI –, die nicht verändert werden.
  • Geerbtes Symbol Geerbte Prozesse, die Sie anpassen können und die Definitionen vom Systemprozess erben, aus dem sie erstellt wurden. Systemprozesse werden regelmäßig von Microsoft verwaltet und aktualisiert. Alle An einem Systemprozess vorgenommenen Updates führen automatisch zu einer Aktualisierung ihrer geerbten Prozesse und deren untergeordneten geerbten Prozessen. Aktualisierungen von Prozessen werden in den Versionshinweisen für Azure DevOps Server dokumentiert.

Hinweis

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

Darüber hinaus werden alle Prozesse gemeinsam genutzt. Das heißt, ein oder mehrere Projekte können einen einzelnen Prozess verwenden. Anstatt ein einzelnes Projekt anzupassen, passen Sie einen Prozess an. Am Prozess vorgenommene Änderungen aktualisieren automatisch alle Projekte, die diesen Prozess verwenden. Nachdem Sie einen geerbten Prozess erstellt haben, können Sie ihn anpassen, Projekte basierend darauf erstellen, eine Kopie davon erstellen und vorhandene Projekte ändern, um ihn zu verwenden.

Wie in der folgenden Abbildung dargestellt, sehen Sie beispielsweise eine Liste der Projekte, die für die Fabrikam-Organisation definiert sind. In der zweiten Spalte wird der von jedem Projekt verwendete Prozess angezeigt. Um die Anpassungen des Fabrikam Fiber-Projekts zu ändern, müssen Sie den MyScrum-Prozess ändern (der vom Scrum-Systemprozess erbt). Alle Änderungen, die Sie am MyScrum-Prozess vornehmen, aktualisieren auch andere Projekte, die diesen Prozess verwenden. Sie können das Abfragetestprojekt jedoch erst anpassen, wenn Sie es in einen Prozess ändern, der von Agile erbt.

Screenshot des Administratorkontexts, Organisationseinstellungen, Projektliste und des verwendeten Prozesses.

Einschränkungen für Prozessnamen

Prozessnamen müssen eindeutig und 128 Unicode-Zeichen oder weniger sein. Außerdem dürfen Namen nicht die folgenden Zeichen enthalten: .,;'`:~\/\*|?"&%$!+=()[]{}<>

Um einen Prozess umzubenennen, öffnen Sie die ... Kontextmenü für den Prozess, und wählen Sie "Bearbeiten" aus.

Ändern des Referenzprozesses eines Projekts

Wenn Sie den Prozess, den ein Projekt verwendet, von einem Systemprozess auf einen anderen umstellen möchten, können Sie dies tun. Um diese Änderungen vorzunehmen, müssen Sie einen geerbten Prozess basierend auf dem Prozess erstellen, zu dem Sie wechseln möchten. Es werden z. B. Anweisungen zur Unterstützung der folgenden Änderungen bereitgestellt:

Im Anschluss an die in den oben aufgeführten Artikeln aufgeführten Anleitungen können Sie auch zusätzliche Änderungen vornehmen, z. B. von CMMI zu Agile oder Agile zu CMMI.

Bevor Sie diese Änderung vornehmen, sollten Sie sich mit dem Prozess vertraut machen, zu dem Sie wechseln. Die Systemprozesse werden in Informationen zu Prozessen und Prozessvorlagen zusammengefasst.

Bewährte Methoden beim Vornehmen von Änderungen

Das Vornehmen von Änderungen an einem geerbten Prozess ist gerade vorwärts und sicher. Es ist jedoch immer eine bewährte Methode, diese Änderungen zu testen, bevor sie auf ein aktives Projekt angewendet werden. Wenn Sie diese Schritte ausführen , können Sie negative Auswirkungen auf Ihre Prozessänderungen haben.

Geerbte Objekte im Vergleich zu benutzerdefinierten Objekten

Jeder geerbte Prozess, den Sie erstellen, erbt die im Systemprozess definierten WITs – Basic, Agile, Scrum oder CMMI. Der Agile-Prozess stellt z. B. Fehler, Aufgabe, Benutzergeschichte, Feature, episches, Problem und testbezogene WITs bereit.

Konzeptionelle Darstellung der Hierarchie von Agile-Prozessaufgaben.

Sie können Felder hinzufügen und das Workflow- und Arbeitselementformular für alle geerbten WITs ändern, die auf der Seite "Arbeitsaufgabentypen " angezeigt werden. Wenn Sie nicht möchten, dass Benutzer ein WIT erstellen, können Sie es deaktivieren. Darüber hinaus können Sie benutzerdefinierte WITs hinzufügen.

Anpassung von Feldern

Im Systemprozess definierte Felder werden mit einem geerbten Symbol angezeigt, das angibt, dass Sie in Ihrem geerbten Prozess eingeschränkte Änderungen daran vornehmen können.

Felder werden für alle Projekte und Prozesse in der Organisation definiert. Das bedeutet, dass jedes benutzerdefinierte Feld, das Sie für ein WIT in einem Prozess definiert haben, jedem anderen WIT hinzugefügt werden kann, der für einen anderen Prozess definiert ist.

Feldtyp

Anpassungsunterstützung

Geerbte Felder

Benutzerdefinierte Felder

Benutzerdefiniertes Steuerelement

Beachten Sie beim Hinzufügen benutzerdefinierter Felder die folgenden Grenzwerte:

  • Für jeden Arbeitselementtyp können maximal 64 Felder definiert werden.
  • Pro Prozess können maximal 512 Felder definiert werden.

Darüber hinaus können Sie innerhalb des Prozesses ein vorhandenes Feld zu einem anderen WIT hinzufügen. Sie können z. B. dem Benutzerabschnitt Fälligkeitsdatum oder Fehler-WITs hinzufügen.For example, you can add Due Date to the user story or bug WITs.

Was Sie nicht anpassen können

  • Sie können den Feldnamen oder Datentyp nicht ändern, nachdem Sie ihn definiert haben.
  • Sie können den grauen Bereich im Formular nicht ändern, in dem sich die Felder "Bundesland", "Grund", "Bereichspfad" und "Iterationspfad" befinden.
  • Sie können eine globale Liste nicht importieren oder definieren, wie sie von den gehosteten XML- und lokalen XML-Prozessmodellen unterstützt wird. Weitere Informationen finden Sie unter Definieren globaler Listen.
  • Sie können den Feldnamen oder Datentyp nicht ändern, nachdem Sie ihn definiert haben.
  • Sie können den grauen Bereich im Formular nicht ändern, in dem sich die Felder "Bundesland", "Grund", "Bereichspfad" und "Iterationspfad" befinden.
  • Im Hinblick auf Auswahllisten können Sie derzeit diese Vorgänge nicht ausführen:
    • Ändern der Auswahlliste eines geerbten Felds, z. B. des Felds "Aktivität" oder "Disziplin"
    • Ändern der Auswahllistenreihenfolge, Auswahllisten in alphabetischer Reihenfolge
  • Sie können den Hilfetext "Beschreibung" von geerbten Feldern nicht ändern.
  • Importieren oder definieren Sie eine globale Liste, die von den gehosteten XML- und lokalen XML-Prozessmodellen unterstützt wird. Weitere Informationen finden Sie unter Definieren globaler Listen.

Hinweis

Mit dem geerbten Prozess können Sie die Auswahllisten vordefinierter Felder nicht ändern, z. B. Aktivität, Automatisierungsstatus, Disziplin, Priorität und andere.

Konfigurierbare Auswahllisten

Die folgenden Auswahllisten sind für jedes Projekt konfiguriert und können nicht über einen geerbten Prozess angepasst werden.

Auswahllisten, die Personennamenfeldern zugeordnet sind, z. B. "Zugewiesen an" und "Geändert von", werden basierend auf den Benutzern verwaltet, die Sie einem Projekt oder Team hinzufügen.

Kann ich ein Feld umbenennen oder seinen Datentyp ändern?

Das Umbenennen eines Felds oder das Ändern des Datentyps werden nicht unterstützt. Sie können jedoch die Beschriftung ändern, die für ein Feld im Arbeitsaufgabenformular auf der Registerkarte "Layout" angezeigt wird. Beim Auswählen des Felds in einer Abfrage müssen Sie den Feldnamen und nicht die Feldbezeichnung auswählen.

Kann ich ein gelöschtes Feld löschen oder wiederherstellen?

Sie können ein Feld löschen und später wiederherstellen. Durch das Löschen eines Felds werden alle daten gelöscht, die diesem Feld zugeordnet sind, einschließlich historischer Werte. Nach dem Löschen können Sie das Feld nur wiederherstellen und die Daten mithilfe der Fields - Update REST API wiederherstellen.

Anstatt ein Feld zu löschen, sollten Sie das Feld stattdessen aus einem Arbeitselementformular ausblenden oder entfernen. Weitere Informationen finden Sie unter Hinzufügen und Verwalten von Feldern, Einblenden, Ausblenden oder Entfernen eines Felds.

Was ist ein Feld? Wie werden Feldnamen verwendet?

Jedem Arbeitselementtyp sind 31 Systemfelder und mehrere typspezifische Felder zugeordnet. Sie verwenden Arbeitselemente, um Ihr Projekt zu planen und nachzuverfolgen.

Jedes Feld unterstützt die Nachverfolgung einzelner Informationen über die auszuführende Arbeit. Werte, die Sie einem Feld zuweisen, werden im Datenspeicher für die Arbeitsnachverfolgung gespeichert, und Sie können Abfragen erstellen, um Status und Trends zu ermitteln.

Beschreibungen und Verwendung der einzelnen Felder, die für die Kernsystemprozesse – Scrum-, Agile- und CMMI-Systemprozesse – definiert sind, finden Sie unter Arbeitselementfeldindex.

Feldnamen

Ein Feldname für eine Arbeitsaufgabe legt jedes Arbeitsaufgabenfeld eindeutig fest. Stellen Sie sicher, dass Ihre Feldnamen den folgenden Richtlinien entsprechen:

  • Feldnamen müssen innerhalb der Organisation oder Projektsammlung eindeutig sein.
  • Feldnamen dürfen maximal 128 Unicode-Zeichen umfassen.
  • Feldnamen dürfen weder führende oder nachgestellte Leerzeichen noch zwei oder mehr aufeinanderfolgende Leerzeichen enthalten.
  • Feldnamen müssen mindestens ein alphabetisches Zeichen enthalten.
  • Feldnamen dürfen die folgenden Zeichen nicht enthalten: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Da alle Felder für die Organisation definiert sind, können Sie kein benutzerdefiniertes Feld mit demselben Feldnamen hinzufügen, der bereits in der Organisation vorhanden ist oder einem WIT in einem anderen geerbten Prozess hinzugefügt wurde.

Hinweis

Wenn Sie ein Projekt auf einen geerbten Prozess umstellen, können Agile-Tools oder Arbeitsaufgaben in einem ungültigen Zustand in den folgenden Beispielen auftreten:

  • Wenn Sie ein Feld als erforderlich festlegen, werden arbeitsaufgaben, die diesem Feld fehlen, eine Fehlermeldung angezeigt. Um mit weiteren Änderungen fortzufahren und die Arbeitsaufgabe zu speichern, beheben Sie diese Fehler.
  • Wenn Sie Workflowzustände für ein WIT hinzufügen, entfernen oder ausblenden, das auf der Tafel angezeigt wird, stellen Sie sicher, dass Sie die Boardspaltenkonfigurationen für alle im Projekt definierten Teams aktualisieren. Erwägen Sie außerdem, den Besitz einzelner Arbeitsaufgaben nach Teambereichspfad zu verwalten oder Spalten mit benutzerdefinierten Zuständen für teamsübergreifend zu formalisieren.

Benutzerdefinierte Regeln und Systemregeln

Jeder WIT – Fehler, Aufgabe, Benutzergeschichte usw. – hat bereits mehrere Systemregeln definiert. Einige sind einfach, z. B. das Feld "Titel" erforderlich zu machen oder einen Standardwert für das Feld "Wertbereich" festzulegen. Darüber hinaus definieren eine Reihe von Systemregeln Aktionen, die ausgeführt werden sollen, wenn sich ein Workflowstatus ändert.

Beispielsweise sind mehrere Regeln vorhanden, um die aktuelle Benutzeridentität unter den folgenden Bedingungen zu kopieren:

  • Wenn eine Arbeitsaufgabe geändert wird, kopieren Sie die Benutzeridentität in das Feld "Geändert von"
  • Wenn sich der Workflowstatus in "Geschlossen" oder "Fertig" ändert, kopieren Sie die Benutzeridentität in das Feld "Geschlossen von".

Wichtig

Vordefinierte Systemregeln haben Vorrang vor jeder benutzerdefinierten Regel, die Sie definieren, welche sie überschreiben würde.

Benutzerdefinierte Regeln bieten Unterstützung für eine Reihe von Geschäftsanwendungsfällen, sodass Sie über das Festlegen eines Standardwerts für ein Feld hinausgehen oder es erforderlich machen können. Mithilfe von Regeln können Sie den Wert eines Felds löschen, einen Wert in ein Feld kopieren und Werte basierend auf Abhängigkeiten zwischen den Werten verschiedener Felder anwenden.

Mit einer benutzerdefinierten Regel können Sie eine Reihe von Aktionen basierend auf bestimmten Bedingungen definieren. Sie können beispielsweise eine Regel anwenden, um diese Arten von Szenarien zu unterstützen:

  • Wenn ein Wert für "Priorität" definiert ist, müssen Sie "Risiko" als pflichtfeld festlegen.
  • Wenn eine Änderung am Wert von Release vorgenommen wird, löschen Sie den Wert von "Milestone"
  • Wenn eine Änderung am Wert "Verbleibende Arbeit" vorgenommen wurde, nehmen Sie "Abgeschlossene Arbeit" als pflichtfeld vor.
  • Wenn der Wert "Genehmigt" auf "True" festgelegt ist, erstellen Sie "Genehmigt von" ein erforderliches Feld.
  • Wenn ein Benutzerabschnitt erstellt wird, müssen Sie die folgenden Felder erforderlich machen: Priorität, Risiko und Aufwand

Tipp

Sie können eine Formel nicht mithilfe einer Regel definieren. Möglicherweise finden Sie jedoch eine Lösung, die Ihren Anforderungen mit der Erweiterung Power Automate oder TFS Aggregator (Web Service) Marketplace entspricht. Siehe auch "Rollup von Arbeit" und anderen Feldern.

Ausführliche Informationen zum Definieren von benutzerdefinierten Regeln finden Sie unter "Regeln und Regelauswertung".

Einschränken der Änderung von Auswahlfeldern für ausgewählte Benutzergruppen

Mit einer der folgenden beiden Bedingungen können Sie auswählen, welche Felder für einen Benutzer einer Sicherheitsgruppe erforderlich sind oder kein Mitglied einer Sicherheitsgruppe sind.

  • current user is a member of a group...
  • current user is not a member of a group...

Sie können z. B. das Feld "Titel" oder "Status" für ausgewählte Benutzer oder Gruppen schreibgeschützt festlegen.

Einschränken der Änderung von Arbeitsaufgaben basierend auf dem Bereichspfad

Sie können Benutzern das Ändern der ausgewählten Arbeitsaufgaben verbieten, indem Sie Berechtigungen für einen Bereichspfad festlegen. Dies ist keine Regeleinstellung, sondern eine Berechtigungseinstellung. Weitere Informationen finden Sie unter Erstellen untergeordneter Knoten, Ändern von Arbeitsaufgaben unter einem Bereichspfad.

Anpassungen des Arbeitsaufgabentyps (Work Item Type, WIT)

Hier sind Ihre Anpassungsoptionen für geerbte und benutzerdefinierte WITs.

Arbeitsaufgabentyp

Anpassungsunterstützung

Geerbte Arbeitsaufgabentypen

Benutzerdefinierte Arbeitsaufgabentypen

Was Sie nicht anpassen können

  • Sie können kein geerbtes WIT zu oder aus einem Backlog hinzufügen oder daraus entfernen.
  • Sie können die Position eines geerbten Felds innerhalb des Formularlayouts nicht ändern (Sie können das Feld jedoch in einem Bereich des Formulars ausblenden und an anderer Stelle im Formular hinzufügen)
  • Sie können die geerbte Portfolioebene nicht aus dem Produkt entfernen (aber Sie können sie umbenennen).
  • Sie können den Namen eines benutzerdefinierten WIT nicht ändern.

Anpassungen des Arbeitselementformulars

Sie können die folgenden Anpassungen an ein WIT-Formular vornehmen.

Gruppen- oder Seitentyp

Anpassungsunterstützung

Geerbte Gruppen

Benutzerdefinierte Gruppen

Geerbte Seiten

Benutzerdefinierte Seiten

Layout und Größenänderung

Das Webformularlayout ist in drei Spalten angeordnet, wie in der abbildung unten dargestellt.

Abbildung des 3-Spalten-Seitenlayouts für das Arbeitsaufgabenformular.

Wenn Sie nur Gruppen und Felder zu den ersten beiden Spalten hinzufügen, spiegelt das Layout ein zweispaltiges Layout wider. Ebenso, wenn Sie nur Gruppen und Felder zur ersten Spalte hinzufügen, spiegelt das Layout ein einspaltiges Layout wider.

Das Webformular ändert die Größe abhängig von der verfügbaren Breite und der Anzahl der Spalten im Layout. Bei maximaler Breite werden in den meisten Webbrowsern jede Spalte innerhalb einer Seite in einer eigenen Spalte angezeigt. Wenn die Anzeigebreite verringert wird, ändert sich die Größe jeder Spalte proportional wie folgt:

  • Für drei Spalten: 50 %, 25 % und 25 %
  • Für zwei Spalten: 66 % und 33 %
  • Für eine Spalte: 100 %.

Wenn die Anzeigebreite nicht für alle Spalten geeignet ist, werden Spalten innerhalb der Spalte links gestapelt angezeigt.

Anpassung von Workflows

Sie können den Workflow eines beliebigen Arbeitsaufgabentyps (WIT) anpassen, indem Sie geerbte Zustände ausblenden oder benutzerdefinierte Zustände hinzufügen. Geerbte Zustände variieren je nach dem Systemprozess, den Sie zum Erstellen des benutzerdefinierten Prozesses ausgewählt haben. Die Optionen sind Agile, Basic, Scrum oder Capability Maturity Model Integration (CMMI). Weitere Informationen finden Sie unter Workflowzustände, Übergänge und Gründe.

Jeder Standardworkflow für jede WIT definiert zwischen zwei und vier Zuständen und gibt die folgenden Workflowvorgänge an:

  • Vorwärts- und Rückwärtsübergänge zwischen jedem Zustand. Beispielsweise enthält das Grundlegende Prozessproblem WIT drei Zustände: To Do, Doing und Done.
  • Standardgründe für jeden Zustandsübergang

Statustypen

Unterstützte Anpassungen

Geerbte Zustände

Benutzerdefinierte Zustände

Workflowzustände müssen den folgenden Regeln entsprechen:

  • Definieren Sie mindestens einen Status für die Kategorien "Vorgeschlagen" oder "In Bearbeitung ".

    Hinweis

    Bevor Sie einen Workflowstatus hinzufügen, lesen Sie Informationen zu Workflowzuständen in Backlogs und Boards , um zu erfahren, wie Workflowzustände Zustandskategorien zugeordnet werden.

  • Definieren Sie mindestens zwei Workflowzustände.
  • Definieren Sie maximal 32 Workflowzustände pro Arbeitsaufgabentyp.

Nicht unterstützte Workflowanpassungen

  • Blenden Sie geerbte Zustände aus, wenn sie nicht sichtbar sein sollen (Sie können den Namen, die Farbe oder die Kategorie nicht ändern).
  • Stellen Sie sicher, dass nur ein Status in der Kategorie "Abgeschlossen" vorhanden ist. Durch Hinzufügen eines benutzerdefinierten Zustands zu dieser Kategorie werden alle anderen Zustände entfernt oder ausgeblendet.
  • Behalten Sie den Namen von benutzerdefinierten Zuständen wie folgt bei; Sie können sie nicht ändern.
  • Verwenden Sie Standardgründe für Zustandsübergänge, z . B. "In Zustandsauszug verschoben" und "Verschoben" aus dem Zustand "Triaged". Sie können keine benutzerdefinierten Gründe angeben.
  • Übernehmen Sie den Standardspeicherort der Felder "Bundesland" und "Grund" im Formular; Sie können deren Platzierung nicht ändern.
  • Verwenden Sie die Standardnamen der Statuskategorie; Sie können sie nicht anpassen.
  • Blenden Sie geerbte Zustände aus, wenn sie nicht sichtbar sein sollen (Sie können den Namen, die Farbe oder die Kategorie nicht ändern).
  • Stellen Sie sicher, dass nur ein Status in der Kategorie "Abgeschlossen" vorhanden ist. Das System lässt das Hinzufügen eines benutzerdefinierten Zustands zu dieser Kategorie nicht zu.
  • Behalten Sie den Namen von benutzerdefinierten Zuständen wie folgt bei; Sie können sie nicht ändern.
  • Akzeptieren Sie die natürliche Abfolge von Zuständen in der Dropdownliste im Arbeitsaufgabenformular; Sie können deren Reihenfolge nicht ändern.
  • Verwenden Sie Standardgründe für Zustandsübergänge, z . B. "In Zustandsauszug verschoben" und "Verschoben" aus dem Zustand "Triaged". Sie können keine benutzerdefinierten Gründe angeben.
  • Übernehmen Sie den Standardspeicherort der Felder "Bundesland" und "Grund" im Formular; Sie können deren Platzierung nicht ändern.
  • Übergänge von einem beliebigen Zustand zu einem anderen zulassen; Sie können keine Übergänge einschränken.

Backlog- und Boardanpassungen

Backlogs und Boards sind wichtige Agile-Tools zum Erstellen und Verwalten von Arbeit für ein Team. Die vom Systemprozess geerbten Standardbacklogs (Produkt, Iteration und Portfolio) sind vollständig anpassbar. Außerdem können Sie insgesamt fünf benutzerdefinierte Portfoliobacklogs hinzufügen.

Backlog-Typen

Anpassungsunterstützung

Geerbte Backlogs

Benutzerdefinierte Portfolio-Backlogs

Nicht unterstützte Anpassungen:

  • Entfernen einer geerbten Portfolioebene:
    • Sie können zwar nicht direkt eine geerbte Portfolioebene aus einem Produkt entfernen, sie haben jedoch eine Reihe von Optionen:
      • Benennen Sie die Portfolioebene um: Sie können die geerbte Portfolioebene umbenennen, um Ihren Anforderungen besser gerecht zu werden.
      • Deaktivieren Sie ein geerbtes WIT: Wenn die geerbte Portfolioebene WITs enthält, die Sie nicht verwenden möchten, können Sie sie deaktivieren. Diese Aktion verhindert, dass Teams neue Arbeitsaufgaben dieser Typen erstellen.
  • Einfügen einer Backlogebene:
    • Sie können keine neue Backlog-Ebene innerhalb der vorhandenen Gruppe definierter Backlogs einfügen. Die vordefinierten Backlogebenen sind in der Regel behoben (z. B. Epics, Features, User Stories, Tasks), und Sie können keine benutzerdefinierten Zwischenebenen hinzufügen.
  • Neuanordnen von Backlogebenen:
    • Leider können Sie die Backlogebenen nicht neu anordnen. Normalerweise folgen sie einer vordefinierten Hierarchie, und das Ändern ihrer Reihenfolge wird nicht unterstützt.
  • Hinzufügen eines WIT zu mehreren Backlogebenen:
    • Jede WIT kann nur zu einer Backlog-Ebene gehören. Sie können ein WIT nicht gleichzeitig zu zwei verschiedenen Backlog-Ebenen hinzufügen.
  • Erstellen einer benutzerdefinierten Vorgangsrücklogebene:
    • Obwohl Sie keine benutzerdefinierte aufgabenspezifische Backlogebene erstellen können, können Sie dem Iterationsrückstand weiterhin benutzerdefinierte WITs hinzufügen. Sie können z. B. ein benutzerdefiniertes WIT namens "Enhancement" oder "Maintenance" erstellen und dem Iterationsbacklog zuordnen.
  • Verwalten von Fehlern:
  • Hinzufügen oder Entfernen eines geerbten WIT aus einem Backlog:
    • Sie können kein geerbtes WIT direkt zu einem Oder aus einem Backlog hinzufügen oder daraus entfernen. Beispielsweise wird das Hinzufügen des WIT-Werts "Problem" zum Produktbacklog nicht unterstützt.
    • Sie haben jedoch folgende Möglichkeiten:
      • Benennen Sie die Portfolioebene um: Wenn die geerbte Portfolioebene WITs enthält, die Sie nicht verwenden möchten, sollten Sie es nach Ihren Anforderungen umbenennen.
      • Deaktivieren Sie ein geerbtes WIT: Wenn geerbte WITs vorhanden sind, die Sie ausschließen möchten, können Sie sie deaktivieren. Diese Aktion verhindert, dass Teams neue Arbeitsaufgaben dieser Typen erstellen.
  • Entfernen einer geerbten Portfolioebene:
    • Sie können zwar keine geerbte Portfolioebene von einem Produkt entfernen, sie haben jedoch eine Reihe von Optionen:
      • Benennen Sie die Portfolioebene um: Geben Sie ihm einen passenderen Namen.
      • Geerbte WITs deaktivieren: Verhindern, dass Teams bestimmte geerbte WITs verwenden.
  • Einfügen einer Backlogebene:
    • Leider können Sie keine neue Backlog-Ebene innerhalb der vorhandenen Gruppe definierter Backlogs einfügen. Die vordefinierten Backlog-Ebenen bleiben fest (z. B. Epics, Features, User Stories, Tasks).
  • Neuanordnen von Backlogebenen:
    • Backlogebenen folgen in der Regel einer vordefinierten Hierarchie, und das Ändern ihrer Reihenfolge wird nicht unterstützt. Sie können sie nicht neu anordnen.
  • Hinzufügen eines WIT zu mehreren Backlogebenen:
    • Jedes WIT (z. B. Bug, Task, User Story) kann nur zu einer Backlog-Ebene gehören. Sie können ein WIT nicht gleichzeitig zu zwei verschiedenen Backlog-Ebenen hinzufügen.
  • Erstellen einer benutzerdefinierten Aufgabenebene:
    • Obwohl Sie keine benutzerdefinierte aufgabenspezifische Backlogebene erstellen können, können Sie dem Iterationsrückstand weiterhin benutzerdefinierte WITs hinzufügen. Erstellen Sie beispielsweise ein benutzerdefiniertes WIT namens "Enhancement" oder "Maintenance", und ordnen Sie es dem Iterationsrückstand zu.
  • Verwalten von Fehlern:

Hinweis

Bestimmte Features erfordern die Installation des Azure DevOps Server 2020.1-Updates. Weitere Informationen finden Sie unter Azure DevOps Server 2020 Update 1 RC1 Versionshinweise, Boards.

Wenn Sie das Standard-WIT für einen Backlog-Level ändern, wird WIT standardmäßig im Schnell-Add-Bereich angezeigt. Beispielsweise wird das Kundenticket standardmäßig im folgenden Schnell-Add-Bereich für den Produktrücklog angezeigt.

Screenshot des Produktrückstands, Quick Add Panel, Displays Default WIT for a backlog level

Objektgrenzwerte

Eine Liste der Grenzwerte für die Anzahl der Felder, WITs, Backlog-Ebenen und andere Objekte, die Sie anpassen können, finden Sie unter Einschränkungen des Arbeitsverfolgungsobjekts.