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 Kanban do śledzenia postępu, aktualizując stan tych elementów.

Koncepcyjny obraz procesu Agile, typy elementów roboczych używane do planowania i śledzenia pracy.

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.

Zrzut ekranu przedstawiający formularz elementu roboczego scenariusza użytkownika.

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.

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

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.

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

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 !.

Zrzut ekranu przedstawiający sekcję dyskusji z menu rozwijanego wzmianki.

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ń.

Zrzut ekranu przedstawiający sekcję Dyskusji, Edytowanie, Usuwanie akcji.

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.

Zrzut ekranu przedstawiający kontrolkę Dyskusja, Dodawanie reakcji do komentarza.

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.

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

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.

Zrzut ekranu przedstawiający formularz elementu roboczego usterki, obszar 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 Usterka Zadanie
Obraz koncepcyjny przedstawiający stany przepływu pracy scenariusza użytkownika, proces Agile. Obraz koncepcyjny stanów przepływu pracy usterki, proces Agile. Obraz koncepcyjny stanów przepływu pracy zadania, proces Agile.

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ą kanbanu lub tablicy zadań

Zespoły mogą używać tablicy Kanban 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.

Zrzut ekranu przedstawiający śledzenie postępu na tablicy Kanban.

Możesz dostosować tablicę Kanban, aby obsługiwać więcej pasków kąpielowych 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.

Zrzut ekranu przedstawiający listę prac przebiegu i dodaj zadanie.

Nadaj zadanie nazwę i szacuj wykonaną pracę.

Zrzut ekranu przedstawiający formularz elementu roboczego zadania Agile.

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.

Zrzut ekranu przedstawiający portal internetowy planu testów.

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).

Zrzut ekranu przedstawiający formularz przypadku testowego.

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.

Ś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.

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

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.