Konfigurowanie list prac i tablic projektu w usłudze Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
W większości przypadków można rozpocząć korzystanie z list prac produktu i portfela po utworzeniu projektu. Domyślny zespół jest tworzony wraz ze skojarzonymi listami prac i tablicami. Możesz rozpocząć dodawanie elementów roboczych do listy prac produktu przy użyciu listy prac lub tablicy.
Może jednak być konieczne upewnienie się, że listy prac i tablice zostały prawidłowo skonfigurowane. Upewnij się, że konfiguracja została dodana przez zespół i chcesz rozpocząć korzystanie z list prac zespołu i tablic. Zmiany mogą zostać wprowadzone w konfiguracji projektu lub zespołu w czasie. Te zmiany mogą mieć wpływ na elementy robocze wyświetlane na liście prac i tablicach.
Aby zapoznać się z omówieniem narzędzi skojarzonych z zespołem, zobacz Zarządzanie i konfigurowanie narzędzi zespołu.
Domyślne elementy robocze listy prac i tablicy
Pierwszą rzeczą, którą musisz zrozumieć, jest to, że na liście prac produktu i tablicy są wyświetlane elementy robocze spełniające następujące kryteria:
- Typ elementu roboczego należy do kategorii Wymagania. Typy różnią się w zależności od procesu wybranego dla projektu:
- Podstawowa: Problem, Nazwa listy prac=Problemy
- Agile: historia użytkownika, nazwa listy prac=Historie
- Scrum: element listy prac produktu, nazwa listy prac=elementy listy prac
- CMMI: Wymaganie, Nazwa listy prac=Wymagania
- Ścieżka obszaru elementu roboczego jest zgodna z jedną z wybranych ścieżek obszaru zespołu
- Ścieżka iteracji elementu roboczego znajduje się pod domyślną ścieżką iteracji zespołu
Uwaga
Proces podstawowy jest dostępny podczas dodawania projektu do usług Azure DevOps Services lub Azure DevOps Server 2019 Update 1. W przypadku wcześniejszych wdrożeń lokalnych wybierz pozycję Agile, Scrum lub PROCES CMMI.
Możesz określić typy elementów roboczych, które należą do kategorii Wymagania. Określ elementy, otwierając listę prac produktu i sprawdzając nazwę listy prac produktu.
Wyszukaj ścieżki obszaru zespołu i ścieżki iteracji. Aby uzyskać więcej informacji, zobacz Definiowanie ścieżek obszaru i przypisywanie do zespołu oraz Definiowanie ścieżek przebiegu i konfigurowanie iteracji zespołu.
Domyślna lista prac przebiegu i elementy robocze tablicy zadań
Lista prac przebiegu i Tablica zadań stosują filtry skojarzone z domyślną listą prac zespołu i elementami roboczymi tablicy wraz z wybraną ścieżką iteracji.
Możesz wybrać tylko ścieżki iteracji, które zostały wstępnie wybrane przez zespół.
Lista prac przebiegu zawiera tylko te elementy robocze przypisane do wybranego przebiegu. Podrzędne zadania przypisane do innych przebiegów nie są wyświetlane.
Przejrzyj listę kontrolną elementów roboczych, list prac i tablic
Jeśli nie widzisz elementów roboczych, których oczekujesz na tablicy Listy prac produktu lub Kanban, wykonaj następujące testy:
Upewnij się, że wybrano listę prac zespołu lub tablicę zainteresowań. Aby dowiedzieć się, jak to zrobić, zobacz Używanie stron nadrzędnych i selektorów, aby przejść do artefaktów i otworzyć je.
Utwórz zapytanie dotyczące elementów listy prac, określając typy elementów roboczych należących do kategorii Wymagania i Ścieżkę obszaru skojarzona z zespołem, na przykład:
Dodaj pola Stan, Ścieżka obszaru i Ścieżka iteracji do opcji kolumny.
Sprawdź wyniki zapytania i sprawdź, czy wartości elementów roboczych, które mają być wyświetlane na liście prac, spełniają następujące kryteria:
- Ścieżka obszaru należy do ścieżek obszaru twojego zespołu
- Ścieżka iteracji należy do domyślnej ścieżki iteracji zespołu
- Stan nie jest zamknięty, ukończony, gotowy lub usunięty.
Uwaga
Listę prac produktu można również filtrować, aby pokazać lub ukryć elementy robocze znajdujące się w kategorii stanu W toku odpowiadającej stanowi Aktywne, Rozwiązane, Zatwierdzone, Robi przepływ pracy.
Dodawanie usterek do list prac i tablic
W przypadku wszystkich procesów z wyjątkiem procesu podstawowego każdy zespół zarządza sposobem śledzenia usterek. Śledź usterki w kategorii Wymagania, ponieważ są one wyświetlane na tablicy Listy prac i Kanban lub w kategorii Zadania. Mogą również pojawić się na tablicy zadań lub kategorii Usterki, w których nie są wyświetlane na listach prac lub tablicach.
Uwaga
Typy elementów roboczych błędów nie są dostępne w procesie podstawowym. Proces podstawowy śledzi błędy jako problemy i jest dostępny podczas tworzenia nowego projektu z usług Azure DevOps Services lub Azure DevOps Server 2019.1 lub nowszych wersji.
Jeśli chcesz, aby usterki były wyświetlane na liście prac i tablicy, wybierz pozycję Usterki są zarządzane z wymaganiami.
Aby uzyskać więcej informacji, zobacz Wyświetlanie usterek na listach prac i tablicach.
Poprawianie konfiguracji tablicy Kanban
Jeśli podczas otwierania tablicy Kanban zostanie wyświetlony następujący błąd, musisz poprawić konfigurację. Głównym powodem tego błędu jest to, że stany przepływu pracy typów elementów roboczych, które zostały dodane do kategorii Wymagania, nie są mapowane na kolumnę.
Wybierz pozycję Popraw teraz, aby otworzyć okno dialogowe Ustawienia. Aby zamapować stany przepływu pracy, zobacz Dodawanie kolumn do tablicy Kanban, Aktualizowanie mapowań kolumny Kanban na stan.
Dostosowywanie elementów listy kontrolnej tablicy Kanban
Listy kontrolne to doskonały sposób tworzenia elementów roboczych, które są automatycznie połączone z linkiem nadrzędny-podrzędny do innego elementu roboczego na tablicy Kanban. Możesz dostosować typy elementów roboczych, które można dodać jako listę kontrolną, otwierając tablicę Ustawienia, wybierając pozycję Adnotacje i włącz typy elementów roboczych, które chcesz wyświetlić na tablicy. Aby uzyskać więcej informacji, zobacz Dostosowywanie kart.
Na przykład w tym miejscu wybraliśmy śledzenie usterek wraz z zadaniami i włączenie zadań, usterek, obiektów GitHub i testów do wyświetlania na listach kontrolnych.
Uwaga
Adnotacje usługi GitHub wymagają usługi Azure DevOps Server 2019 update 1 lub nowszej wersji.
Aby dowiedzieć się więcej o listach kontrolnych, zobacz następujące artykuły:
Dodawanie innych typów elementów roboczych do listy kontrolnej tablicy Kanban
Jeśli dodano typy elementów roboczych do kategorii zadań zgodnie z opisem w sekcji Dodawanie niestandardowych typów elementów roboczych do tablicy zadań w dalszej części tego artykułu, możesz wybrać, czy te typy są wyświetlane na liście kontrolnej na tablicy Kanban produktu. Możesz dokonać tego wyboru, otwierając Ustawienia tablicy, wybierz pozycję Adnotacje i włącz typy elementów roboczych, które mają być wyświetlane na tablicy. Można włączyć maksymalnie pięć adnotacji. Aby uzyskać więcej informacji, zobacz Dostosowywanie kart.
Na przykład w tym miejscu wybraliśmy śledzenie usterek wraz z zadaniami i włączamy pozycje Problem i Bilet oraz Zadanie i Usterka. Aby dowiedzieć się więcej o listach kontrolnych, zobacz Dodawanie zadań lub elementów podrzędnych jako list kontrolnych i Dodawanie, uruchamianie i aktualizowanie testów wbudowanych.
Ukrywanie lub pokazywanie poziomów listy prac
Twój zespół może również ukryć lub pokazać jeden lub więcej poziomów listy prac. Zespoły funkcji często zarządzają elementami listy prac, a zespoły zarządzania zarządzają funkcjami i epikami. W takiej sytuacji można włączyć lub wyłączyć poziom listy prac.
Aby uzyskać więcej informacji, zobacz Wybieranie poziomów nawigacji listy prac dla zespołu.
Dodawanie niestandardowych typów elementów roboczych do list prac i poziomów listy prac portfela
Jeśli chcesz śledzić różne typy elementów roboczych na liście prac produktu, możesz to zrobić, dodając niestandardowe typy elementów roboczych i dodając je do określonego poziomu listy prac.
Możesz również dodać niestandardowe typy elementów roboczych i dodać je do list prac portfela. Możesz dodać maksymalnie pięć list prac portfela.
Na przykład w tym miejscu dodaliśmy typy elementów roboczych inicjatyw, czwartego poziomu i piątego poziomu, aby obsługiwać pięć poziomów listy prac portfela. Dodaliśmy również niestandardowy typ elementu roboczego o nazwie Ticket i dodaliśmy go do listy prac produktu.
Aby uzyskać więcej informacji, zobacz następujące zasoby:
Model procesu dziedziczenia:
- Dodawanie typów elementów roboczych i zarządzanie nimi (proces dziedziczony)
- Dostosowywanie list prac lub tablic (proces dziedziczony)
- Dostosowywanie procesu dziedziczenia
Lokalny model procesu XML:
Dodawanie niestandardowych typów elementów roboczych do tablicy zadań
Aby dodać niestandardowe typy elementów roboczych, które mają być wyświetlane na tablicy zadań przebiegu, wykonaj kroki opisane dalej na podstawie modelu procesu używanego przez projekt.
Uwaga
Możesz włączyć typy elementów roboczych, które dodajesz do listy prac iteracji, aby były wyświetlane jako lista kontrolna na tablicy Kanban produktu. Aby dowiedzieć się, jak to zrobić, zobacz Dostosowywanie elementów listy kontrolnej tablicy Kanban podanych wcześniej w tym artykule.
Śledzenie niestandardowych elementów roboczych przy użyciu modelu odziedziczonego procesu
Jeśli na przykład chcesz śledzić niestandardowy typ elementu roboczego, Bilety wraz z zadaniami i usterkami, wykonaj następujące zadania:
Zdefiniuj niestandardowy typ elementu roboczego Biletu. Zobacz Dodawanie typów elementów roboczych i zarządzanie nimi.
Dodaj typy elementów roboczych Bilet do listy prac iteracji. Aby uzyskać więcej informacji, zobacz Dostosowywanie list prac lub tablic na potrzeby procesu.
Dodawanie istniejących i niestandardowych typów elementów roboczych przy użyciu lokalnego modelu procesów XML
W przypadku wdrożeń lokalnych, które używają lokalnego modelu procesów XML do dostosowywania śledzenia pracy, można dodać istniejące i niestandardowe typy elementów roboczych do sprintu Taskboards. Jeśli na przykład chcesz śledzić problemy (lub przeszkody dla procesu Scrum) i niestandardowy typ elementu roboczego, Bilety, wraz z zadaniami i usterkami, wykonaj następujące zadania:
Zdefiniuj niestandardowy typ elementu roboczego Biletu. Zobacz Dodawanie lub modyfikowanie typu elementu roboczego.
Dodaj typy elementów roboczych Problem i Bilet do kategorii zadań, modyfikując plik XML Kategorii. Aby uzyskać więcej informacji, zobacz Kategorie dokumentacji elementu XML.
Na przykład w tym miejscu dodajemy pole Problem i Bilet do kategorii zadań.
<CATEGORY name="Task Category" refname="Microsoft.TaskCategory"> <DEFAULTWORKITEMTYPE name="Task" /> <WORKITEMTYPE name="Issue" / <WORKITEMTYPE name="Ticket" / </CATEGORY>Upewnij się, że stany przepływu pracy Problem i Bilet są mapowane na stany kategorii. W razie potrzeby zmodyfikuj plik XML ProcessConfiguration, aby dodać problemy i bilety do
TaskBacklogsekcji.Na przykład w tym miejscu są mapowane stany Nowe, Aktywne i Zamknięte dla kategorii zadań.
<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="1000"> <States> <State value="New" type="Proposed" /> <State value="Active" type="InProgress" /> <State value="Closed" type="Complete" /> </States> . . . </TaskBacklog>Aby zweryfikować zmiany, otwórz listę prac przebiegu i upewnij się, że możesz dodać problem lub bilet w taki sam sposób, jak w przypadku dodawania zadania. Zobacz Dodawanie zadań.
Inne czynniki, które mogą mieć wpływ na elementy robocze na listach prac i tablicach
Poniższe ustawienia mogą mieć wpływ na typ i liczbę elementów roboczych wyświetlanych na listach prac i tablicach.
Na tablicy Kanban nowo dodane elementy robocze mogą nie być wyświetlane, jeśli są one umieszczone na stosie poniżej listy prac produktu. Wybierając pozycję Pokaż więcej elementów, możesz spowodować odświeżenie tablicy i wyświetlenie większej liczby elementów roboczych.
Jeśli zagnieżdżone elementy robocze należą do tej samej kategorii, na tablicy Kanban mogą być wyświetlane tylko węzły liścia (w przypadku wersji TFS 2018.1 i starszych). Z tego powodu zalecamy, aby nie zagnieżdżać elementów roboczych tego samego typu elementu roboczego ani należeć do tej samej kategorii. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z zmienianiem kolejności i zagnieżdżaniem, Jak listy prac i tablice wyświetlają elementy hierarchiczne (zagnieżdżone).
Jeśli widok W toku został wyłączony, te elementy robocze, w których rozpoczęto pracę, nie będą wyświetlane na liście prac.
Elementy robocze są wyświetlane w kolejności priorytetu, do której są dodawane lub przenoszone. Ta kolejność lub sekwencja jest zarządzana przez pole Stack Rank (procesy Basic, Agile i CMMI) lub Priorytet listy prac (Scrum). Aby uzyskać więcej informacji, zobacz sekcję Stack rank (Ranga stosu) w temacie Backlogs, portfolios i Agile project management (Zarządzanie projektami Agile).
Każda zaległości może wyświetlać maksymalnie 999 elementów roboczych. Jeśli zaległość przekroczy ten limit, warto rozważyć dodanie zespołu i przeniesienie niektórych elementów roboczych do listy prac innego zespołu.
Listy prac przebiegu pokazują tylko te elementy robocze, które spełniają ścieżkę obszaru zespołu i ścieżkę iteracji zdefiniowaną dla przebiegu.
Model procesu dziedziczenia: jeśli administrator wyłączy lub usunie typ elementu roboczego, nie jest wyświetlany na listach prac i tablicach.
Lokalny model procesu XML: jeśli administrator usunie lub zniszczy typ elementu roboczego, nie pojawia się na listach prac i tablicach.
Powiązane artykuły
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla