Informacje o dostosowywaniu procesów i procesach dziedziczonych
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ć.
Uwaga
Aby uzyskać więcej informacji, zobacz następujące artykuły:
Procesy systemowe a dziedziczone
Zobaczysz dwa typy procesów:
- Procesy systemowe — Agile, Basic, Scrum i CMMI — które są zablokowane przed zmianą.
- 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.
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.
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
- Dodawanie pola niestandardowego
- Dodaj listę wyboru (menu rozwijane)
- Dodawanie nazwiska/tożsamości
- Dodawanie pola tekstu sformatowanego (HTML)
- Dodawanie pola wyboru (wartość logiczna)
- Dodawanie kontrolki niestandardowej
- Dodawanie reguł niestandardowych do pola
- Zmienianie etykiety pola
- Ustaw opcje wymagane/domyślne
- Przenoszenie pola w układzie
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 uzyskać więcej informacji, 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 uzyskać więcej informacji, 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 uzyskać więcej informacji, 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
- Dodawanie niestandardowego WIT
- Zmienianie koloru lub opisu
- Dodawanie/usuwanie pól niestandardowych
- Dodawanie/usuwanie grup niestandardowych
- Dodawanie/usuwanie stron niestandardowych
- Dodawanie/usuwanie kontrolki niestandardowej
- Dodawanie reguł niestandardowych do dowcipu
- Dodawanie, edytowanie lub usuwanie stanu przepływu pracy
- Włączanie/wyłączanie
- Usuń
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.
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 wybranego do utworzenia procesu niestandardowego. Dostępne opcje to Agile, Basic, Scrum lub Capability Maturity Model Integration (CMMI). Aby uzyskać więcej informacji, zobacz Stany, przejścia i przyczyny przepływu pracy.
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. Na przykład podstawowy problem z procesem WIT obejmuje trzy stany — Do wykonania, Robienie i Gotowe.
- Domyślne przyczyny przejścia poszczególnych stanów
Typy stanów
Obsługiwane dostosowania
Stany dziedziczone
Stany niestandardowe
Stany przepływu pracy muszą być zgodne z następującymi regułami
- Zdefiniuj co najmniej jeden stan dla kategorii Stan proponowany lub W toku .
Uwaga
Przed dodaniem stanu przepływu pracy zobacz About workflow states in backlogs and boards (Informacje o stanach przepływu pracy na listach prac i tablicach ), aby dowiedzieć się, jak stany przepływu pracy są mapowane na kategorie stanów.
- Zdefiniuj co najmniej dwa stany przepływu pracy.
- Zdefiniuj maksymalnie 32 stany przepływu pracy na typ elementu roboczego.
Nieobsługiwane dostosowania przepływu pracy
- Ukryj dziedziczone stany, jeśli nie chcesz, aby były widoczne (nie można zmienić ich nazwy, koloru ani kategorii).
- Upewnij się, że w kategorii Stan ukończony istnieje tylko jeden stan. Dodanie stanu niestandardowego do tej kategorii powoduje usunięcie lub ukrycie dowolnego innego stanu.
- Zachowaj nazwę stanów niestandardowych w następujący sposób: nie można ich zmienić.
- Użyj domyślnych przyczyn przejścia stanu, takich jak Przeniesiono do klasyfikacji stanu i Przeniesiono z klasyfikacji stanu; nie można określić przyczyn niestandardowych.
- Zaakceptuj domyślną lokalizację pól Stan i Przyczyna w formularzu; nie można zmienić ich umieszczania.
- Użyj domyślnych nazw kategorii stanów; nie można ich dostosować.
- Ukryj dziedziczone stany, jeśli nie chcesz, aby były widoczne (nie można zmienić ich nazwy, koloru ani kategorii).
- Upewnij się, że w kategorii Ukończono istnieje tylko jeden stan; system nie zezwala na dodawanie dowolnego stanu niestandardowego do tej kategorii.
- Zachowaj nazwę stanów niestandardowych w następujący sposób: nie można ich zmienić.
- Zaakceptuj naturalną sekwencję stanów na liście rozwijanej w formularzu elementu roboczego; nie można zmienić ich kolejności.
- Użyj domyślnych przyczyn przejścia stanu, takich jak Przeniesiono do klasyfikacji stanu i Przeniesiono z klasyfikacji stanu; nie można określić przyczyn niestandardowych.
- Zaakceptuj domyślną lokalizację pól Stan i Przyczyna w formularzu; nie można zmienić ich umieszczania.
- Zezwalaj na przejścia z dowolnego stanu na inny; nie można ograniczyć przejść.
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.
- Chociaż nie można bezpośrednio usunąć dziedziczonego poziomu portfela z produktu, masz kilka opcji:
- 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.
- Chociaż nie można usunąć dziedziczonego poziomu portfela z produktu, masz kilka opcji:
- 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.
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).