Udostępnij przez

Dostosowywanie i dziedziczenie procesów

Azure DevOps Services

Aby dostosować system śledzenia pracy usługi Azure DevOps do potrzeb organizacji, możesz dostosować dziedziczony proces za pomocą ustawień organizacji. Wszystkie projekty w organizacji korzystającej z dziedziczonego procesu uzyskują dostosowania wprowadzone w tym procesie. Następnie można skonfigurować listy prac projektu, przebiegi i tablice dla każdego zespołu projektu.

Ważne

Ten artykuł dotyczy tylko modelu procesu dziedziczenia w usługach Azure DevOps Services. Aby dostosować lokalne projekty lub zaktualizować pliki definicji XML, zobacz Hostowany model procesu XML i Dostosowywanie hostowanego procesu XML.

Można wprowadzić kilka dostosowań w dziedziczone procesy. Najważniejsze są tworzenie niestandardowych typów elementów roboczych (WIT) lub modyfikowanie istniejących sieci WIT w celu dodawania pól niestandardowych, modyfikowania układów lub zmieniania przepływów pracy. Niektóre opcje dziedziczonych elementów są zablokowane i nie można ich dostosować.

Ten artykuł zawiera omówienie sposobów dostosowywania dziedziczych procesów. Aby uzyskać informacje o limitach liczby pól, typów elementów roboczych, poziomów zaległości i innych obiektów, które można konfigurować, zobacz Śledzenie pracy, procesy i limity projektów.

Uwaga

Zmiany wprowadzone w procesie odziedziczonym można przejrzeć przy użyciu funkcji dziennika inspekcji i inspekcji. Aby uzyskać więcej informacji, zobacz Access, export, and filter audit logs (Uzyskiwanie dostępu, eksportowanie i filtrowanie dzienników inspekcji).

Procesy systemowe i dziedziczone

Procesy systemuAgile, Basic, Scrum i Capability Maturity Model Integration (CMMI) są zablokowane, a użytkownicy nie mogą ich zmieniać. Firma Microsoft jest właścicielem tych procesów systemowych i okresowo je aktualizuje.

Dziedziczone procesy są dostosowywane z procesów systemowych i dziedziczą definicje z procesu systemowego, na podstawie którego są oparte. Wszelkie aktualizacje wykonywane przez firmę Microsoft w procesach systemowych automatycznie aktualizują się w dziedziczonych procesach i ich podrzędnych, dziedziczonych procesach.

Wszystkie projekty w organizacji mogą współużytkować wszystkie procesy. Proces można dostosować zamiast dostosowywać pojedyncze projekty.

Po utworzeniu dziedziczonego procesu można go dostosować, skopiować, utworzyć na podstawie niego projekty i zmienić istniejące projekty, aby go używać. Zmiany wprowadzane do dziedziczonego procesu automatycznie aktualizują wszystkie projekty w organizacji korzystającej z tego procesu.

Poniższy przykład przedstawia listę projektów w organizacji fabrikamprime i proces, z których korzysta każdy projekt. Aby zmienić dostosowania projektu Fabrikam Fiber , należy zmodyfikować proces My Agile , który dziedziczy z procesu systemu Agile . Zmiany wprowadzone w procesie My Agile aktualizują również projekt Agile zaprojektowany zgodnie z zasadami który korzysta z tego procesu. Aby dostosować inne projekty, należy zmienić je tak, aby korzystały z procesów dziedziczynych.

Zrzut ekranu przedstawiający projekty i używane przez nie procesy.

Zmienianie procesu istniejącego projektu

Możesz przełączyć proces używany przez projekt z jednego procesu na inny. Aby uzyskać więcej informacji i instrukcji, zobacz następujące artykuły:

Postępując zgodnie z ogólnymi wskazówkami w wymienionych artykułach, możesz wprowadzić inne zmiany, takie jak z CMMI na Agile lub Agile do CMMI. Przed zmianą procesu projektu zapoznaj się z procesem, do którego się zmieniasz. Aby uzyskać więcej informacji, zobacz About processes and process templates (Informacje o procesach i szablonach procesów).

W przypadku przejścia projektu do innego procesu niektóre istniejące narzędzia lub elementy robocze mogą stać się nieprawidłowe. Na przykład elementy robocze, które nie mają pola wymaganego w nowym procesie, mogą wyświetlać błędy. Aby kontynuować wprowadzanie zmian i zapisywać elementy robocze, należy usunąć te błędy. Jeśli zmiana procesu dodaje, usuwa lub ukrywa stany przepływu pracy dla elementu WIT wyświetlanego na tablicy, pamiętaj, aby zaktualizować konfiguracje kolumn tablicy dla wszystkich zespołów zdefiniowanych w projekcie.

Zmiana lub zmiana nazwy dziedziczonego procesu

Zmiana dziedziczonego procesu jest prosta, ale najlepiej przetestować zmiany przed zastosowaniem ich do aktywnego projektu. Możesz skopiować proces i najpierw wprowadzić zmiany w skopiowanym procesie, aby uniknąć wpływu na istniejące projekty i zidentyfikować ewentualne negatywne skutki tych zmian.

Możesz zmienić nazwę dziedziczonego procesu w ustawieniach organizacji , wybierając ikonę Więcej akcji obok nazwy procesu i wybierając pozycję Edytuj.

Nazwy procesów

Nazwy procesów mają następujące wymagania:

  • Musi być unikatowa w organizacji
  • Musi mieć maksymalnie 128 znaków Unicode
  • Nie można zawierać żadnego z następujących znaków: .,;':~\/*|?"&%$!+=()[]{}<>

Obiekty dziedziczone i niestandardowe

Każdy dziedziczony proces dziedziczy WITy zdefiniowane w systemowym procesie Basic, Agile, Scrum lub CMMI. Na przykład procesy dziedziczone z metodyki Agile zapewniają usterkę, zadanie, historię użytkownika, funkcję, epik, problem oraz powiązane z testami typy elementów roboczych.

Możesz dodawać pola i modyfikować przepływ pracy oraz formularz elementu roboczego dla wszystkich typów elementów roboczych (WIT), które są wyświetlane na stronie Typy elementów roboczych w dziedziczonym procesie. Możesz również dodać niestandardowe WITs.

Jeśli nie chcesz, aby użytkownicy utworzyli nowe elementy robocze na podstawie dziedziczonego procesu WIT, możesz ją wyłączyć, wybierając ikonę Więcej akcji obok nazwy funkcji WIT w ustawieniach organizacji i wybierając pozycję Wyłącz z menu kontekstowego.

Pola elementów roboczych

W tej sekcji opisano pola elementów roboczych.

Pola i odwołania do pól

Elementy robocze służą do planowania i śledzenia projektu. Każdy typ elementu roboczego jest skojarzony z 31 polami systemowymi i kilkoma kolejnymi polami specyficznymi dla typu, które zapewniają informacje dotyczące śledzenia elementów roboczych. Wartości przypisywane do pola są przechowywane w magazynie danych do śledzenia pracy, który można przeszukiwać zapytaniami w celu określenia stanu i trendów.

Opisy i sposób użycia każdego pola zdefiniowanego dla podstawowych procesów systemowych Scrum, Agile i Capability Maturity Model Integration (CMMI) znajdziesz w temacie Indeks pól elementu roboczego.

Nazwy pól

Nazwa pola elementu roboczego jednoznacznie identyfikuje każde pole elementu roboczego. Upewnij się, że nazwy pól spełniają następujące wymagania:

  • Musi być unikatowa w organizacji lub kolekcji projektów
  • Musi mieć co najwyżej 128 znaków Unicode
  • Musi zawierać co najmniej jeden znak alfabetyczny
  • Nie można zawierać żadnych spacji wiodących ani końcowych albo co najmniej dwóch kolejnych spacji
  • Nie można zawierać żadnego z następujących znaków: .,;':~\/*|?"&%$!+=()[]{}<>

Nazwy pól i definicje mają zastosowanie do całej organizacji. Nie można dodać pola o nazwie, która już istnieje w organizacji lub którą inny dziedziczony proces dodał do typu elementu pracy (WIT).

Dostosowania pól

Pola są definiowane dla wszystkich projektów i procesów w organizacji. Dziedziczone procesy dziedziczą pola zdefiniowane w procesach systemowych i można wprowadzać w nich ograniczone modyfikacje. Pola niestandardowe można tworzyć i modyfikować w procesach dziedziczynych.

Możesz dodać dowolne pole niestandardowe zdefiniowane dla elementu WIT w jednym procesie do dowolnego elementu WIT zdefiniowanego dla innego procesu. Możesz również dodać istniejące pole do innego elementu WIT w ramach tego samego procesu. Możesz na przykład dodać termin ukończenia do opisu użytkownika lub błędów WIT.

Dostosowywanie pól i kontrolek

W poniższych zasobach opisano sposób implementowania różnych dostosowań dla dziedzicowanych pól, pól niestandardowych lub kontrolek niestandardowych.

Pola dziedziczone

Pola niestandardowe

Kontrolka niestandardowa

Usuwanie lub przywracanie usuniętych pól

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 ukryć lub usunąć pole z formularza elementu roboczego. Aby uzyskać szczegółowe informacje, zobacz Pokaż, ukryj lub usuń pole.

Ograniczenia

  • Nie można zmienić nazwy pola ani typu danych po jego zdefiniowaniu. Można jednak zmienić etykietę wyświetlaną dla pola w formularzu elementu roboczego z karty Układ . Po wybraniu pola w zapytaniu należy użyć nazwy pola, a nie etykiety pola.
  • Nie można zmodyfikować szarego obszaru w formularzu zawierającym pola Stan, Przyczyna, Ścieżka obszaru i Ścieżka iteracji .
  • Ścieżki obszaru i listy wyboru ścieżek iteracji są konfigurowane dla każdego projektu i nie można ich dostosowywać za pomocą dziedziczonego procesu.
  • Listy wyboru skojarzone z polami tożsamości użytkownika, takimi jak Przypisany do i Zmienione przez, uzupełniane są na podstawie użytkowników dodanych do projektu lub zespołu.
  • Dla każdego elementu WIT można zdefiniować maksymalnie 64 pola, a dla każdego procesu można zdefiniować maksymalnie 512 pól.
  • Nie można zaimportować ani zdefiniować listy globalnej, która jest obsługiwana przez modele procesów Hosted XML i On-premises XML.

Reguły niestandardowe i reguły systemowe

Każdy element WIT ma kilka zdefiniowanych reguł systemowych, takich jak wymaganie pola Tytuł lub ustawienie wartości domyślnej dla pola Obszar wartości . Reguły systemowe definiują również akcje do wykonania w przypadku zmiany stanu przepływu pracy.

Na przykład kilka reguł kopiuje bieżącą tożsamość użytkownika do pola Zmodyfikowano przez, gdy element roboczy zostanie zmodyfikowany, lub do pola Zamknięte przez, gdy stan przepływu pracy osiąga Zamknięty lub Gotowe. Wstępnie zdefiniowane reguły systemowe mają pierwszeństwo przed wszelkimi regułami niestandardowymi, które mogłyby je zastąpić.

Reguły niestandardowe zapewniają obsługę kilku przypadków użycia biznesowego, pozwalając nie tylko na ustawienie wartości domyślnej dla pola czy wymaganie jej. Reguły niestandardowe umożliwiają wyczyszczenie wartości pola, skopiowanie wartości do pola lub zastosowanie wartości na podstawie zależności między różnymi wartościami pól.

Za pomocą reguł niestandardowych można definiować różne akcje na podstawie określonych warunków. Można na przykład zastosować reguły do obsługi następujących scenariuszy:

  • Jeśli wartość jest zdefiniowana dla priorytetu, ustaw pole Ryzyko jako wymagane.
  • Po wprowadzeniu zmiany wartości Release, wyczyść wartość Kamienia milowego.
  • Po wprowadzeniu zmiany wartości Pozostała praca ustaw pole Ukończono pracę jako wymagane.
  • Gdy wartość Approved jest True, pole Zatwierdzone przez powinno być wymagane.
  • Po utworzeniu scenariusza użytkownika wprowadź wymagane pola Priorytet, Ryzyko i Nakład pracy .

Aby uzyskać więcej informacji na temat definiowania reguł niestandardowych, zobacz Dodawanie reguły do typu elementu roboczego (proces dziedziczenia).

Napiwek

Nie można zdefiniować formuły przy użyciu reguły. Możesz jednak znaleźć rozwiązanie, które odpowiada Twoim potrzebom w usłudze Power Automate. Aby uzyskać więcej informacji, zobacz Zestawienie pracy i innych pól.

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

Korzystając z warunków current user is a member of a group... lub current user is not a member of a group..., można wymagać lub skonfigurować wybrane pola dla użytkowników, którzy są członkami lub nieczłonkami grupy lub grupy zabezpieczeń. Można na przykład ustawić pole Tytuł lub Stan tylko do odczytu dla wybranych użytkowników lub grup.

Ogranicz modyfikację elementów roboczych w oparciu o ścieżkę obszaru

Rozważ zachowanie jednej własności elementów roboczych według ścieżki obszaru zespołu lub sformalizowanie kolumn z stanami niestandardowymi udostępnianymi przez zespoły.

Możesz uniemożliwić użytkownikom modyfikowanie wybranych elementów roboczych, ustawiając uprawnienia na ścieżce obszaru. To ustawienie nie jest regułą, ale ustawieniem uprawnień. Aby uzyskać więcej informacji, zobacz Tworzenie węzłów podrzędnych, modyfikowanie elementów roboczych w obszarze lub ścieżce iteracji.

Dostosowania typu elementu roboczego

Poniższe zasoby opisują opcje dostosowywania dla dziedziczonych i niestandardowych WIT-ów.

Dziedziczone typy elementów roboczych

Niestandardowe typy elementów roboczych

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

Zrzut ekranu przedstawiający panel szybkiego dodawania z domyślnie ustawionym niestandardowym typem elementu roboczego.

Ograniczenia

  • Nie można dodawać ani usuwać dziedziczonego elementu WIT z listy prac.
  • Nie można zmienić położenia dziedziczonego pola w układzie formularza. Można jednak ukryć pole w jednym obszarze formularza i dodać je w innym miejscu w formularzu.
  • Nie można zmienić nazwy niestandardowego elementu WIT po jego zdefiniowaniu.

Dostosowania formularza elementu roboczego

W formularzu WIT można wprowadzić następujące dostosowania:

Grupy dziedziczone

Grupy niestandardowe

Dziedziczone strony

Strony niestandardowe

Układ i zmiana rozmiaru

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

Ilustracja przedstawiająca układ strony z trzema kolumnami dla formularza elementu roboczego.

Jeśli do pierwszych dwóch kolumn dodasz tylko grupy i pola, układ zawiera dwie kolumny. Jeśli do pierwszej kolumny dodasz tylko grupy i pola, układ zawiera 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. Gdy szerokość ekranu nie pasuje do wszystkich kolumn, kolumny są wyświetlane w obrębie kolumny po lewej stronie.

W miarę spadku szerokości wyświetlania kolumny są zmieniane 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%

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 używanego do tworzenia procesu niestandardowego: Agile, Basic, Scrum lub Capability Maturity Model Integration (CMMI). Aby uzyskać więcej informacji, zobacz Stany, przejścia i przyczyny przepływu pracy.

Domyślny przepływ pracy dla każdego WIT definiuje od dwóch do czterech stanów i określa następujące procesy przepływu pracy:

  • Przechodzenie do przodu i do tyłu między poszczególnymi stanami. Na przykład podstawowy proces Issue WIT obejmuje trzy stany: To Do, Doing i Done.
  • Domyślne przyczyny każdej zmiany statusu.

Dziedziczone i niestandardowe przepływy pracy muszą być zgodne z następującymi regułami:

  • Zdefiniuj co najmniej dwa stany przepływu pracy.
  • Zdefiniuj co najmniej jeden stan dla kategorii stanu Proponowane lub W toku .
  • Zdefiniuj maksymalnie 32 stany przepływu pracy na typ elementu roboczego.

Uwaga

Przed dodaniem niestandardowego 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.

Aby dostosować dziedziczone i niestandardowe stany przepływu pracy, zapoznaj się z następującymi zasobami:

Stany dziedziczone

Stany niestandardowe

Ograniczenia

  • Nie można zmienić nazwy, koloru ani kategorii odziedziczonych stanów, ale możesz je ukryć, jeśli nie chcesz, aby były widoczne.
  • Nie można zmienić nazw stanów niestandardowych po zdefiniowaniu.
  • Nie można zmienić ani dostosować domyślnych nazw kategorii stanu.
  • W kategorii Stan ukończony może istnieć tylko jeden stan. Dodanie stanu niestandardowego do tej kategorii powoduje usunięcie lub ukrycie dowolnego innego stanu w tej kategorii.
  • Nie można określić niestandardowych przyczyn przejścia stanu. Użyj przyczyn domyślnych, takich jak Przeniesiono do stanu "Triaged" i Przeniesiono ze stanu "Triaged".
  • Nie można zmienić położenia pól Stan i Przyczyna w formularzu elementu roboczego.

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 produktu, iteracji i portfolio dziedziczone z procesów systemowych są w pełni customizowalne. Możesz również dodać niestandardowe listy prac portfela, łącznie do pięciu list prac portfela.

Aby uzyskać więcej informacji na temat dostosowywania odziedziczonych i niestandardowych list backlogów portfelowych, zapoznaj się z następującymi zasobami:

Odziedziczone zaległości

Niestandardowe backlogi portfela

Ograniczenia

  • Nie można usunąć dziedziczonego poziomu portfela z produktu. Możesz zmienić nazwę poziomu lub wyłączyć sieci WITs, aby uniemożliwić zespołom tworzenie nowych elementów roboczych tego typu.
  • Nie można wstawić nowego niestandardowego 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, Historie użytkowników i Zadania.
  • Nie można zmienić kolejności poziomów backlogu. Zwykle są one zgodne ze wstępnie zdefiniowaną hierarchią i zmiana kolejności nie jest obsługiwana.
  • Nie można dodać WIT do dwóch różnych poziomów backlogu. Każdy element WIT może należeć tylko do jednego poziomu listy prac.
  • Nie można utworzyć niestandardowego poziomu listy prac specyficznych dla zadania, ale nadal można dodać niestandardowe sieci WIT do listy prac iteracji. Można na przykład utworzyć niestandardowy WIT o nazwie Ulepszenie lub Konserwacja i skojarzyć go z listą prac iteracji.
  • Typ elementu pracy Bug nie przynależy domyślnie do żadnego konkretnego poziomu backlogu. Każdy zespół może zdecydować, jak chcą zarządzać usterkami. Możesz wybrać wyświetlanie błędów na listach prac i tablicach lub obsługiwać je oddzielnie. Aby uzyskać więcej informacji, zobacz Wyświetlanie błędów w backlogach.

Treści powiązane

  • Last updated on