Rozwiązywanie problemów z zmienianiem kolejności i zagnieżdżaniem
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
W przypadku zmiany kolejności, zagnieżdżania i wyświetlania elementów roboczych usługa Azure DevOps oczekuje naturalnej hierarchii. Naturalna hierarchia przerywa tworzenie łączy tej samej kategorii lub tego samego typu między elementami roboczymi. Na przykład linki nadrzędne do linków podrzędnych, które są błędem usterki lub scenariuszem użytkownika w scenariuszu użytkownika lub kategorii wymagań do kategorii zadań . Ten artykuł umożliwia rozwiązywanie problemów z komunikatami o błędach podczas dodawania linków, które nie znajdują się w hierarchii naturalnej.
"Nie można zmienić kolejności elementów roboczych, a niektóre elementy robocze mogą nie być wyświetlane"
Może zostać wyświetlony błąd podobny do jednego z następujących komunikatów:
- Nie można zmienić kolejności elementów roboczych, a niektóre elementy robocze mogą nie być wyświetlane
- Nie ma identyfikatorów elementów roboczych
Aby rozwiązać ten błąd, wykonaj następujące czynności:
Otwórz swoją listę prac.
Przejrzyj listę elementów, aby zidentyfikować te same typy, które są zagnieżdżone.
- Przykład nr 1: Na poniższej ilustracji przedstawiono historię użytkownika jako element podrzędny innego scenariusza użytkownika.
- Przykład nr 2: Na poniższej ilustracji przedstawiono usterkę jako element podrzędny historii użytkownika. Gdy lista prac wyświetla scenariusze użytkowników i usterki na tym samym poziomie (kategoria Wymagania), powoduje to zagnieżdżony element, który wyłącza funkcję zamawiania.
Usuń wszystkie łącza nadrzędno-podrzędne, które istnieją wśród zagnieżdżonych elementów tego samego typu lub kategorii elementu roboczego, lub rozważ zmianę typu łącza na "Powiązane".
Odśwież listę prac.
Wykonanie tych kroków powinno rozwiązać ten problem, a komunikat o błędzie nie jest już wyświetlany.
"Nie można zmienić kolejności elementu roboczego, ponieważ jego element nadrzędny znajduje się w tej samej kategorii"
Może zostać wyświetlony błąd podobny do jednego z następujących komunikatów:
- Nie można zmienić kolejności elementów roboczych, a niektóre elementy robocze mogą nie być wyświetlane. Zobacz 7 elementów roboczych, aby usunąć łącze nadrzędne z elementem podrzędnym lub zmienić typ łącza na Powiązane.
- Nie można zmienić kolejności elementu roboczego 3, ponieważ jego element nadrzędny znajduje się w tej samej kategorii.
Aby rozwiązać ten błąd, wykonaj następujące czynności:
- Otwórz element roboczy wymieniony w komunikacie o błędzie.
- Wyszukaj link nadrzędny lub podrzędny. Upewnij się, że ten link przechodzi do elementu roboczego w tej samej kategorii co otwarty element roboczy. Ten link przechodzi do innego elementu roboczego, który jest wyświetlany na tym samym poziomie listy prac co otwarty element roboczy. W zależności od ustawienia zachowania usterki zespołu błędy mogą pojawiać się z wymaganiami lub zadaniami.
- Usuń problem z linkiem nadrzędny-podrzędny. Jeśli chcesz zachować te elementy skojarzone, zamiast tego użyj typu linku "Powiązane".
Komunikat nie jest już wyświetlany.
"Elementy robocze w toku mogą zniknąć podczas odświeżania"
Może zostać wyświetlony błąd podobny do jednego z następujących komunikatów:
Elementy dodane do listy prac mogą zniknąć podczas odświeżania, ponieważ projekt zespołowy oznacza je jako "w toku". Te elementy są wyświetlane po zmianie filtru "W toku" na Pokaż.
Ten komunikat wskazuje, że filtr W toku listy prac jest wyłączony.
Po odświeżeniu przeglądarki elementy robocze będą wyświetlane na podstawie wybranych filtrów. Aby zresetować filtry, wykonaj następujące kroki.
- Otwórz swoją listę prac.
- Z selektora Opcji widoku wybierz, aby pokazać lub ukryć elementy w toku.
- Jeśli wyłączysz kontrolkę W toku, elementy znajdujące się w stanach Aktywne, Zatwierdzone lub Rozwiązane albo stany, które są mapowane na stan kategorii W toku, nie są wyświetlane.
- Ukryj elementy w toku, gdy chcesz prognozować pracę. Aby uzyskać więcej informacji, zobacz Prognozowanie listy prac produktu.
Uwaga
- Aby uzyskać więcej informacji, zobacz Konfigurowanie widoku listy prac i Dodawanie niestandardowych typów elementów roboczych.
- W przypadku problemów, które mogą wystąpić z własnością wielu zespołów, zobacz Konfigurowanie hierarchii zespołów, Ćwiczenie wybierania funkcji z udostępnionymi ścieżkami obszaru.
- Aby zmienić kolejność elementów roboczych na liście prac, musisz mieć dostęp na poziomie podstawowym lub wyższym. Jeśli masz dostęp do uczestników projektu, nie możesz zmienić kolejności elementów roboczych. Aby uzyskać więcej informacji, zobacz Stakeholder access quick reference (Dostęp uczestnika projektu — krótki przewodnik).
Naturalna hierarchia typów elementów roboczych
Na poniższej ilustracji przedstawiono naturalną hierarchię procesów agile, Scrum i Capability Maturity Model Integration (CMMI).
Najlepsze rozwiązania
Część praktyczna:
- Zachowaj płaską listę, a nie zagnieżdżanie wymagań, usterek i zadań.
- Utwórz tylko łącza nadrzędno-podrzędne o jeden poziom głębokości między elementami należącymi do innej kategorii. Kategoria, do którego należy element roboczy, zależy od poziomów procesów i wybranego zachowania usterki twojego zespołu.
- Użyj typu elementu roboczego funkcji , aby grupować scenariusze użytkowników (Agile), problemy (Basic), elementy robocze (Scrum) lub wymagania (CMMI). Elementy robocze można szybko mapować na funkcje, co powoduje utworzenie linków nadrzędny-podrzędnych w tle.
Nie:
- Utwórz hierarchię elementów roboczych, zadań i usterek.
- Ustanów hierarchie tej samej kategorii, takie jak linki nadrzędno-podrzędne między elementami roboczymi tego samego typu (na przykład scenariusz, usterka, usterka, zadanie-zadanie lub problem- problem). Środowiska listy prac, tablic i przebiegów nie obsługują zmiany kolejności dla hierarchii tej samej kategorii, ponieważ wprowadza zamieszanie przez porządkowanie elementu roboczego, który nie należy na tym poziomie.
Śledzenie usterek jako wymagań lub zadań
Każdy zespół ma elastyczność wybierania sposobu śledzenia usterek — niezależnie od tego, czy są to wymagania, zadania, czy też nie. Zapoznaj się z następującymi wskazówkami:
W przypadku śledzenia usterek jako wymagań: zagnieżdżaj je tylko na poziomie funkcji .
W przypadku śledzenia usterek jako zadań: zagnieżdżaj je tylko na poziomie Wymagania .
Wyświetlanie zagnieżdżonych elementów na listach prac i tablicach
Listy prac przebiegu i tablice zadań wyświetlają wyłącznie ostatni węzeł w hierarchii tej samej kategorii, która jest nazywana węzłem liścia.
Listy prac przebiegu i tablice zadań
Gdy zadania i usterki łączą się z wymaganiami nadrzędnymi, grupują je poprawnie na liście prac przebiegu i tablicy zadań. Jednak po ustanowieniu powiązań nadrzędny-podrzędny między wymaganiem i usterką oraz między usterką a zadaniem, jak pokazano tutaj, zadanie pojawia się na liście prac przebiegu i tablicy zadań, podczas gdy usterka nie jest.
Hierarchia elementów przypisanych do listy prac przebiegu
Na listach prac przebiegu są wyświetlane tylko węzły liści
Na tablicach zadań są wyświetlane tylko węzły liści
Często zadawane pytania (FAQ)
.: Czy istnieje obejście umożliwiające wyświetlenie węzłów pośrednich w hierarchii?
Ach: Nie, a nie w tej chwili. Zawsze możesz sprawdzić całą listę elementów przypisanych do przebiegu po wybraniu pozycji Utwórz zapytanie.