Informationen zur Prozessanpassung und geerbten Prozessen

  • Artikel

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

Um das Arbeitsnachverfolgungssystem anzupassen, passen Sie einen geerbten Prozess über die Administrative Benutzeroberfläche für die organization an. Alle Projekte, die einen geerbten Prozess verwenden, erhalten die anpassungen an diesen Prozess. Andererseits konfigurieren Sie Ihre Agile-Tools – Backlogs, Sprints, Kanban-Boards und Taskboard – für jedes Team.

Wichtig

Informationen zum Anpassen eines lokalen Projekts oder zum 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 primären sind das Hinzufügen benutzerdefinierter Arbeitselementtypen (WITs) oder das Ändern eines vorhandenen 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 Zugriff, Exportieren und Filtern von Überwachungsprotokollen.

Im Folgenden finden Sie einen Index für die Aufgaben, die Sie ausführen können, um einen geerbten Prozess anzupassen. Einige Optionen geerbter Elemente 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 geändert werden können.
  • Geerbtes Symbol Geerbte Prozesse, die Sie anpassen können und die Definitionen von dem Systemprozess erben, aus dem sie erstellt wurden. Systemprozesse werden von Microsoft in regelmäßigen Abständen aktualisiert. Alle An einem Systemprozess vorgenommenen Updates führen automatisch zu einer Aktualisierung Ihrer geerbten Prozesse und ihrer untergeordneten geerbten Prozesse. Updates zu Prozessen sind 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. Änderungen am Prozess werden automatisch alle Projekte aktualisiert, 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 so ändern, dass er verwendet wird.

Wie in der folgenden Abbildung gezeigt, sehen Sie beispielsweise eine Liste der Projekte, die für die fabrikam-organization definiert sind. Die zweite Spalte zeigt den Prozess, der von den einzelnen Projekten verwendet wird. Um die Anpassungen des Fabrikam Fiber-Projekts zu ändern, müssen Sie den MyScrum-Prozess (der vom Scrum-Systemprozess erbt) ändern. Alle Änderungen, die Sie am MyScrum-Prozess vornehmen, aktualisieren auch andere Projekte, die diesen Prozess verwenden. Sie können das Abfragetestprojekt dagegen erst anpassen, wenn Sie es in einen Prozess ändern, der von Agile erbt.

Screenshot: Admin Kontext, Organisationseinstellungen, Projektliste und den verwendeten Prozess.

Einschränkungen für Prozessnamen

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

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

Ändern des Verweisprozesses 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. Beispielsweise werden Anweisungen zur Unterstützung der folgenden Änderungen bereitgestellt:

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

Bevor Sie diese Änderung vornehmen, empfehlen wir Ihnen, sich mit dem Prozess vertraut zu machen, zu dem Sie wechseln. Die Systemprozesse sind unter Informationen zu Prozessen und Prozessvorlagen zusammengefasst.

Bewährte Methoden beim Vornehmen von Änderungen

Änderungen an einem geerbten Prozess sind einfach und sicher. Es empfiehlt sich jedoch immer, diese Änderungen zu testen, bevor Sie sie auf ein aktives Projekt anwenden. Wenn Sie diese Schritte ausführen , können Sie alle negativen Auswirkungen ihrer Prozessänderungen ermitteln.

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 bietet beispielsweise Fehler, Aufgabe, User Story, Feature, Epic, Issue und Test-bezogene WITs.

Konzeptionelles Bild der Arbeitselementhierarchie des agilen Prozesses.

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

Anpassung von Feldern

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

Felder werden für alle Projekte und Prozesse im organization definiert. Das bedeutet, dass jedes benutzerdefinierte Feld, das Sie für einen 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 ein vorhandenes Feld zu einem anderen WIT innerhalb des Prozesses hinzufügen. Sie können z. B. Fälligkeitsdatum der Benutzerstory- oder Fehler-WITs hinzufügen.

Was Sie nicht anpassen können

  • Sie können den Feldnamen oder Datentyp nicht mehr ändern, nachdem Sie ihn definiert haben.
  • Sie können den Graubereich auf dem Formular nicht ändern, in dem sich die Felder Zustand, Grund, Bereichspfad und Iterationspfad befinden.
  • Sie können keine globale Liste 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 mehr ändern, nachdem Sie ihn definiert haben.
  • Sie können den Graubereich auf dem Formular nicht ändern, in dem sich die Felder Zustand, Grund, Bereichspfad und Iterationspfad befinden.
  • In Bezug auf Auswahllisten können Sie derzeit die folgenden Vorgänge nicht ausführen:
    • Ändern der Auswahlliste eines geerbten Felds, z. B. des Felds Aktivität oder Disziplin
    • Ändern der Reihenfolge der Auswahlliste, Anzeige der Auswahllisten in alphabetischer Reihenfolge
  • Sie können den Beschreibungshilfetext 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 wie Aktivität, Automatisierungsstatus, Disziplin, Priorität und andere nicht ändern.

Konfigurierbare Auswahllisten

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

Auswahllisten, die Den Feldern "Personenname" 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 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 später wiederherstellen. Durch das Löschen eines Felds werden alle diesem Feld zugeordneten Daten gelöscht, einschließlich verlaufsbezogener Werte. Nach dem Löschen können Sie das Feld nur wiederherstellen und die Daten mithilfe der REST-API Felder – Update wiederherstellen.

Anstatt ein Feld zu löschen, können Sie das Feld stattdessen ausblenden oder aus einem Arbeitselementformular entfernen. Weitere Informationen finden Sie unter Hinzufügen und Verwalten von Feldern, Anzeigen, 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 Verwendungen der einzelnen Felder, die für die Kernsystemprozesse definiert sind – 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 den folgenden Richtlinien entsprechen:

  • Feldnamen müssen innerhalb der organization- 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 organization definiert sind, können Sie kein benutzerdefiniertes Feld mit demselben Feldnamen hinzufügen, der bereits im organization vorhanden ist oder einem WIT in einem anderen geerbten Prozess hinzugefügt wurde.

Hinweis

Wenn Sie ein Projekt so ändern, dass es einen geerbten Prozess verwendet, werden möglicherweise mindestens ein Agile-Tools oder Arbeitselemente in einem ungültigen Zustand angezeigt. Zum Beispiel:

  • Wenn Sie ein Feld erforderlich machen, zeigen Arbeitselemente mit diesem Feld undefined eine Fehlermeldung an. 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 ausblenden, die auf dem Kanban-Board angezeigt wird, müssen Sie die Spaltenkonfigurationen des Kanban-Boards für alle im Projekt definierten Teams aktualisieren.

Benutzerdefinierte Regeln und Systemregeln

Für jeden WIT (Fehler, Aufgabe, Benutzergeschichte usw.) sind 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 gibt es mehrere Regeln zum Kopieren der aktuellen Benutzeridentität unter den folgenden Bedingungen:

  • 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 allen benutzerdefinierten Regeln, die Sie definieren, die sie überschreiben würden.

Benutzerdefinierte Regeln bieten Unterstützung für eine Reihe von Geschäftlichen Anwendungsfällen, sodass Sie über das Festlegen eines Standardwerts für ein Feld hinaus gehen oder ihn erforderlich machen können. Mit 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, machen Sie Risiko zu einem Pflichtfeld.
  • Wenn eine Änderung am Wert von Release vorgenommen wird, löschen Sie den Wert von "Meilenstein".
  • Wenn eine Änderung am Wert von Restarbeit vorgenommen wurde, müssen Sie abgeschlossene Arbeit als erforderliches Feld festlegen.
  • Wenn der Wert von Genehmigt auf True festgelegt ist, stellen Sie genehmigt von ein erforderliches Feld fest.
  • Wenn ein Benutzerabschnitt erstellt wird, müssen Die folgenden Felder erforderlich sein: Priorität, Risiko und Aufwand

Tipp

Sie können eine Formel nicht mithilfe einer Regel definieren. Möglicherweise finden Sie jedoch mit der Marketplace-Erweiterung Power Automate oder TFS Aggregator (Webdienst) eine Lösung, die Ihren Anforderungen entspricht. Siehe auch Rollup der Arbeit und anderer Felder.

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

Einschränken der Änderung ausgewählter Felder für ausgewählte Benutzergruppen

Mithilfe einer der folgenden beiden Bedingungen können Sie für einen Benutzer einer Sicherheitsgruppe oder für personen, die kein Mitglied einer Sicherheitsgruppe sind, ausgewählte Felder erforderlich machen.

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

Beispielsweise können Sie das Feld Titel oder Zustand für ausgewählte Benutzer oder Gruppen schreibgeschützt festlegen.

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

Sie können Benutzern das Ändern ausgewählter Arbeitselemente verweigern, 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 Arbeitselementen 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 einen geerbten WIT zu oder aus einem Backlog nicht 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 es an einer anderen 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 einem WIT-Formular vornehmen.

Gruppen- oder Seitentyp

Anpassungsunterstützung

Geerbte Gruppen

Benutzerdefinierte Gruppen

Geerbte Seiten

Benutzerdefinierte Seiten

Layout und Größenänderung

Das Webformularlayout ist wie in der folgenden Abbildung dargestellt in drei Spalten organisiert.

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

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

Die Größe des Webformulars wird abhängig von der verfügbaren Breite und der Anzahl der Spalten im Layout geändert. Bei maximaler Breite wird in den meisten Webbrowsern jede Spalte innerhalb einer Seite in einer eigenen Spalte angezeigt. Wenn die Anzeigebreite abnimmt, ä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 in der Spalte auf der linken Seite gestapelt angezeigt.

Anpassung von Workflows

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 je nach Systemprozess (Agile, Basic, Scrum oder CMMI), aus dem Sie ihren benutzerdefinierten Prozess erstellen möchten.

Jeder Standardworkflow für jedes WIT definiert zwischen zwei und vier Status und gibt die folgenden Workflowvorgänge an:

  • Vorwärts- und Rückwärtsübergänge zwischen den einzelnen Zuständen
  • Standardgründe für jeden Zustandsübergang

Der Grundlegende Prozess, Issue WIT zeichnet sich beispielsweise durch die drei Status "To Do", "Doing" und " Done" und die in der folgenden Abbildung dargestellten Übergänge aus.

Standardprozess, Problemarbeitselementtyp, Workflowstatusmodell

Zustandstypen

Unterstützte Anpassungen

Geerbtes Symbol Geerbte Zustände

Benutzerdefinierte Zustände

Workflowzustände müssen den folgenden Regeln entsprechen

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

    Hinweis

    Lesen Sie vor dem Hinzufügen eines Workflowzustands Workflowstatus und Zustandskategorien , 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 Arbeitselementtyp definieren.

Nicht unterstützte Workflowanpassungen

  • Sie können einen geerbten Zustand nicht ändern (Name, Farbe oder Kategorie können nicht geändert werden), 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. Stattdessen werden Standardgründe definiert, z. B . Verschoben in Zustand selektieren, Aus dem Zustand entfernt Selektierend
  • Sie können den Speicherort der Felder State und Reason im Formular nicht ändern.
  • Sie können Die Namen der Statuskategorie nicht anpassen.
  • Sie können einen geerbten Zustand nicht ändern (Name, Farbe oder Kategorie können nicht geändert werden), aber Sie können ihn ausblenden.
  • Sie können nur einen Status in der Kategorie Abgeschlossen haben. Das System lässt das Hinzufügen eines benutzerdefinierten Zustands zu dieser Kategorie nicht zu.
  • 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 in der Dropdownliste eines Arbeitselementformulars aufgelistet.
  • Sie können keinen Grund für einen Zustand angeben. Stattdessen werden Standardgründe definiert, z. B . Verschoben in Zustand selektieren, Aus dem Zustand entfernt Selektierend
  • Sie können den Speicherort der Felder State und Reason im Formular nicht ändern.
  • Sie können keine Übergänge einschränken, da alle Übergänge von einem beliebigen Zustand in einen anderen Zustand definiert sind.

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.

Backlogtypen

Anpassungsunterstützung

Geerbte Backlogs

Benutzerdefinierte Portfoliobacklogs

Was Sie nicht anpassen können

  • Sie können eine geerbte Portfolioebene nicht 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 von definierten Backlogs einfügen.
  • Sie können die Backlogebenen nicht neu anordnen.
  • Sie können zwei verschiedenen Backlogebenen keinen Arbeitselementtyp hinzufügen.
  • Sie können keine benutzerdefinierte Aufgabenbacklogebene erstellen, obwohl Sie dem Iterationsbacklog benutzerdefinierte WITs hinzufügen können.
  • Sie können die Fehler-WIT keiner 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 in Backlogs und Boards.
  • Sie können einen geerbten WIT nicht zu oder aus einem Backlog hinzufügen, z. B. können Sie die Issue WIT nicht zum Produktbacklog hinzufügen.
  • Sie können eine geerbte Portfolioebene nicht 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 von definierten Backlogs einfügen.
  • Sie können die Backlogebenen nicht neu anordnen.
  • Sie können zwei verschiedenen Backlogebenen keinen Arbeitselementtyp hinzufügen.
  • Sie können keine benutzerdefinierte Aufgabenebene erstellen, obwohl Sie dem Iterationsbacklog benutzerdefinierte Arbeitselementtypen hinzufügen können.
  • Sie können die Fehler-WIT keiner 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 in Backlogs und Boards.

Hinweis

Für bestimmte Features ist die Installation von Azure DevOps Server Update 2020.1 erforderlich. Weitere Informationen finden Sie unter versionshinweise zu Azure DevOps Server 2020 Update 1 RC1, Boards.

Wenn Sie die Standard-WIT für eine Backlogebene ändern, wird dieser WIT standardmäßig im Bereich schnell hinzufügen angezeigt. Kundenticket wird beispielsweise standardmäßig im folgenden Bereich für schnelles Hinzufügen für das Produktbacklog angezeigt.

Screenshot des Produktbacklogs, Bereich

Objektgrenzwerte

Eine Liste der Grenzwerte für die Anzahl von Feldern, WITs, Backlogebenen und anderen Objekten, die Sie anpassen können, finden Sie unter Grenzwerte von Arbeitsverfolgungsobjekten.