Zarządzanie typami elementów roboczych i przepływem pracy procesu scrum
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Aby zaplanować projekt oprogramowania i śledzić wady oprogramowania przy użyciu scrum, zespoły używają elementu listy prac produktu (PBI) i typów elementów roboczych błędów (WI). Aby uzyskać wgląd w portfolio funkcji, scenariuszy lub środowisk użytkownika, właściciele produktów i menedżerowie programów mogą mapować elementy PBI i błędy na funkcje. Gdy zespoły pracują w przebiegach, definiują zadania, które automatycznie łączą się z usługami PBI i usterkami.
Uwaga
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).
Testerzy mogą tworzyć i uruchamiać przypadki testowe oraz tworzyć błędy w celu śledzenia wad kodu przy użyciu portalu internetowego lub programu Microsoft Test Manager. Przeszkody śledzą problemy z blokowaniem.
Definiowanie interfejsów PBI i usterek
Podczas definiowania elementu listy prac produktu skoncentruj się na wartości, jaką klienci uzyskują i unikają opisów sposobu rozwoju funkcji przez zespół. Właściciel produktu może określić priorytety listy prac produktu na podstawie wartości biznesowej, nakładu pracy i względnej zależności od innych elementów listy prac. W miarę rozwoju wymagań biznesowych, tak samo jak zaległości produktu. Zazwyczaj zespoły określają szczegóły tylko dla elementów o najwyższym priorytcie lub tych elementów przypisanych do bieżącego i następnego przebiegu.
Możesz tworzyć wystąpienia PBI i usterki z panelu szybkiego dodawania na stronie listy prac produktu.
Następnie możesz otworzyć każdy element PBI lub usterkę, aby uzyskać więcej szczegółów i oszacować nakład pracy. Ponadto, priorytetowo określając elementy PBI i usterki na stronie listy prac (która jest przechwytywana w polu Priorytet listy prac), właściciele produktów mogą wskazać, które elementy powinny mieć wyższy priorytet.
Podczas definiowania nakładu pracy dla interfejsów PBI i usterek można użyć wykresów prognozowania i szybkości, aby oszacować przyszłe przebiegi lub nakłady pracy. Podczas definiowania wartości biznesowej właściciele produktów mogą określać priorytety oddzielone od klasyfikacji stosu listy prac, które można zmienić.
Podczas wykonywania formularza elementu roboczego użyj następujących pól i pól używanych w typach elementów roboczych. Aby uzyskać więcej informacji, zobacz Zarządzanie usterkami.
Pole/karta
Użycie
Szacowanie ilości pracy wymaganej do ukończenia usługi PBI przy użyciu dowolnej jednostki miary preferowanej przez zespół, takiej jak punkty scenariusza lub czas. Wymagana jest wartość liczbowa.
Wykresy zwinności i narzędzia do prognozowania odwołują się do wartości w tym polu. Aby uzyskać więcej informacji, zobacz oficjalny dokument dotyczący szacowania .
Określ liczbę, która przechwytuje względną wartość usługi PBI w porównaniu z innymi interfejsami PBI. Im większa liczba, tym większa wartość biznesowa.
Podaj wystarczającą ilość szczegółów na potrzeby szacowania ilości pracy wymaganej do zaimplementowania elementu. Skoncentruj się na tym, kim jest funkcja, co użytkownicy chcą osiągnąć i dlaczego. Nie opisz sposobu opracowywania funkcji. Podaj wystarczające szczegóły, aby zespół mógł pisać zadania i przypadki testowe w celu zaimplementowania elementu.
Zdefiniuj, co oznacza "Gotowe", opisując kryteria, których zespół powinien użyć do sprawdzenia, czy usługa PBI lub poprawka usterek została w pełni zaimplementowana.
Przed rozpoczęciem pracy nad usługą PBI lub usterką opisz kryteria akceptacji klienta tak wyraźnie, jak to możliwe. Rozmowy między zespołem a klientami w celu określenia kryteriów akceptacji pomagają zapewnić wspólne zrozumienie w zespole w celu spełnienia oczekiwań klientów. Kryteria akceptacji mogą służyć jako podstawa testów akceptacyjnych, dzięki czemu zespół może skuteczniej ocenić, czy element został ukończony w sposób zadowalający.
Przechwytywanie komentarzy w sekcji Dyskusja
Użyj sekcji Dyskusja, aby dodać i przejrzeć komentarze dotyczące wykonywanej pracy.
Pasek narzędzi edytora tekstu sformatowanych jest wyświetlany poniżej obszaru wprowadzania tekstu. Zostanie ono wyświetlone po wybraniu każdego pola tekstowego obsługującego formatowanie tekstu.
Uwaga
Nie ma pola elementu roboczego Dyskusja . Aby wykonywać zapytania dotyczące elementów roboczych z komentarzami wprowadzonymi w obszarze Dyskusji, należy filtrować 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
Aby otworzyć menu ostatnich wpisów, które zostały wprowadzone, aby wspomnieć kogoś, link do elementu roboczego lub link do żądania ściągnięcia, wybierz 
lub 
, lub wprowadź #@, lub !.
Wprowadź nazwę lub numer, a filtry listy menu pasujące do wpisu. Wybierz wpis, który chcesz dodać. Aby przełączyć grupę do dyskusji, wprowadź @ i nazwę grupy, taką jak zespół lub grupa zabezpieczeń.
Edytuj lub usuń komentarz
Aby edytować lub usunąć dowolne komentarze do dyskusji, wybierz pozycję 
Edytuj lub wybierz 
ikonę akcji, a następnie wybierz pozycję Usuń.
Uwaga
Edytowanie i usuwanie komentarzy wymaga usługi Azure DevOps Server 2019 Update 1 lub nowszej wersji.
Po zaktualizowaniu komentarza wybierz pozycję Aktualizuj. Aby usunąć komentarz, upewnij się, że chcesz go usunąć.
Pełny dziennik inspekcji wszystkich edytowanych i usuniętych komentarzy jest przechowywany na karcie Historia w formularzu elementu roboczego.
Ważne
W przypadku lokalnego serwera Azure DevOps Server należy skonfigurować serwer SMTP, aby członkowie zespołu otrzymywali powiadomienia.
Dodawanie reakcji na komentarz
Dodaj co najmniej jedną reakcję do komentarza, wybierając ikonę uśmiechniętej buźki w prawym górnym rogu dowolnego komentarza. Możesz też wybrać ikony w dolnej części komentarza obok wszystkich istniejących reakcji. Aby usunąć reakcję, wybierz reakcję na dole komentarza. Na poniższej ilustracji przedstawiono przykładowe doświadczenie dodawania reakcji i wyświetlania reakcji na komentarz.
Zapisywanie komentarza bez zapisywania elementu roboczego
Uwaga
Ta funkcja jest dostępna od wersji 2022.1 usługi Azure DevOps Server.
Jeśli masz uprawnienia do dodawania do dyskusji o elemencie roboczym, możesz to zrobić, zapisując komentarze. To uprawnienie jest kontrolowane przez węzły ścieżki obszaru i uprawnienia Edytuj komentarz elementu roboczego w tym węźle . Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień śledzenia pracy, Tworzenie węzłów podrzędnych, modyfikowanie elementów roboczych w obszarze lub ścieżce iteracji.
Po zapisaniu komentarzy nie trzeba zapisywać elementu roboczego.
Uwaga
Po zapisaniu zmian wprowadzonych w kontrolce Dyskusja zostanie zapisany tylko komentarz. Nie są zdefiniowane żadne reguły elementów roboczych dla typu elementu roboczego.
Śledzenie postępu
W miarę postępu pracy zmieniasz pole Stan, aby zaktualizować stan. Opcjonalnie możesz określić przyczynę. Pola stanu i przyczyny są wyświetlane w formularzu elementu roboczego w obszarze nagłówka.
Stany przepływu pracy scrum
Po zaktualizowaniu stanu zespoły wiedzą, które elementy są nowe, w toku lub ukończone. Większość sieci WITs obsługuje przejście zarówno do przodu, jak i do tyłu z każdego stanu przepływu pracy. Te diagramy przedstawiają główne stany progresji i regresji pbI, usterek i sieci WITs zadań.
| Element listy prac produktu | Usterka | Zadanie |
|---|---|---|
|
|
|
Wskaźniki PBI i usterki są zgodne z typowym postępem przepływu pracy:
- Właściciel produktu tworzy usługę PBI lub tester tworzy usterkę w stanie Nowy z przyczyną domyślną— Nowy element listy prac
- Właściciel produktu przenosi element do zatwierdzonego , gdy jest wystarczająco opisany i gotowy dla zespołu, aby oszacować poziom nakładu pracy. W większości przypadków elementy znajdujące się w górnej części listy prac produktu znajdują się w stanie Zatwierdzone, natomiast elementy w kierunku środka i dołu znajdują się w stanie Nowy
- Zespół aktualizuje stan Zatwierdzone , gdy zdecyduje się na zatwierdzenie pracy nad nim podczas przebiegu
- Element zostanie przeniesiony do stanu Gotowe , gdy zespół wykonał wszystkie skojarzone zadania, a właściciel produktu zgadza się, że został wdrożony zgodnie z kryteriami akceptacji.
Aktualizowanie stanu za pomocą kanbanu lub tablicy zadań
Zespoły mogą używać tablicy Kanban do aktualizowania stanu interfejsów PBI i sprintu Taskboard w celu zaktualizowania stanu zadań. Przeciąganie elementów do nowej kolumny stanu aktualizuje pola Stan i Przyczyna.
Możesz dostosować tablicę Kanban, aby obsługiwać więcej pasów ruchu lub kolumn. Aby uzyskać informacje o innych opcjach dostosowywania, zobacz Dostosowywanie środowiska śledzenia pracy.
Mapuj interfejsy PBI na funkcje
Jeśli zarządzasz pakietem produktów lub środowisk użytkownika, możesz wyświetlić zakres i postęp pracy w portfolio produktów. W tym celu zdefiniuj funkcje i zamapuj interfejsy PBI na funkcje.
Korzystając z list prac portfela, możesz przejść do szczegółów z jednej listy prac do innej, aby wyświetlić odpowiedni poziom szczegółów. Ponadto możesz użyć list prac portfela, aby wyświetlić zestawienie pracy w toku w kilku zespołach podczas konfigurowania hierarchii zespołów.
Definiowanie zadań
Gdy zespół zarządza swoją pracą w sprintach, może użyć strony listy prac przebiegu, aby podzielić pracę do wykonania w różnych zadaniach.
Nadaj zadanie nazwę i szacuj wykonaną pracę.
Zespoły mogą prognozować pracę i definiować zadania na początku każdego przebiegu, a każdy członek zespołu wykonuje podzestaw tych zadań. Zadania mogą obejmować programowanie, testowanie i inne rodzaje pracy. Na przykład deweloper może definiować zadania implementowania interfejsów PBI, a tester może definiować zadania do pisania i uruchamiania przypadków testowych.
Gdy zespoły szacują pracę przy użyciu godzin lub dni, definiują zadania i pola Pozostała praca i aktywność (opcjonalnie).
Pole/karta
Użycie
Określ, ile godzin lub dni pracy pozostało do ukończenia zadania. W miarę postępu pracy zaktualizuj to pole. Służy do obliczania wykresów pojemności, wykresu postępu przebiegu i raportu Sprint Burndown (Scrum).
Jeśli zadanie zostanie podzielone na podzadania, określ opcję Pozostała praca tylko dla podzadań. Możesz określić pracę w dowolnej jednostce miary wybranej przez zespół.
Wybierz typ działania reprezentowanego przez to zadanie, gdy zespół szacuje wydajność przebiegu według aktywności.
Śledzenie postępu testu
Testowanie interfejsów PBI
Z poziomu portalu internetowego lub Menedżera testów możesz utworzyć przypadki testowe, które automatycznie łączą się z usługą PBI lub usterką. Możesz też połączyć usługę PBI lub usterkę z przypadkiem testowym z 
karty (linki).
Przypadek testowy zawiera wiele pól, z których wiele jest zautomatyzowanych i zintegrowanych z menedżerem testów i procesem kompilacji. Opis każdego pola można znaleźć w temacie Query based on build and test integration fields (Wykonywanie zapytań na podstawie pól integracji kompilacji i testowania).
Karta (linki) przechwytuje linki do wszystkich interfejsów PBI i usterek w przypadku testowym. Łącząc elementy PBI i usterki z przypadkami testowymi, zespół może śledzić postęp w testowaniu każdego elementu.
Śledzenie wad kodu
Usterki można tworzyć w portalu internetowym portalu internetowym, programie Visual Studio lub podczas testowania za pomocą Menedżera testów.
Definicje typowych pól śledzenia pracy
W większości elementów roboczych są wyświetlane następujące pola i karty. Każda karta służy do śledzenia określonych informacji, takich jak 
Historia, Linki lub
Załączniki. Te trzy karty zawierają historię zmian, widok połączonych elementów roboczych oraz możliwość wyświetlania i dołączania plików.
Jedynym polem wymaganym dla wszystkich typów elementów roboczych jest Tytuł. Po zapisaniu elementu roboczego system przypisuje mu unikatowy identyfikator. Formularz wyróżnia wymagane pole w kolorze żółtym. Aby uzyskać informacje o innych polach, zobacz Indeks pól elementu roboczego.
Uwaga
W zależności od dostosowań wprowadzonych w procesie i projekcie mogą być wymagane dodatkowe pola.
Pole/karta
Użycie
Wprowadź opis 255 znaków lub mniej. Tytuł można zawsze modyfikować później.
Przypisz element roboczy do członka zespołu odpowiedzialnego za wykonywanie pracy.
Po utworzeniu elementu roboczego stan domyślny to pierwszy stan w przepływie pracy. W miarę postępu pracy zaktualizuj ją, aby odzwierciedlała bieżący stan.
Najpierw użyj wartości domyślnej. Zaktualizuj go po zmianie stanu. Każdy stan jest skojarzony z przyczyną domyślną.
Wybierz ścieżkę obszaru skojarzona z produktem lub zespołem lub pozostaw ją pustą do momentu przypisania podczas spotkania planistycznego. Aby zmienić listę rozwijaną obszarów, zobacz Definiowanie ścieżek obszaru i przypisywanie do zespołu.
Wybierz przebieg lub iterację, w której ma zostać ukończona praca, lub pozostaw ją pustą i przypisz ją później podczas spotkania planistycznego. Aby zmienić listę rozwijaną iteracji, zobacz Definiowanie ścieżek iteracji (przebiegów) i konfigurowanie iteracji zespołu.
Przejrzyj dziennik inspekcji przechwycony przez system i przechwyć dodatkowe informacje.
Za każdym razem, gdy element roboczy jest aktualizowany, informacje są dołączane do historii. Historia zawiera datę zmiany, która dokonała zmiany i które pola zostały zmienione. Do pola historii można również dodać sformatowany tekst.
Dodaj wszystkie typy łączy, takich jak hiperlinki, zestawy zmian, pliki źródłowe itd.
Ta karta zawiera również listę wszystkich linków zdefiniowanych dla elementu roboczego.
Udostępnij bardziej szczegółowe informacje, dodając pliki do elementu roboczego, takie jak wątki poczty e-mail, dokumenty, obrazy, pliki dziennika lub inne typy plików.
Dostosowywanie typów elementów roboczych
W przypadku większości typów elementów roboczych można dodawać pola, zmieniać przepływ pracy, dodawać reguły niestandardowe i dodawać strony niestandardowe do formularza elementu roboczego. Można również dodać 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, zmieniać przepływ pracy, dodawać reguły niestandardowe i dodawać strony niestandardowe do formularza elementu roboczego. Można również dodać 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 używanego przez projekt.
Przeszkody w śledzeniu
Użyj typu elementu roboczego Impediment, aby śledzić zdarzenia, które mogą blokować postęp lub wysyłać usługę PBI. Użyj typu usterki elementu roboczego wyłącznie do śledzenia wad kodu.
Możesz dodać przeszkodę z widżetu Nowy element roboczy dodany do pulpitu nawigacyjnego zespołu lub z menu Nowy na stronie Zapytania.
Elementy robocze dodawane z widżetu są automatycznie ograniczone do domyślnego obszaru zespołu i ścieżek iteracji. Aby zmienić kontekst zespołu, zobacz Przełączanie kontekstu zespołu.
Kolejność listy prac
Pole Priorytet listy prac służy do śledzenia względnej klasyfikacji pbI, usterek, funkcji lub epików. Jednak domyślnie nie jest ona wyświetlana w formularzu elementu roboczego. Sekwencja elementów na stronie listy prac jest określana zgodnie z tym, gdzie zostały dodane elementy lub przeniesione elementy na stronie. Podczas przeciągania elementów proces w tle aktualizuje to pole.
Powiązane artykuły
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla