Zarządzanie typami elementów roboczych i przepływem pracy procesu scrum

Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Użyj scrum w Azure Boards, aby zaplanować i ustalić priorytety dostarczania oprogramowania oraz śledzić wady. Zespoły ujmują pracę jako elementy rejestru produktu (PBI) i usterki, przypisują te elementy do funkcji, aby zapewnić widoczność na poziomie portfela, oraz dzielą pracę sprintu na zadania powiązane z elementami PBI i usterkami.

Obraz koncepcyjny przedstawiający typy elementów roboczych procesu Scrum używane do planowania i śledzenia.

Note

Jeśli dopiero zaczynasz korzystać z procesu Scrum, zapoznaj się z artykułem About Sprints, Scrum and project management (Informacje o sprintach, scrumie i zarządzaniu projektami).

Ten artykuł pomoże Ci:

Prerequisites

Obszar Wymaganie Dlaczego ma to znaczenie
członkostwo w projekcie Musisz być członkiem projektu z uprawnieniami do wyświetlania i edytowania elementów roboczych w Azure Boards. Wymagane do tworzenia, aktualizowania i przenoszenia elementów roboczych między stanami przepływu pracy Scrum.
Poziom dostępu Potrzebujesz co najmniej podstawowego dostępu do tworzenia i aktualizowania elementów roboczych. Wymagane do podstawowych działań związanych ze śledzeniem głównego backlogu, tablicy i zadań.
Dostęp do listy prac i tablicy Potrzebujesz dostępu do rejestrów zaległości zespołu i tablic. Służy do ustalania priorytetów elementów PBI, planowania sprintów i aktualizowania stanu na tablicach i tablicach zadań.
Uprawnienia konfiguracji zespołu Aby zdefiniować ustawienia zespołu, poziomy backlogu lub konfigurację tablicy, musisz mieć członkostwo w grupie Project Administrators lub równoważne uprawnienia delegowane. Wymagane do konfigurowania i dostosowywania na poziomie zespołu.
Dostęp do zarządzania testami Aby utworzyć i uruchomić przypadki testowe, musisz mieć dostęp do Azure Test Plans (lub równoważnych narzędzi testowych dla wdrożenia). Wymagane do łączenia przypadków testowych z elementami PBI i śledzenia wyników testów.

Aby uzyskać więcej informacji, zobacz Ustaw uprawnienia i dostęp do śledzenia pracy.

Definiowanie interfejsów PBI i usterek

Najpierw zdefiniuj PBI i błędy, aby uchwycić wartość dla klienta, a szczegóły implementacji doprecyzuj, gdy prace zbliżają się do realizacji.

Użyj tego wzorca:

  • Twórz elementy w panelu szybkiego dodawania na stronie rejestru produktu.
  • Określanie priorytetów według wartości biznesowej, nakładu pracy i zależności.
  • Dodaj pełne szczegóły do elementów o najwyższym priorytecie oraz elementów zaplanowanych na bieżący lub następny sprint.

W miarę zmiany priorytetów zaktualizuj kolejność listy prac. Strona listy prac śledzi tę kolejność za pomocą priorytetu listy prac.

Zrzut ekranu przedstawiający formularz elementu roboczego z rejestru produktu.

Ustaw nakład pracy, aby wykresy prognozy i prędkości mogły prognozować przyszłą pojemność sprintu. Ustaw Wartość biznesową, aby wyrazić priorytet niezależnie od rankingu.

Użyj poniższych pól, aby w sposób spójny uzupełnić każdy element przed planowaniem sprintu. Aby uzyskać szczegółowe informacje na temat usterek, zobacz Zarządzanie usterkami.

Pole Korzystanie
Effort Szacuj pracę wymaganą do ukończenia usługi PBI przy użyciu jednostki liczbowej zespołu (na przykład punktów scenariuszy lub czasu). W zależności od dostosowania procesu to pole może być opcjonalne lub wymagane. Wykresy prędkości i prognozy używają tej wartości.
Wartość biznesowa Wprowadź liczbę określającą względną wartość biznesową w porównaniu z innymi PBI. Wyższe liczby wskazują wyższą wartość.
Description Opisz, dla kogo jest przeznaczona funkcja, co użytkownik musi zrobić i dlaczego jest to ważne. Uwzględnij wystarczający kontekst dla podziału zadań i projektu testu.
Kryteria akceptacji Zdefiniuj warunki do wykonania przed rozpoczęciem implementacji. Jasne kryteria są zgodne z oczekiwaniami zespołu i uczestników projektu oraz wspierają testowanie akceptacyjne.

Przechwytywanie komentarzy w sekcji Dyskusja

Użyj sekcji Dyskusja , aby współpracować nad elementami roboczymi, dodając i przeglądając komentarze.

Zrzut ekranu przedstawiający sekcję Dyskusja w formularzu elementu roboczego.

Gdy umieścisz kursor w polu tekstowym obsługującym formatowanie, zostanie wyświetlony pasek narzędzi edytora tekstu sformatowanego.

Zrzut ekranu przedstawiający sekcję Dyskusji, pasek narzędzi edytora tekstu sformatowanego.

Note

Pole elementu roboczego Dyskusji nie istnieje. Aby wykonać zapytanie o elementy robocze z komentarzami z obszaru dyskusji, przefiltruj pole Historia. Pełna zawartość tekstu wprowadzonego w polu tekstowym Dyskusja jest dodawana do pola Historia.

Wzmianka o kimś, grupie, elemencie roboczym lub żądaniu ściągnięcia

Użyj jednej z następujących ikon, aby otworzyć ostatnie wpisy dla osób, elementów roboczych lub żądań ściągnięcia:

Możesz otworzyć to samo menu za pomocą skrótów klawiaturowych: at-mention @, hashtag #i wykrzyknik !.

Zrzut ekranu przedstawiający sekcję Dyskusji z menu rozwijanego do wybierania osób (@wzmianka).

Wprowadź nazwę lub numer, aby filtrować listę, a następnie wybierz element, który chcesz dodać. Aby wspomnieć o grupie, wprowadź @ po nim nazwę grupy, taką jak zespół lub grupa zabezpieczeń.

Edytuj lub usuń komentarz

Aby zaktualizować lub usunąć jeden z komentarzy, wybierz pozycję Edytuj lub wybierz pozycję Więcej akcji ( ), a następnie wybierz pozycję Usuń:

Zrzut ekranu przedstawiający sekcję Dyskusji, w której można wybrać pozycję Edytuj lub Usuń akcje.

Po zmianie komentarza wybierz pozycję Aktualizuj. Aby usunąć komentarz, potwierdź usunięcie. Karta Historia przechowuje dziennik inspekcji wszystkich edytowanych i usuniętych komentarzy.

Important

W przypadku Azure DevOps Server lokalnych skonfiguruj serwer SMTP, aby członkowie zespołu mogli otrzymywać powiadomienia.

Dodawanie reakcji na komentarz

Dodaj co najmniej jedną reakcję do komentarza, wybierając ikonę emoji w komentarzu. Aby usunąć reakcję, ponownie wybierz tę samą reakcję. Na poniższej ilustracji przedstawiono przykład dodawania i wyświetlania reakcji na komentarz.

Zrzut ekranu przedstawiający sekcję Dyskusja, dodaj reakcję na komentarz.

Zapisz komentarz bez zapisywania elementu roboczego

Note

Ta funkcja jest dostępna od wersji 2022.1 usługi Azure DevOps Server.

Jeśli masz uprawnienia do dodawania komentarzy w dyskusji dotyczącej elementu roboczego, możesz to zrobić, zapisując je w systemie. To uprawnienie jest kontrolowane przez węzły ścieżki obszaru i uprawnienie Edytuj komentarze elementów roboczych w tym węźle. Aby uzyskać więcej informacji, zobacz Konfigurowanie uprawnień do śledzenia pracy — tworzenie węzłów podrzędnych, modyfikowanie elementów roboczych w ramach obszaru lub ścieżki iteracyjnej.

Podczas zapisywania komentarzy nie trzeba zapisywać elementu roboczego.

Zrzut ekranu przedstawiający sekcję Dyskusji, zapisz komentarz.

Note

Po zapisaniu zmian wprowadzonych w kontrolce Dyskusja zostanie zapisany tylko komentarz. Nie są wykonywane żadne reguły elementów roboczych zdefiniowane dla typu elementu roboczego.

Śledzenie postępu

W miarę rozwoju pracy zaktualizuj stan , aby odzwierciedlić bieżący stan i ustawić przyczynę w razie potrzeby. Oba pola są wyświetlane w nagłówku elementu roboczego.

Konsekwentnie aktualizuj stan, aby zachować spójność backlogu, tablicy i widoków raportów.

Szybki przepływ:

  • Definiuj elementy PBIs i błędy oraz ustalaj ich priorytety.
  • Przenoś elementy między etapami przepływu pracy w miarę postępów prac.
  • Przejrzyj tablicę i raporty, aby potwierdzić spójność statusu.

Zrzut ekranu przedstawiający obszar nagłówka formularza elementu roboczego usterki.

Stany przepływu pracy Scrum

Zaktualizuj stan , aby pokazać, czy element jest nowy, w toku, ukończony lub usunięty z zakresu. Większość sieci WITs obsługuje przejścia zarówno do przodu, jak i do tyłu.

Na poniższych diagramach przedstawiono główne stany progresji i regresji dla typów elementów roboczych PBI, Bug i Task.

Element backlogu produktu Bug Task
Koncepcyjny obraz przedstawiający etapy przepływu pracy elementu Backlogu Produktu w procesie Scrum. Obraz koncepcyjny przedstawiający stany przepływu pracy usterki, proces Scrum. Obraz koncepcyjny przedstawiający stany przepływu pracy zadania, proces Scrum.

Typowy cykl życia usługi PBI i usterki:

  • Nowy: właściciel produktu lub tester tworzy element. Przyczyna domyślna zależy od typu elementu roboczego i konfiguracji procesu (na przykład nowego elementu listy prac).
  • Zatwierdzone: element jest na tyle dobrze zdefiniowany, aby zespół mógł oszacować go i przygotować się do planowania sprintu. Elementy o wyższym priorytcie zwykle są najpierw przenoszone do tego stanu.
  • Zobowiązanie: Zespół zobowiązuje się dostarczyć element w sprincie.
  • Gotowe: wszystkie powiązane zadania są wykonywane, a właściciel produktu potwierdza, że element spełnia kryteria akceptacji.

Użyj oznaczenia Removed dla elementów celowo wyłączonych z zakresu i nieplanowanych do dostarczenia. Pozostawienie tych elementów poza stanem Gotowe pomaga utrzymać dokładność raportowania.

Aktualizowanie stanu tablic i tablic zadań

Użyj tablic, aby na bieżąco śledzić status w miarę postępu prac w sprincie:

  • Użyj tablicy, aby zaktualizować status PBI i błędu.
  • Użyj tablicy zadań sprintu, aby zaktualizować status zadania.
  • Przeciągnij element do nowej kolumny, aby zaktualizować zarówno stan , jak i przyczynę.

Zrzut ekranu przedstawiający śledzenie postępu na tablicy w portalu internetowym.

Tablicę można dostosować przy użyciu pasów pływaków i kolumn. Aby uzyskać więcej opcji, zobacz Dostosowywanie środowiska śledzenia pracy.

Przypisz elementy PBI do funkcji

Przypisz elementy PBI do funkcji, aby śledzić zakres i postęp w różnych produktach, scenariuszach lub zespołach.

Użyj tego podejścia:

Sprawdzanie poprawności: Potwierdź, że każda funkcja pokazuje połączone podrzędne interfejsy PBI i że wartości zestawienia są zgodne z postępem elementu podrzędnego.

Definiowanie zadań

Gdy twój zespół pracuje w sprintach, podziel elementy rejestru produktu (PBI) i błędy na zadania na stronie rejestru zadań sprintu.

Zrzut ekranu przedstawiający backlog sprintu z funkcją dodawania zadania.

Nadaj każdemu zadaniu nazwę i szacuj nakład pracy.

Zrzut ekranu przedstawiający formularz elementu roboczego zadania Scrum.

Zespoły zwykle definiują zadania na początku każdego sprintu. Członkowie zespołu ukończyli podzestawy pracy, takie jak programowanie, testowanie lub dokumentacja.

Użyj tego wzorca:

  • Utwórz zadania dla każdego etapu dostarczania potrzebnego do ukończenia elementu PBI lub błędu.
  • Przypisz zadania członkom zespołu na podstawie odpowiedzialności.
  • Aktualizuj wartości zadań codziennie, aby wydajność i spalenie były dokładne.

Gdy zespół szacuje pracę w godzinach lub dniach, użyj pól Pozostała praca i opcjonalnie Czynność.

Pole Korzystanie
Praca pozostała Wprowadź liczbę godzin lub dni, a następnie zaktualizuj wartość w miarę postępu pracy. To pole służy do tworzenia wykresów wydajności, wykresów spalania sprintu oraz powiązanych raportów. Jeśli podzielisz pracę na podzadania, śledź pozostałą pracę tylko w podzadaniach.
Activity Wybierz kategorię aktywności, która najlepiej opisuje zadanie, aby Twój zespół mógł oszacować i przeanalizować pojemność sprintu według typu aktywności.

Śledzenie postępu testu

Skorzystaj z poniższych wskazówek, aby połączyć pokrycie testami i śledzenie defektów z elementami rejestru zadań sprintu.

Użyj tego wzorca, aby połączyć pracę testowania z elementami listy prac:

  • Utwórz przypadki testowe w portalu internetowym, tak aby były połączone z elementem PBI lub błędem.
  • W razie potrzeby otwórz kartę Linki i ręcznie dodaj relację.

W przypadku Azure DevOps Server 2022 r. można również użyć programu Microsoft Test Manager 2017.

Zrzut ekranu przedstawiający wybieranie zestawu testów i dodawanie przypadku testowego.

Przypadki testowe obejmują pola zintegrowane z przepływami pracy kompilacji i testowania. Aby uzyskać szczegółowe informacje, zobacz Query based on build and test integration fields (Wykonywanie zapytań na podstawie pól integracji kompilacji i testowania).

Zrzut ekranu przedstawiający formularz elementu roboczego Przypadku testowego scrum.

Na karcie Linki znajduje się lista elementów PBI i błędów powiązanych z każdym przypadkiem testowym.

Kontrola poprawności: Potwierdź, że w każdym przypadku testowym na karcie Linki jest wyświetlany powiązany element PBI lub błąd.

Śledzenie wad kodu

Tworzenie usterek z poziomu portalu internetowego lub Visual Studio. Aby uzyskać szczegółowe informacje, zobacz Zarządzanie usterkami.

W przypadku Azure DevOps Server 2022 r. można również tworzyć usterki za pomocą programu Microsoft Test Manager 2017.

Definicje typowych pól śledzenia pracy

W większości elementów roboczych są wyświetlane następujące pola i karty. Typowe karty obejmują historię, linki i załączniki.

W przypadku wszystkich typów elementów roboczych tytuł jest jedynym powszechnie wymaganym polem. Podczas zapisywania elementu roboczego Azure DevOps przypisuje unikatowy identyfikator. Wymagane pola są wyróżnione kolorem żółtym. Więcej informacji o polach znajdziesz w artykule Indeks pól elementu roboczego.

Note

Inne pola mogą być wymagane w oparciu o dostosowania procesów i projektów.

Pole lub zakładka Usage
Title Wprowadź krótki opis (maksymalnie 255 znaków). Tytuł można edytować później.
Przypisane do Przypisz element pracy do osoby odpowiedzialnej za jego realizację lub pozostaw go nieprzypisanym, dopóki nie będzie jasne, kto jest za niego odpowiedzialny.
State Po utworzeniu Stan domyślnie przyjmuje pierwszy stan przepływu pracy (taki jak Nowy lub Nieprzypisany). Zaktualizuj je w miarę postępu pracy.
Reason Przyczyna wyjaśnia, dlaczego element znajduje się w bieżącym stanie. Wartości domyślne różnią się w zależności od typu i procesu elementu roboczego.
Area Wybierz ścieżkę obszaru dla produktu lub zespołu. Szczegółowe informacje zawiera temat Definiowanie ścieżek obszaru i przypisywanie ich do zespołu.
Iteration Wybierz sprint/iterację na potrzeby planowanego ukończenia. Aby uzyskać szczegółowe informacje, zobacz Definiowanie ścieżek iteracji (sprintów) i konfigurowanie iteracji zespołu.
Karta Historia Wyświetl pełny dziennik zmian dla elementu roboczego, w tym autor, datę i zaktualizowane pola. Możesz również dodać sformatowany tekst w obszarze Historia.
Karta Łącze Dodaj relacje do innych artefaktów (na przykład elementów roboczych nadrzędnych/podrzędnych, zestawów zmian, plików źródłowych lub wyników testów).
Karta Załączniki Dodaj pliki pomocnicze, takie jak dokumenty, obrazy, dzienniki lub wątki poczty e-mail.

Dostosowywanie typów elementów roboczych

W przypadku większości typów elementów roboczych można dodawać pola, aktualizować przepływ pracy, definiować reguły niestandardowe, dodawać strony niestandardowe i tworzyć niestandardowe typy elementów roboczych. Aby uzyskać więcej informacji, zobacz Dostosowywanie procesu dziedziczenia.

W przypadku większości typów elementów roboczych można dodawać pola, aktualizować przepływ pracy, definiować reguły niestandardowe, dodawać strony niestandardowe i tworzyć niestandardowe typy elementów roboczych. Aby uzyskać więcej informacji, zobacz Dostosowywanie procesu dziedziczenia lub Dostosowywanie lokalnego modelu procesu XML w zależności od modelu procesu.

Przeszkody w śledzeniu

Użyj typu elementu roboczego Impediment, aby śledzić blokery. Stosuj określenie Bug wyłącznie w odniesieniu do defektów kodu.

Możesz dodać przeszkodę z:

Zrzut ekranu przedstawiający dodawanie elementu roboczego z widżetu Nowy element roboczy.

Elementy robocze dodawane z widżetu są automatycznie przypisywane do domyślnego obszaru zespołu i ścieżek iteracji. Aby użyć innego kontekstu zespołu, zobacz Przełączanie kontekstu zespołu.

Kolejność listy zaległych zadań

Użyj Priorytetu rejestru produktu, aby zarządzać względną kolejnością elementów PBI, usterek, funkcji i epik.

Użyj tego wzorca:

  • Zmiana kolejności elementów bezpośrednio na stronie listy prac (zobacz Tworzenie listy prac).
  • Przeciągnij elementy, aby odzwierciedlić bieżący priorytet biznesowy.
  • Pozwól, aby Azure DevOps aktualizował w tle priorytet rejestru prac.

Sprawdzanie poprawności: potwierdź, że kolejność listy prac jest zgodna z priorytetem biznesowym po zmianie kolejności.

Rozwiązywanie typowych problemów

Problematyka Przyczyna Resolution
Nie można przenieść elementu roboczego do oczekiwanego stanu Reguły przepływu pracy lub dostosowanie procesu ograniczają przejścia Przejrzyj dostosowywanie procesu i dozwolone przejścia. Zobacz Dostosowywanie procesu dziedziczenia.
Wymagane pole blokuje zapisywanie elementu roboczego reguły niestandardowe specyficzne dla Project wymagają dodatkowych pól Sprawdź komunikat weryfikacji i wypełnij wymagane pola dla procesu. Zobacz Ustawianie reguł dla elementów roboczych.
Nie można tworzyć ani edytować przypadków testowych Brak uprawnień testowych lub poziomu dostępu Sprawdź dostęp i uprawnienia do testowania artefaktów. Zobacz Ustawianie uprawnień i dostępu do śledzenia pracy.
Powiązany przypadek testowy nie pojawia się w elemencie backlogu Łącze nie zostało utworzone jako łącze elementu roboczego lub zostało dodane do innego elementu Otwórz element przypadku testowego i listy prac, a następnie sprawdź linki na karcie Linki dla obu elementów.
Nie można rozwiązać problemu po zastosowaniu tych poprawek Zasady lub uprawnienia na poziomie organizacji nadal blokują akcję Najpierw skontaktuj się z administratorem Project. Jeśli problem dotyczy całej organizacji, skontaktuj się z administratorem kolekcji Project lub administratorem Azure DevOps.

Treści powiązane

  • Last updated on