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, Kanban-Boards und Taskboard – 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

Sie können änderungen, die an einem geerbten Prozess vorgenommen wurden, über das Überwachungsprotokoll überprüfen. Weitere Informationen finden Sie unter Zugreifen, Exportieren 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:

  • locked icon Systemprozesse – Agile, Basic, Scrum und CMMI –, die nicht verändert werden.
  • inherited icon 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 of Admin context, Organization settings, Project list and the process they use.

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.

Conceptual image of Agile process work item hierarchy.

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 so ändern, dass ein geerbter Prozess verwendet wird, können Sie feststellen, dass ein oder mehrere Agile-Tools oder Arbeitselemente in einem ungültigen Zustand angezeigt werden. Beispiel:

  • Wenn Sie ein Feld erforderlich machen, wird für Arbeitselemente, für die dieses Feld nicht definiert ist, eine Fehlermeldung angezeigt. Sie müssen die Fehler beheben, um zusätzliche Änderungen vorzunehmen und das Arbeitselement zu speichern.
  • Wenn Sie Workflowzustände einer WIT hinzufügen oder entfernen oder ausblenden, die auf dem Kanban-Board angezeigt wird, müssen Sie die Konfigurationen der Kanban-Boardspalte für alle im Projekt definierten Teams aktualisieren.

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 von "Re Standard ing Work" vorgenommen wurde, müssen Sie "Abgeschlossene Arbeit" als Pflichtfeld festlegen.
  • 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.

Illustration of 3-column page layout for work item form.

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 unterscheiden sich je nach Systemprozess – Agile, Basic, Scrum oder CMMI – sie haben sich für die Erstellung Ihres benutzerdefinierten Prozesses entschieden.

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
  • Standardgründe für jeden Zustandsübergang

Beispielsweise zeichnet sich das Problem-WIT durch die drei Zustände "To Do", "Do", "Do" und " Done" aus, und übergänge, die in der folgenden Abbildung dargestellt sind.

Basic Process, Issue work item type, workflow state model

Statustypen

Unterstützte Anpassungen

Inherited icon Geerbte Zustände

Benutzerdefinierte Zustände

Workflowzustände müssen den folgenden Regeln entsprechen:

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

    Hinweis

    Bevor Sie einen Workflowstatus hinzufügen, überprüfen Sie Workflowzustände und Statuskategorien , um zu erfahren, wie Workflowzustände Zustandskategorien zugeordnet werden.

  • Sie müssen mindestens zwei Workflowzustände definieren.
  • Sie können maximal 32 Workflowzustände pro Arbeitsaufgabentyp definieren.

Nicht unterstützte Workflowanpassungen

  • Sie können keinen geerbten Zustand ändern (Sie können den Namen, die Farbe oder die Kategorie nicht ändern), aber Sie können ihn ausblenden.
  • Sie können nur einen Status in der Kategorie "Abgeschlossen" haben. Wenn Sie der Kategorie "Abgeschlossen" einen benutzerdefinierten Zustand hinzufügen, wird ein anderer Zustand entfernt oder ausgeblendet.
  • Sie können den Namen eines benutzerdefinierten Zustands nicht ändern.
  • Sie können keinen Grund für einen Zustand angeben, sondern standardgründe werden definiert, z . B. "Verschoben in Zustand Triaged", "Verschoben" aus dem Status "Triaged"
  • Sie können die Position der Felder "Bundesland" und "Grund" im Formular nicht ändern.
  • Statuskategorienamen können nicht angepasst werden
  • Sie können keinen geerbten Zustand ändern (Sie können den Namen, die Farbe oder die Kategorie nicht ändern), aber Sie können ihn ausblenden.
  • Sie können nur einen Status in der Kategorie "Abgeschlossen" haben. Das System verbietet das Hinzufügen eines benutzerdefinierten Zustands zu dieser Kategorie.
  • Sie können den Namen eines benutzerdefinierten Zustands nicht ändern.
  • Sie können die Reihenfolge der Zustände nicht ändern, Zustände werden in ihrer natürlichen Reihenfolge basierend auf ihrer Statuskategorie in der Dropdownliste eines Arbeitsaufgabenformulars aufgelistet.
  • Sie können keinen Grund für einen Zustand angeben, sondern standardgründe werden definiert, z . B. "Verschoben in Zustand Triaged", "Verschoben" aus dem Status "Triaged"
  • Sie können die Position der Felder "Bundesland" und "Grund" im Formular nicht ändern.
  • Sie können keine Übergänge einschränken, alle Übergänge werden von jedem Zustand in einen anderen Zustand definiert.

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

Was Sie nicht anpassen können

  • Sie können keine geerbte Portfolioebene aus dem Produkt entfernen (sie können die Portfolioebene jedoch umbenennen und einen geerbten Arbeitsaufgabentyp deaktivieren).
  • Sie können keinen Backlog-Level innerhalb der vorhandenen Gruppe definierter Backlogs einfügen.
  • Sie können die Backlogebenen nicht neu anordnen.
  • Sie können keinen Arbeitsaufgabentyp zu zwei verschiedenen Backlogebenen hinzufügen.
  • Sie können keine benutzerdefinierte Vorgangsrückstandsebene erstellen, obwohl Sie dem Iterationsrückstand benutzerdefinierte WITs hinzufügen können.
  • Sie können den Bug WIT nicht zu jeder Backlog-Ebene hinzufügen. Stattdessen kann das System jedes Team entscheiden, wie sie Fehler verwalten möchten. Weitere Informationen finden Sie unter "Anzeigen von Fehlern bei Backlogs und Boards".
  • Sie können kein geerbtes WIT zu einem Oder aus einem Backlog hinzufügen oder daraus entfernen, z. B. können Sie das Problem WIT nicht zum Produktrücklog hinzufügen.
  • Sie können keine geerbte Portfolioebene aus dem Produkt entfernen (sie können die Portfolioebene jedoch umbenennen und einen geerbten Arbeitsaufgabentyp deaktivieren).
  • Sie können keinen Backlog-Level innerhalb der vorhandenen Gruppe definierter Backlogs einfügen.
  • Sie können die Backlogebenen nicht neu anordnen.
  • Sie können keinen Arbeitsaufgabentyp zu zwei verschiedenen Backlogebenen hinzufügen.
  • Sie können keine benutzerdefinierte Aufgabenebene erstellen, obwohl Sie dem Iterationsbacklog benutzerdefinierte Arbeitsaufgabentypen hinzufügen können.
  • Sie können den Bug WIT nicht zu jeder Backlog-Ebene hinzufügen. Stattdessen kann das System jedes Team entscheiden, wie sie Fehler verwalten möchten. Weitere Informationen finden Sie unter "Anzeigen von Fehlern bei Backlogs und Boards".

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 of Product backlog, 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.