Definiowanie, przechwytywanie, klasyfikowanie i zarządzanie usterkami oprogramowania w usłudze Azure Boards

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

Jak śledzić wady w kodzie i zarządzać nimi? Jak upewnić się, że problemy z oprogramowaniem i opinie klientów są szybko rozwiązywane w celu obsługi wdrożeń oprogramowania wysokiej jakości? Jak poczynić dobre postępy w zakresie nowych funkcji i rozwiązać problem z długiem technicznym?

Potrzebujesz co najmniej sposobu na przechwycenie problemów z oprogramowaniem, nadanie im priorytetów, przypisanie ich do członka zespołu i śledzenie postępu. Chcesz zarządzać wadami kodu w sposób zgodny z praktykami Agile.

Aby obsługiwać te scenariusze, usługa Azure Boards udostępnia określony typ elementu roboczego do śledzenia wad kodu o nazwie Usterka. Elementy robocze błędów udostępniają wszystkie standardowe funkcje innych typów elementów roboczych z kilkoma innymi elementami roboczymi. Aby zapoznać się z omówieniem standardowych funkcji, zobacz About work items and work item types (Informacje o elementach roboczych i typach elementów roboczych).

Usterki udostępniają również następujące funkcje:

• Opcje dla każdego zespołu do wyboru sposobu śledzenia usterek
• Testowanie narzędzi do przechwytywania usterek
• Wbudowana integracja w usłudze Azure DevOps w celu śledzenia usterek połączonych z kompilacjami, wydaniami i testami

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.

Wymagania wstępne

• Dostęp do projektu: należy dodać go do projektu.

• Uprawnienia:

  • Wyświetl elementy robocze w tym węźle i Edytuj elementy robocze w tym węźle uprawnienia ustawione na Zezwalaj. Domyślnie grupa Współautorzy ma te uprawnienia. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień śledzenia pracy.

  • Aby dodać nowe tagi do elementów roboczych, mają dostęp podstawowy lub wyższy, a uprawnienie Utwórz nową definicję tagu na wartość Zezwalaj. Domyślnie grupa Współautorzy ma to uprawnienie.

    Uwaga

    Uczestnicy projektu nie mogą dodawać nowych tagów, nawet jeśli uprawnienie jest jawnie ustawione ze względu na ich poziom dostępu. Aby uzyskać więcej informacji, zobacz Stakeholder access quick reference (Dostęp uczestnika projektu — krótki przewodnik).

• Elementy robocze wiadomości e-mail: wszyscy członkowie projektu, w tym członkowie projektu w grupie Czytelnicy , mogą wysyłać wiadomości e-mail zawierające elementy robocze.

Napiwek

Aby zgłosić usterkę, użytkownik musi mieć co najmniej dostęp do uczestników projektu . Użytkownik musi mieć uprawnienie Edytuj elementy robocze w tym węźle ustawionym na wartość Zezwalaj na ścieżkę obszaru, w której dodają usterkę. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień śledzenia pracy

Typ elementu roboczego usterki

Na poniższej ilustracji przedstawiono typ elementu roboczego usterki dla procesu Scrum. Typ elementu roboczego usterki dla procesów integracji modelu agile i możliwości dojrzałości (CMMI, Capability Maturity Model Integration) śledzi podobne informacje. Zostanie on wyświetlony na liście prac produktu wraz z wymaganiami lub na tablicy zadań wraz z zadaniami.

Uwaga

Obrazy widoczne w portalu internetowym mogą różnić się od obrazów widocznych w tym artykule. Te różnice wynikają z aktualizacji wprowadzonych w aplikacji internetowej, opcji, które włączono dla Ciebie lub administratora, i który proces został wybrany podczas tworzenia projektu: Agile, Basic, Scrum lub CMMI. Proces podstawowy jest dostępny w usłudze Azure DevOps Server 2019 Update 1 i nowszych wersjach.

Pola specyficzne dla usterek

Typ elementu roboczego Usterka używa niektórych pól specyficznych dla usterek. Aby przechwycić zarówno początkowy problem, jak i bieżące odkrycia, użyj pól opisanych w poniższej tabeli. Aby uzyskać informacje o polach specyficznych dla usterki zdefiniowanej dla procesu integracji modelu dojrzałości możliwości (CMMI), zobacz Usterki, problemy i informacje o polach ryzyka. Aby uzyskać informacje o wszystkich innych polach, zobacz Indeks pól elementu roboczego.

---

Pole, grupa lub karta

Użycie

---

Kroki odtwarzania (przyjazna nazwa=Kroki odtwarzania)

Służy do przechwytywania wystarczającej ilości informacji, aby inni członkowie zespołu mogli w pełni zrozumieć usterkę kodu. Uwzględnij akcje podjęte w celu znalezienia lub odtworzenia usterki i oczekiwanego zachowania.

---

Informacje osystemie znalezione w kompilacji

Informacje o konfiguracji oprogramowania i systemu, które są istotne dla usterki i testów do zastosowania. Informacje o systemie i Znalezione w polach Kompilacja są automatycznie wypełniane podczas tworzenia usterki za pomocą narzędzia do testowania. Te pola określają informacje o środowisku oprogramowania i kompilują miejsce wystąpienia usterki. Aby uzyskać więcej informacji, zobacz Testowanie różnych konfiguracji.

---

Kryteria akceptacji

Podaj kryteria, które należy spełnić przed zamknięciem usterki. Przed rozpoczęciem pracy opisz kryteria akceptacji klienta tak wyraźnie, jak to możliwe. Zespoły powinny używać tych kryteriów jako podstawy testów akceptacyjnych i oceniać, czy element jest ukończony w sposób zadowalający.

---

Zintegrowane w kompilacji

Określa nazwę kompilacji, która zawiera kod, który naprawia usterkę. To pole powinno zostać określone podczas rozwiązywania błędu.

W przypadku lokalnej usługi Azure DevOps, aby uzyskać dostęp do menu rozwijanego wszystkich kompilacji, które zostały uruchomione, możesz zaktualizować FIELD definicje polecenia Found in Build and Integrated in Build (Kompilacja i zintegrowana w kompilacji ), aby odwoływać się do listy globalnej. Lista globalna jest automatycznie aktualizowana przy użyciu każdej uruchomionej kompilacji. Aby uzyskać więcej informacji, zobacz Query based on build and test integration fields (Wykonywanie zapytań na podstawie pól integracji kompilacji i testowania).

Aby uzyskać informacje o sposobie definiowania numerów kompilacji, zobacz Konfiguracja potoków klasycznych.

---

Priorytet¹

• 1: Produkt wymaga pomyślnego rozwiązania elementu roboczego, zanim zostanie on dostarczany i wkrótce rozwiązany.
• 2: Produkt wymaga pomyślnego rozwiązania elementu roboczego przed jego wysyłką, ale nie musi być natychmiast rozwiązany.
• 3: Rozwiązanie elementu roboczego jest opcjonalne na podstawie zasobów, czasu i ryzyka.

---

Ważność¹

Subiektywna ocena wpływu usterki lub elementu roboczego na projekt lub system oprogramowania. Na przykład: Jeśli link zdalny w interfejsie użytkownika (rzadkie zdarzenie) powoduje awarię aplikacji lub strony internetowej (poważne środowisko klienta), możesz określić ważność = 2 — Wysoki i Priorytet = 3. Dozwolone wartości i sugerowane wytyczne są następujące:

• 1 — Krytyczne: musi naprawić. Usterka powodująca zakończenie co najmniej jednego składnika systemu lub kompletnego systemu lub powoduje rozległe uszkodzenie danych. Nie ma akceptowalnych metod alternatywnych, aby osiągnąć wymagane wyniki.
• 2 — Wysoki: Rozważ poprawkę. Usterka powodująca zakończenie co najmniej jednego składnika systemu lub kompletnego systemu lub powoduje rozległe uszkodzenie danych. Istnieje akceptowalna metoda alternatywna, aby osiągnąć wymagane wyniki.
• 3 — Średni: (ustawienie domyślne) Usterka, która powoduje, że system generuje nieprawidłowe, niekompletne lub niespójne wyniki.
• 4 - Niski: niewielka lub kosmetyczna wada, która ma dopuszczalne obejścia, aby osiągnąć wymagane wyniki.

---

Wdrożenie

Kontrolka Wdrażanie obsługuje linki do i wyświetlanie wydań zawierających elementy robocze. Aby użyć kontrolki, musisz włączyć ustawienia dla wydania. Aby uzyskać więcej informacji, zobacz Łączenie elementów roboczych z wydaniami w dalszej części tego artykułu.

---

Opracowywanie zawartości

Kontrolka Programowanie obsługuje łącza do obiektów deweloperskich i wyświetlanie ich. Te obiekty obejmują zatwierdzenia i żądania ściągnięcia usługi Git lub zestawy zmian kontroli wersji i elementy wersji. Można zdefiniować łącza z elementu roboczego lub zatwierdzeń, żądań ściągnięcia lub innych obiektów programistycznych. Aby uzyskać więcej informacji, zobacz Łączenie elementów roboczych z programowaniem w dalszej części tego artykułu.

---

Uwagi

¹ Aby zmienić wybór menu lub listę wyboru, zobacz Dostosowywanie środowiska śledzenia pracy. Metoda dostosowywania zależy od modelu procesu używanego przez projekt.

Wybieranie sposobu, w jaki zespół śledzi usterki

Twój zespół może śledzić usterki jako wymagania lub zadania podrzędne. Aby wspierać wybór zespołu, należy wziąć pod uwagę następujące czynniki.

• Rozmiar zespołu. Mniejsze zespoły mogą zachować lekki ślad, śledząc usterki jako wymagania.
• Wymagania organizacji dotyczące śledzenia pracy. Jeśli twój zespół jest wymagany do śledzenia godzin, wybierz śledzenie usterek jako zadań.
• Organizacja pracy twojego zespołu. Jeśli twój zespół korzysta z listy prac produktu w celu nadania priorytetów pracy i dodawania usterek, śledź usterki jako wymagania.
• Narzędzia, których zespół chce użyć, takich jak okienko Planowanie, wykres prędkości, prognoza, zestawienie i plany dostarczania. Śledzenie usterek jako zadań uniemożliwia korzystanie z kilku z tych narzędzi.

Poniższa tabela zawiera podsumowanie trzech opcji, które zespoły muszą śledzić usterki. Aby dowiedzieć się więcej i ustawić opcję dla zespołu, zobacz Wyświetlanie usterek na listach prac i tablicach.

---

Opcja

Wybierz, kiedy chcesz...

---

Śledzenie usterek jako wymagań

• Określanie priorytetów lub ranga stosu oraz usterek wraz z wymaganiami
• Szacowanie nakładu pracy nad usterek na potrzeby prognozowania
• Aktualizowanie stanu usterki na pokładzie
• Uwzględnianie usterek na wykresach prędkości i diagramach przepływu skumulowanego
• Możliwość korzystania z narzędzia Prognoza do obsługi planowania przebiegu
• Przeciągnij usterki do okienka Planowanie, aby przypisać usterki do przebiegu
• Wyświetlanie usterek w planach dostarczania

Uwaga

• Usterki są przypisywane do kategorii wymagań

---

Śledzenie usterek jako zadań

• Szacowanie pracy dla usterek podobnych do zadań
• Aktualizowanie stanu usterki na tablicach zadań przebiegu
• Łączenie usterek z wymaganiami jako elementów podrzędnych
• Przeciągnij usterki do okienka Planowanie, aby przypisać usterki do przebiegu

Uwaga

• Usterki są przypisywane do kategorii zadań
• Scenariusze użytkownika (Agile), elementy listy prac produktu (Scrum) lub wymagania (CMMI) są naturalnym nadrzędnym typem elementu roboczego dla usterek
• Usterki nie są widoczne w planach dostarczania

---

Usterki nie są wyświetlane na listach prac lub tablicach

• Zarządzanie usterkami przy użyciu zapytań

Uwaga

• Usterki są skojarzone z kategorią usterek i nie są wyświetlane na listach prac lub tablicach
• Usterki nie są widoczne na listach prac, tablicach, listach prac przebiegu, tablicach, tablicach zadań lub planach dostarczania
• Nie można przeciągać usterek do okienka Planowanie, aby przypisać usterki do przebiegu

---

Dostosowywanie typu elementu roboczego

Możesz dostosować usterkę i inne typy elementów roboczych. Możesz też utworzyć typy niestandardowe w celu śledzenia problemów z oprogramowaniem lub opinii klientów. Dla wszystkich typów elementów roboczych można dostosować następujące elementy:

• Dodawanie lub usuwanie pól niestandardowych
• Dodawanie kontrolek niestandardowych lub kart niestandardowych w formularzu elementu roboczego
• Dostosowywanie stanów przepływu pracy
• Dodawanie reguł warunkowych
• Wybierz poziom listy prac, na którym są wyświetlane elementy robocze

Przed dostosowaniem procesu zalecamy zapoznanie się z artykułem Informacje o konfigurowaniu i dostosowywaniu usługi Azure Boards.

Aby dostosować konkretny proces, zobacz Dostosowywanie procesu dziedziczenia.

Dodawanie lub przechwytywanie usterek

Możesz zdefiniować usterki z kilku różnych narzędzi usługi Azure DevOps. Te narzędzia obejmują listy prac i tablice oraz narzędzia do testowania.

Napiwek

Domyślnie pole Tytuł jest jedynym polem wymaganym podczas tworzenia usterki. Usterki można dodawać w taki sam sposób, jak dodawanie scenariuszy użytkowników lub elementów listy prac produktu przy użyciu usługi Azure Boards. Niektóre pola można wprowadzić, dodając reguły warunkowe na podstawie zmiany stanu. Aby uzyskać więcej informacji, zobacz Dodawanie reguły do typu elementu roboczego.

Dodawanie usterki z listy prac lub tablicy

Jeśli twój zespół zdecydował się zarządzać usterkami z wymaganiami, możesz zdefiniować usterki z listy prac lub tablicy produktu. Aby uzyskać więcej informacji, zobacz Tworzenie listy prac produktu lub Używanie tablicy.

• Dodawanie usterki z listy prac produktu

  

• Dodawanie usterki z tablicy

  

Napiwek

Po dodaniu usterki z listy prac lub tablicy produktu usterka jest automatycznie przypisywana do domyślnej ścieżki obszaru i ścieżki iteracji zdefiniowanej dla zespołu. Aby uzyskać więcej informacji, zobacz Team defaults referenced by backlogs and boards (Domyślne ustawienia zespołu, do których odwołuje się listy prac i tablice).

Dodawanie usterki z listy prac przebiegu lub tablicy zadań

Jeśli twój zespół zdecydował się zarządzać usterkami za pomocą zadań, możesz zdefiniować usterki z tablicy, listy prac produktu, listy prac przebiegu lub tablicy zadań przebiegu. Do elementu roboczego listy prac produktu dodaje się usterkę jako element podrzędny.

• Dodawanie połączonej usterki podrzędnej z listy prac przebiegu

  Dodajesz usterkę w taki sam sposób, jak dodajesz zadanie do listy prac przebiegu. Aby uzyskać więcej informacji, zobacz Dodawanie zadań do elementów listy prac.

  

• Dodawanie połączonej usterki podrzędnej z tablicy

  Dodajesz usterkę w taki sam sposób, jak dodajesz zadanie do elementu listy prac. Aby uzyskać więcej informacji, zobacz Dodawanie zadań lub elementów podrzędnych jako list kontrolnych.

  

Tworzenie usterki na podstawie narzędzia do testowania

Dwa narzędzia do testowania, których można użyć do dodawania usterek podczas testowania, obejmują moduł uruchamiający testy w portalu internetowym oraz rozszerzenie Test & Feedback.

• Moduł uruchamiający testy testowe: podczas uruchamiania testów ręcznych możesz wybrać opcję Utwórz usterkę. Aby uzyskać więcej informacji, zobacz Uruchamianie testów ręcznych.

  

• Rozszerzenie Testuj i opinie: podczas uruchamiania testów eksploracyjnych możesz wybrać opcję Utwórz usterkę lub Utwórz zadanie. Aby uzyskać więcej informacji, zobacz Testowanie eksploracyjne z rozszerzeniem Test & Feedback.

  

Cykl życia usterki i stany przepływu pracy

Podobnie jak w przypadku wszystkich innych typów elementów roboczych, typ elementu roboczego usterki ma dobrze zdefiniowany przepływ pracy. Każdy przepływ pracy składa się z co najmniej trzech stanów i przyczyny. Powody określają, dlaczego element przeszedł z jednego stanu na inny. Na poniższych obrazach przedstawiono domyślny przepływ pracy błędów zdefiniowany dla procesów Agile, Scrum i CMMI .

Zwinność	Scrum	CMMI

W przypadku usterek scrum zmienisz stan z Zatwierdzone (podobne do aktywne) na Gotowe. W przypadku funkcji Agile i CMMI należy najpierw usunąć usterkę i wybrać przyczynę, która wskazuje, że usterka została usunięta. Zazwyczaj osoba, która utworzyła usterkę, weryfikuje poprawkę i aktualizuje stan z Rozwiązane na Zamknięte. Jeśli znajdziesz więcej pracy po rozwiązaniu lub zamknięciu usterki, aktywuj ją ponownie, ustawiając stan na Zatwierdzone lub Aktywne.

Uwaga

Typ elementu roboczego procesu Agile miał wcześniej regułę, która ponownie przypisała usterkę do osoby, która ją utworzyła. Ta reguła została usunięta z domyślnego procesu systemowego. Tę automatyzację można przywrócić, dodając regułę. W przypadku procesu dziedziczenia zobacz Automatyzowanie ponownego przypisania na podstawie zmiany stanu.

Weryfikowanie poprawki

Aby zweryfikować poprawkę, deweloper lub tester próbuje odtworzyć usterkę i wyszukać bardziej nieoczekiwane zachowanie. W razie potrzeby należy ponownie uaktywnić usterkę.

Podczas weryfikowania poprawki usterek może się okazać, że usterka nie została usunięta lub nie zgadzasz się z rozwiązaniem. W takim przypadku omówimy usterkę z osobą, która ją rozwiązała, doszli do porozumienia i ewentualnie ponownie uaktywnią usterkę. Jeśli ponownie uaktywnisz usterkę, uwzględnij przyczyny ponownego aktywowania usterki w opisie usterki.

Zamykanie usterki

Zamykasz usterkę, gdy członek zespołu weryfikuje ją jako naprawioną. Jednak możesz również zamknąć usterkę z jednego z następujących powodów. Dostępne przyczyny zależą od procesu projektu i stanów przejścia błędów.

Proces Agile:

• Odroczone: odroczenie poprawki błędów do następnego wydania produktu.
• Naprawiono: Usterka została zweryfikowana jako stała.
• Duplikat: Usterka śledzi obecnie zdefiniowaną inną usterkę. Możesz połączyć każdą usterkę z typem linku Duplikuj/Duplikat i zamknąć jedną z usterek.
• Zgodnie z projektem: funkcja działa zgodnie z projektem.
• Nie można odtworzyć: testy dowodzą, że nie można odtworzyć usterki.
• Przestarzałe: funkcja usterki nie znajduje się już w produkcie.
• Skopiowane do listy prac: historia użytkownika została otwarta w celu śledzenia usterki.

Proces scrum:

• Nie usterka: Usterka jest weryfikowana, że nie jest to usterka.
• Duplikat: Usterka śledzi obecnie zdefiniowaną inną usterkę. Możesz połączyć każdą usterkę z typem linku Duplikuj/Duplikat i zamknąć jedną z usterek.
• Usunięto z listy prac: Usterka została zweryfikowana, że nie jest to usterka. Usuń usterkę z listy prac.
• Praca zakończona: Usterka została zweryfikowana jako naprawiona.

Proces CMMI:

• Odroczone: odroczenie poprawki błędów do następnego wydania produktu.
• Duplikat: Usterka śledzi obecnie zdefiniowaną inną usterkę. Możesz połączyć każdą usterkę z typem linku Duplikuj/Duplikat i zamknąć jedną z usterek.
• Odrzucono: Usterka jest weryfikowana, że nie jest to usterka.
• Zweryfikowano: Usterka została zweryfikowana jako stała.

Napiwek

Po zamknięciu usterki i aktywnym wydaniu poprawki we wdrożeniach zaleca się, aby nigdy nie otwierać go ponownie z powodu regresji. Zamiast tego należy rozważyć otwarcie nowej usterki i link do starszej, zamkniętej usterki.

Zawsze dobrym pomysłem jest opisanie kolejnych szczegółów dotyczących zamknięcia usterki w polu Dyskusja, aby uniknąć przyszłych pomyłek co do tego, dlaczego usterka została zamknięta.

Automatyzowanie zamykania usterek podczas scalania żądań ściągnięcia

Jeśli twój zespół korzysta z repozytorium Git, możesz ustawić stan w połączonych usterek i innych elementach roboczych, aby zamknąć pomyślne scalanie żądań ściągnięcia. Aby uzyskać więcej informacji, zobacz Ustawianie stanu elementu roboczego w żądaniu ściągnięcia w dalszej części tego artykułu.

Wyświetlanie listy i klasyfikacji usterek

Większość zespołów, niezależnie od wybranej opcji śledzenia usterek, definiuje co najmniej jedno zapytanie o usterkę. Za pomocą zapytań można wyświetlać aktywne usterki, nieprzypisane usterki, nieaktualne usterki, trendy błędów i nie tylko. Możesz dodawać zapytania i wykresy zapytań do pulpitów nawigacyjnych zespołu, aby monitorować stan błędów i postęp.

Zapytania o błędy

Otwórz udostępnione zapytanie lub użyj edytora zapytań, aby utworzyć przydatne zapytania o usterki, takie jak następujące opcje:

• Aktywne usterki według priorytetu (State <> Done lub State <> Closed)
• W toku usterki (State = Committed lub State = Active)
• Usterki w celu naprawienia wersji docelowej (Tags Contains RTM)
• Ostatnie usterki, takie jak usterki otwarte w ciągu ostatnich trzech tygodni (Created Date > @Today-21)

Jeśli masz interesujące Cię zapytania dla zespołu, możesz utworzyć wykresy stanu lub trendu. Możesz również dodać utworzony wykres do pulpitu nawigacyjnego.

Tryb klasyfikacji w wynikach zapytania

Po rozpoczęciu kodowania i testowania organizuj okresowe spotkania klasyfikacji, aby przejrzeć i sklasyfikować usterki. Zazwyczaj właściciel projektu uruchamia spotkania klasyfikacji błędów. Liderzy zespołu, analitycy biznesowi i inni uczestnicy projektu, którzy mogą mówić o konkretnym ryzyku projektu, uczestniczą w spotkaniach klasyfikacji.

Właściciel projektu może zdefiniować udostępnione zapytanie dla nowych i ponownie otwartych usterek, aby wyświetlić listę usterek do klasyfikacji.

Na stronie wyników zapytania możesz przejść w górę i w dół na liście elementów roboczych błędów przy użyciu strzałek w górę i w dół. Podczas przeglądania każdej usterki możesz przypisać ją, dodać szczegóły lub ustawić priorytet.

Organizowanie i przypisywanie usterek do przebiegu

Jeśli zespół śledzi błędy jako wymagania, wyświetl listę aktywnych usterek z listy prac. Dzięki funkcji filter można skoncentrować się wyłącznie na błędach. Z listy prac produktu można również wykonać następujące zadania:

• Organizowanie usterek na liście prac. Ranga stosu względem innych elementów. Klasyfikacja stosu jest wyłączona podczas włączania filtrowania.
• Przypisz usterki do przebiegu z listy prac przy użyciu okienka Planowanie .
• Mapuj usterki nadrzędne na funkcje lub inne elementy listy prac portfela przy użyciu okienka Mapowanie .
• Wyświetl zestawienie pracy dla elementów listy prac portfela.

Jeśli zespół śledzi błędy jako zadania, użyj zarządzanych zapytań, aby wyświetlić listę i klasyfikację usterek. W każdym przebiegu zobaczysz usterki przypisane do przebiegu z listy prac przebiegu lub tablicy zadań.

Elementy tablicy zadań a elementy listy zapytań

Możesz zauważyć i zastanawiać się, dlaczego elementy wyświetlane na tablicy zadań przebiegu mogą się różnić od listy zapytań utworzonej na odpowiedniej liście prac przebiegu.

Można przypisać zadania lub usterki do iteracji, ale nie połączyć ich z nadrzędnym elementem listy prac. Te elementy są wyświetlane w utworzonym zapytaniu, ale mogą nie być wyświetlane na tablicy zadań. System uruchamia zapytanie, a następnie stosuje kilka procesów w tle przed wyświetleniem elementów Tablicy zadań.

Te przyczyny mogą spowodować, że elementy robocze należące do kategorii zadań nie będą wyświetlane na liście prac przebiegu lub na tablicy zadań:

• Zadanie lub usterka nie jest połączona z nadrzędnym elementem listy prac. Tylko usterki i zadania są połączone z nadrzędnym elementem listy prac produktu (Scrum), scenariuszem użytkownika (Agile) lub wymaganiami (CMMI) ze ścieżką iteracji ustawioną na przebieg jest wyświetlany na stronie listy prac przebiegu.
• Zadanie lub usterka jest elementem nadrzędnym innego zadania lub usterki albo historia użytkownika jest elementem nadrzędnym innej historii użytkownika. Jeśli tworzysz hierarchię zadań, usterek lub scenariuszy użytkownika, wyświetlane są tylko zadania na poziomie podrzędnym lub scenariusze na poziomie podrzędnym w dolnej części hierarchii. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z zmienianiem kolejności i zagnieżdżaniem.
• Połączony element nadrzędny zadania lub usterki odpowiada elementowi listy prac zdefiniowanej dla innego zespołu. Lub ścieżka obszaru elementu nadrzędnej listy prac zadania lub usterki różni się od ścieżki obszaru zadania lub usterki.

Tworzenie testów wbudowanych połączonych z usterkami

Gdy zespół śledzi błędy jako wymagania, możesz użyć tablicy, aby dodać testy w celu zweryfikowania poprawek błędów.

Aktualizowanie stanu usterki

Stan usterki można zaktualizować, przeciągając i upuszczając usterki do nowej kolumny na tablicy.

• Jeśli zespół śledzi błędy jako wymagania, użyj tablicy, jak pokazano na poniższej ilustracji. Aby uzyskać więcej informacji, zobacz Aktualizowanie stanu elementu roboczego.

  

• Jeśli zespół śledzi błędy jako zadania, należy użyć tablicy zadań. Aby uzyskać więcej informacji, zobacz Aktualizowanie i monitorowanie tablicy zadań.

  

Dostosowywanie tablicy do śledzenia stanów pośrednich

Możesz dodać kolumny pośrednie, aby śledzić stan usterki na tablicy. Można również zdefiniować zapytania, które filtrują na podstawie stanu kolumny tablicy. Aby uzyskać więcej informacji, zobacz następujące artykuły:

• Dodawanie kolumn do tablicy
• Dostosowywanie tablicy zadań przebiegu
• Wykonywanie zapytań dotyczących zmian w tablicy

Automatyzowanie ponownego przypisania usterki na podstawie stanu przepływu pracy

Aby zautomatyzować wybieranie akcji, dodaj niestandardowe reguły do typu elementu roboczego usterki. Na przykład dodaj regułę, jak pokazano na poniższej ilustracji. Ta reguła określa ponowne przypisanie usterki do osoby, która otworzyła usterkę, gdy członek zespołu go rozpozna. Zazwyczaj ta osoba sprawdza, czy usterka została naprawiona i zamyka usterkę. Aby uzyskać więcej informacji, zobacz Stosowanie reguł do stanów przepływu pracy (proces dziedziczenia).

Ustawianie stanu elementu roboczego w żądaniu ściągnięcia

Podczas tworzenia żądania ściągnięcia można ustawić wartość stanu połączonych elementów roboczych w opisie. Postępuj zgodnie ze składnią: {state value}: #ID.

Podczas scalania żądania ściągnięcia system odczytuje opis i aktualizuje stan elementu roboczego. Poniższy przykład ustawia elementy robocze #300 i #301 na Rozwiązane, a #323 i #324 na Zamknięte.

Integracja w usłudze Azure DevOps

Jedną z metod używanych przez usługę Azure DevOps do obsługi integracji jest łączenie obiektów z innymi obiektami. Oprócz łączenia elementów roboczych z elementami roboczymi można również połączyć elementy robocze z innymi obiektami. Połącz z obiektami, takimi jak kompilacje, wydania, gałęzie, zatwierdzenia i żądania ściągnięcia, jak pokazano na poniższej ilustracji.

Możesz dodać link z elementu roboczego lub z obiektów kompilacji i wydania.

Łączenie elementów roboczych z programowaniem

Kontrolka Programowanie obsługuje łączenie z kompilacjami, zatwierdzeniami usługi Git i żądaniami ściągnięcia oraz wyświetlanie linków wykonanych do kompilacji. Gdy jest używane repozytorium TFVC, obsługuje linki do zestawów zmian i elementów w wersji. Wybranie linku spowoduje otwarcie odpowiedniego elementu na nowej karcie przeglądarki. Aby uzyskać więcej informacji, zobacz Drive Git development from a work item (Wspieranie programowania w usłudze Git na podstawie elementu roboczego).

Łączenie elementów roboczych z wydaniami

Kontrolka Wdrażanie obsługuje linki do i wyświetlanie wydań zawierających elementy robocze. Na przykład na poniższej ilustracji przedstawiono kilka wydań zawierających linki do bieżącego elementu roboczego. Poszczególne wydania można rozwinąć, aby wyświetlić szczegółowe informacje o poszczególnych etapach. Możesz wybrać link dla każdej wersji i etapu, aby otworzyć odpowiednie wydanie lub etap. Aby uzyskać więcej informacji, zobacz Łączenie elementów roboczych z wdrożeniami.

Łączenie elementów roboczych z przebiegami potoków

Potoki są często definiowane do automatycznego uruchamiania w przypadku wystąpienia nowego zatwierdzenia w repozytorium Git. Elementy robocze skojarzone z potokami zatwierdzania są wyświetlane w ramach przebiegu potoku, jeśli dostosujesz ustawienia potoku. Aby uzyskać więcej informacji, zobacz Dostosowywanie potoku.

Tworzenie lub edytowanie elementu roboczego podczas niepowodzenia kompilacji

Jeśli używasz klasycznych potoków (nie YAML), możesz utworzyć elementy robocze w przypadku niepowodzenia kompilacji. Aby uzyskać więcej informacji, zobacz Tworzenie elementu roboczego w przypadku niepowodzenia.

Monitorowanie stanu usterki, przypisań i trendów

Stan usterki, przypisania i trendy można śledzić przy użyciu zapytań, które można utworzyć na wykresie i dodać do pulpitu nawigacyjnego. Oto na przykład dwa przykłady pokazujące aktywne trendy błędów według stanu i aktywnych usterek według priorytetu w czasie.

Aby uzyskać więcej informacji na temat zapytań, wykresów i pulpitów nawigacyjnych, zobacz zarządzane zapytania, wykresy i pulpity nawigacyjne.

Tworzenie raportów o błędach przy użyciu widoków analizy i usługi Analytics

Usługa Analytics to platforma raportowania dla usługi Azure DevOps. Zastępuje poprzednią platformę na podstawie usług SQL Server Reporting Services.

Widoki analizy udostępniają wstępnie utworzone filtry do wyświetlania elementów roboczych. Cztery widoki analityczne są obsługiwane w przypadku raportowania błędów. Tych widoków można użyć zgodnie z definicją lub dodatkowo edytować, aby utworzyć niestandardowy, filtrowany widok.

• Usterki — cała historia według miesiąca
• Usterki — ostatnie 26 tygodni
• Usterki — ostatnie 30 dni
• Usterki — dzisiaj

Aby uzyskać więcej informacji na temat korzystania z widoków analitycznych, zobacz About Analytics views (Informacje o widokach analizy) i Create an active bugs report in Power BI based on a custom Analytics view (Tworzenie aktywnego raportu usterek w usłudze Power BI na podstawie niestandardowego widoku analizy).

Usługa Power BI umożliwia tworzenie bardziej złożonych raportów niż zapytanie. Aby uzyskać więcej informacji, zobacz Łączenie z łącznikiem danych usługi Power BI.

Rozszerzenia witryny Marketplace

Istnieje wiele rozszerzeń witryny Marketplace związanych z usterkami. Zobacz Marketplace for Azure DevOps (Witryna Marketplace dla usługi Azure DevOps).

Aby uzyskać więcej informacji na temat rozszerzeń, zobacz Rozszerzenia usługi Azure Boards opracowane przez firmę Microsoft.

Następne kroki

Dodawanie i aktualizowanie elementów roboczych za pomocą szablonów

Powiązane artykuły

• Usuwanie, usuwanie lub przywracanie elementów roboczych
• Kopiowanie lub klonowanie elementu roboczego

Zaległości i tablica produktu

• Zarządzanie projektami przy użyciu list prac
• Tworzenie listy prac
• Definiowanie funkcji i epików
• Organizowanie listy prac i mapowania podrzędnych elementów roboczych na elementy nadrzędne
• Interakcyjne filtrowanie list prac, tablic, zapytań i planów
• Prognozowanie listy prac produktu

Board (płytka drukowana)

• Informacje o tablicach i kanbanach
• Korzystanie z tablicy
• Zmienianie kolejności kart
• Dodawanie zadań lub elementów podrzędnych jako list kontrolnych

Lista prac przebiegu i tablica zadań

• Dowiedz się więcej o najlepszych rozwiązaniach scrum
• Przypisywanie elementów listy prac do przebiegu
• Dodawanie zadań
• Aktualizowanie tablicy zadań

Integracja w usłudze Azure DevOps

• Łączenie historii użytkowników, problemów, usterek i innych elementów roboczych
• Obserwowanie elementu roboczego lub żądania ściągnięcia
• Konfigurowanie numerów przebiegu lub kompilacji

Zasoby branżowe

• Dobry i zły dług techniczny (i jak TDD pomaga) Henrik Kniberg
• Zarządzanie długem technicznym opublikowanym przez Sven Johann & Eberhard Wolff