Udostępnij za pośrednictwem

Informacje o dostosowywaniu procesów i procesach dziedziczonych

  • Artykuł

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

Aby dostosować system śledzenia pracy, należy dostosować dziedziczony proces za pomocą interfejsu użytkownika administracyjnego dla organizacji. Wszystkie projekty korzystające z dziedziczonego procesu uzyskują dostosowania wprowadzone w tym procesie. Z drugiej strony skonfigurujesz narzędzia Agile — listy prac, przebiegi, tablice i tablice zadań — dla każdego zespołu.

Ważne

Aby dostosować lokalny projekt lub zaktualizować pliki definicji XML w celu obsługi dostosowywania, zobacz Lokalny model procesu XML. Ten artykuł dotyczy tylko usług Azure DevOps Services i Azure DevOps Server 2019.

Istnieje wiele dostosowań, które można wprowadzić. Podstawowe są dodawanie niestandardowych typów elementów roboczych (WIT) lub modyfikowanie istniejącego elementu WIT w celu dodawania pól niestandardowych, modyfikowania układu lub zmiany przepływu pracy.

Uwaga

Przejrzyj zmiany wprowadzone do dziedziczonego procesu za pośrednictwem dziennika inspekcji. Aby uzyskać więcej informacji, zobacz Access, export, and filter audit logs (Uzyskiwanie dostępu, eksportowanie i filtrowanie dzienników inspekcji).

Poniżej znajdziesz indeks do tych zadań, które można wykonać w celu dostosowania dziedziczonego procesu. Niektóre opcje dziedziczonych elementów są zablokowane i nie można ich dostosować.

Procesy systemowe a dziedziczone

Zobaczysz dwa typy procesów:

  • zablokowana ikona Procesy systemowe — Agile, Basic, Scrum i CMMI — które są zablokowane przed zmianą.
  • ikona dziedziczona Dziedziczone procesy, które można dostosować i dziedziczą definicje z procesu systemowego, z którego zostały utworzone. Procesy systemowe są okresowo własnością i aktualizowane przez firmę Microsoft. Wszystkie aktualizacje wprowadzone w procesie systemowym automatycznie powodują aktualizację odziedziczonych procesów i ich podrzędnych procesów dziedziczynych. Aktualizacje procesów są udokumentowane w informacjach o wersji dla usługi Azure DevOps Server.

Uwaga

Proces podstawowy jest dostępny w usłudze Azure DevOps Server 2019 Update 1 i nowszych wersjach.

Ponadto wszystkie procesy są współużytkowane. Oznacza to, że co najmniej jeden projekt może używać jednego procesu. Zamiast dostosowywać pojedynczy projekt, można dostosować proces. Zmiany wprowadzone w procesie automatycznie aktualizują wszystkie projekty, które używają tego procesu. Po utworzeniu dziedziczonego procesu możesz go dostosować, utworzyć na podstawie niego projekty, utworzyć kopię i zmienić istniejące projekty, aby go używać.

Na przykład, jak pokazano na poniższej ilustracji, zostanie wyświetlona lista projektów zdefiniowanych dla organizacji fabrikam . Druga kolumna przedstawia proces używany przez każdy projekt. Aby zmienić dostosowania projektu Fabrikam Fiber , należy zmodyfikować proces MyScrum (który dziedziczy z procesu systemu Scrum ). Wszelkie zmiany wprowadzone w procesie MyScrum aktualizują również inne projekty, które używają tego procesu. Z drugiej strony nie można dostosować projektu testu zapytania, dopóki nie zmienisz go na proces dziedziczony z metody Agile.

Zrzut ekranu przedstawiający kontekst administratora, ustawienia organizacji, listę projektu i używany proces.

Ograniczenia nazw procesów

Nazwy procesów muszą być unikatowe i mieć co najmniej 128 znaków Unicode. Ponadto nazwy nie mogą zawierać następujących znaków: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Aby zmienić nazwę procesu, otwórz plik ... menu kontekstowe dla procesu i wybierz pozycję Edytuj.

Zmienianie procesu referencyjnego projektu

Jeśli chcesz przełączyć proces używany przez projekt z jednego procesu systemowego na inny, możesz to zrobić. Aby wprowadzić te zmiany, należy utworzyć dziedziczony proces na podstawie procesu, do którego chcesz przełączyć się. Instrukcje są na przykład udostępniane w celu obsługi następujących zmian:

Postępując zgodnie ze wskazówkami podanymi w powyższych artykułach, możesz również wprowadzić dodatkowe zmiany, na przykład z cmMI na Agile lub Agile do CMMI.

Przed wprowadzeniem tej zmiany zalecamy zapoznanie się z procesem, do którego się zmieniasz. Procesy systemowe są podsumowane w temacie Informacje o procesach i szablonach procesów.

Najlepsze rozwiązania dotyczące wprowadzania zmian

Wprowadzanie zmian w odziedziczonym procesie jest proste i bezpieczne. Jednak zawsze najlepszym rozwiązaniem jest przetestowanie tych zmian przed zastosowaniem ich do aktywnego projektu. Wykonanie tych kroków pomoże Ci przedstawić wszelkie negatywne wpływy na zmiany procesu.

Obiekty dziedziczone a obiekty niestandardowe

Każdy proces dziedziczony dziedziczy elementy WITs zdefiniowane w procesie systemowym — Podstawowa, Agile, Scrum lub CMMI. Na przykład proces Agile zapewnia usterkę, zadanie, historię użytkownika, funkcję, epik, problem i powiązane z testami sieci WITs.

Obraz koncepcyjny hierarchii elementów roboczych procesu Agile.

Pola można dodawać i modyfikować przepływ pracy oraz formularz elementu roboczego dla wszystkich dziedziczych sieci WIT wyświetlanych na stronie Typy elementów roboczych . Jeśli nie chcesz, aby użytkownicy utworzyli funkcję WIT, możesz ją wyłączyć. Ponadto można dodawać niestandardowe sieci WITs.

Dostosowania pól

Pola zdefiniowane w procesie systemowym są wyświetlane z dziedziczą ikoną wskazującą, że w procesie odziedziczonym można wprowadzać ograniczone modyfikacje.

Pola są definiowane dla wszystkich projektów i procesów w organizacji. Oznacza to, że dowolne pole niestandardowe zdefiniowane dla elementu WIT w jednym procesie można dodać do dowolnego innego elementu WIT zdefiniowanego dla innego procesu.

Typ pola

Obsługa dostosowywania

Pola dziedziczone

Pola niestandardowe

Kontrolka niestandardowa

Podczas dodawania pól niestandardowych zwróć uwagę na następujące limity:

  • Dla każdego elementu WIT można zdefiniować maksymalnie 64 pola
  • Maksymalnie 512 pól można zdefiniować na proces

Ponadto możesz dodać istniejące pole do innego elementu WIT w ramach tego procesu. Możesz na przykład dodać termin ukończenia do historii użytkownika lub błędu sieci WITs.

Czego nie można dostosować

  • Nie można zmienić nazwy pola ani typu danych po jego zdefiniowaniu
  • Nie można zmodyfikować szarego obszaru w formularzu, w którym znajdują się pola Stan, Przyczyna, Ścieżka obszaru i ścieżka iteracji
  • Nie można zaimportować ani zdefiniować listy globalnej, która jest obsługiwana przez modele procesów Hosted XML i On-premises XML. Aby dowiedzieć się więcej, zobacz Definiowanie list globalnych.
  • Nie można zmienić nazwy pola ani typu danych po jego zdefiniowaniu
  • Nie można zmodyfikować szarego obszaru w formularzu, w którym znajdują się pola Stan, Przyczyna, Ścieżka obszaru i ścieżka iteracji
  • Jeśli chodzi o listy wyboru, obecnie nie można wykonać tych operacji:
    • Zmienianie listy wyboru dziedziczonego pola, takiego jak pole Działanie lub Dyscyplina
    • Zmień kolejność listy wyboru, listy wyboru wyświetlane w kolejności alfabetycznej
  • Nie można zmodyfikować tekstu pomocy opisowej dziedziczonego pola
  • Zaimportuj lub zdefiniuj listę globalną obsługiwaną przez hostowane modele procesów XML i lokalnego kodu XML. Aby dowiedzieć się więcej, zobacz Definiowanie list globalnych.

Uwaga

W przypadku dziedziczonego procesu nie można modyfikować list wyboru wstępnie zdefiniowanych pól, takich jak Działanie, Stan automatyzacji, Dyscyplina, Priorytet i inne.

Konfigurowalne listy wyboru

Poniższe listy wyboru są konfigurowane dla każdego projektu i nie można ich dostosowywać za pomocą dziedziczonego procesu.

Listy wyboru skojarzone z polami osób, takie jak Przypisane do i Zmienione według, są zarządzane na podstawie użytkowników dodanych do projektu lub zespołu.

Czy mogę zmienić nazwę pola lub zmienić jego typ danych?

Zmiana nazwy pola lub zmiana typu danych nie jest obsługiwana. Można jednak zmienić etykietę wyświetlaną dla pola w formularzu elementu roboczego z karty Układ. Podczas wybierania pola w zapytaniu należy wybrać nazwę pola, a nie etykietę pola.

Czy mogę usunąć lub przywrócić usunięte pole?

Możesz usunąć pole, a później je przywrócić. Usunięcie pola powoduje usunięcie wszystkich danych skojarzonych z tym polem, w tym wartości historycznych. Po usunięciu można przywrócić pole i odzyskać dane tylko przy użyciu interfejsu API REST Pola — aktualizowanie.

Zamiast usuwać pole, możesz zamiast tego ukryć lub usunąć pole z formularza elementu roboczego. Aby uzyskać szczegółowe informacje, zobacz Dodawanie pól i zarządzanie nimi, Pokazywanie, ukrywanie lub usuwanie pola.

Co to jest pole? Jak są używane nazwy pól?

Każdy typ elementu roboczego jest skojarzony z 31 polami systemowymi i kilkoma polami specyficznymi dla typu. Elementy robocze służą do planowania i śledzenia projektu.

Każde pole obsługuje śledzenie fragmentu informacji o pracy do wykonania. Wartości przypisywane do pola są przechowywane w magazynie danych śledzenia pracy, które można tworzyć zapytania w celu określenia stanu i trendów.

Opisy i użycie każdego pola zdefiniowanego dla podstawowych procesów systemowych — procesów systemu Scrum, Agile i CMMI — zobacz Indeks pola elementu roboczego.

Nazwy pól

Nazwa pola elementu roboczego jednoznacznie identyfikuje każde pole elementu roboczego. Upewnij się, że nazwy pól należą do następujących wytycznych:

  • Nazwy pól muszą być unikatowe w organizacji lub kolekcji projektów
  • Nazwy pól muszą mieć co najmniej 128 znaków Unicode
  • Nazwy pól nie mogą zawierać żadnych spacji wiodących ani końcowych, ani dwóch lub więcej kolejnych spacji
  • Nazwy pól muszą zawierać co najmniej jeden znak alfabetyczny
  • Nazwy pól nie mogą zawierać następujących znaków: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Ponieważ wszystkie pola są zdefiniowane dla organizacji, nie można dodać pola niestandardowego o tej samej nazwie pola, która już istnieje w organizacji lub została dodana do funkcji WIT w innym odziedziczonym procesie.

Uwaga

Przejście projektu do dziedziczonego procesu może spowodować wystąpienie narzędzi Agile lub elementów roboczych w nieprawidłowym stanie zgodnie z następującymi przykładami:

  • Jeśli wyznaczysz pole zgodnie z wymaganiami, elementy robocze, których brakuje w tym polu, wyświetlają komunikat o błędzie. Aby kontynuować wprowadzanie dalszych zmian i zapisać element roboczy, rozwiąż te błędy.
  • Jeśli dodasz, usuniesz lub ukryjesz stany przepływu pracy dla elementu WIT wyświetlanego na tablicy, upewnij się, że zaktualizujesz konfiguracje kolumn tablicy dla wszystkich zespołów zdefiniowanych w projekcie. Należy również rozważyć zachowanie pojedynczej własności elementów roboczych według ścieżki obszaru zespołu lub sformalizowania kolumn z niestandardowymi stanami współużytkowania między zespołami.

Reguły niestandardowe i reguły systemowe

Każdy element WIT — usterka, zadanie, historia użytkownika itp. — ma już kilka zdefiniowanych reguł systemowych. Niektóre z nich są proste, takie jak wymaganie pola Tytuł lub ustawienie wartości domyślnej dla pola Obszar wartości. Ponadto wiele reguł systemu definiuje akcje, które należy wykonać, gdy zmieni się stan przepływu pracy.

Istnieje na przykład kilka reguł, które umożliwiają skopiowanie bieżącej tożsamości użytkownika w następujących warunkach:

  • Po zmodyfikowaniu elementu roboczego skopiuj tożsamość użytkownika do pola Zmieniono według
  • Gdy stan przepływu pracy zmieni się na Zamknięte lub Gotowe, skopiuj tożsamość użytkownika do pola Zamknięte według.

Ważne

Wstępnie zdefiniowane reguły systemowe mają pierwszeństwo przed dowolną regułą niestandardową, która ją zastąpi.

Reguły niestandardowe zapewniają obsługę wielu przypadków użycia biznesowego, co pozwala na wykraczanie poza ustawienie wartości domyślnej dla pola lub wymaganie. Reguły umożliwiają wyczyszczenie wartości pola, skopiowanie wartości do pola i zastosowanie wartości na podstawie zależności między wartościami różnych pól.

Za pomocą reguły niestandardowej można zdefiniować wiele akcji na podstawie określonych warunków. Możesz na przykład zastosować regułę do obsługi tego typu scenariuszy:

  • Gdy wartość jest zdefiniowana dla priorytetu, ustaw pole Ryzyko jako wymagane
  • Po wprowadzeniu zmiany wartości Release wyczyść wartość "Kamień milowy"
  • Gdy wprowadzono zmianę wartości Pozostałe prace, wprowadź pole Ukończona praca jako wymagane
  • Gdy wartość Approved ma wartość True, a następnie wprowadź wartość Approved By a required field (Zatwierdzone przez wymagane pole)
  • Po utworzeniu scenariusza użytkownika wprowadź następujące pola: Priorytet, Ryzyko i Nakład pracy

Napiwek

Nie można zdefiniować formuły przy użyciu reguły. Można jednak znaleźć rozwiązanie, które odpowiada Twoim potrzebom za pomocą rozszerzenia witryny Marketplace usługi Power Automate lub serwera TFS (usługa internetowa). Zobacz również zestawienie pracy i innych pól.

Aby uzyskać szczegółowe informacje na temat definiowania reguł niestandardowych, zobacz Reguły i ocena reguł.

Ogranicz modyfikowanie wybranych pól dla wybranych grup użytkowników

Korzystając z jednego z następujących dwóch warunków, możesz ustawić pola wyboru wymagane dla użytkownika grupy zabezpieczeń lub którzy nie są członkami grupy zabezpieczeń.

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

Możesz na przykład ustawić pole Tytuł lub Stan tylko do odczytu dla wybranych użytkowników lub grup.

Ograniczanie modyfikacji elementów roboczych na podstawie ścieżki obszaru

Możesz uniemożliwić użytkownikom modyfikowanie wybranych elementów roboczych, ustawiając uprawnienia na ścieżce obszaru. Nie jest to ustawienie reguły, ale ustawienie uprawnień. Aby dowiedzieć się więcej, zobacz Tworzenie węzłów podrzędnych, modyfikowanie elementów roboczych w ścieżce obszaru.

Dostosowania typu elementu roboczego (WIT)

Poniżej przedstawiono opcje dostosowywania dla dziedziczych i niestandardowych sieci WIT.

Typ elementu roboczego

Obsługa dostosowywania

Dziedziczone typy elementów roboczych

Niestandardowe typy elementów roboczych

Czego nie można dostosować

  • Nie można dodawać ani usuwać dziedziczonego trybu WIT do lub z listy prac
  • Nie można zmienić położenia dziedziczonego pola w układzie formularza (można jednak ukryć to pole w jednym obszarze formularza i dodać je w innym miejscu formularza)
  • Nie można usunąć dziedziczonego poziomu portfela z produktu (ale można je zmienić)
  • Nie można zmienić nazwy niestandardowego elementu WIT.

Dostosowania formularza elementu roboczego

Następujące dostosowania można wprowadzić w formularzu funkcji WIT.

Typ grupy lub strony

Obsługa dostosowywania

Grupy dziedziczone

Grupy niestandardowe

Dziedziczone strony

Strony niestandardowe

Układ i zmiana rozmiaru

Układ formularza internetowego jest podzielony na trzy kolumny, jak pokazano na poniższej ilustracji.

Ilustracja układu strony 3-kolumnowej dla formularza elementu roboczego.

Jeśli do pierwszych dwóch kolumn dodasz tylko grupy i pola, układ odzwierciedla układ dwukolumny. Podobnie jeśli do pierwszej kolumny dodasz tylko grupy i pola, układ odzwierciedla układ z jedną kolumną.

Rozmiar formularza internetowego zależy od dostępnej szerokości i liczby kolumn w układzie. Przy maksymalnej szerokości w większości przeglądarek internetowych każda kolumna na stronie jest wyświetlana we własnej kolumnie. W miarę zmniejszania szerokości wyświetlania każda kolumna zmienia rozmiar proporcjonalnie w następujący sposób:

  • W przypadku trzech kolumn: 50%, 25%i 25%
  • W przypadku dwóch kolumn: 66% i 33%
  • Dla jednej kolumny: 100%.

Gdy szerokość ekranu nie będzie pomieścić wszystkich kolumn, kolumny są wyświetlane w obrębie kolumny po lewej stronie.

Dostosowania przepływu pracy

Przepływ pracy dowolnego typu elementu roboczego (WIT) można dostosować, ukrywając dziedziczone stany lub dodając stany niestandardowe. Stany dziedziczone różnią się w zależności od procesu systemowego — Agile, Basic, Scrum lub CMMI — z którego wybrano sposób tworzenia niestandardowego procesu.

Każdy domyślny przepływ pracy dla każdego elementu WIT definiuje między dwoma i czterema stanami i określa następujące operacje przepływu pracy:

  • Przechodzenie do przodu i do tyłu między poszczególnymi stanami
  • Domyślne przyczyny przejścia poszczególnych stanów

Na przykład w procesie podstawowym funkcja WIT problemu charakteryzuje się trzema stanami — do wykonania, wykonywania i wykonania — oraz przejściami pokazanymi na poniższej ilustracji.

Podstawowy proces, typ elementu roboczego, model stanu przepływu pracy

Typy stanów

Obsługiwane dostosowania

Ikona dziedziczona Stany dziedziczone

Stany niestandardowe

Stany przepływu pracy muszą być zgodne z następującymi regułami

  • Musisz zdefiniować co najmniej jeden stan dla kategorii Stan proponowany lub W toku

    Uwaga

    Przed dodaniem stanu przepływu pracy zapoznaj się z tematem Stany przepływu pracy i kategorie stanów, aby dowiedzieć się, jak stany przepływu pracy są mapowe na kategorie stanów.

  • Musisz zdefiniować co najmniej dwa stany przepływu pracy
  • Można zdefiniować maksymalnie 32 stany przepływu pracy na typ elementu roboczego

Nieobsługiwane dostosowania przepływu pracy

  • Nie można zmodyfikować stanu dziedziczonego (nie można zmienić jego nazwy, koloru lub kategorii), ale możesz go ukryć
  • W kategorii Stan ukończony można mieć tylko jeden stan. Jeśli dodasz stan niestandardowy do kategorii Ukończono, każdy inny stan zostanie usunięty lub ukryty
  • Nie można zmienić nazwy stanu niestandardowego
  • Nie można określić przyczyny stanu, zamiast tego zdefiniowano przyczyny domyślne, takie jak Przeniesiono do klasyfikacji stanu, Przeniesiono z klasyfikacji stanu
  • Nie można zmienić lokalizacji pól Stan i Przyczyna w formularzu
  • Nie można dostosować nazw kategorii stanów
  • Nie można zmodyfikować stanu dziedziczonego (nie można zmienić jego nazwy, koloru lub kategorii), ale możesz go ukryć
  • W kategorii Stan ukończony można mieć tylko jeden stan. System nie zezwala na dodawanie dowolnego stanu niestandardowego do tej kategorii
  • Nie można zmienić nazwy stanu niestandardowego
  • Nie można zmienić kolejności stanów, stany są wyświetlane w ich sekwencji naturalnej na podstawie ich kategorii stanu na liście rozwijanej formularza elementu roboczego
  • Nie można określić przyczyny stanu, zamiast tego zdefiniowano przyczyny domyślne, takie jak Przeniesiono do klasyfikacji stanu, Przeniesiono z klasyfikacji stanu
  • Nie można zmienić lokalizacji pól Stan i Przyczyna w formularzu
  • Nie można ograniczyć przejść. Wszystkie przejścia są definiowane z dowolnego stanu do innego stanu.

Dostosowania listy prac i tablicy

Listy prac i tablice są niezbędnymi narzędziami Agile do tworzenia pracy dla zespołu i zarządzania nimi. Standardowe listy prac — produkt, iteracja i portfolio — dziedziczone z procesu systemowego są w pełni dostosowywalne. Ponadto możesz dodać niestandardowe listy prac dla portfolio, aby mieć łącznie pięć takich list prac.

Typy list prac

Obsługa dostosowywania

Odziedziczone listy prac

Niestandardowe listy prac portfela

Nieobsługiwane dostosowania:

  • Usuwanie dziedziczonego poziomu portfela:
    • Chociaż nie można bezpośrednio usunąć dziedziczonego poziomu portfela z produktu, masz kilka opcji:
      • Zmień nazwę poziomu portfela: możesz zmienić nazwę dziedziczonego poziomu portfela, aby lepiej dopasować się do Twoich potrzeb.
      • Wyłącz dziedziczony tryb WIT: jeśli dziedziczony poziom portfela obejmuje sieci WIT, których nie chcesz używać, możesz je wyłączyć. Ta akcja uniemożliwia zespołom tworzenie nowych elementów roboczych tego typu.
  • Wstawianie poziomu listy prac:
    • Nie można wstawić nowego poziomu listy prac w istniejącym zestawie zdefiniowanych list prac. Wstępnie zdefiniowane poziomy listy prac są zwykle stałe (na przykład Epiki, Funkcje, Scenariusze użytkowników, Zadania) i nie można dodawać niestandardowych między nimi.
  • Zmiana kolejności poziomów listy prac:
    • Niestety, nie można zmienić kolejności poziomów listy prac. Zwykle są one zgodne ze wstępnie zdefiniowaną hierarchią i zmiana ich kolejności nie jest obsługiwana.
  • Dodawanie funkcji WIT do wielu poziomów listy prac:
    • Każdy element WIT może należeć tylko do jednego poziomu listy prac. Nie można jednocześnie dodać trybu WIT do dwóch różnych poziomów listy prac.
  • Tworzenie niestandardowego poziomu listy prac zadań:
    • Chociaż nie można utworzyć niestandardowego poziomu listy prac specyficznych dla zadania, można nadal dodawać niestandardowe sieci WIT do listy prac iteracji. Można na przykład utworzyć niestandardowy element WIT o nazwie "Ulepszenia" lub "Konserwacja" i skojarzyć go z listą prac iteracji.
  • Zarządzanie usterkami:
    • Funkcja WIT usterki nie należy do żadnego określonego poziomu listy prac domyślnie. Zamiast tego każdy zespół może zdecydować, jak chcą zarządzać usterkami. Możesz wybrać wyświetlanie usterek na listach prac i tablicach lub obsługiwać je oddzielnie.
  • Dodawanie lub usuwanie dziedziczonego elementu WIT z listy prac:
    • Nie można bezpośrednio dodawać ani usuwać dziedziczonego elementu WIT do lub z listy prac. Na przykład dodanie elementu WIT "Problem" do listy prac produktu nie jest obsługiwane.
    • Można jednak wykonać następujące czynności:
      • Zmień nazwę poziomu portfela: jeśli odziedziczony poziom portfela obejmuje sieci WIT, których nie chcesz używać, rozważ zmianę nazwy na lepiej dopasowane do Twoich potrzeb.
      • Wyłącz dziedziczony WIT: jeśli istnieją dziedziczone sieci WIT, które chcesz wykluczyć, możesz je wyłączyć. Ta akcja uniemożliwia zespołom tworzenie nowych elementów roboczych tego typu.
  • Usuwanie dziedziczonego poziomu portfela:
    • Chociaż nie można usunąć dziedziczonego poziomu portfela z produktu, masz kilka opcji:
      • Zmień nazwę poziomu portfela: Nadaj jej bardziej odpowiednią nazwę.
      • Wyłącz dziedziczone sieci WITs: uniemożliwia zespołom korzystanie z określonych dziedziczych sieci WITs.
  • Wstawianie poziomu listy prac:
    • Niestety nie można wstawić nowego poziomu listy prac w istniejącym zestawie zdefiniowanych list prac. Wstępnie zdefiniowane poziomy listy prac pozostają stałe (na przykład Epiki, Funkcje, Scenariusze użytkownika, Zadania).
  • Zmiana kolejności poziomów listy prac:
    • Poziomy listy prac zwykle są zgodne ze wstępnie zdefiniowaną hierarchią, a zmiana ich kolejności nie jest obsługiwana. Nie można ich zmienić.
  • Dodawanie funkcji WIT do wielu poziomów listy prac:
    • Każdy element WIT (na przykład Usterka, Zadanie, Historia użytkownika) może należeć tylko do jednego poziomu listy prac. Nie można jednocześnie dodać trybu WIT do dwóch różnych poziomów listy prac.
  • Tworzenie niestandardowego poziomu zadań:
    • Chociaż nie można utworzyć niestandardowego poziomu listy prac specyficznych dla zadania, można nadal dodawać niestandardowe sieci WIT do listy prac iteracji. Na przykład utwórz niestandardowy element WIT o nazwie "Ulepszenia" lub "Konserwacja" i skojarz go z listą prac iteracji.
  • Zarządzanie usterkami:
    • Funkcja WIT usterki nie należy do żadnego określonego poziomu listy prac domyślnie. Zamiast tego każdy zespół może zdecydować, jak chcą zarządzać usterkami. Możesz wybrać wyświetlanie usterek na listach prac i tablicach lub obsługiwać je oddzielnie.

Uwaga

Niektóre funkcje wymagają zainstalowania aktualizacji usługi Azure DevOps Server 2020.1. Aby uzyskać więcej informacji, zobacz Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards.

Zmiana domyślnego trybu WIT dla poziomu listy prac powoduje, że funkcja WIT będzie domyślnie wyświetlana w panelu szybkiego dodawania. Na przykład bilet klienta jest domyślnie wyświetlany w następującym panelu szybkiego dodawania dla listy prac produktu.

Zrzut ekranu przedstawiający listę prac produktu, panel szybkiego dodawania, wyświetla domyślny WIT na poziomie listy prac

Limity obiektów

Aby uzyskać listę limitów dotyczących liczby pól, sieci WITs, poziomów listy prac i innych obiektów, które można dostosować, zobacz Work tracking object limits (Limity obiektów śledzenia pracy).