Typy elementów roboczych i przepływ pracy procesu CMMI w usłudze Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Zespoły używają typów elementów roboczych (WITs) dostarczanych z msF na potrzeby procesu poprawy procesu CMMI 2015 (CMMI), aby zaplanować i śledzić postęp projektów oprogramowania. Zespoły definiują wymagania dotyczące zarządzania listą prac, a następnie, korzystając z tablicy, śledzić postęp, aktualizując stan wymagań.
Aby uzyskać wgląd w portfolio wymagań, właściciele produktów mogą mapować wymagania na funkcje. Gdy zespoły pracują w iteracji, definiują zadania, które automatycznie łączą się z wymaganiami.
Korzystając z programu Microsoft Test Manager i portalu internetowego, testerzy tworzą i uruchamiają przypadki testowe oraz definiują błędy w celu śledzenia wad kodu.
Aby obsługiwać inne procesy CMMI, zespoły mogą śledzić żądania zmian, ryzyko, problemy i notatki przechwycone w spotkaniach przeglądu. Jeśli dopiero zaczynasz korzystać z procesu CMMI, zapoznaj się z sekcją Planowanie i śledzenie pracy z programem CMMI , aby rozpocząć pracę.
Definiowanie wymagań
Utwórz wymagania na podstawie panelu szybkiego dodawania na stronie listy prac produktu. Później możesz otworzyć każde wymaganie, aby podać więcej szczegółów i oszacować jego rozmiar.
Możesz też zbiorczo dodawać wymagania przy użyciu pliku cvs.
Możesz też zbiorczo dodawać wymagania przy użyciu programu Excel lub projektu.
Ważne
Integracja z programem Microsoft Project i TFSFieldMapping polecenie nie są obsługiwane w następujących celach:
- Visual Studio 2019 i Azure DevOps Office Integration 2019.
- Azure DevOps Server 2019 i nowsze wersje, w tym Azure DevOps Services.
Pełna obsługa integracji programu Microsoft Excel jest utrzymywana, umożliwiając zbiorcze importowanie i aktualizowanie elementów roboczych. Alternatywy dla korzystania z programu Microsoft Project obejmują:
- Plany dostarczania
- Rozszerzenia witryny Marketplace, takie jak Program Project Connect lub wykres GANTT
Wymagania określają funkcje i elementy produktu, które zespoły muszą utworzyć. Właściciele produktów zazwyczaj definiują wymagania dotyczące klasyfikacji stosu na stronie listy prac produktu. Następnie zespół określa rozmiar nakładu pracy w celu dostarczenia elementów o najwyższym priorytcie.
Skorzystaj z poniższych wskazówek i podanych dla pól używanych w typach elementów roboczych podczas wypełniania formularza. Aby uzyskać więcej informacji, zobacz Planowanie projektu.
Pole
Użycie
Podaj wystarczającą ilość szczegółów na potrzeby szacowania ilości pracy wymaganej do wdrożenia wymagania. Skoncentruj się na tym, kto jest wymagany, co użytkownicy chcą osiągnąć i dlaczego. Nie opisz sposobu opracowywania wymagań. Podaj wystarczające szczegóły, aby zespół mógł pisać zadania i przypadki testowe w celu zaimplementowania elementu.
W polach HTML można dodawać tekst sformatowany i obrazy.
Wpływ klienta na to wymaganie nie jest implementowanie. Możesz uwzględnić szczegóły z modelu Kano dotyczące tego, czy to wymaganie znajduje się w niespodziewanej, wymaganej lub oczywistej kategorii. Te informacje są przechwytywane w polu HTML sformatowanym, które odpowiada ocenie wpływu.
Typ wymagania (wymagany)
Rodzaj wymagania do zaimplementowania. Można określić jedną z następujących wartości:
- Cel biznesowy
- Funkcja (wartość domyślna )
- Funkcjonalny
- Interfejs
- Operacyjne
- Jakość usług
- Bezpieczeństwo
- Scenariusz
- Bezpieczeństwo
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 wymagania przy użyciu dowolnej jednostki liczbowej miary preferowanej przez twój zespół. Definiując rozmiar dla wymagań, zespoły mogą używać wykresów prędkości agile i narzędzi do prognozowania w celu oszacowania przyszłych iteracji lub pracy. Diagram przepływu skumulowanego odwołuje się do wartości w tym polu. Aby uzyskać więcej informacji, zobacz oficjalny dokument dotyczący szacowania .
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.
Daty docelowe dla daty rozpoczęcia lub zakończenia pracy.
Priorytet (wymagany)
Subiektywna ocena wymogu w odniesieniu do działalności. Dozwolone wartości to:
- 1: Produkt nie może być dostarczony bez elementu.
- 2: (ustawienie domyślne) Produkt nie może być dostarczony bez elementu, ale nie musi być natychmiast rozwiązany.
- 3: Implementacja elementu jest opcjonalna na podstawie zasobów, czasu i ryzyka.
Wskazuje typ decyzji klasyfikacji oczekującej na element roboczy. Użyj tego pola, gdy element roboczy ma stan Proponowane i określ jedną z następujących wartości: Oczekujące (domyślne), Więcej informacji, Odebrane informacje i Klasyfikacja.
Wskazuje, czy członek zespołu nie może poczynić postępów w kierunku wdrożenia wymagania, zadania lub rozwiązania usterki, żądania zmiany lub ryzyka. Jeśli problem został otwarty w celu śledzenia problemu blokującego, możesz utworzyć link do problemu. Możesz określić wartość Tak dla pozycji Nie.
Zatwierdzone (wymagane)
Wskazuje, czy wymaganie jest zatwierdzane w projekcie, czy nie. Możesz określić wartość Tak lub Nie (wartość domyślna).
Numer kompilacji produktu, który zawiera wymaganie, żądanie zmiany lub naprawia usterkę.
Test akceptacji użytkownika (wymagany)
Stan testu akceptacji użytkownika dla wymagania. Można określić jedną z następujących wartości:
- Przechodzić
- Zawieść
- Nie gotowe (wartość domyślna)
- Gotowe
- Pominięto
- Odebrane informacje
Gdy wymaganie ma stan Aktywny, należy określić wartość Gotowe, gdy wymaganie ma stan Rozwiązane.
Nazwy członków zespołu, którzy znają obszar klienta, który reprezentuje to wymaganie.
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 pracy
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 cmMI
Na tych diagramach przedstawiono główne stany progresji i regresji dla WIT wymagań, błędów i zadań.
| Wymaganie | Błąd | Zadanie |
|---|---|---|
 |
 |
 |
Typowy postęp przepływu pracy dla wymagania to:
- Właściciel produktu tworzy wymaganie w stanie Proponowane z przyczyną domyślną New requirement (Nowe wymaganie).
- Właściciel produktu aktualizuje stan Aktywne po rozpoczęciu pracy w celu zaimplementowania go.
- Zespół aktualizuje stan Rozwiązania po zakończeniu programowania kodu, a testy systemowe zostały zakończone.
- Na koniec, zespół lub właściciel produktu przenosi wymóg zamknięcia , gdy właściciel produktu zgadza się, że został wdrożony zgodnie z kryteriami akceptacji i przeszedł wszystkie testy weryfikacyjne.
Aktualizowanie stanu pracy za pomocą tablicy lub tablicy zadań
Zespoły mogą używać tablicy do aktualizowania stanu wymagań oraz tablicy zadań przebiegu 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 pasów ruchu lub kolumn.
Mapuj wymagania dotyczące funkcji
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 można wyświetlić, definiując funkcje i wymagania dotyczące mapowania 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.
Element roboczy funkcji zawiera podobne pola podane dla wymagań i zawiera inne pola, jak opisano w poniższej tabeli.
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 i szacuj wykonaną pracę.
Gdy zespoły szacują pracę, definiują zadania i szacują godziny lub dni wykonywania zadań. Zespoły prognozują pracę i definiują zadania na początku iteracji, a każdy członek zespołu wykonuje podzbiór tych zadań. Zadania mogą obejmować programowanie, testowanie i inne rodzaje pracy. Na przykład deweloper może zdefiniować zadania w celu zaimplementowania wymagań, a tester może zdefiniować zadania do pisania i uruchamiania przypadków testowych. Łącząc zadania z wymaganiami i usterkami, widzą postęp w tych elementach. Aby uzyskać więcej informacji, zobacz Działania iteracji.
Pole
Użycie
Wybierz rodzaj zadania do zaimplementowania z dozwolonych wartości:
Działanie naprawcze
Akcja zaradcze
Rozmyślny
Wybierz dyscyplinę, którą reprezentuje to zadanie, gdy zespół szacuje wydajność przebiegu według aktywności.
Analiza
Opracowywanie zawartości
Test
Edukacja użytkowników
Środowisko użytkownika
To pole służy również do obliczania pojemności według dyscypliny. Jest on przypisany do type="Activity" elementu w pliku ProcessConfiguration. (2)
Aby uzyskać więcej informacji, zobacz Implementowanie zadań programistycznych.
Ilość szacowanej pracy wymaganej do wykonania zadania. Zazwyczaj to pole nie zmienia się po przypisaniu.
Ilość pracy pozostałej do wykonania 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 . 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, która została wydana na implementację zadania.
Śledzenie postępu testu
Wymagania testowe
W portalu internetowym lub Menedżerze testów można tworzyć przypadki testowe, które automatycznie łączą się z wymaganiem lub usterką. Możesz też połączyć wymóg 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) zawiera listę wszystkich wymagań i usterek w przypadku testowym. Korzystając z linków, zespół może śledzić postęp poczyniony w testowaniu każdego elementu i obsługuje informacje wyświetlane w raporcie Raport przeglądów wymagań.
Śledzenie wad kodu
Usterki można tworzyć w portalu internetowym portalu internetowym, programie Visual Studio lub podczas testowania za pomocą Menedżera testów.
Śledzenie żądań zmian, czynników ryzyka, problemów i notatek przechwyconych podczas spotkań przeglądu
Oprócz wymagań, funkcji, zadań i usterek WIT można śledzić informacje zalecane przez proces CMMI przy użyciu następujących WITS.
- Żądanie zmiany w celu zarządzania proponowanymi zmianami w dowolnym produkcie roboczym, który jest pod kontrolą zmian.
- Problem polegający na śledzeniu zdarzenia lub sytuacji, która może blokować pracę lub blokuje działanie produktu. Problemy różnią się od czynników ryzyka , które zespoły identyfikują problemy spontanicznie, zazwyczaj podczas codziennych spotkań zespołowych.
- Ryzyko śledzenia prawdopodobieństwa i stopnia wariancji między rzeczywistymi i pożądanymi wynikami. Podczas zarządzania ryzykiem należy strategicznie zminimalizować wariancję między pożądanym wynikiem a rzeczywistym wynikiem.
- Przejrzyj , aby udokumentować wyniki przeglądu projektu lub kodu. Członkowie zespołu mogą przechwytywać szczegółowe informacje o tym, jak projekt lub kod spełnia standardy w obszarach poprawności nazw, istotności kodu, rozszerzalności, złożoności kodu, złożoności algorytmicznej i zabezpieczeń 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.
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
Kolejność listy prac
Pole Stack Rank służy do śledzenia względnego klasyfikowania wymagań, 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.
To pole nie jest wyświetlane w formularzu elementu roboczego.