Elastyczny przepływ pracy w usłudze Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
W przypadku korzystania z procesu Agile w usłudze Azure Boards następujące typy elementów roboczych (WIT) ułatwiają zespołowi planowanie i śledzenie postępu projektów: epiki, funkcje, scenariusze użytkownika, zadania, problemy/błędy. Po zdefiniowaniu sieci WITs możesz użyć tablicy do śledzenia postępu, aktualizując stan tych elementów.
Aby uzyskać wgląd w portfolio funkcji, scenariuszy lub środowisk użytkownika, właściciele produktów i menedżerowie programów mapować historie użytkowników na funkcje. Gdy zespół pracuje w przebiegu, definiuje zadania , które automatycznie łączą się z scenariuszami użytkowników. Jeśli dopiero zaczynasz proces Agile, zapoznaj się z sekcją Planowanie i śledzenie pracy z aplikacją Agile , aby rozpocząć pracę.
Z poziomu portalu internetowego lub programu Microsoft Test Manager testerzy mogą tworzyć i uruchamiać przypadki testowe pod kątem usterek i problemów, które są używane do śledzenia wad kodu i problemów blokujących.
Definiowanie historii użytkowników
Właściciele produktów zazwyczaj definiują i stosują scenariusze użytkowników, które opisują pracę związaną z tworzeniem aplikacji, wymagań i elementów. Następnie zespół szacuje nakład pracy i pracuje nad dostarczeniem elementów o najwyższym priorytcie.
Tworzenie scenariuszy użytkownika na podstawie panelu szybkiego dodawania na stronie listy prac produktu. Na tej stronie można również przeciągać i upuszczać elementy, aby zmienić ich kolejność lub mapować je na funkcje.
Możesz otworzyć każdy scenariusz użytkownika, aby uzyskać więcej szczegółów i oszacować punkty scenariusza. Zdefiniuj punkty scenariusza, aby zespół mógł użyć funkcji prognozy i wykresów prędkości do oszacowania przyszłych przebiegów lub wysiłków pracy. Określając priorytety historii użytkowników na stronie listy prac (przechwyconej w polu Stack Rank), właściciele produktów mogą wskazać, które elementy powinny mieć wyższy priorytet.
Skorzystaj ze wskazówek w poniższej tabeli i typowych pól używanych w typach elementów roboczych po zakończeniu formularza.
Pole/karta
Użycie
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ć, że twój zespół rozumie oczekiwania 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 adresowany przez element epików, funkcji, wymagań lub listy prac. Wartości są następujące:
- Architektura: usługi techniczne do implementowania funkcji biznesowych dostarczających rozwiązanie
- Biznes: usługi spełniające potrzeby klientów lub uczestników projektu, które bezpośrednio dostarczają wartość klienta do obsługi firmy (wartość domyślna)
Szacuj ilość pracy wymaganą do ukończenia scenariusza użytkownika przy użyciu dowolnej jednostki liczbowej miary preferowanej przez twój 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 wokół 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 dodać i przejrzeć komentarze dotyczące wykonywanej pracy.
Pasek narzędzi edytora tekstu sformatowanego jest wyświetlany w obszarze wprowadzania tekstu po umieścieniu kursora w dowolnym polu tekstowym obsługującym formatowanie tekstu.
Uwaga
Pole elementu roboczego Dyskusji nie istnieje. Aby wykonać zapytanie o elementy robocze z komentarzami z obszaru Dyskusja, 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
Wybierz jedną z następujących ikon, aby otworzyć menu ostatnich wpisów, w których wymieniono kogoś, połączonego z elementem roboczym lub połączonego z żądaniem ściągnięcia. Alternatywnie możesz otworzyć to samo menu, wprowadzając ciąg @
, #
lub !
.
Wprowadź nazwę lub numer, aby filtrować listę menu w celu dopasowania do wpisu. Wybierz wpis, który chcesz dodać. Aby przełączyć grupę do dyskusji, wprowadź @
po nim 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 skonfiguruj 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 oraz wyświetlanie 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ą wykonywane żadne reguły elementów roboczych zdefiniowane 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.
Zwinne stany przepływu pracy
Po zaktualizowaniu przepływu pracy 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 historii użytkownika, usterki i sieci WITs zadań.
Historia użytkownika | Błąd | Zadanie |
---|---|---|
Typowy postęp przepływu pracy dla scenariusza użytkownika jest następujący:
- Właściciel produktu tworzy historię użytkownika w stanie Nowy z przyczyną domyślną Nowa historia użytkownika.
- Zespół aktualizuje stan Aktywne po podjęciu decyzji o zakończeniu pracy podczas przebiegu.
- Historia użytkownika zostanie przeniesiona do rozwiązania Rozwiązana , gdy zespół ukończył wszystkie skojarzone zadania i testy jednostkowe dla przebiegu scenariusza.
- Historia użytkownika zostaje przeniesiona do stanu Zamknięte , gdy właściciel produktu zgadza się, że historia została wdrożona zgodnie z kryteriami akceptacji i pomyślnie zakończone testy akceptacyjne.
Aktualizowanie stanu za pomocą tablicy lub tablic 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 torów lub kolumn. Aby uzyskać więcej informacji, zobacz Dostosowywanie środowiska śledzenia pracy.
Mapuj historie użytkowników 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. Zakres i postęp pracy można wyświetlić, definiując funkcje i mapując scenariusze użytkowników 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 użyj 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ę.
W przypadku korzystania z procesu Agile zespoły prognozują pracę i definiują zadania na początku każdego przebiegu. Następnie każdy członek zespołu wykonuje podzestaw tych zadań. Zadania mogą obejmować programowanie, testowanie i inne rodzaje pracy. Na przykład deweloper definiuje zadania implementowania scenariuszy użytkownika, a tester definiuje 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
Ilość szacowanej pracy wymaganej do wykonania zadania. Zazwyczaj to pole nie zmienia się po przypisaniu. Możesz określić pracę w godzinach lub w dniach. 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. To pole służy do obliczania wykresów pojemności, wykresu postępu przebiegu oraz następujących raportów programu SQL Server: Burndown and Burn Rate(Wydajność), Remaining Work (Praca pozostała) i Status (Stan) w przypadku wszystkich iteracji. Jeśli zadanie zostanie podzielone na podzadania, określ tylko godziny podzadania. Możesz określić pracę w dowolnej jednostce miary wybranej przez zespół.
Ilość pracy poświęcanej na implementowanie zadania.
Wybierz typ działania reprezentowanego przez to zadanie, gdy zespół szacuje wydajność przebiegu według aktywności.
Numer kompilacji produktu, który zawiera kod lub naprawia usterkę.
Śledzenie postępu testu
Śledzenie postępu testowania za pomocą scenariuszy użytkownika i wad kodu.
Scenariusze użytkownika testowego
W portalu internetowym lub Menedżerze testów można tworzyć przypadki testowe, które automatycznie łączą się z historią użytkownika lub usterką. Możesz też 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 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 scenariuszy użytkownika i usterek w przypadku testowym. Łącząc scenariusze użytkowników i usterki z przypadkami testowym, zespół może śledzić postęp poczyniony podczas testowania każdego elementu. Definiując te linki, można obsługiwać informacje wyświetlane w raporcie Raport o przeglądzie scenariuszy.
Śledzenie wad kodu
Usterki można tworzyć z poziomu portalu internetowego, programu 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.
Powiązane artykuły
- Utwórz projekt
- Dodawanie elementów roboczych do zarządzania projektem
- Tworzenie listy prac
- Zarządzanie dostępem do określonych funkcji
- Dowiedz się więcej o domyślnych uprawnieniach i poziomach dostępu dla usługi Azure Boards
Śledzenie problemów
Problemy są używane do śledzenia zdarzeń, które mogą blokować postęp lub wysyłać historię użytkownika. Z drugiej strony usterki są używane do śledzenia wad kodu. Problem można dodać 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.
Śledzenie wartości biznesowej
Możesz użyć pola Priorytet, aby odróżnić wartość różnych scenariuszy. Możesz też dodać pole niestandardowe do elementu WIT scenariusza użytkownika, które śledzi względną wartość scenariuszy. Aby dowiedzieć się, jak to zrobić, zobacz Dostosowywanie pola dla procesu.
Kolejność listy prac
Pole Stack Rank służy do śledzenia względnego klasyfikowania historii użytkowników, jednak domyślnie nie jest ono wyświetlane 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.