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 Kanban, śledzą 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.

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 obsługiwana i obsługuje zbiorcze importowanie i aktualizowanie elementów roboczych. Alternatywy dla korzystania z programu Microsoft Project obejmują:

• Plany dostarczania.
• Rozszerzenie witryny Marketplace, takie jak project Połączenie 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

---

Opis

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ływu

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 )
• Funkcjonalne
• Interfejs
• Operacyjne
• Jakość usług
• Bezpieczeństwo
• Scenariusz
• Bezpieczeństwo

Obszar wartości

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)

Rozmiar

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 Kanban odwołuje się do wartości w tym polu. Aby uzyskać więcej informacji, zobacz oficjalny dokument dotyczący szacowania .

Oryginalne oszacowanie

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.

Data rozpoczęcia/data zakończenia

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.

Klasyfikacja (wymagana )

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.

Zablokowane

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

Zintegrowane w systemie

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:

• Przekazać
• Nie
• 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.

Eksperci z dziedziny

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 sformatowanych jest wyświetlany poniżej obszaru wprowadzania tekstu. Zostanie ono wyświetlone po wybraniu każdego pola tekstowego obsługującego formatowanie tekstu.

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

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

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.

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.

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ą zdefiniowane żadne reguły elementów roboczych 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	Usterka	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 przy użyciu kanbanu lub tablicy zadań

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

Możesz dostosować tablicę Kanban, aby obsługiwać więcej pasów ruchu lub kolumn. Aby uzyskać więcej opcji dostosowywania, zobacz Dostosowywanie środowiska śledzenia pracy.

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

Typ zadania

Wybierz rodzaj zadania do zaimplementowania z dozwolonych wartości:

• Działanie naprawcze

• Akcja zaradcze

• Planowane

Dyscypliny

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.

Oryginalne oszacowanie

Ilość szacowanej pracy wymaganej do wykonania zadania. Zazwyczaj to pole nie zmienia się po przypisaniu.

Praca pozostała

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ół.

Ukończono pracę

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

---

Tytuł

Wprowadź opis 255 znaków lub mniej. Tytuł można zawsze modyfikować później.

Przypisane do

Przypisz element roboczy do członka zespołu odpowiedzialnego za wykonywanie pracy.

Stanowy

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.

Przyczyna

Najpierw użyj wartości domyślnej. Zaktualizuj go po zmianie stanu. Każdy stan jest skojarzony z przyczyną domyślną.

Obszar

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.

Iteracja

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.

(Historia)

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.

(Łącza)

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.

(Załączniki)

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.

Powiązane artykuły

• Utwórz projekt
• Dodawanie elementów roboczych do zarządzania projektem
• Tworzenie listy prac
• Korzystanie z tablicy Kanban
• Planowanie przebiegu

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.