Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
W Azure Boards proces Agile używa typów elementów roboczych (WITs), aby ułatwić planowanie zespołu, określanie priorytetów i śledzenie postępu. Proces Agile obejmuje epiki, funkcje, historie użytkowników, zadania, problemy i błędy. Po zdefiniowaniu elementów WIT można śledzić postęp, aktualizując stany elementów roboczych.
Aby uzyskać wgląd w portfolio funkcji, scenariuszy i doświadczeń użytkowników, właściciele produktu i menedżerowie programów mapują historie użytkowników na funkcje. Zespoły pracujące w sprintach następnie definiują zadania powiązane z tymi historyjkami użytkownika. Jeśli dopiero zaczynasz korzystać z procesu Agile, zobacz Planowanie i śledzenie pracy z aplikacją Agile.
W tym artykule pokazano, jak wykonać następujące działania:
- Definiowanie i określanie priorytetów historii użytkowników.
- Śledź stan przepływu pracy, gdy zadania przechodzą od nowych do ukończonych.
- Podziel scenariusze na zadania przebiegu i szacuj pozostałą pracę.
- Łączenie przypadków testowych i usterek w celu śledzenia jakości i wad.
W usługach Azure DevOps testerzy tworzą i uruchamiają przypadki testowe w portalu internetowym. W Azure DevOps Server testerzy mogą również używać menedżera testów Microsoft do śledzenia błędów kodu i blokowania problemów.
Definiowanie historii użytkowników
Właściciele produktu zazwyczaj definiują i szeregują według priorytetu historie użytkownika, które opisują wymagania aplikacji i elementy pracy. Następnie zespół szacuje nakład pracy wymagany do dostarczenia elementów o najwyższym priorytcie.
Utwórz historyjki użytkownika korzystając z panelu szybkiego dodawania na stronie Product Backlog. Możesz również przeciągać i upuszczać elementy na stronie, zmienić ich kolejność i mapować elementy na funkcje.
Otwórz każdy scenariusz użytkownika, aby dodać szczegóły i oszacować punkty scenariusza. Zdefiniuj Story Points, aby zespół mógł używać funkcji prognozowania i wykresów prędkości do szacowania przyszłych sprintów i nakładu pracy. Określając priorytety historii użytkowników na stronie listy prac (przechwyconych w polu Stack Rank ), właściciele produktów wskazują, które elementy mają wyższy priorytet.
Skorzystaj ze wskazówek w poniższej tabeli oraz z typowych pól używanych w typach elementów roboczych podczas wypełniania formularza.
Field
Usage
W przypadku scenariuszy użytkowników podaj wystarczającą ilość szczegółów do szacowania ilości pracy wymaganej do zaimplementowania scenariusza. 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.
Podaj kryteria, które należy spełnić, zanim można zamknąć usterkę lub historię użytkownika. Przed rozpoczęciem pracy opisz kryteria akceptacji klienta tak wyraźnie, jak to możliwe. Rozmowy między zespołem a klientami w celu zdefiniowania kryteriów akceptacji pomagają zapewnić zespołowi zrozumienie oczekiwań klientów. Można użyć kryteriów akceptacji jako podstawy do testów akceptacyjnych, aby skuteczniej ocenić, czy element jest ukończony w sposób zadowalający.
Obszar wartości klienta dotyczący epików, funkcji, wymagań lub elementów backlogu. Wartości są następujące:
- Architektura: usługi techniczne do wdrażania funkcji biznesowych zapewniających rozwiązania.
- Biznes: (Domyślnie) Usługi spełniające potrzeby klientów lub interesariuszy i bezpośrednio dostarczające wartość klientom, wspierając tym samym działalność biznesową.
Szacuj ilość pracy wymaganą do ukończenia scenariusza użytkownika przy użyciu dowolnej jednostki liczbowej miary preferowanej przez zespół. 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 .
Subiektywna ocena historii, funkcji lub wymagania użytkownika w odniesieniu do firmy. Dozwolone wartości to:
- 1: Produkt nie może być dostarczony bez funkcji.
- 2: Produkt nie może być dostarczony bez funkcji, ale nie musi być natychmiast rozwiązany.
- 3: Implementacja funkcji jest opcjonalna, oparta na zasobach, czasie i ryzyku.
Subiektywna ocena względnej niepewności pomyślnego ukończenia historii użytkownika. Dozwolone wartości to:
- 1 — Wysoki
- 2 — średni rozmiar
- 3 — Niski
Przechwytywanie komentarzy w sekcji Dyskusja
Użyj sekcji Dyskusja , aby współpracować nad elementami roboczymi, dodając i przeglądając komentarze.
Gdy umieścisz kursor w polu tekstowym obsługującym formatowanie, zostanie wyświetlony 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.
Wspomnij o kimś, grupie, elemencie roboczym lub pull request.
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 !.
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ń:
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.
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 do dyskusji o elemencie roboczym, możesz to zrobić, zapisując komentarze. To uprawnienie jest kontrolowane przez węzły Ścieżki Obszaru i uprawnienie Edytuj komentarze 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.
Podczas zapisywania komentarzy nie trzeba zapisywać elementu roboczego.
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ę postępu pracy zaktualizuj pole Stan , aby odzwierciedlało stan. Opcjonalnie możesz określić przyczynę. Pola Stan i Przyczyna są wyświetlane w obszarze nagłówka formularza elementu roboczego:
Zwinne stany przepływu pracy
Gdy zespoły aktualizują stany przepływu pracy, mogą zidentyfikować, które elementy są nowe, w toku lub ukończone. Większość WIT-ów obsługuje przejścia w przód i wstecz między stanami. Na poniższych diagramach przedstawiono główne stany progresji i regresji dla user story, błędów i typów zadań WIT.
Oto typowy postęp przepływu pracy dla historii użytkownika:
- Właściciel produktu tworzy historyjkę użytkownika w stanie Nowy z domyślnym powodem Nowa historyjka użytkownika.
- Zespół aktualizuje stan scenariusza na Aktywny po podjęciu decyzji o rozpoczęciu pracy w trakcie sprintu.
- Scenariusz przechodzi do stanu Rozwiązane , gdy zespół wykonuje wszystkie skojarzone zadania, a testy jednostkowe przechodzą.
- Historia przechodzi do stanu Zamknięte, gdy właściciel produktu zgadza się, że historia została zaimplementowana zgodnie z Kryteriami Akceptacji i kiedy testy akceptacyjne zakończą się sukcesem.
Aktualizowanie stanu za pomocą tablicy lub tablicy zadań
Zespoły mogą używać tablicy do aktualizowania stanu wymagań oraz tablicy zadań w celu zaktualizowania stanu zadań. Przeciąganie elementów do nowej kolumny stanu aktualizuje pola Stan i Przyczyna .
Tablicę można dostosować tak, aby obsługiwała więcej ścieżek lub kolumn. Aby uzyskać więcej informacji, zobacz Dostosowywanie doświadczenia śledzenia pracy.
Przypisz historie użytkowników do funkcji
Podczas zarządzania pakietem produktów lub środowisk użytkownika może być konieczne przejrzenie zakresu pracy i postępu w portfolio. Użyj funkcji i mapowania z scenariuszy użytkownika do funkcji , aby śledzić ten pakiet zbiorczy.
Korzystając z list prac portfela, możesz przejść z jednej listy prac do innej, aby wyświetlić odpowiedni poziom szczegółów. Ponadto użyj list prac portfela, aby wyświetlić zestawienie pracy w toku w kilku zespołach podczas konfigurowania hierarchii zespołów.
Definiowanie zadań
Gdy Twój zespół zarządza pracą w sprintach, użyj strony backlogu sprintu, aby podzielić zaplanowaną pracę na odrębne zadania.
Wprowadź nazwę zadania i szacuj nakład pracy w polu Nakład pracy :
W przypadku korzystania z procesu Agile zespoły prognozują pracę i definiują zadania na początku każdego sprintu. Następnie każdy członek zespołu wykonuje podzestaw tych zadań. Zadania mogą obejmować programowanie, testowanie i inne zadania. Na przykład deweloper może definiować zadania implementowania scenariuszy użytkownika, a tester może definiować zadania do pisania i uruchamiania przypadków testowych.
Gdy zespoły szacują pracę zgodnie z liczbą godzin lub dni, definiują zadania i pola Pozostała praca i działanie (opcjonalnie).
Field
Usage
Ilość szacowanej pracy wymaganej do wykonania zadania. Zazwyczaj wartość pola nie zmienia się po wprowadzeniu wartości początkowej. Możesz określić pracę w liczbie godzin lub dni. Nie ma żadnych nieodłącznych jednostek czasu skojarzonych z tym polem.
Ilość pracy pozostałej do wykonania zadania. W miarę postępu pracy zaktualizuj to pole. Jeśli zadanie zostanie podzielone na podzadania, określ tylko godziny podzadania. Możesz określić pracę w dowolnej jednostce miary wybranej przez zespół. To pole służy do obliczania następujących wykresów i raportów programu SQL Server:
Ilość pracy poświęcanej na implementowanie zadania.
Wybierz typ działania, które to zadanie reprezentuje, gdy zespół szacuje pojemność sprintu na podstawie aktywności.
Numer kompilacji produktu, który zawiera kod lub naprawia usterkę.
Śledzenie postępu testu
Śledzenie postępu testowania przy użyciu scenariuszy użytkownika i usterek w przypadku błędów kodu. Aby uzyskać wskazówki dotyczące śledzenia innych typów problemów, zobacz Śledzenie innych problemów.
Scenariusze użytkownika testowego
W usługach Azure DevOps można tworzyć przypadki testowe, które automatycznie łączą się z historią użytkownika lub usterką w portalu internetowym. W Azure DevOps Server można również użyć menedżera testów Microsoft. Możesz również połączyć historię użytkownika z przypadkiem testowym na 
karcie Linki.
Przypadek testowy zawiera wiele pól, z których wiele jest zautomatyzowanych i zintegrowanych z zarządzaniem testami 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).
Zakładka Linki zawiera łącza do historii użytkownika i błędów w przypadku testowym. Łącząc scenariusze użytkowników i usterki z przypadkami testowym, zespół może śledzić postęp testowania dla każdego elementu. Te linki obsługują również informacje wyświetlane w raporcie SQL Server Stories Overview (Omówienie scenariuszy SQL Server).
Śledzenie wad kodu
Aby śledzić testowanie pod kątem wad kodu, utwórz usterki z portalu internetowego, Visual Studio lub menedżera testów Microsoft.
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 procesu i projektu.
| 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. |
Śledzenie innych problemów
Używaj zgłoszeń do śledzenia zdarzeń, które mogą blokować postępy lub uniemożliwić dostarczenie historyjki użytkownika. Użyj usterek, aby śledzić wady kodu. Dodaj problem przy użyciu widżetu Nowy element roboczy na pulpicie nawigacyjnym 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łącz kontekst zespołu.
Śledzenie wartości biznesowej
Użyj pola Priorytet , aby odróżnić wartość scenariuszy. Możesz również dodać pole niestandardowe do funkcji WIT scenariusza użytkownika, aby śledzić względną wartość scenariusza. Aby uzyskać więcej informacji, zobacz Dostosowywanie pola dla procesu.
Kolejność elementów backlogu
Pole Stack Rank śledzi względną klasyfikację historii użytkowników. Domyślnie formularz elementu roboczego nie wyświetla tego pola. Sekwencja elementów na stronie listy prac jest określana przez miejsce dodawania lub przenoszenia elementów na stronie. Podczas przeciągania elementów proces w tle aktualizuje pole Stack Rank .
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.