Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Azure Boards oferuje kilka procesów zarządzania elementami roboczymi. Wybranie odpowiedniego procesu pomaga zoptymalizować przepływ pracy projektu i ustawić zespół w celu osiągnięcia sukcesu. W tym artykule opisano procesy dostępne w Azure Boards i ułatwiają wybór tego, który pasuje do 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.
| Term | Description |
|---|---|
| Model przetwarzania | 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. |
| Process | 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ą edytora wizualizacji w portalu internetowym Azure DevOps. |
| 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 modelem Hosted XML i On-premises XML. Projekty można dostosować, modyfikując i importując pliki definicji XML szablonu procesu. |
Domyślne typy procesów to Podstawowa, Agile, Integracja modelu dojrzałości możliwości (CMMI) i Scrum. Obiekty śledzenia pracy w domyślnych procesach i szablonach procesów są takie same. Ten artykuł zawiera podsumowanie.
Tip
Za pomocą usługi Azure DevOps Server możesz wybrać model procesów dziedziczony lub lokalny model procesu XML. Aby uzyskać więcej informacji, zobacz Wybieranie modelu procesu dla kolekcji projektów. Aby uzyskać dostęp do najnowszych wersji domyślnych procesów lub szablonów procesów:
Model procesu dziedziczonego: otwórz stronę Procesy . Aby uzyskać więcej informacji, zobacz Zarządzanie procesami.
Lokalny model procesu XML:
- Zainstaluj lub uaktualnij do najnowszej wersji usługi Azure DevOps Server.
- Pobierz spakowany plik szablonu przy użyciu Menedżera szablonów procesu. Użyj wersji programu Visual Studio na tym samym poziomie wersji co usługa Azure DevOps Server. Najnowszą wersję programu Visual Studio Community można zainstalować bezpłatnie.
- Uzyskaj dostęp do najnowszych domyślnych szablonów procesów zainstalowanych na serwerze Azure DevOps Server, na przykład:
%programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033. Opisy poszczególnych plików i folderów można znaleźć w temacie Omówienie plików szablonów procesu.
Domyślne procesy
Domyślne procesy różnią się głównie typami elementów roboczych, które zapewniają planowanie i śledzenie pracy. Skorzystaj z następującego przewodnika, aby wybrać proces pasujący do twojego zespołu:
- Wybierz Podstawowe, aby korzystać z najprostszego sposobu pracy — śledź pracę w postaci epików, zgłoszeń i zadań.
- Wybierz metodę Agile , jeśli twój zespół korzysta z metod Agile i chcesz śledzić scenariusze użytkowników z oddzielnymi działaniami programistycznymi i testowymi.
- Wybierz Scrum, jeśli twój zespół pracuje zgodnie z metodyką Scrum i śledzi elementy rejestru produktu oraz błędy.
- Wybierz pozycję CMMI , jeśli twój zespół potrzebuje formalnego zarządzania zmianami, rekordu z możliwością inspekcji decyzji oraz śledzenia wymagań, żądań zmian, czynników ryzyka i przeglądów.
Wybieranie odpowiedniego procesu
Jeśli nie masz pewności, który proces pasuje do twojego zespołu, użyj następujących scenariuszy jako punktu wyjścia:
Określanie procesu projektu
Aby dowiedzieć się, którego procesu używa projekt:
- Zaloguj się do projektu Azure DevOps.
- Wybierz Ustawienia projektu>Proces.
Nazwa procesu jest wyświetlana w górnej części strony (na przykład Agile, Scrum, Basic lub CMMI).
Aby uzyskać więcej informacji, zobacz Zarządzanie projektami.
Wybieranie odpowiedniego procesu
Jeśli nie masz pewności, który proces pasuje do twojego zespołu, użyj następujących scenariuszy jako punktu wyjścia:
| Scenariusz | Zalecany proces | Dlaczego |
|---|---|---|
| Dopiero zaczynasz pracę z Azure Boards lub chcesz najprostszego sposobu śledzenia. | Basic | Trzy typy elementów roboczych (Epik, Problem, Zadanie) i prosty To Do / Doing / Done przepływ pracy. |
| Twój zespół stosuje metodykę Agile, śledzi historyjki użytkownika i oddziela prace programistyczne od testowych. | Agile | Historie użytkownika z oddzielnym śledzeniem błędów; bogatsze stany (New, Active, Resolved, Closed, Removed). |
| Twój zespół stosuje metodykę Scrum ze sprintami, pozycjami backlogu produktu i blokadami. | Scrum | Elementy rejestru produktu i usterki na tablicy; stany Approved i Committed odpowiadają bezpośrednio wydarzeniom Scrum. |
| Pracujesz w środowisku regulowanym, które wymaga formalnej kontroli zmian, audytowalnego rejestru decyzji oraz śledzenia ryzyka i przeglądów. | CMMI | Dodaje typy elementów roboczych Wymaganie, Żądanie zmiany, Ryzyko i Przegląd oraz obsługuje formalne działania związane z zarządzaniem zmianami. |
Important
Nie można zmienić procesu podstawowego projektu po utworzeniu projektu. Możesz dostosować dziedziczony proces , aby dodać pola, stany i typy elementów roboczych lub utworzyć nowy projekt w innym procesie i przenieść elementy robocze między projektami.
Note
Wybranie lub dostosowanie procesu wymaga członkostwa w grupie Project Collection Administrators. Aby uzyskać więcej informacji, zobacz Szybkie informacje o uprawnieniach domyślnych.
| Process | Hierarchia elementów roboczych |
|---|---|
|
Basic 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 wspierają śledzenie pozostałej pracy. |
|
|
Agile 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 historii użytkownika oraz opcjonalnie usterek na tablicy. Możesz również śledzić usterki i zadania na tablicy zadań. Aby uzyskać więcej informacji na temat metodologii Agile, zobacz Agile Alliance. Zadania umożliwiają śledzenie oryginalnego oszacowania, pozostałej pracy oraz ukończonej pracy. |
|
|
Scrum Wybierz scrum, gdy twój zespół praktykuje Scrum . Ten proces doskonale sprawdza się w przypadku monitorowania elementów backlogu produktu i usterek na tablicy. Możesz również podzielić elementy rejestru produktu i usterki na zadania na tablicy projektów zadań. Ten proces obsługuje metodologię Scrum zdefiniowaną przez organizację Scrum. Zadania obsługują śledzenie tylko pozostałej pracy. |
|
|
CMMI Wybierz CMMI, gdy zespół przestrzega bardziej formalnych metod projektowych, które wymagają struktury w celu ulepszania procesów i audytowalnej dokumentacji 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 umożliwiają śledzenie oryginalnego oszacowania, pozostałej pracy oraz ukończonej pracy. |
|
Jeśli potrzebujesz więcej niż dwóch lub trzech poziomów backlogu, dodaj więcej w oparciu o model procesu, który stosujesz.
- 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 spełniają 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 | Basic | Agile | Scrum | CMMI |
|---|---|---|---|---|
| Stany przepływu pracy | - Do zrobienia - Wykonywanie - Gotowe |
- Nowy -Aktywny - Rozwiązane - Zamknięte -Usunięte |
- Nowy -Zatwierdzone -Popełnione - Gotowe -Usunięte |
- Proponowane -Aktywny - Rozwiązane - Zamknięte |
| Planowanie produktu (patrz Uwaga 1) | -Problem | — Historia użytkownika - Usterka (opcjonalnie) |
- Element rejestru produktu - Usterka (opcjonalnie) |
-Wymaganie - Usterka (opcjonalnie) |
| Rejestry zadań portfela (zobacz uwagę 2) | -Epiczny | -Epiczny -Cecha |
-Epiczny -Cecha |
-Epiczny -Cecha |
| Planowanie zadań i sprintów (patrz Uwaga 3) | -Zadanie | -Zadanie - Usterka (opcjonalnie) |
-Zadanie - Usterka (opcjonalnie) |
-Zadanie - Usterka (opcjonalnie) |
| Zarządzanie zaległościami błędów (patrz Uwaga 1) | -Problem | -Pluskwa | -Pluskwa | -Pluskwa |
| Zarządzanie problemami i ryzykiem | -Problem | -Problem | -Przeszkoda | - Żądanie zmiany -Problem -Ryzyko -Recenzja |
Note
- Dodaj elementy robocze z rejestru produktu lub tablicy. Backlog produktu pokazuje jeden widok bieżącej listy zadań, którą można dynamicznie porządkować i grupować. Właściciele produktów mogą określić priorytety pracy oraz zależności i relacje. Każdy zespół może skonfigurować sposób wyświetlania usterek na listach prac i tablicach.
- Zdefiniuj hierarchię zaległości portfela, aby zrozumieć zakres pracy w kilku zespołach i zobaczyć, jak ta praca integruje się w szersze inicjatywy. Każdy zespół konfiguruje, które listy zaległości portfela są wyświetlane do ich użytku.
- Zdefiniuj zadania z sprint backlog i tablicy zadań. W przypadku planowania pojemności zespoły mogą określić, czy są one przeciążone, czy mają nadmiar zasobów na sprint.
Stany, przejścia i przyczyny przepływu pracy
Stany przepływu pracy obsługują śledzenie stanu pracy w miarę przejścia ze New stanu do Closed stanu lub Done stanu. 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.
Important
Przejścia przepływu pracy: Domyślne przepływy pracy w Azure DevOps obsługują przejścia typu dowolny stan do dowolnego stanu. Możesz dostosować te przepływy pracy, aby ograniczyć określone przejścia na podstawie wymagań twojego zespołu. Aby uzyskać więcej informacji, zobacz Dostosowywanie swojego doświadczenia śledzenia pracy.
Wizualizowanie przepływów pracy: Aby wyświetlić obsługiwane przejścia przepływu pracy dla każdego typu elementu roboczego, zainstaluj rozszerzenie State Model Visualization Marketplace. To rozszerzenie dodaje centrum State Visualizer w obszarze Tablice , gdzie można wybrać typ elementu roboczego i wyświetlić jego kompletny 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 domyślną przyczynę związaną z przejściem.
Historia użytkownika
Feature
Epic
Bug
Task
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 lub tablicy zadań. Przeciągnij element roboczy do odpowiedniej kolumny stanu.
Zmień przepływ pracy, aby obsługiwał inne stany, przejścia i przyczyny. Aby uzyskać więcej informacji, zobacz Dostosowywanie swojego doświadczenia śledzenia pracy.
Jak zachowują się stany Usunięte, Zamknięte i Gotowe na listach prac
Po zmianie stanu elementu roboczego na Removed, Closedlub Donesystem odpowiada w następujący sposób:
-
ClosedlubDone: Elementy pracy w tym stanie nie są wyświetlane na stronach rejestru portfela ani rejestru prac, ale są wyświetlane na stronach rejestru sprintu, na tablicy i tablicy zadań. Po zmianie widoku listy prac portfela na Pokaż elementy listy prac — na przykład aby wyświetlić funkcje obok elementów listy prac produktu — elementy robocze w stanachClosediDonerównież są wyświetlane. -
Removed: Elementy robocze w tym stanie nie są wyświetlane na żadnej liście prac ani tablicy.
Note
Domyślny przepływ pracy CMMI nie zawiera stanu Removed. Aby zabrać element roboczy CMMI z aktywnego śledzenia, ustaw jego stan na Closed i wybierz odpowiedni powód (na przykład Odroczone lub Odrzucone). Możesz dostosować dziedziczony proces, aby dodać Removed stan, jeśli Twój zespół tego potrzebuje.
Projekt utrzymuje elementy robocze, dopóki projekt jest aktywny. Nawet jeśli ustawisz elementy robocze na Closed, Donelub Removed, magazyn danych przechowuje rekord. Tego rekordu można użyć do tworzenia zapytań lub raportów.
Note
- Rejestry i tablice ukrywają ukończone lub zamknięte elementy robocze, gdy ich Data zmiany jest starsza niż 183 dni (około sześciu miesięcy).
- Znajdź ukryte elementy, uruchamiając zapytanie.
- Ponownie wyświetl element na liście prac lub tablicy, wprowadzając niewielką aktualizację, aby odświeżyć jego Datę zmiany.
Note
- Rejestry i tablice ukrywają ukończone lub zamknięte elementy robocze, jeśli ich Data zmiany jest wcześniejsza niż rok temu.
- Znajdź ukryte elementy, uruchamiając zapytanie.
- Ponownie wyświetl element na liście prac lub tablicy, wprowadzając niewielką aktualizację, aby odświeżyć jego Datę zmiany.
Jeśli chcesz trwale usunąć elementy robocze, zobacz Usuń lub trwale usuń elementy robocze.
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. Te typy elementów roboczych pozostają w schemacie pod kątem zgodności historycznej. Microsoft Test Manager i środowisko Moja praca w Team Explorer to starsze narzędzia, które zostały w dużej mierze zastąpione przez portal internetowy.
| Tool | Typy elementów roboczych |
|---|---|
| Microsoft Test Manager (starsza wersja) |
Test Plan, , Test Suite, , Test Case Shared StepsShared Parameters |
| Żądanie opinii |
Feedback Request, Feedback Response |
| Moja praca (ze starszej wersji programu Team Explorer), przegląd kodu |
Code Review Request, Code Review Response |
Nie można ręcznie tworzyć elementów roboczych z tych definicji typów. Są one 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 linków pokazane na poniższej ilustracji łączą typy elementów roboczych, które obsługują środowisko testowe i współpracują z menedżerem testów i portalem internetowym.
Z poziomu portalu internetowego lub Microsoft Menedżera testów można wyświetlić przypadki testowe zdefiniowane dla zestawu testów i wyświetlić zestawy testów 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 swojego doświadczenia śledzenia pracy.
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 artykule. Aby uzyskać definicje każdego pola testowego, zobacz Tworzenie zapytania na podstawie pól integracji kompilacji i testowania.