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 oraz kilka dodatkowych. 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

Kategoria	Wymagania
uprawnienia	— Aby wyświetlać, śledzić i edytować elementy robocze: 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 Ustaw uprawnienia śledzenia pracy. — Aby dodać tagi do elementów roboczych: Utwórz nową definicję tagu na poziomie projektu z uprawnieniem ustawionym na Zezwalaj. Domyślnie grupa Współautorzy ma to uprawnienie.
poziomy dostępu	- członek projektu. — Aby dodać nowe tagi do elementów roboczych lub wyświetlić lub śledzić pull requesty: podstawowy dostęp, co najmniej. - Aby wyświetlić lub śledzić elementy robocze: co najmniej dostęp interesariusza. Aby uzyskać więcej informacji, zobacz About access levels (Informacje o poziomach dostępu). — Wszyscy członkowie projektu, w tym członkowie grupy czytelników, mogą wysyłać maile zawierające elementy pracy.

Uwaga

• Zapewnij dostęp do interesariuszy członkom, którzy chcą przyczynić się do dyskusji i przeglądu postępu. Są to zazwyczaj członkowie, którzy nie współtworzyją kodu, ale chcą wyświetlać elementy robocze, listy prac, tablice i pulpity nawigacyjne.
• Domyślnie wszyscy Kontrybutorzy i Interesariusze w projektach publicznych mogą dodawać nowe i istniejące tagi. W projektach prywatnych uczestnicy projektu mogą dodawać tylko istniejące tagi. Aby zarządzać możliwością tworzenia nowych tagów, ustaw uprawnienia Utwórz definicję tagu na poziomie projektu. Aby uzyskać więcej informacji, zobacz Zmienianie uprawnień na poziomie projektu.

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

Dla procesu Scrum na poniższej ilustracji pokazano typ elementu pracy - usterki. 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 w procesie CMMI, zobacz Usterki, problemy i informacje o polach dotyczących 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 zidentyfikowania usterki i zastosowania odpowiednich testów. Informacje o systemie i Znalezione w kompilacji są automatycznie wypełniane podczas tworzenia błędu za pomocą narzędzia do testowania. Te pola określają informacje o środowisku oprogramowania i budowie, w której wystąpiła usterka. 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ć definicje FIELD dla Znaleziono w kompilacji i Zintegrowano 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 wysłany, i musi być szybko rozpatrzony.
• 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.

---

Stopień ciężkości¹

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

• 1 — Krytyczne: Musi zostać naprawione. 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ż poprawienie. 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 rozwiązania, 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 dotyczące wydania. Aby uzyskać więcej informacji, zobacz Łączenie elementów roboczych z wydaniami w dalszej części tego artykułu.

---

Rozwój

Kontrola Rozwoju obsługuje łącza do obiektów rozwojowych oraz ich wyświetlanie. Te obiekty obejmują zatwierdzenia Git i żądania ściągnięcia, albo zestawy zmian TFVC oraz elementy wersjonowane. Można zdefiniować łącza z elementu roboczego lub z zatwierdzeń, żądań ściągnięcia albo innych obiektów deweloperskich. 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 Dostosuj środowisko ś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ć błędy jako wymagania lub zadania. Aby wspierać wybór zespołu, należy wziąć pod uwagę następujące czynniki.

• Rozmiar zespołu. Mniejsze zespoły mogą utrzymać lekką strukturę, śledząc usterki jako wymagania.
• Wymagania organizacji dotyczące śledzenia pracy. Jeśli Twój zespół musi śledzić czas pracy, wybierz śledzenie bugów 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óre zespół chce używać, takie jak okienko planowania, wykres prędkości, prognoza, podsumowanie i harmonogramy dostaw. Śledzenie usterek jako zadań uniemożliwia korzystanie z kilku z tych narzędzi.

Poniższa tabela zawiera podsumowanie trzech opcji, które zespoły mają do wyboru, aby śledzić usterki. Aby uzyskać więcej informacji i ustawić opcję dla swojego zespołu, zobacz Wyświetlanie usterek na listach prac i tablicach.

---

Opcja

Wybierz, kiedy chcesz...

---

Śledzenie usterek jako wymagań

• Ustal priorytety lub określ rangę błędów 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
• Umiejętność używania narzędzia Prognoza do wspierania planowania sprintu
• Przeciągnij błędy do okienka Planowanie, aby przypisać błędy do sprintu
• Wyświetl usterki w planach dostarczania

Uwaga

• Usterki są przypisywane do kategorii wymagań

---

Śledź błędy jako zadania

• Szacowanie pracy dla usterek podobnych do zadań
• Aktualizowanie stanu usterki na tablicach zadań sprintu
• Łączenie usterek z wymaganiami jako elementów podrzędnych
• Przeciągnij błędy do panelu Planowania, aby przypisać je do sprintu.

Uwaga

• Usterki są przypisywane do kategorii zadań
• Historyjki użytkownika (Agile), elementy Backlogu Produktu (Scrum) lub wymagania (CMMI) są naturalnym nadrzędnym rodzajem pracy dla błędów
• Błędy nie są widoczne w planach dostarczania

---

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

• Zarządzanie usterkami przy użyciu zapytań

Uwaga

• Błędy są przypisane do kategorii Błędów i nie pojawiają się ani w backlogach, ani na tablicach.
• Błędy nie są widoczne na backlogach, tablicach, backlogach sprintu, tablicach zadań lub planach dostarczania.
• Nie można przeciągać usterek do okienka planowania, aby przypisać usterki do sprintu.

---

Dostosowywanie typu elementu roboczego

Możesz dostosować typ Usterki 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 backlogu, na którym pojawiają się 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ą rejestry zaległości, 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 ustawić jako obowiązkowe, dodając reguły warunkowe w oparciu o zmianę stanu. Aby uzyskać więcej informacji, zobacz Dodawanie reguły do typu elementu roboczego.

Dodawanie usterki z listy prac lub tablicy

Jeśli wasz zespół zdecydował się zarządzać usterkami w kontekście wymagań, możesz zdefiniować usterki z backlogu produktu lub tablicy projektowej. Aby uzyskać więcej informacji, zobacz Tworzenie backlogu produktu lub Korzystanie z tablicy.

• Dodaj usterkę z rejestru produktu

  

• Dodaj usterkę 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 Domyślne ustawienia zespołu, do których odwołują się listy prac i tablice.

Dodaj usterkę 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. Dodajesz usterkę jako element podrzędny do elementu roboczego w backlogu produktu.

• Dodaj połączoną usterkę podrzędną z Backlogu Sprintu

  Dodajesz błąd w taki sam sposób, jak dodajesz zadanie do backlogu Sprintu. 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 Test & Feedback: podczas uruchamiania testów eksploracyjnych możesz wybrać opcję Utwórz błąd 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 .

Agile	Scrum	CMMI

W przypadku błędów Scrum zmień „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 zadania metodyki Agile zawierał wcześniej regułę, która ponownie przypisywała usterkę osobie, która ją stworzyła. Ta reguła została usunięta z domyślnego procesu systemowego. Tę automatyzację można przywrócić, dodając regułę. Dla procesu dziedziczenia zobacz Automatyzacja 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ów usterkę z osobą, która ją rozwiązała, dojdź do porozumienia i ewentualnie ponownie aktywuj usterkę. Jeśli ponownie uaktywnisz usterkę, uwzględnij przyczyny ponownego aktywowania usterki w opisie usterki.

Zamknij problem

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: Błąd dotyczy innego już zdefiniowanego błędu. 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 Backlog: opis użytkownika został otwarty w celu śledzenia błędu.

Proces Scrum:

• Nie jest to usterka: Przeprowadzono weryfikację, która potwierdza, że nie jest to usterka.
• Duplikat błędu: Jeden błąd śledzi inny, obecnie zdefiniowany błąd. Możesz połączyć każdy błąd z typem linku Duplikat/Duplikat z i zamknąć jeden z błędów.
• 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: Błąd śledzi inny błąd, który jest obecnie zdefiniowany. Możesz połączyć każdy błąd z typem odnośnika Duplikat/Duplikat z i zamknąć jeden z błędów.
• 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 nowego błędu i połączenie go z wcześniejszym, zamkniętym błędem.

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.

Automatyczne zamykanie błędów podczas scalania próśb pull

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

Lista i priorytetyzacja 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)
• Błędy w toku (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)

Gdy masz interesujące zapytania dla swojego 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 interesariusze, którzy mogą mówić o konkretnym ryzyku projektu, uczestniczą w spotkaniach priorytetyzujących.

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

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 sprintu

Jeśli Twój zespół śledzi błędy jako wymagania, wyświetl listę aktywnych błędów z backlogu. 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:

• Zorganizuj usterki na swoim backlogu. Ranga stosu względem innych elementów. Sortowanie stosowe jest wyłączone, gdy filtrowanie jest włączone.
• Przypisz usterki do sprintu z zespołu zadań przy użyciu panelu Planowanie.
• Przypisz usterki nadrzędne do funkcji lub innych elementów zaległości portfela przy użyciu okienka Mapowanie.
• Wyświetl podsumowanie pracy dla elementów zaległości portfela.

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

Elementy tablicy zadań a elementy listy zapytań

Możesz zauważyć i zastanawiać się, dlaczego elementy wyświetlane na tablicy zadań sprintu mogą się różnić od listy wynikającej z zapytania utworzonej w odpowiednim rejestrze sprintu.

Można przypisać zadania lub usterki do iteracji, ale nie można ich połączyć 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 z Kategorii zadań nie będą wyświetlane na zestawieniu sprintu lub tablicy zadań:

• Zadanie lub usterka nie jest połączona z nadrzędnym elementem backlogu. Tylko usterki i zadania połączone z nadrzędnym elementem backlogu produktu (Scrum), historyjką użytkownika (Agile) lub wymaganiem (CMMI), które mają ścieżkę iteracji ustawioną na sprint, są wyświetlane na stronie backlogu sprintu.
• 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 zaległości zdefiniowanemu dla innego zespołu. Lub ścieżka obszaru elementu nadrzędnego w backlogu zadania lub usterki różni się od ścieżki obszaru samego zadania lub usterki.

Utwórz testy wbudowane powiązane z błędami

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 Twój zespół śledzi błędy jako wymagania, używasz 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ń.

  

Dostosuj tablicę 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
• Dostosuj tablicę zadań sprintu
• Wykonywanie zapytań dotyczących zmian w tablicy

Automatyzowanie ponownego przypisania usterki na podstawie stanu przepływu pracy

Aby zautomatyzować wybrane akcje, 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 pull requestu 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 Development obsługuje łączenie z kompilacjami, zatwierdzeniami w Git oraz żądaniami ściągnięcia, a także wyświetlanie linków prowadzących do kompilacji, zatwierdzeń i żądań ściągnięcia. 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 zadań są często definiowane, aby automatycznie uruchamiać się przy wystąpieniu nowego zatwierdzenia w repozytorium Git. Elementy zadań skojarzone z potokami commitów są wyświetlane w ramach uruchomienia potoku, jeśli dostosujesz ustawienia potoku. Aby uzyskać więcej informacji, zajrzyj do Dostosuj swój potok.

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
• Błędy — 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 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

• Usuń, skasuj lub przywróć elementy robocze
• Kopiowanie lub klonowanie elementu roboczego

Zaległości i tablica produktu

• Używaj backlogów do zarządzania projektami
• Tworzenie listy prac
• Zdefiniuj funkcje i epiki
• Zorganizuj swoją listę prac i przyporządkuj podrzędne elementy robocze do elementów nadrzędnych
• Interaktywne filtrowanie list prac, tablic, zapytań i planów
• Prognozuj backlog produktu

Board (płytka drukowana)

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

Backlog sprintu i tablica zadań

• Dowiedz się więcej o najlepszych rozwiązaniach scrum
• Przypisywanie elementów listy prac do sprintu
• 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 pobrania
• 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