Rozwiązywanie problemów z zmienianiem kolejności i zagnieżdżaniem
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Gdy zmieniasz kolejność, zagnieżdżasz i wyświetlasz elementy robocze, usługa Azure Boards 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 elementy tego samego typu, 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 elementu roboczego lub kategorii, lub rozważ zmianę typu łącza na Powiązane.
Odśwież listę prac.
Te kroki powinny 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. Wyszukaj link, który 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, które są w toku, mogą zniknąć podczas odświeżenia
Może zostać wyświetlony błąd podobny do następującego komunikatu:
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.
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 zarządzaniem zespołami, zobacz Korzystanie z wybranych funkcji z udostępnionymi ścieżkami obszaru.
- Aby zmienić kolejność elementów roboczych na zaległościach, posiadaj co najmniej dostęp podstawowy. 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 mapować na funkcje. To mapowanie tworzy łącza nadrzędno-podrzędne w tle. Aby uzyskać więcej informacji, zobacz Organizowanie listy prac.
Nie:
- Utwórz hierarchię elementów roboczych, zadań i usterek.
- Ustanów hierarchie w tej samej kategorii, takie jak powiązania nadrzędno-podrzędne między elementami roboczymi tego samego typu. Na przykład utwórz linki „story-story”, „bug-bug”, „task-task” lub „issue-issue”. Środowiska listy prac, tablic i przebiegów nie obsługują zmiany kolejności w hierarchii w ramach tej samej kategorii, ponieważ takie podejście wprowadza zamieszanie, próbując uporządkować element roboczy, który nie pasuje na tym poziomie.
Śledzenie usterek jako wymagań lub zadań
Każdy zespół ma elastyczność w decydowaniu o śledzeniu usterek jako wymogów, zadań albo żadnego z nich. Zapoznaj się z następującymi wskazówkami:
Jeśli traktujesz usterki jako wymagania: Zagnieżdżaj je tylko na poziomie funkcji.
Jeśli śledzisz usterki jako zadania: umieszczaj je tylko na poziomie wymagań.
Aby uzyskać więcej informacji, zobacz Pokaż błędy na listach zaległości i tablicach.
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ń. Podczas tworzenia linków nadrzędny-podrzędny między wymaganiem a usterką oraz między usterką a zadaniem, jak pokazano tutaj, zadanie pojawia się na backlogu sprintu i tablicy zadań, podczas gdy usterka nie.
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.