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 konfigurujesz swoje narzędzia Agile — listy prac, sprinty, 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ą zarządzane i okresowo aktualizowane przez firmę Microsoft. Wszystkie aktualizacje wprowadzone w procesie systemowym automatycznie powodują aktualizację odziedziczonych procesów i ich procesów pochodnych. Aktualizacje procesów są udokumentowane w informacjach o wersji dla usługi Azure DevOps Server.

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, na który przechodzisz. 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 zidentyfikować wszelkie negatywne skutki, które mogą powodować zmiany w procesie.

Obiekty dziedziczone a obiekty niestandardowe

Każdy utworzony proces dziedziczony przejmuje typy pracy zdefiniowane w procesie systemowym — Podstawowy, Agile, Scrum lub CMMI. Na przykład proces Agile udostępnia usterkę, zadanie, historię użytkownika, funkcję, epik, problem oraz testy powiązane z WITs.

Obraz koncepcyjny hierarchii elementów roboczych procesu Agile.

Pola można dodawać i modyfikować przepływ pracy oraz formularz elementu roboczego dla wszystkich dziedziczonych 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żesz dodawać niestandardowe typy WIT.

Dostosowania pól

Pola zdefiniowane w procesie systemowym są wyświetlane z ikoną dziedziczoną , wskazującą, że w odziedziczonym procesie można dokonywać ograniczonych modyfikacji.

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 wykonania do historii użytkownika lub błędu 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.

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 związanymi z nazwą osoby, takimi jak "Przypisane do" i "Zmienione przez", są zarządzane w oparciu o użytkowników, których dodasz 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 REST API Aktualizacja Pola.

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, które przypisujesz do pola, są przechowywane w bazie danych śledzenia pracy, do których można tworzyć zapytania w celu określenia stanu i trendów.

Aby zobaczyć opisy i użycie każdego pola zdefiniowanego dla głównych procesów systemowych — procesów systemu Scrum, Agile i CMMI— zobacz Indeks pól elementów roboczych.

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ć maksymalnie 128 znaków Unicode
  • Nazwy pól nie mogą zawierać żadnych spacji wiodących ani końcowych, ani dwóch lub więcej następujących po sobie 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 elementów 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 oznaczysz pole jako wymagane, elementy robocze, w których brakuje tego pola, 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ć utrzymanie jednolitej własności elementów roboczych według ścieżki obszaru zespołu lub sformalizowanie kolumn z niestandardowymi stanami, które są współdzielone 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 modyfikacji 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 identyfikator użytkownika do pola "Zamknięte przez".

Ważne

Zdefiniowane reguły systemowe mają pierwszeństwo przed każdą regułą niestandardową, którą zdefiniujesz, mogącą je 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 działań 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, należy wyczyścić wartość "Kamień milowy".
  • Gdy wprowadzono zmianę wartości Pozostałe prace, oznacz pole Ukończona praca jako wymagane.
  • Gdy wartość Approved jest True, pole Approved By powinno być wymagane.
  • 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żesz jednak znaleźć rozwiązanie, które odpowiada Twoim potrzebom, korzystając z Power Automate lub rozszerzenia Marketplace TFS Aggregator (usługa internetowa). Zobacz również podsumowanie 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.

Ogranicz modyfikację 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 i modyfikowanie elementów roboczych w obszarze ścieżki.

Dostosowania typu elementu roboczego (WIT)

Poniżej przedstawiono opcje dostosowywania dla dziedziczonych i niestandardowych WIT-ów.

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 typu elementu roboczego do lub z backlogu.
  • 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ąć dziedziczonych poziomów portfela z produktu (ale można je zmienić nazwy)
  • Nie można zmienić nazwy niestandardowego elementu WIT.

Dostosowania formularza elementu roboczego

Następujące dostosowania można wprowadzić w formularzu 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 3-kolumnowego układu strony dla formularza elementów roboczych.

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 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ć poprzez ukrycie dziedziczonych stanów lub dodanie stanów niestandardowych. 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 podstawowe zadanie procesu WIT obejmuje trzy stany — Do zrobienia, W trakcie i Zrobione.
  • Domyślne przyczyny przejść między stanami

Typy stanów

Obsługiwane dostosowania

Stany dziedziczone

Stany niestandardowe

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

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 bez zmian; nie można ich zmienić.
  • Użyj domyślnych przyczyn przejścia stanu, takich jak Przeniesiono do stanu Klasyfikacja i Przeniesiono ze stanu Klasyfikacja; 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ć.

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 zaległości, jak produkt, iteracja i portfolio, dziedziczone z systemowego procesu są w pełni dostosowywalne. Ponadto możesz dodać niestandardowe listy prac dla portfolio, aby mieć łącznie pięć takich list prac.

Typy backlogu

Obsługa dostosowywania

Odziedziczone zaległości

Niestandardowe backlogi 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 typ WIT: Jeśli dziedziczony poziom portfela obejmuje typy 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 backlogu:
    • 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 backlogu. Zwykle przestrzegają wstępnie zdefiniowanej hierarchii i nie wspiera się zmiany ich kolejności.
  • 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ć WIT do dwóch różnych poziomów backlogu.
  • Tworzenie niestandardowego poziomu listy prac zadań:
    • Chociaż nie można utworzyć niestandardowego poziomu listy prac dla konkretnego zadania, nadal można dodawać niestandardowe elementy 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:
    • Element WIT typu usterka domyślnie nie należy do żadnego określonego poziomu backlogu. 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 elementu WIT dla poziomu backlogu powoduje, że element WIT wyświetla się domyślnie w panelu szybkiego dodawania. Na przykład, zlecenie klienta pojawi się domyślnie w następującym panelu szybkiego dodawania dla rejestru produktu.

Zrzut ekranu przedstawiający backlog produktu, szybki panel dodawania, wyświetla domyślny WIT dla poziomu backlogu

Limity obiektów

Aby uzyskać listę limitów dotyczących liczby pól, WITs, poziomów backlogu i innych obiektów, które można dostosować, zobacz Limity obiektów śledzenia pracy.