Informacje o domyślnych procesach i szablonach procesów

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

Usługa Azure Boards oferuje różne procesy do wyboru na potrzeby zarządzania elementami roboczymi. Wybór odpowiedniego procesu jest niezbędny do optymalizacji przepływu pracy projektu i zapewnienia jego sukcesu. W tym artykule zapoznamy się z różnymi procesami dostępnymi w usłudze Azure Boards. Ten artykuł zawiera również wskazówki dotyczące wybierania najbardziej odpowiedniego procesu dla projektu.

Podczas tworzenia projektu wybierasz szablon procesu lub procesu na podstawie modelu procesu, dla którego utworzono organizację lub kolekcję. Przed wybraniem procesu projektu należy zrozumieć następujące terminy.

Okres	opis
Model procesów	Odwołuje się do modelu używanego do obsługi projektów utworzonych dla organizacji lub kolekcji projektów. Tylko jeden model procesu jest obsługiwany dla projektu w danym momencie.
Przetwarzaj	Definiuje bloki konstrukcyjne systemu śledzenia elementów roboczych i obsługuje model procesu dziedziczenia dla usługi Azure Boards. Ten model obsługuje dostosowywanie projektów za pomocą interfejsu użytkownika What You See Is What You Get (WYSIWYG).
Szablon procesu	Definiuje bloki konstrukcyjne systemu śledzenia elementów roboczych i innych podsystemów, do których uzyskujesz dostęp za pośrednictwem usługi Azure DevOps. Szablony procesów są używane tylko z hostowanymi modelami procesów XML i lokalnymi plikami XML. Projekty można dostosować, modyfikując i importując pliki definicji XML szablonu procesu.

Obiekty śledzenia pracy zawarte w domyślnych procesach i szablonach procesów, które są Podstawowe, Agile, Capability Maturity Model Integration (CMMI) i Scrum, są takie same. Zostały one podsumowane w tym artykule.

Domyślne procesy

Domyślne procesy różnią się głównie w typach elementów roboczych, które zapewniają planowanie i śledzenie pracy. Domyślne procesy to:

• Podstawowa: jest najbardziej lekki i jest w selektywnej wersji zapoznawczej.
• Scrum: Jest następnym najbardziej lekkim.
• Agile: obsługuje wiele terminów metody Agile.
• CMMI: zapewnia największą obsługę procesów formalnych i zarządzania zmianami.

Uwaga

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

Podstawowa

Wybierz pozycję Podstawowa , gdy twój zespół chce najprostszego modelu, który używa typów elementów roboczych Problem, Zadanie i Epika do śledzenia pracy.

Zadania obsługują śledzenie pozostałej pracy.

---

Zwinność

Wybierz metodę Agile , gdy zespół korzysta z metod planowania Agile, w tym Scrum, i śledzi działania programistyczne i testowe oddzielnie. Ten proces doskonale sprawdza się w przypadku śledzenia scenariuszy użytkownika i (opcjonalnie) usterek na tablicy Kanban. Możesz również śledzić usterki i zadania na tablicy zadań.

Aby uzyskać więcej informacji na temat metodologii Agile, zobacz Agile Alliance.

Zadania obsługują śledzenie oryginalnego oszacowania, pozostałej pracy i ukończonej pracy.

---

Scrum

Wybierz scrum, gdy twój zespół praktykuje Scrum . Ten proces doskonale sprawdza się w przypadku śledzenia elementów listy prac produktu i usterek na tablicy Kanban. Możesz również podzielić elementy listy prac produktów i usterki na zadania na tablicy zadań.

Ten proces obsługuje metodologię Scrum zdefiniowaną przez organizację Scrum.

Zadania obsługują śledzenie tylko pozostałej pracy.

---

CMMI

Wybierz cmMI, gdy zespół będzie przestrzegać bardziej formalnych metod projektu, które wymagają struktury na potrzeby ulepszania procesów i inspekcji rekordu decyzji. Dzięki temu procesowi można śledzić wymagania, żądania zmian, czynniki ryzyka i przeglądy.

Ten proces obsługuje formalne działania związane z zarządzaniem zmianami. Zadania obsługują śledzenie oryginalnego oszacowania, pozostałej pracy i ukończonej pracy.

---

Jeśli potrzebujesz więcej niż dwóch lub trzech poziomów listy prac, dodaj więcej na podstawie używanego modelu procesu:

• Dziedziczenie: dostosowywanie list prac lub tablic dla procesu
• Hostowany kod XML lub lokalny kod XML: dodawanie list prac portfela

Główne różnice między procesami domyślnymi

Domyślne procesy są zaprojektowane tak, aby spełniały potrzeby większości zespołów. Jeśli twój zespół ma nietypowe potrzeby i nawiązuje połączenie z serwerem lokalnym, dostosuj proces, a następnie utwórz projekt. Możesz również utworzyć projekt na podstawie procesu, a następnie dostosować projekt.

Poniższa tabela zawiera podsumowanie głównych różnic między typami elementów roboczych a stanami używanymi przez cztery procesy domyślne.

Obszar śledzenia

Podstawowa

Zwinność

Scrum

CMMI

---

Stany przepływu pracy

• Do wykonania
• Robi
• Gotowe

• Nowe
• Aktywne
• Resolved
• Zamknięcie
• Usunięte

• Nowe
• Zatwierdzona
• Popełnione
• Gotowe
• Usunięte

• Zaproponowano
• Aktywne
• Resolved
• Zamknięcie

Planowanie produktu (patrz Uwaga 1)

• Problem

• Historia użytkownika
• Usterka (opcjonalnie)

• Element listy prac produktu
• Usterka (opcjonalnie)

• Wymaganie
• Usterka (opcjonalnie)

Listy prac portfela (patrz Uwaga 2)

• Epik

• Epik
• Funkcja

• Epik
• Funkcja

• Epik
• Funkcja

Planowanie zadań i przebiegów (patrz Uwaga 3)

• Zadanie

• Zadanie
• Usterka (opcjonalnie)

• Zadanie
• Usterka (opcjonalnie)

• Zadanie
• Usterka (opcjonalnie)

Zarządzanie listami prac błędów (patrz Uwaga 1)

• Problem

• Usterka

• Usterka

• Usterka

Zarządzanie problemami i ryzykiem

• Problem

• Problem

• Przeszkody

• Problem
• Ryzyko
• Wykonaj przegląd

---

Uwagi:

1. Dodaj elementy robocze z listy prac produktu lub tablicy Kanban. Lista prac produktu przedstawia pojedynczy widok bieżącej listy prac, które mogą być dynamicznie zmieniane i pogrupowane. Właściciele produktów mogą szybko określić priorytety pracy i konspektu zależności i relacji. Ponadto każdy zespół może skonfigurować sposób wyświetlania usterek na listach prac i tablicach.
2. Zdefiniuj hierarchię list prac portfela, aby zrozumieć zakres pracy w kilku zespołach i zobaczyć, jak działa to rolować w szerszych inicjatywach. Każdy zespół konfiguruje listy prac portfela wyświetlane do użytku.
3. Zdefiniuj zadania z listy prac przebiegu i tablicy zadań. Dzięki planowaniu pojemności zespoły mogą szybko określić, czy są nadmierne lub niedostatki przebiegu.

Stany, przejścia i przyczyny przepływu pracy

Stany przepływu pracy obsługują śledzenie stanu pracy w miarę jego przejścia ze New stanu do Closed stanu lub Done . Każdy przepływ pracy składa się z zestawu stanów, prawidłowych przejść między stanami i przyczyn przejścia elementu roboczego do wybranego stanu.

Ważne

W przypadku usług Azure DevOps Services i Azure DevOps Server 2019 domyślne przejścia przepływu pracy obsługują dowolny stan do dowolnego przejścia stanu. Dostosuj te przepływy pracy, aby ograniczyć niektóre przejścia. Aby uzyskać więcej informacji, zobacz Dostosowywanie obiektów śledzenia pracy w celu obsługi procesów zespołu.

Ponadto wyświetl obsługiwane przejścia przepływu pracy dla każdego typu elementu roboczego, instalując rozszerzenie State Model Visualization Marketplace. To rozszerzenie dodaje nowe centrum w obszarze Tablice z etykietą State Visualizer. Na tej stronie wybierz typ elementu roboczego i wyświetl model stanu przepływu pracy.

Na poniższych diagramach przedstawiono typowy postęp tych typów elementów roboczych używanych do śledzenia wad pracy i kodu dla trzech procesów domyślnych. Pokazują one również niektóre regresje do byłych stanów i przejść do usuniętych stanów. Każdy obraz przedstawia tylko przyczynę domyślną skojarzą z przejściem.

Proces Agile

Historia użytkownika

Funkcja

Epik

Usterka

Zadanie

Proces podstawowy

Uwaga

Proces podstawowy jest dostępny podczas tworzenia nowego projektu z usług Azure DevOps Services lub Azure DevOps Server 2019.1. W przypadku wcześniejszych wdrożeń lokalnych wybierz proces Agile, Scrum lub CMMI.

Hierarchia epików, problemów i zadań

Przepływ pracy epików, problemów i zadań

Proces Scrum

Element listy prac produktu

Funkcja

Epik

Usterka

Zadanie

Proces CMMI

Wymaganie

Funkcja

Epik

Usterka

Zadanie

Większość typów elementów roboczych używanych przez narzędzia Agile, tych, które pojawiają się na listach prac i tablicach, obsługują przejścia typu dowolna-dowolna. Zaktualizuj stan elementu roboczego przy użyciu tablicy Kanban lub tablicy zadań, przeciągając go do odpowiedniej kolumny stanu.

Zmień przepływ pracy, aby obsługiwał inne stany, przejścia i przyczyny. Aby uzyskać więcej informacji, zobacz Dostosowywanie środowiska śledzenia pracy.

Stany elementów roboczych

Po zmianie stanu elementu roboczego na Removed, Closedlub Donesystem odpowiada w następujący sposób:

• Closed/Done: Elementy robocze w tym stanie nie są wyświetlane na stronach listy prac i listy prac portfela. Są one wyświetlane na stronach listy prac przebiegu, tablicy Kanban i tablicy zadań. Ponadto po zmianie widoku listy prac portfela na Pokaż elementy listy prac, na przykład w celu wyświetlenia funkcji elementów listy prac produktu, elementów roboczych w Closed stanie i Done .
• Removed: Elementy robocze w tym stanie nie są wyświetlane na żadnej liście prac ani tablicy.

Projekt obsługuje elementy robocze, o ile projekt jest aktywny. Nawet jeśli ustawisz elementy robocze na Closed, Donelub Removed, magazyn danych przechowuje rekord. Użyj rekordu do tworzenia zapytań lub raportów.

Uwaga

Ukończone lub zamknięte elementy robocze nie są wyświetlane na listach prac i tablicach po zmianie wartości daty jest większa niż 183 dni (około pół roku). Nadal możesz wyświetlić te elementy przy użyciu zapytania. Jeśli chcesz, aby były wyświetlane na liście prac lub tablicy, możesz wprowadzić drobne zmiany w nich, co spowoduje zresetowanie zegara.

Jeśli chcesz trwale usunąć elementy robocze, zobacz Usuwanie lub usuwanie elementów roboczych.

Typy elementów roboczych dodane do wszystkich procesów

Następujące typy elementów roboczych są dodawane do wszystkich procesów z wyjątkiem procesu podstawowego.

Twój zespół może tworzyć i pracować z tymi typami przy użyciu odpowiedniego narzędzia.

Narzędzie	Typy elementów roboczych
Microsoft Test Manager	Test Plan, , Test Suite, , Test Case Shared StepsShared Parameters
Żądanie opinii	Feedback Request, Feedback Response
Moja praca (z programu Team Explorer), przegląd kodu	Code Review Request, Code Review Response

Elementy robocze z tych definicji typów nie mają być tworzone ręcznie, a następnie dodawane do Hidden Types kategorii. Typy elementów roboczych dodane do Hidden Types kategorii nie są wyświetlane w menu, które tworzą nowe elementy robocze.

Typy elementów roboczych, które obsługują środowisko testowania

Typy elementów roboczych, które obsługują środowisko testowania i współpracują z menedżerem testów i portalem internetowym, są połączone ze sobą przy użyciu typów linków przedstawionych na poniższej ilustracji.

W portalu internetowym lub programie Microsoft Test Manager sprawdź, które przypadki testowe są zdefiniowane dla zestawu testów i wyświetl, które zestawy testów są zdefiniowane dla planu testu. Te obiekty nie są jednak połączone ze sobą za pośrednictwem typów łączy. Dostosuj te typy elementów roboczych tak, jak w przypadku innych typów elementów roboczych. Aby uzyskać więcej informacji, zobacz Dostosowywanie obiektów śledzenia pracy w celu obsługi procesów zespołu.

Jeśli zmienisz przepływ pracy dla planu testów i zestawu testów, może być konieczne zaktualizowanie konfiguracji procesu zgodnie z opisem w tym miejscu. Aby zapoznać się z definicjami każdego pola testowego, zobacz Query based on build and test integration fields (Wykonywanie zapytań na podstawie pól integracji kompilacji i testowania).

Powiązane artykuły

• Dostosowywanie środowiska śledzenia pracy
• Przekazywanie i pobieranie szablonów procesów