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? I jak zrobić dobry postęp w sprawie nowych funkcji i rozwiązać swój dług techniczny?

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. Ponadto 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 Śledzenie pracy z historiami użytkowników, problemami, usterkami, funkcjami i epikami.

Usterki udostępniają również następujące dodatkowe 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

• Musisz zostać dodany do projektu.
• Aby wyświetlić lub zmodyfikować elementy robocze, musisz mieć pozycję Wyświetl elementy robocze w tym węźle i Edytować elementy robocze w tym węźle z uprawnieniami ustawionymi na Zezwalaj. Domyślnie grupa Współautorzy ma ten zestaw uprawnień. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień i dostępu do śledzenia pracy.
• Aby dodać nowe tagi do dodania do elementów roboczych, musisz mieć dostęp podstawowy lub wyższy i mieć uprawnienia utwórz nową definicję tagu na wartość Zezwalaj. Domyślnie grupa Współautorzy ma ten zestaw uprawnień. Nawet jeśli uprawnienie jest jawnie ustawione dla uczestnika projektu, nie ma uprawnień do dodawania nowych tagów, ponieważ są one zabronione za pośrednictwem poziomu dostępu. Aby uzyskać więcej informacji, zobacz Stakeholder access quick reference (Dostęp uczestnika projektu — krótki przewodnik).
• Wszyscy członkowie projektu, nawet członkowie grupy 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 i Edytować elementy robocze w tym węźle ustawionym na wartość Zezwalaj dla ścieżki obszaru, w której dodają usterkę. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień i dostępu do ś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 Agile i CMMI śledzi podobne informacje. Jest on przeznaczony do wyświetlania 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 zostały włączone przez 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 odtworzenia)

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 o systemie
Znaleziono 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 do testów akceptacyjnych i oceniać, czy element został 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 uruchomionych kompilacji, 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 opcje formatu numeru kompilacji.

---

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. I 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 jednak 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ń.
• Jak twój zespół organizuje pracę. 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 usterek (ranga stosu) wraz z wymaganiami
• Szacowanie nakładu pracy nad usterek na potrzeby prognozowania
• Aktualizowanie stanu usterki na tablicy Kanban
• Uwzględnianie usterek na wykresach prędkości i diagramach przepływu skumulowanego
• Może używać narzędzia Prognoza do obsługi planowania przebiegu
• Może przeciągać i upuszczać usterki w okienku Planowania , aby przypisywać usterki do przebiegu
• Może wyświetlać usterki 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
• Może przeciągać i upuszczać usterki w okienku Planowania, aby przypisywać 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 będą 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 będą wyświetlane na listach prac lub tablicach
• Usterki nie będą widoczne na listach prac, tablicach, listach prac przebiegu, tablicach, tablicach zadań lub planach dostarczania
• Nie można przeciągać i upuszczać usterek w okienku Planowania, 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. Za pomocą 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 Konfigurowanie i dostosowywanie 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. Obejmują one listy prac i tablice oraz narzędzia do testowania.

Napiwek

Domyślnie pole Tytuł jest jedynym polem wymaganym podczas tworzenia usterki. Możesz szybko dodawać usterki w taki sam sposób, jak dodawanie scenariuszy użytkowników lub elementów listy prac produktu przy użyciu usługi Azure Boards. Jeśli chcesz, aby niektóre pola są wymagane, należy to zrobić, dodając reguły warunkowe na podstawie zmiany stanu. Aby uzyskać więcej informacji, zobacz Dodawanie reguły do typu elementu roboczego (proces dziedziczenia).

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 produktu lub tablicy Kanban. Aby uzyskać więcej informacji, zobacz Tworzenie listy prac produktu lub Rozpocznij korzystanie z tablicy Kanban.

• Dodawanie usterki z listy prac produktu

  

• Dodawanie usterki z listy prac produktu

  

Napiwek

Po dodaniu usterki z listy prac produktu lub tablicy Kanban 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 Kanban, 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 tablicy Kanban
  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.

  

• 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.

  

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 Exploratory testing with the Test &Feedback extension (Testowanie eksploracyjne za pomocą rozszerzenia 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 znaleziono więcej pracy po rozwiązaniu lub zamknięciu usterki, możesz ją ponownie uaktywnić, 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łę. Aby zapoznać się z procesem dziedziczenia, zobacz Stosowanie reguł do stanów przepływu pracy, 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ę po zweryfikowaniu jej jako naprawionej. Jednak możesz również zamknąć usterkę z jednego z następujących powodów. Przyczyny wyboru zależą od procesu projektu i stanów przejścia usterek.

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 zalecaną praktyką jest nigdy ponowne otwarcie 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. Następnie 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 — usterki otwarte w ciągu ostatnich trzech tygodni (Created Date > @Today-21)

Gdy 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 należy przeprowadzić 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 szybko przejść w górę i w dół na liście elementów roboczych błędów za pomocą 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, klasyfikowanie stosu względem innych elementów (klasyfikacja stosu jest wyłączona podczas włączania filtrowania)
• Przypisywanie usterek do przebiegu z listy prac przy użyciu okienka Planowanie
• Usterki nadrzędne w elementach funkcji lub innych elementów 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. Następnie 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.

Istnieje możliwość przypisania zadań lub usterek do iteracji, ale nie ma ich połączonych 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 zostały połączone z elementem nadrzędnej listy prac. Na stronie listy prac przebiegu są wyświetlane tylko usterki i zadania połączone z nadrzędnym elementem listy prac produktu (Scrum), scenariusz użytkownika (Agile) lub wymagania (CMMI) ze ścieżką iteracji ustawioną na przebieg.
• 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 utworzono 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.
• 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 Kanban do dodania testów 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 Kanban, jak pokazano na poniższej ilustracji. Aby uzyskać więcej informacji, zobacz Wprowadzenie do tablicy Kanban.

  

• 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 Kanban
• Dostosowywanie tablicy zadań przebiegu
• Zapytania dotyczące zmian tablicy Kanban

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ę po jego rozwiązaniu. 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. W poniższym przykładzie ustawiliśmy elementy robocze #300 i #301 na Wartość 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 z kompilacji. Lub, gdy jest używane repozytorium TFVC, obsługuje linki do zestawów zmian i elementó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 Opcje kompilacji, 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 następnie można utworzyć wykres 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 dowiedzieć się więcej o zapytaniach, wykresach i pulpitach nawigacyjnych; Zobacz Informacje o zarządzanych zapytaniach i wykresach oraz pulpitach nawigacyjnych.

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ępując poprzednią platformę opartą na usługach 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 dowiedzieć się więcej na temat korzystania z widoków analitycznych, zobacz Co to są widoki analizy i 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ż te, które można uzyskać z zapytania. Aby uzyskać więcej informacji, zobacz Połączenie z usługą Power BI Data Połączenie or.

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

• Przenoszenie, zmienianie typu lub usuwanie elementów roboczych
• Kopiowanie lub klonowanie elementu roboczego

List prac produktu i tablica Kanban

• Listy prac, portfolio i zarządzanie projektami Agile
• Tworzenie listy prac
• Definiowanie funkcji i epików
• Organizowanie listy prac, mapuj podrzędne elementy robocze na elementy nadrzędne
• Interakcyjne filtrowanie list prac, tablic, zapytań i planów
• Prognozowanie listy prac produktu

Tablica Kanban

• Informacje o tablicach i kanbanach
• Przewodnik Szybki start dotyczący tablicy Kanban
• Zmienianie kolejności kart
• Dodawanie zadań lub elementów podrzędnych jako list kontrolnych

Lista prac przebiegu i tablica zadań

• Scrum i praca z najlepszymi rozwiązaniami dotyczącymi przebiegów
• 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