Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Zespoły używają typów elementów roboczych (WITs), które są dostarczane z MSF for CMMI Process Improvement 2015 (CMMI) do planowania i śledzenia projektów oprogramowania. Właściciele produktów definiują wymagania dotyczące zarządzania listą prac, a zespoły śledzą postęp na tablicy, aktualizując wymagania i stan zadania.
Właściciele produktów przyporządkowują wymagania funkcji, aby wyświetlić postęp na poziomie portfela. Gdy zespoły pracują w iteracji, tworzą zadania, które automatycznie łączą się z wymaganiami.
Testerzy tworzą i uruchamiają przypadki testowe przy użyciu programu Microsoft Test Manager lub portalu internetowego i zgłaszają błędy w celu śledzenia wad kodu.
Zespoły śledzą również żądania zmian, czynniki ryzyka, problemy i notatki przechwycone podczas spotkań przeglądu. Jeśli dopiero zaczynasz pracę z procesem CMMI, zacznij od planu i śledzenia pracy z CMMI.
Definiowanie wymagań
Utwórz wymagania z panelu szybkiego dodawania na stronie listy zadań produktowych. Następnie otwórz każde wymaganie, aby podać szczegóły i oszacować jego rozmiar.
Możesz też zbiorczo dodawać wymagania przy użyciu pliku CSV (zobacz Importowanie elementów roboczych z pliku CSV).
Important
Integracja z programem Microsoft Project nie jest już obsługiwana
Integracja z programem Microsoft Project oraz polecenie TFSFieldMapping zostały wycofane dla następujących elementów:
- Visual Studio 2019 i nowsze wersje (w tym integracja z usługą Azure DevOps Office)
- Azure DevOps Server 2020 i nowsze wersje
- Azure DevOps Services
Co nadal działa: Integracja programu Microsoft Excel pozostaje w pełni obsługiwana w przypadku zbiorczego importowania i aktualizowania elementów roboczych.
Zalecane alternatywy:
- Plany dostarczania — natywna funkcja usługi Azure DevOps do planowania projektu i śledzenia między zespołami
- Rozszerzenia zarządzania projektami — przeglądanie witryny Azure DevOps Marketplace dla bieżących rozwiązań do zarządzania wykresem Gantta i projektami
- Integracje innych firm — wiele narzędzi do zarządzania projektami oferuje łączniki usługi Azure DevOps na potrzeby bezproblemowej integracji przepływu pracy
Wymagania opisują elementy i funkcje produktu, które zespoły muszą zbudować. Właściciele produktów zazwyczaj definiują i ustalają priorytety wymagań na stronie backlogu produktu. Następnie zespół określa zakres wymaganego nakładu pracy i zapisuje zadania i przypadki testowe w celu zaimplementowania każdego elementu.
Skorzystaj z poniższych wskazówek i sekcji pól używanych wspólnie dla różnych typów elementów roboczych podczas wypełniania formularza. Aby uzyskać więcej informacji, zobacz Planowanie projektu.
Field
Usage
Podaj wystarczającą ilość szczegółów dla zespołu, aby oszacować nakład pracy nad implementacją. Skoncentruj się na tym, kto spełnia wymagania, co użytkownicy chcą osiągnąć i dlaczego. Unikaj opisywania sposobu implementowania wymagania. Uwzględnij wystarczający kontekst, aby zespół mógł pisać zadania i przypadki testowe z elementu.
W polach HTML można dodawać tekst bogaty i obrazy.
Zarejestruj wpływ braku realizacji wymagania na klienta w sformatowanym polu tekstowym ocena wpływu. Możesz uwzględnić szczegóły modelu Kano, które wskazują, czy wymaganie jest zaskakujące, wymagane, czy oczywiste.
Typ wymagania (wymagany)
Określ jedną z tych wartości dla opcji Typ wymagania:
- Cel biznesowy
- Funkcja (wartość domyślna)
- Functional
- Interface
- Operational
- Jakość usług
- Safety
- Scenario
- Security
Wskaż obszar wartości klienta, który adresuje epik, funkcja lub wymaganie. Typowe wartości to:
- Architektura: usługi techniczne do implementowania funkcji biznesowych, które zapewniają możliwości rozwiązania.
- Biznes: usługi spełniające potrzeby uczestników projektu i bezpośrednio dostarczające wartość klienta (wartość domyślna).
Szacuj pracę wymaganą do wykonania wymagania przy użyciu dowolnej jednostki liczbowej preferowanej przez twój zespół. Zespoły używają opcji Rozmiar dla wykresów prędkości i prognoz. Diagram przepływu skumulowanego odwołuje się również do wartości w tym polu. Aby uzyskać więcej informacji, zobacz oficjalny dokument dotyczący szacowania .
Podaj oryginalne oszacowanie zadania. Zazwyczaj ta wartość nie zmienia się po przypisaniu zadania. Możesz określić pracę w godzinach lub dniach; pole nie ma nieodłącznej jednostki czasowej.
Podaj docelowe daty rozpoczęcia i zakończenia pracy.
Priorytet (wymagany)
Ustaw ocenę subiektywną, która odzwierciedla priorytet biznesowy:
- 1: Produkt nie może być dostarczony bez elementu.
- 2: (ustawienie domyślne) Produkt nie może być dostarczony bez elementu, ale nie wymaga natychmiastowej uwagi.
- 3: Implementacja jest opcjonalna na podstawie zasobów, czasu i ryzyka.
Użyj Triage, gdy element roboczy jest w stanie Proponowany. Wybierz jedną z opcji: Oczekujące na rozstrzygnięcie (ustawienie domyślne), Więcej informacji, Informacje otrzymane, Ztriage’owane.
Określ, czy członek zespołu nie może poczynić postępów w elemencie roboczym. Jeśli problem blokuje działanie, utwórz link do problemu. Wybierz pozycję Tak lub Nie.
Zatwierdzone (wymagane)
Określ, czy zespół zobowiązał się do spełnienia wymagań. Wybierz pozycję Tak lub Nie (ustawienie domyślne).
Zarejestruj numer kompilacji produktu, który zawiera wymagania, żądanie zmiany lub poprawkę usterki.
Test akceptacji użytkownika (wymagany)
Ustaw status testu akceptacji użytkownika dla wymagania z:
- Pass
- Fail
- Nie gotowe (wartość domyślna)
- Ready
- Skipped
- Odebrane informacje
Użyj opcji Nie gotowe , gdy wymaganie jest aktywne i gotowe po rozwiązaniu problemu.
Wymień członków zespołu zaznajomionych z obszarem klienta, z którymi wiąże się 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 pojawia się pod obszarem wprowadzania tekstu po umieszczeniu kursora w dowolnym polu tekstowym obsługującym formatowanie tekstu.
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.
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 wspomniano kogoś, połączono z elementem roboczym lub połączono z pull requestem.
To samo menu można otworzyć przy użyciu skrótów klawiaturowych: wzmianka @, znak hash # i wykrzyknik !.
Wprowadź nazwę lub numer, aby filtrować listę menu w celu dopasowania do wpisu. Wybierz wpis, który chcesz dodać. Aby wprowadzić grupę do dyskusji, wprowadź symbol at@, a następnie nazwę grupy, na przykład zespół lub grupa zabezpieczeń.
Edytuj lub usuń komentarz
Aby edytować lub usunąć dowolne komentarze do dyskusji, wybierz pozycję Edytuj
lub więcej akcji (
), a następnie wybierz pozycję Usuń:
Po zaktualizowaniu komentarza wybierz pozycję Aktualizuj. Aby usunąć komentarz, potwierdź usunięcie. Karta Historia w formularzu elementu roboczego przechowuje pełny dziennik audytu wszystkich edytowanych i usuniętych komentarzy.
Important
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ę emoji w prawym górnym rogu dowolnego komentarza. Wybierz 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.
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 komentarzy do dyskusji o elemencie roboczym, to możesz to zrobić, zapisując komentarze. To uprawnienie jest kontrolowane przez węzły ścieżki obszaru oraz uprawnienie Edytuj komentarze elementów roboczych w tym węźle. Aby uzyskać więcej informacji, zobacz Ustaw uprawnienia do śledzenia pracy — twórz węzły podrzędne, modyfikuj elementy robocze w ramach obszaru lub ścieżki 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 pracy
W miarę postępu pracy zaktualizuj pole Stan, aby odzwierciedlić bieżący stan. Opcjonalnie podaj przyczynę; pola stanu i przyczyny są wyświetlane w nagłówku formularza elementu roboczego.
Stany przepływu pracy cmMI
Na poniższych diagramach przedstawiono główne stany progresji i regresji dla WIT wymagań, błędów i zadań.
| Requirement | Bug | Task |
|---|---|---|
|
|
|
Typowy przepływ pracy dla wymagania jest zgodny z następującymi krokami:
- Właściciel produktu tworzy wymaganie w stanie Proponowane z przyczyną domyślną New requirement (Nowe wymaganie).
- Właściciel produktu przenosi wymaganie do Active po rozpoczęciu pracy.
- Zespół ustawia status wymagań na Rozwiązano, gdy programowanie jest zakończone i testy systemowe są udane.
- Na koniec właściciel zespołu lub produktu przenosi wymaganie do stanu Zamknięte po tym, jak kryteria akceptacji i testy weryfikacyjne potwierdzą ukończenie.
Aktualizowanie stanu pracy za pomocą tablicy lub tablicy zadań
Użyj tablicy lub tablicy zadań sprintu, aby zaktualizować stany elementów. Przeciągnięcie elementu do innej kolumny aktualizuje pola Stan i Przyczyna.
Tablicę można dostosować, aby dodać więcej pasów lub kolumn pływaków.
Mapuj wymagania dotyczące funkcji
W przypadku zarządzania wieloma produktami lub doświadczeniami użytkownika zdefiniuj funkcje i przypisz wymagania do tych funkcji, aby wyświetlić zakres i postęp w całym portfolio.
Użyj rejestrów zadań portfela, aby zgłębiać poziomy listy prac i podsumowywać zadania w toku między zespołami. Zbiorcze dane można również wyświetlać po skonfigurowaniu hierarchii zespołów.
Element pracy funkcji zawiera pola podobne do wymagań oraz inne pola opisane w jego dokumentacji referencyjnej.
Definiowanie zadań
Gdy zespół dostarcza pracę w sprintach, podziel wymagania na zadania ze strony backlogu sprintu i szacuj nakład pracy.
Nadaj zadaniu nazwę i szacuj pracę.
Gdy zespoły szacują pracę, definiują zadania i szacują godziny lub dni ich ukończenia. Zespoły prognozują pojemność i uściśliją zadania na początku iteracji; każdy członek zespołu wykonuje następnie podzestaw zadań. Zadania mogą obejmować programowanie, testowanie i inne działania. Na przykład deweloper tworzy zadania w celu zaimplementowania wymagania, podczas gdy tester tworzy zadania do pisania i uruchamiania przypadków testowych. Łącząc zadania z wymaganiami i usterkami, zespoły wyraźnie widzą postęp implementacji. Aby uzyskać więcej informacji, zobacz Działania iteracji.
Field
Usage
Wybierz typ zadania z:
- Akcja naprawcza
- Akcja zaradcze
- Planned
Wybierz dyscyplinę reprezentującą to zadanie podczas szacowania wydajności sprintu według aktywności.
- Analysis
- Development
- Test
- Edukacja użytkowników
- Środowisko użytkownika
To pole pomaga również obliczyć pojemność według dyscypliny. Jest przypisany do type="Activity" w pliku ProcessConfiguration. Aby uzyskać więcej informacji, zobacz Implementowanie zadań programistycznych.
Wprowadź oryginalne oszacowanie zadania.
Aktualizuj pozostałą pracę w miarę postępu zespołu. Ta wartość zasila wykresy pojemności, wykres spalania sprintu i powiązane raporty. Jeśli podzielisz zadanie na podzadania, śledź tylko godziny podzadania.
Zarejestruj pracę, na którą już zostało poświęcone czas przy realizacji zadania.
Śledzenie postępu testu
Wymagania testowe
W portalu internetowym lub Menedżerze testów utwórz przypadki testowe, które automatycznie łączą się z wymaganiem lub usterką, albo dodaj link z 
karty (linki).
Przypadek testowy zawiera wiele pól, w tym pola integrujące się z procesem kompilacji i testowania. Aby uzyskać szczegółowe informacje, zobacz Zapytanie oparte na polach integracji kompilacji i testowania .
Karta (linki) zawiera listę wszystkich wymagań i usterek, do których odwołuje się przypadek testowy. Łączenie pomaga zespołom śledzić postęp testów i obsługuje raporty, takie jak raport Przegląd wymagań.
Śledzenie wad kodu
Tworzenie usterek z poziomu portalu internetowego, programu Visual Studio lub Menedżera testów (zobacz Zarządzanie usterkami).
Śledzenie żądań zmian, czynników ryzyka, problemów i notatek przechwyconych podczas spotkań przeglądu
Oprócz wymagań, funkcji, zadań i błędów proces CMMI zaleca następujące WIT-y:
- Żądanie zmiany w celu zarządzania proponowanymi zmianami w produktach prac objętych kontrolą zmian.
- Problem z śledzeniem zdarzeń lub sytuacji, które mogą blokować pracę. Problemy różnią się od ryzyka , ponieważ zespoły zwykle identyfikują problemy spontanicznie podczas codziennych spotkań.
- Ryzyko monitorowania prawdopodobieństwa i wariancji między rzeczywistymi i pożądanymi wynikami. Podczas zarządzania ryzykiem można zminimalizować wariancję między oczekiwanym i rzeczywistymi wynikami.
- Zrecenzuj, aby udokumentować, w jaki sposób przegląd projektu lub kodu spełnia standardy, takie jak poprawność nazw, istotność kodu, rozszerzalność, złożoność i zabezpieczenia.
Problem można dodać przy użyciu widżetu Nowy element roboczy na pulpicie nawigacyjnym zespołu lub z menu Nowy na stronie Zapytania.
Elementy robocze dodane z widżetu automatycznie przypisują się do domyślnego obszaru i ścieżek iteracji zespołu. Aby zmienić kontekst zespołu, sprawdź Przełącz kontekst 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. Najczęściej używane karty obejmują 
historię, linki i 
załączniki.
Jedynym polem wymaganym dla wszystkich typów elementów roboczych jest Tytuł. Podczas zapisywania elementu roboczego system przypisuje unikatowy identyfikator, ID. Formularz wyróżnia wymagane pola w kolorze żółtym. Aby uzyskać informacje o innych polach, zobacz Indeks pól elementu roboczego.
Note
Inne pola mogą być wymagane w zależności od dostosowań dokonanych w procesie i projekcie.
Pole lub zakładka
Usage
Wprowadź opis 255 znaków lub mniej. Tytuł można zmodyfikować później.
Przypisz element roboczy do członka zespołu odpowiedzialnego za wykonywanie pracy lub pozostaw ten element pusty i ukończ zadanie później.
Po pierwszym utworzeniu elementu roboczego pole Stan automatycznie wyświetla pierwszy stan w przepływie pracy, taki jak Nowy lub Nieprzypisany. W miarę postępu pracy zaktualizuj stan , aby odzwierciedlał bieżący stan elementu roboczego.
Podczas pierwszego tworzenia elementu roboczego ustaw domyślną wartość Przyczyna , taką jak Utworzono lub Nowy element roboczy. W miarę zmiany stanu elementu roboczego należy odpowiednio zaktualizować wartość Przyczyna . Każdy stan elementu roboczego jest skojarzony z domyślną wartością Przyczyna .
Wybierz ścieżkę obszaru skojarzoną z produktem lub zespołem, lub pozostaw ją pustą i wprowadź odpowiednią wartość później. Listę rozwijaną dostępnych obszarów można zmienić. Aby uzyskać więcej informacji, zobacz Definiowanie ścieżek obszaru i przypisywanie do zespołu.
Wybierz przebieg lub iterację, w której chcesz ukończyć element roboczy, lub pozostaw wartość pustą i przypisz ją później. Można zmienić listę rozwijaną z iteracjami. Aby uzyskać więcej informacji, zobacz Definiowanie ścieżek iteracji (sprintów) i konfigurowanie iteracji zespołu.
Zakładka Historia
Wyświetl historię elementu roboczego, aby wyświetlić wszystkie zmiany wprowadzone w elemencie, które zostały przechwycone przez system. Za każdym razem, gdy element roboczy jest aktualizowany, szczegóły są dołączane do historii. Zostanie wyświetlona data zmiany, autor zmian i lista zaktualizowanych pól. Możesz również dodać sformatowany tekst do pola Historia .
Karta Linki
Dodaj łącza , aby tworzyć połączenia z innymi elementami roboczymi. Obsługiwanych jest wiele rodzajów łączy, takich jak hiperlinki, zestawy zmian, pliki źródłowe i inne. Określ relację połączonego elementu z elementem roboczym, na przykład Element nadrzędny, Znaleziony w kompilacji lub Wynik testu.
Karta Załączniki
Użyj załączników do uwzględnienia informacji pomocniczych dotyczących elementu roboczego, dołączając je do niego. Dołączanie wątków wiadomości e-mail, dokumentów, obrazów, plików dziennika lub innych typów 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.
Treści powiązane
- Utwórz projekt
- Dodawanie elementów roboczych i zarządzanie projektem
- Stwórz zaległości
- 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
Użyj pola Stack Rank, aby śledzić względną kolejność wymagań, funkcji lub epiki. Strona listy prac określa sekwencję na podstawie miejsca dodawania lub przenoszenia elementów na stronie (zobacz Tworzenie listy prac). Podczas przeciągania elementów proces w tle aktualizuje pole Stack Rank. To pole nie jest domyślnie wyświetlane w formularzu elementu roboczego.