Informationen zur Prozessanpassung und zu geerbten Prozessen

Azure DevOps Services | Azure DevOps Server 2020 | 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 diesen Prozess vorgenommen werden. Andererseits konfigurieren Sie Ihre agilen 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 im lokalen 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 primären Elemente fügen benutzerdefinierte Arbeitselementtypen (WITs) hinzu oder ändern ein vorhandenes WIT, um benutzerdefinierte Felder hinzuzufügen, das Layout zu ändern oder den Workflow zu ändern.

Hinweis

Sie können Änderungen, die an einem geerbten Prozess vorgenommen wurden, über das Überwachungsprotokoll überprüfen. Weitere Informationen finden Sie unter Access, Export und Filterüberwachungsprotokolle.

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

Hinweis

Anleitungen zum Konfigurieren und Anpassen Ihres Projekts und Teams, um Ihre Geschäftlichen Anforderungen zu unterstützen, Konfiguration und Anpassung von Azure Boards zu überprüfen.

System im Vergleich zu geerbten Prozessen

Es werden zwei Arten von Prozessen angezeigt:

  • locked icon Systemprozesse – Agile, Basic, Scrum und CMMI – die von der Änderung gesperrt sind.
  • inherited icon Geerbte Prozesse, die Sie anpassen können und die Definitionen aus dem Systemprozess erben, aus dem sie erstellt wurden. Systemprozesse gehören und werden regelmäßig von Microsoft aktualisiert. Alle Updates, die an einem Systemprozess vorgenommen wurden, führen automatisch zu einer Aktualisierung ihrer geerbten Prozesse.

Hinweis

Der Grundlegende Prozess ist mit Azure DevOps Server 2019 Update 1 und höher versionen verfügbar.

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

Wie in der folgenden Abbildung dargestellt, wird beispielsweise eine Liste der Projekte angezeigt, die für die Fabrikam-Organisation definiert sind. Die zweite Spalte zeigt den Prozess, der von jedem Projekt verwendet wird. 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 beim MyScrum-Prozess vornehmen, aktualisieren auch andere Projekte, die diesen Prozess verwenden. Sie können das Abfragetestprojekt auf der anderen Seite nicht anpassen, bis Sie ihn in einen Prozess ändern, der von Agile erbt.

Admin context, Organization settings, Project list and the process they use

Einschränkungen für Prozessnamen

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

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

Ändern des Referenzvorgangs eines Projekts

Wenn Sie den Prozess wechseln möchten, den ein Projekt von einem Systemprozess in einen anderen verwendet, 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. Anweisungen zum Unterstützen der folgenden Änderungen werden z. B. bereitgestellt:

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

Bevor Sie diese Änderung vornehmen, empfehlen wir Ihnen, sich mit dem Prozess vertraut zu machen, den Sie ändern. Die Systemprozesse werden in "Prozess auswählen" zusammengefasst.

Bewährte Methoden beim Vornehmen von Änderungen

Das Vornehmen von Änderungen an einem geerbten Prozess ist gerade und sicher. Es ist jedoch immer eine bewährte Methode, diese Änderungen zu testen, bevor sie auf ein aktives Projekt angewendet werden. In den folgenden Schritten 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 beispielsweise Fehler, Aufgabe, Benutzergeschichte, Feature, Epen, Problem und testbezogene WITs bereit.

Agile work item types

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

Feldanpassungen

Felder, die im Systemprozess definiert sind, werden mit einem geerbten Symbol angezeigt, das angibt, dass Sie in Ihrem geerbten Prozess begrenzte Änderungen vornehmen können.

Felder werden für alle Projekte und Prozesse in der Organisation definiert. Das bedeutet, dass alle benutzerdefinierten Felder, die Sie für ein WIT in einem Prozess definiert haben, für einen anderen PROZESS hinzugefügt werden können.


Feldtyp

Anpassungsunterstützung


Geerbte Felder


Benutzerdefinierte Felder


Benutzerdefiniertes Steuerelement


Beachten Sie beim Hinzufügen von benutzerdefinierten Feldern die folgenden Grenzwerte:

  • Maximal 64 Felder können für jede WIT definiert werden.
  • Maximal 512 Felder können pro Prozess definiert werden.

Darüber hinaus können Sie einem anderen WIT im Prozess ein vorhandenes Feld hinzufügen . Sie können z. B. dem Benutzerverlauf oder dem Fehler WITs Fälligkeitsdatum hinzufügen.

Was Sie nicht anpassen können

  • Sie können den Feldnamen oder Datentyp nicht ändern, nachdem Sie sie definiert haben.
  • Sie können den grauen Bereich im Formular nicht ändern, in dem sich die Felder "Status", "Grund", "Bereichspfad" und "Iterationspfad" befinden.
  • Sie können keine globale Liste importieren oder definieren, die 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 sie definiert haben.
  • Sie können den grauen Bereich im Formular nicht ändern, in dem sich die Felder "Status", "Grund", "Bereichspfad" und "Iterationspfad" befinden.
  • Im Hinblick auf Auswahllisten können Sie diese Vorgänge derzeit nicht ausführen:
    • Ändern der Auswahlliste eines geerbten Felds, z. B. des Felds "Aktivität" oder "Disziplin"
    • Ändern der Auswahllistereihenfolge, Auswahllisten in alphabetischer Reihenfolge
  • Sie können den Hilfetext "Beschreibung" von geerbten Feldern nicht ändern.
  • Importieren oder definieren Sie eine globale Liste, die vom 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äts-, 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 mit Personennamenfeldern verknüpft sind, z. B. "Zugewiesen an" und "Geändert nach", werden basierend auf den Benutzern verwaltet, die Sie einem Projekt oder Team hinzufügen.

Kann ich ein Feld umbenennen oder den Datentyp ändern?

Das Umbenennen eines Felds oder das Ändern des Datentyps werden nicht unterstützt. Sie können jedoch die Bezeichnung ändern, die für ein Feld im Arbeitselementformular auf der Registerkarte "Layout" angezeigt wird. Wenn Sie das Feld in einer Abfrage auswählen, 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 es später wiederherstellen. Das Löschen eines Felds löscht alle Daten, 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 Felder - REST-API aktualisieren.

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

Was ist ein Feld? Wie werden Feldnamen verwendet?

Jeder Arbeitselementtyp ist 31 Systemfeldern und mehreren typspezifischen Feldern zugeordnet. Sie verwenden Arbeitselemente, um Ihr Projekt zu planen und zu verfolgen.

Jedes Feld unterstützt das Nachverfolgen eines Informationsteils über die auszuführende Arbeit. Werte, die Sie einem Feld zuweisen, werden im Arbeitsverfolgungsdatenspeicher gespeichert, den Sie Abfragen erstellen können, um Status und Trends zu bestimmen.

Beschreibungen und Verwendung jedes Felds, das für die Kernsystemprozesse definiert ist – Scrum, Agile und CMMI-Systemprozesse – finden Sie unter Arbeitselementfeldindex.

Feldnamen

Ein Feldname für eine Arbeitsaufgabe legt jedes Arbeitsaufgabenfeld eindeutig fest. Stellen Sie sicher, dass Ihre Feldnamen in diesen Richtlinien liegen:

  • Feldnamen müssen innerhalb der Organisation oder Projektsammlung eindeutig sein.
  • Feldnamen müssen 128 oder weniger Unicode-Zeichen sein.
  • Feldnamen können keine führenden oder nachgestellten Leerzeichen enthalten, noch zwei oder mehr fortlaufende Leerzeichen
  • Feldnamen müssen mindestens ein alphabetisches Zeichen enthalten.
  • Feldnamen können nicht die folgenden Zeichen 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 ändern, um einen geerbten Prozess zu verwenden, finden Sie möglicherweise ein oder mehrere agile Tools oder Arbeitselemente in einem ungültigen Zustand. Beispiel:

  • Wenn Sie ein Feld erforderlich machen, zeigen Arbeitselemente mit diesem Feld nicht definiert eine Fehlermeldung an. Sie müssen die Fehler beheben, um zusätzliche Änderungen vorzunehmen und das Arbeitselement zu speichern.
  • Wenn Sie Workflowzustände eines WIT hinzufügen oder ausblenden, das im Kanban-Board angezeigt wird, müssen Sie die Kanban-Boardspaltenkonfigurationen für alle im Projekt definierten Teams aktualisieren.

Benutzerdefinierte Regeln und Systemregeln

Jede WIT – Fehler, Aufgabe, Benutzergeschichte usw.– weist bereits mehrere Systemregeln auf. Einige sind einfach, z. B. das Feld "Titel" erforderlich oder einen Standard 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 ein Arbeitselement geändert wird, kopieren Sie die Benutzeridentität in das Feld "Geändert nach"
  • Wenn sich der Workflowstatus in "Geschlossen" oder "Fertig" ändert, kopieren Sie die Benutzeridentität in das Feld "Geschlossen nach".

Wichtig

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

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

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, stellen Sie "Risiko" ein erforderliches Feld vor.
  • Wenn eine Änderung an den Wert von Release vorgenommen wird, löschen Sie dann den Wert "Meilenstein"
  • Wenn eine Änderung an den Wert von "Restarbeit" vorgenommen wurde, machen Sie "Abgeschlossene Arbeit" ein erforderliches Feld.
  • Wenn der Wert "Genehmigt" "True" ist, stellen Sie dann ein erforderliches Feld "Genehmigt" vor.
  • Wenn eine Benutzergeschichte erstellt wird, müssen Sie die folgenden Felder benötigen: Priorität, Risiko und Aufwand

Tipp

Sie können keine Formel mithilfe einer Regel definieren. Sie können jedoch eine Lösung finden, die Ihren Anforderungen über die TFS-Aggregator-Erweiterung (Web Service) Marketplace entspricht. Siehe auch Das Rollup von Arbeit und anderen Feldern.

Ausführliche Informationen zum Definieren benutzerdefinierter Regeln finden Sie unter Regeln und Regelbewertung.

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

Mithilfe einer der folgenden beiden Bedingungen können Sie die für einen Benutzer einer Sicherheitsgruppe erforderlichen Felder auswählen oder nicht 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. den Titel oder das Feld "Status" für ausgewählte Benutzer oder Gruppen schreibgeschützt machen.

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

Sie können Benutzern das Ändern von Arbeitselementen deaktivieren, indem Sie Berechtigungen für einen Bereichspfad festlegen. Dies ist keine Regeleinstellung, sondern eine Berechtigungseinstellung. Weitere Informationen finden Sie unter "Erstellen untergeordneter Knoten", ändern Sie Arbeitselemente unter einem Bereichspfad.

Anpassungen des Arbeitselementtyps (WIT)

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


Arbeitsaufgabentyp

Anpassungsunterstützung


Geerbte Arbeitselementtypen


Benutzerdefinierte Arbeitselementtypen


Was Sie nicht anpassen können

  • Sie können kein geerbtes WIT zu oder aus einem Backlog hinzufügen oder entfernen.
  • Sie können die Position eines geerbten Felds im Formularlayout 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öße ändern

Das Webformularlayout wird in drei Spalten organisiert, wie in der Abbildung unten dargestellt.

3-column page layout

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 Spaltenlayout wider.

Das Webformular ändert die Größe je nach verfügbarer Breite und anzahl der Spalten im Layout. Bei maximaler Breite werden in den meisten Webbrowsern jede Spalte in einer Seite innerhalb einer eigenen Spalte angezeigt. Wenn die Anzeigebreite verringert wird, ändert sich jede 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 allen Spalten entspricht, werden Spalten innerhalb der Spalte nach links gestapelt angezeigt.

Workflowanpassungen

Sie können den Workflow eines beliebigen Arbeitselementtyps (WIT) anpassen, indem Sie geerbte Zustände ausblenden oder benutzerdefinierte Zustände hinzufügen. Geerbte Zustände unterscheiden sich basierend auf dem Systemprozess – Agile, Basic, Scrum oder CMMI – Sie haben ausgewählt, von welchem Sie Ihren benutzerdefinierten Prozess erstellen möchten.

Jeder Standardworkflow für jedes 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

Der Grundlegende Prozess, Problem-WIT wird beispielsweise durch die drei Staaten – To Do, Tun und Fertig – gekennzeichnet und übergänge in der folgenden Abbildung dargestellt.

Basic Process, Issue work item type, workflow state model


Zustandstypen

Unterstützte Anpassungen


Inherited icon Geerbte Zustände

Benutzerdefinierte Zustände


Workflowzustände müssen den folgenden Regeln entsprechen

  • Sie müssen mindestens einen Zustand für die Kategorien "Vorschlag " oder " Statusstatus " definieren.

    Hinweis

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

  • Sie müssen mindestens zwei Workflowzustände definieren
  • Sie können maximal 32 Workflowzustände pro Arbeitselementtyp 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 "Abgeschlossener Zustand" haben. Wenn Sie dem 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, stattdessen werden Standardgründe definiert, z. B. "Verschoben nach Status Triaged", "Verschoben" aus dem Zustand "Triaged"
  • Sie können den Speicherort der Felder "Status" und "Grund" im Formular nicht ändern.
  • 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 "Abgeschlossener Zustand" haben. Das System ermöglicht 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 Sequenz basierend auf ihrer Statuskategorie innerhalb der Dropdownliste eines Arbeitselementformulars aufgeführt.
  • Sie können keinen Grund für einen Zustand angeben, stattdessen werden Standardgründe definiert, z. B. "Verschoben nach Status Triaged", "Verschoben" aus dem Zustand "Triaged"
  • Sie können den Speicherort der Felder "Status" und "Grund" im Formular nicht ändern.
  • Sie können keine Übergänge einschränken, alle Übergänge werden von einem Zustand zu einem anderen Zustand definiert.

Backlog- und Boardanpassungen

Backlogs und Boards sind wichtige agile Tools zum Erstellen und Verwalten von Arbeiten für ein Team. Die Standard-Backlogs – Produkt, Iteration und Portfolio – geerbt aus dem Systemprozess sind vollständig anpassbar. Darüber hinaus können Sie benutzerdefinierte Portfolio-Backlogs für insgesamt fünf Portfolio-Backlogs 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 jedoch die Portfolioebene umbenennen und einen geerbten Arbeitselementtyp deaktivieren)
  • Sie können keine Backlogebene in den vorhandenen Satz definierter Backlogs einfügen.
  • Sie können die Backlogebenen nicht neu anordnen.
  • Sie können keinen Arbeitselementtyp zu zwei verschiedenen Backlogebenen hinzufügen.
  • Sie können keine benutzerdefinierte Vorgangs backlog-Ebene erstellen, obwohl Sie dem Iterationsbacklog benutzerdefinierte WITs hinzufügen können.
  • Sie können den Fehler-WIT nicht zu einer Backlogebene hinzufügen. Stattdessen ermöglicht das System jedem Team, zu entscheiden, wie fehler verwaltet werden sollen. Weitere Informationen finden Sie unter "Anzeigen von Fehlern bei Backlogs und Boards".
  • Sie können kein geerbtes WIT zu oder aus einem Backlog hinzufügen oder entfernen, z. B. können Sie das Problem WIT nicht zum Produktrücklog hinzufügen oder entfernen.
  • Sie können keine geerbte Portfolioebene aus dem Produkt entfernen (sie können jedoch die Portfolioebene umbenennen und einen geerbten Arbeitselementtyp deaktivieren)
  • Sie können keine Backlogebene in den vorhandenen Satz definierter Backlogs einfügen.
  • Sie können die Backlogebenen nicht neu anordnen.
  • Sie können keinen Arbeitselementtyp 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 Fehler-WIT nicht zu einer Backlogebene hinzufügen. Stattdessen ermöglicht das System jedem Team, zu entscheiden, wie fehler verwaltet werden sollen. Weitere Informationen finden Sie unter "Anzeigen von Fehlern bei Backlogs und Boards".

Hinweis

Bestimmte Features erfordern die Installation von Azure DevOps Server 2020.1-Update. Weitere Informationen finden Sie unter Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards.

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

Product backlog, Quick Add Panel, Displays Default WIT for a backlog level

Objektgrenzwerte

Eine Liste der Grenzwerte, die auf die Anzahl der Felder, WITs, Backlogebenen und andere Objekte gesetzt werden, die Sie anpassen können, finden Sie unter Grenzwerte für Arbeitsverfolgungsobjekt.