Freigeben über

Prozessanpassung und Vererbung

Azure DevOps Services

Um das Azure DevOps-System für die Arbeitsnachverfolgung auf die Anforderungen Ihrer Organisation anzupassen, können Sie einen geerbten Prozess über Organisationseinstellungen anpassen. Alle Projekte in einer Organisation, die den geerbten Prozess verwenden, erhalten die Anpassungen, die Sie an diesem Prozess vornehmen. Anschließend können Sie Projekt-Backlogs, Sprints und Boards für jedes Projektteam konfigurieren.

Wichtig

Dieser Artikel gilt nur für das Vererbungsprozessmodell in Azure DevOps Services. Informationen zum Anpassen lokaler Projekte oder Aktualisieren von XML-Definitionsdateien finden Sie unter Gehostetes XML-Prozessmodell und Anpassen eines gehosteten XML-Prozesses.

Sie können mehrere Anpassungen an geerbten Prozessen vornehmen. Die wichtigsten sind das Erstellen benutzerdefinierter Arbeitsaufgabentypen (WITs) oder das Ändern vorhandener WITs zum Hinzufügen von benutzerdefinierten Feldern, Ändern von Layouts oder Ändern von Workflows. Einige Optionen von geerbten Elementen sind gesperrt und können nicht angepasst werden.

Dieser Artikel enthält eine Übersicht über Möglichkeiten zum Anpassen geerbter Prozesse. Informationen zu Grenzwerten für die Anzahl von Feldern, WITs, Backlog-Ebenen und anderen Objekten, die Sie anpassen können, finden Sie unter Arbeitsverfolgung, Prozess- und Projektgrenzwerte.

Hinweis

Sie können Änderungen, die an einem geerbten Prozess vorgenommenen wurden, mithilfe des Auditprotokolls und der Auditfunktionen überprüfen. Weitere Informationen finden Sie unter Access, Export und Filtern von Überwachungsprotokollen.

System- und geerbte Prozesse

Das SystemprozesseAgile, Basic, Scrum und Capability Maturity Model Integration (CMMI) sind gesperrt und Benutzer können sie nicht ändern. Microsoft besitzt diese Systemprozesse und aktualisiert sie regelmäßig.

Geerbte Prozesse werden von Systemprozessen angepasst und erben Definitionen vom Systemprozess, auf dem sie basieren. Alle Updates, die Microsoft an Systemprozessen vornimmt, werden automatisch in geerbten Prozessen und deren untergeordneten geerbten Prozessen vorgenommen.

Alle Projekte in einer Organisation können alle prozesse teilen. Sie passen den Prozess an, anstatt die einzelnen Projekte anzupassen.

Nachdem Sie einen geerbten Prozess erstellt haben, können Sie ihn anpassen, kopieren, projekte basierend darauf erstellen und vorhandene Projekte so ändern, dass er verwendet wird. Änderungen, die Sie am geerbten Prozess vornehmen, aktualisieren automatisch alle Projekte in der Organisation, die diesen Prozess verwenden.

Das folgende Beispiel zeigt eine Liste der Projekte in der Fabrikamprime-Organisation und den Prozess, den jedes Projekt verwendet. Um Anpassungen für das Fabrikam Fiber-Projekt zu ändern, ändern Sie den My Agile-Prozess , der vom Agile-Systemprozess erbt. Änderungen, die Sie am My Agile-Prozess vornehmen, aktualisieren auch das Agile by Design-Projekt , das diesen Prozess verwendet. Um die anderen Projekte anzupassen, müssen Sie sie ändern, um geerbte Prozesse zu verwenden.

Screenshot von Projekten und den verwendeten Prozessen.

Ändern des Prozesses eines vorhandenen Projekts

Sie können den Prozess, den ein Projekt verwendet, von einem Prozess in einen anderen wechseln. Weitere Informationen und Anweisungen finden Sie in den folgenden Artikeln:

Indem Sie den allgemeinen Leitfaden in den aufgeführten Artikeln folgen, können Sie andere Änderungen vornehmen, z. B. von CMMI zu Agile oder Agile zu CMMI. Bevor Sie einen Projektprozess ändern, machen Sie sich mit dem Prozess vertraut, zu dem Sie wechseln. Weitere Informationen finden Sie unter Informationen zu Prozessen und Prozessvorlagen.

Wenn Sie ein Projekt in einen anderen Prozess übertragen, werden möglicherweise einige vorhandene Tools oder Arbeitsaufgaben ungültig. Beispielsweise können Arbeitsaufgaben, für die im neuen Prozess kein Feld erforderlich ist, Fehler anzeigen. Um mit Änderungen fortzufahren und die Arbeitsaufgaben zu speichern, müssen Sie diese Fehler beheben. Wenn die Prozessänderung die Workflowzustände für ein Arbeitsaufgabenelement (WIT), das auf einer Tafel erscheint, hinzufügt, entfernt oder ausblendet, müssen Sie die Spaltenkonfigurationen des Boards für alle im Projekt definierten Teams aktualisieren.

Ändern oder Umbenennen eines geerbten Prozesses

Das Ändern eines geerbten Prozesses ist einfach, aber es empfiehlt sich, die Änderungen zu testen, bevor sie auf ein aktives Projekt angewendet werden. Sie können einen Prozess kopieren und Ihre Änderungen zuerst am kopierten Prozess vornehmen, um zu vermeiden, dass vorhandene Projekte beeinträchtigt werden, und um mögliche negative Auswirkungen der Prozessänderungen zu erkennen.

Sie können einen geerbten Prozess in den Organisationseinstellungen umbenennen, indem Sie das Symbol "Weitere Aktionen " neben dem Prozessnamen auswählen und "Bearbeiten" auswählen.

Prozessnamen

Prozessnamen haben die folgenden Anforderungen:

  • Muss in der Organisation eindeutig sein
  • Darf maximal 128 Unicode-Zeichen enthalten
  • Darf keines der folgenden Zeichen enthalten: .,;':~\/*|?"&%$!+=()[]{}<>

Geerbte und benutzerdefinierte Objekte

Jeder geerbte Prozess erbt die WITs, die im zugrunde liegenden Basic-, Agile-, Scrum- oder CMMI-Systemprozess definiert sind. Prozesse, die von Agile erben, stellen z. B. Bug, Task, User Story, Feature, Epic, Issue und testbezogene WITs bereit.

Sie können Felder hinzufügen und das Workflow- und Arbeitsaufgabenformular für alle WITs ändern, die auf der Seite " Arbeitsaufgabentypen " eines geerbten Prozesses angezeigt werden. Sie können auch benutzerdefinierte WITs hinzufügen.

Wenn Sie nicht möchten, dass Benutzer neue Arbeitsaufgaben basierend auf einem geerbten Prozess WIT erstellen, können Sie sie deaktivieren, indem Sie das Symbol "Weitere Aktionen " neben dem WIT-Namen in den Organisationseinstellungen auswählen und im Kontextmenü die Option "Deaktivieren" auswählen.

Arbeitsaufgabenfelder

In diesem Abschnitt werden Arbeitsaufgabenfelder beschrieben.

Felder und Feldverweise

Sie verwenden Arbeitsaufgaben , um Ihr Projekt zu planen und nachzuverfolgen. Jeder Arbeitsaufgabentyp ist 31 Systemfeldern und mehreren weiteren typspezifischen Feldern zugeordnet, die Nachverfolgungsinformationen zu den Arbeitsaufgaben bereitstellen. Werte, die Sie einem Feld zuweisen, werden im Datenspeicher für die Arbeitsnachverfolgung gespeichert, den Sie abfragen können, um Status und Trends zu ermitteln.

Beschreibungen und Verwendung der einzelnen Felder, die für die Kernsystemprozesse Scrum, Agile und Capability Maturity Model Integration (CMMI) definiert sind, finden Sie unter Arbeitselementfeldindex.

Feldnamen

Ein Feldname für eine Arbeitsaufgabe legt jedes Arbeitsaufgabenfeld eindeutig fest. Stellen Sie sicher, dass ihre Feldnamen die folgenden Anforderungen erfüllen:

  • Muss innerhalb der Organisation oder Projektsammlung eindeutig sein
  • Muss 128 oder weniger Unicode-Zeichen sein
  • Muss mindestens ein alphabetisches Zeichen enthalten
  • Keine führenden oder nachgestellten Leerzeichen oder zwei oder mehr aufeinanderfolgende Leerzeichen enthalten
  • Darf keines der folgenden Zeichen enthalten: .,;':~\/*|?"&%$!+=()[]{}<>

Feldnamen und Definitionen gelten für die gesamte Organisation. Sie können kein Feld mit einem Feldnamen hinzufügen, der bereits in der Organisation vorhanden ist oder dass ein anderer geerbter Prozess zu einem WIT hinzugefügt wurde.

Anpassung von Feldern

Felder werden für alle Projekte und Prozesse in einer Organisation definiert. Geerbte Prozesse erben die in Systemprozessen definierten Felder, und Sie können eingeschränkte Änderungen daran vornehmen. Sie können benutzerdefinierte Felder in geerbten Prozessen erstellen und ändern.

Sie können jedes benutzerdefinierte Feld hinzufügen, das Sie für ein WIT in einem Prozess definieren, zu einem beliebigen WIT, das für einen anderen Prozess definiert ist. Sie können auch ein vorhandenes Feld zu einem anderen WIT innerhalb desselben Prozesses hinzufügen. Sie können z. B. Fälligkeitsdatum zur Benutzergeschichte oder Bug WITs hinzufügen.

Anpassen von Feldern und Steuerelementen

In den folgenden Ressourcen wird beschrieben, wie verschiedene Anpassungen für geerbte Felder, benutzerdefinierte Felder oder benutzerdefinierte Steuerelemente implementiert werden.

Geerbte Felder

Benutzerdefinierte Felder

Benutzerdefiniertes Steuerelement

Löschen oder Wiederherstellen gelöschter Felder

Sie können ein Feld löschen und es 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, können Sie das Feld aus einem Arbeitselementformular ausblenden oder entfernen. Weitere Informationen finden Sie unter Anzeigen, Ausblenden oder Entfernen eines Felds.

Einschränkungen

  • Sie können einen Feldnamen oder Datentyp nicht mehr ändern, nachdem Sie ihn definiert haben. Sie können jedoch die Beschriftung ändern, die für ein Feld im Arbeitsaufgabenformular auf der Registerkarte "Layout " angezeigt wird. Wenn Sie das Feld in einer Abfrage auswählen, müssen Sie den Feldnamen und nicht die Feldbezeichnung verwenden.
  • Sie können den grauen Bereich des Formulars, der die Felder Status, Grund, Bereichspfad und Iterationspfad enthält, nicht ändern.
  • Die Bereichspfade und Iterationspfade sind für jedes Projekt konfiguriert und können nicht durch einen geerbten Prozess angepasst werden.
  • Auswahllisten, die den Benutzeridentitätsfeldern zugeordnet sind, z. B. "Zugewiesen an" und "Geändert von", werden mit den Benutzern gefüllt, die dem Projekt oder Team hinzugefügt wurden.
  • Maximal 64 Felder können für jedes WIT definiert werden, und pro Prozess können maximal 512 Felder definiert werden.
  • Sie können eine globale Liste nicht importieren oder definieren, wie sie von den gehosteten XML- und lokalen XML-Prozessmodellen unterstützt wird.

Benutzerdefinierte Regeln und Systemregeln

Jedes WIT verfügt über mehrere Systemregeln, wie das Erfordernis des Felds "Titel" oder das Festlegen eines Standardwerts für das Feld "Wertbereich". Systemregeln definieren auch Aktionen, die ausgeführt werden sollen, wenn sich ein Workflowstatus ändert.

Beispielsweise kopieren mehrere Regeln die aktuelle Benutzeridentität in das Feld "Geändert von" , wenn eine Arbeitsaufgabe geändert wird, oder in das Feld "Geschlossen nach ", wenn sich der Workflowstatus in "Geschlossen" oder " Fertig" ändert. Vordefinierte Systemregeln haben Vorrang vor allen benutzerdefinierten Regeln, die sie überschreiben würden.

Benutzerdefinierte Regeln bieten Unterstützung für mehrere Geschäftsanwendungsfälle, sodass Sie über das Festlegen eines Standardwerts für ein Feld hinaus gehen oder es erforderlich machen können. Mit benutzerdefinierten Regeln können Sie den Wert eines Felds löschen, einen Wert in ein Feld kopieren oder Werte basierend auf Abhängigkeiten zwischen verschiedenen Feldwerten anwenden.

Mit benutzerdefinierten Regeln können Sie verschiedene Aktionen basierend auf bestimmten Bedingungen definieren. Sie können z. B. Regeln anwenden, um die folgenden Szenarien zu unterstützen:

  • Wenn ein Wert für Priorität definiert ist, muss Risiko als Pflichtfeld festgelegt werden.
  • Wenn eine Änderung am Wert von Release vorgenommen wird, löschen Sie den Wert von Milestone.
  • Wenn eine Änderung am Wert " Verbleibende Arbeit" vorgenommen wird, müssen Sie "Abgeschlossene Arbeit " als Pflichtfeld festlegen.
  • Wenn der Wert von GenehmigtTrue ist, muss Genehmigt von ein Pflichtfeld sein.
  • Wenn eine User Story erstellt wird, machen Sie die Felder Priorität, Risiko und Aufwand erforderlich.

Weitere Informationen zum Definieren benutzerdefinierter Regeln finden Sie in Hinzufügen von Regeln zu einem Arbeitsaufgabentyp (Vererbungsprozess).

Tipp

Sie können eine Formel nicht mithilfe einer Regel definieren. Möglicherweise finden Sie jedoch eine Lösung, die Ihren Anforderungen mit Power Automate entspricht. Weitere Informationen finden Sie unter Rollup von Arbeit und anderen Feldern.

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

Mithilfe der Bedingungen current user is a member of a group... oder current user is not a member of a group..., können Sie ausgewählte Felder für Benutzer erfordern oder konfigurieren, die Mitglieder oder Nichtmitglieder einer Gruppe oder Sicherheitsgruppe sind. Sie können z. B. das Feld "Titel" oder das Feld "Status" für ausgewählte Benutzer oder Gruppen schreibgeschützt festlegen.

Einschränken der Änderung von Arbeitsaufgaben auf Grundlage des Bereichspfads

Erwägen Sie, den Besitz einzelner Arbeitsaufgaben nach Teambereichspfad zu verwalten oder Spalten mit benutzerdefinierten Zuständen zu formalisieren, die für alle Teams freigegeben sind.

Sie können benutzern das Ändern ausgewählter Arbeitsaufgaben verbieten, indem Sie Berechtigungen für einen Bereichspfad festlegen. Diese Einstellung ist keine Regel, sondern eine Berechtigungseinstellung. Weitere Informationen finden Sie unter Erstellen untergeordneter Knoten, Ändern von Arbeitsaufgaben unter einem Bereich oder Iterationspfad.

Anpassungen des Arbeitselementtyps

Die folgenden Ressourcen beschreiben Anpassungsoptionen für geerbte und benutzerdefinierte WITs.

Geerbte Arbeitsaufgabentypen

Benutzerdefinierte Arbeitsaufgabentypen

Wenn Sie das Standard-WIT für einen Backlog ändern, wird das WIT standardmäßig im Schnell-Add-Bereich angezeigt. Beispielsweise wird "Benutzerdefinierte Story" standardmäßig im folgenden Schnellzugriffspanel für ein Produkt-Backlog angezeigt.

Screenshot des Bereichs

Einschränkungen

  • Sie können ein geerbtes WIT nicht zu einem Backlog hinzufügen oder aus einem Backlog 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 den Namen eines benutzerdefinierten WIT nicht mehr ändern, nachdem Sie ihn definiert haben.

Anpassungen des Arbeitselementformulars

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

Geerbte Gruppen

Benutzerdefinierte Gruppen

Geerbte Seiten

Benutzerdefinierte Seiten

Layout und Größenänderung

Das Webformularlayout für eine Arbeitsaufgabe ist in drei Spalten angeordnet, wie in der folgenden Abbildung dargestellt.

Abbildung des dreispaltigen Seitenlayouts für das Arbeitsaufgabenformular.

Wenn Sie nur Gruppen und Felder zu den ersten beiden Spalten hinzufügen, zeigt das Layout zwei Spalten an. Wenn Sie der ersten Spalte nur Gruppen und Felder hinzufügen, wird im Layout eine Spalte angezeigt.

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 nicht für alle Spalten geeignet ist, werden Spalten innerhalb der Spalte links gestapelt angezeigt.

Wenn die Anzeigebreite verringert wird, ändern sich die Spalten proportional wie folgt:

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

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 Systemprozess, der zum Erstellen des benutzerdefinierten Prozesses verwendet wird: Agile, Basic, Scrum oder Capability Maturity Model Integration (CMMI). Weitere Informationen finden Sie unter Workflowzustände, Übergänge und Gründe.

Der 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.

Geerbte und benutzerdefinierte Workflows müssen den folgenden Regeln entsprechen:

  • Definieren Sie mindestens zwei Workflowzustände.
  • Definieren Sie mindestens einen Status für die Kategorien "Vorgeschlagen" oder " In Bearbeitung" .
  • Definieren Sie maximal 32 Workflowzustände pro Arbeitsaufgabentyp.

Hinweis

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

Anpassungen für geerbte und benutzerdefinierte Workflowzustände finden Sie in den folgenden Ressourcen:

Geerbte Zustände

Benutzerdefinierte Zustände

Einschränkungen

  • Sie können den Namen, die Farbe oder die Kategorie der geerbten Zustände nicht ändern, aber Sie können sie ausblenden, wenn sie nicht sichtbar sein sollen.
  • Sie können die Namen benutzerdefinierter Zustände nicht ändern, sobald sie definiert wurden.
  • Sie können die Standardstatuskategorienamen nicht ändern oder anpassen.
  • Nur ein Status kann in der Kategorie "Abgeschlossener Zustand" vorhanden sein. Durch Hinzufügen eines benutzerdefinierten Zustands zu dieser Kategorie werden alle anderen Zustände in dieser Kategorie entfernt oder ausgeblendet.
  • Sie können keine benutzerdefinierten Gründe für Zustandsübergänge angeben. Verwenden Sie Standardgründe, z. B. in den Zustand "Triaged" verschoben und aus dem Zustand "Triaged" verschoben.
  • Sie können die Platzierung der Felder "Bundesland " und " Grund " im Arbeitsaufgabenformular nicht ändern.

Backlog- und Boardanpassungen

Backlogs und Boards sind wichtige Agile-Tools zum Erstellen und Verwalten von Arbeit für ein Team. Die von Systemprozessen geerbten Standardprodukt-, Iterations- und Portfolio-Backlogs können vollständig angepasst werden. Sie können auch benutzerdefinierte Portfolio-Backlogs bis zu insgesamt fünf Portfolio-Backlogs hinzufügen.

Weitere Informationen zum Anpassen geerbter und benutzerdefinierter Portfolio-Backlogs finden Sie in den folgenden Ressourcen:

Geerbte Backlogs

Benutzerdefinierte Portfolio-Backlogs

Einschränkungen

  • Sie können eine geerbte Portfolioebene nicht aus einem Produkt entfernen. Sie können die Ebene umbenennen oder WITs deaktivieren, um zu verhindern, dass Teams neue Arbeitsaufgaben dieser Typen erstellen.
  • Sie können keine neue benutzerdefinierte Backlog-Ebene innerhalb der vorhandenen Gruppe definierter Backlogs einfügen. Die vordefinierten Backlogebenen sind in der Regel festgelegt, z. B. Epics, Features, User Stories und Tasks.
  • Sie können die Backlog-Ebenen nicht neu anordnen. Sie folgen in der Regel einer vordefinierten Hierarchie, und das Ändern der Reihenfolge wird nicht unterstützt.
  • Man kann ein WIT nicht zu zwei verschiedenen Backlogebenen hinzufügen. Jeder WIT kann nur zu einer Backlog-Ebene gehören.
  • Sie können keine benutzerdefinierte task-spezifische Backlogebene erstellen, aber Sie können dem Backlog der Iteration weiterhin benutzerdefinierte WITs hinzufügen. Sie können z. B. ein benutzerdefiniertes WIT namens "Enhancement " oder "Maintenance " erstellen und dem Iterationsbacklog zuordnen.
  • Der Bug WIT gehört standardmäßig nicht zu einer bestimmten Backlog-Ebene. Jedes Team kann entscheiden, wie sie Fehler verwalten möchten. Sie können auswählen, dass Fehler auf Backlogs und Boards angezeigt oder separat behandelt werden. Weitere Informationen finden Sie unter Anzeigen von Fehlern in Backlogs.

Verwandte Inhalte

  • Last updated on