Typy elementów szablonów roboczych procesu CMMI oraz przepływ pracy

  • Artykuł

Zespoły korzystają z typów elementów roboczych (WIT) z szablonu procesu MSF for CMMI Process Improvement 2013 (CMMI), aby planować i śledzić postęp projektów tworzenia oprogramowania.Zespoły Definiowanie wymagań dotyczących zarządzania zaległości pracy i, za pomocą tablicy Kanban, śledzić postęp przez zaktualizowanie stanu wymagań.

Typy elementów roboczych CMMI 7.0

Na uzyskiwanie szczegółowych informacji dotyczących szeroką gamę wymagania, właściciele produktu można mapować wymagania do funkcji.Zespoły pracy iteracji, definiują zadania, które automatyczne łączenie z wymaganiami.

Przy użyciu Microsoft Test Manager zespołu sieci Web Access (TWA), testerzy utworzyć i uruchomić i przypadków testowych zdefiniować usterek do śledzenia usterek kodu.

Do obsługi dodatkowych procesów CMMI, zespoły mogą śledzić ryzyka żądania zmiany, problemy i uwagi dotyczące przechwytywane Przejrzyj spotkań.

Planowanie projektu poprzez określenie wymogów i oszacowanie wielkości nakładu pracy

Utwórz wymagania z panelu szybkiego dodawania na stronie zaległości produktu.Można też zbiorczo dodać wymagania przy użyciu programu Excel lub Project.

Szybkie dodawanie panelu na stronie zaległości wymagania

Później można otworzyć każde wymaganie w celu dostarczenia bardziej szczegółowych informacji i oszacowania jego rozmiaru.

Formularza elementu pracy wymagań

Wymagania określają funkcje i elementy produktu, które zespoły muszą utworzyć.Właściciele produktu zazwyczaj zdefiniują wymagania rangi stosu na stronie zaległości produktu.Następnie zespół oszacowuje nakład pracy związany z dostarczeniem elementów o najwyższym priorytecie.

Definiując Rozmiar związany z wymaganiami, zespoły mogą korzystać z funkcji prognozy i wykresów prędkości, aby oszacować przyszłe iteracje lub nakłady pracy.Przechwytuj istotne informacje za pomocą następujących pól i kart.Aby uzyskać dodatkowe wskazówki, zobacz Planowanie projektu.

Pole/karta

Użycie

Rozmiar (patrz uwaga 1)

Szacowanie ilości pracy wymaganej do ukończenia wymogu przy użyciu dowolnej jednostki miary, którą preferuje zespół, takiej jak rozmiar koszulki, punkty historii lub czas.

Wykresy prędkości Agile i narzędzia prognozowania odwołują się do wartości w tym polu.To pole jest wymagane do generowania wykresów szybkości pracy.

Priorytet [wymagane] (2)

Subiektywna ocena wymagania, jak to odnosi się do działalności.Dozwolone wartości to:

  • 1: Produktu nie można wysłać bez elementu.

  • 2: (ustawienie domyślne) Produktu nie można wysłać bez elementu, ale nie musi on być niezwłocznie kierowany.

  • 3: Implementacja tego elementu jest opcjonalna odpowiednio do zasobów, czasu i ryzyka.

Klasyfikacja [Wymagane] (2)

Wskazuje typ decyzji klasyfikacji, który jest w stanie oczekiwania na element roboczy.Użyj tego pola, gdy element roboczy jest w stanie Proponowane i określ jedną z następujących wartości: Oczekujące (ustawienie domyślne), Więcej informacji, Otrzymane informacje i Zaklasyfikowany.

Zablokowany (2)

Wskazuje, czy nie powstrzymano elementu członkowskiego od zrobienia postępu w kierunku implementacji wymagania lub zadania lub rozwiązania problemu, zmiany żądania bądź ryzyka.Jeśli zostanie otwarty problem do śledzenia problemu z blokowaniem, możesz utworzyć łącze do tego problemu.Możesz określić Tak lub Nie.

Zatwierdzono [Wymagane] (2)

Wskazuje, czy wymóg jest zaangażowana w projekt, czy nie.Możesz określić Tak lub Nie (domyślnie).

Ranga na stosie (1)

Używane do śledzenia względnej klasyfikacji wymagań.Sekwencja elementów na stronie dziennika zaległości produktu jest określana zgodnie z miejscem, w którym dodano elementy lub przeniesiono elementy na stronę.Podczas przeciągania elementów proces w tle aktualizuje zawartość tego pola, które jest przypisane do typu="Order" w pliku ProcessConfiguration.

(Wymaganie) Typ [Wymagane] (2)

Rodzaj wymagania do zaimplementowania.Można określić jedną z następujących wartości:

  • Cel biznesowy

  • Funkcja (domyślnie)

  • Funkcjonalne

  • Interface

  • Operacyjne

  • Jakość usług

  • Bezpieczeństwo

  • Scenariusz

  • Zabezpieczenia

Opis

Zapewnij wystarczającą liczbę szczegółów dla szacowania, ile pracy będzie trzeba do zaimplementowania wymagania.Skup się na tym, dla kogo jest wymaganie, co użytkownicy chcą osiągnąć i dlaczego.Nie opisuj, jak należy zbudować to wymaganie.Zapewniaj wystarczające szczegóły, tak aby zespół mógł napisać zadanie i przypadki testowe potrzebne do wdrożenia elementu.

W polach języka HTML można dodać tekst sformatowany i obrazy.

Analiza

(Oceny wpływu)

Wpływ klienta na niestosowanie tego wymogu.Możesz dołączyć szczegóły z modelu Kano dotyczące tego, czy wymóg ten mieści się w kategorii zaskoczenie, wymagane czy oczywiste.Przechwytujesz tę informację w polu HTML tekstu sformatowanego odnoszącym się do oceny wpływu.

Inne

Następujące pola, znajdujące się na karcie Inne, nie są wymagane.

  • Zintegrowane w: numer kompilacji produktu, który zawiera wymóg lub żądanie zmiany albo naprawia błąd.

  • Test akceptacji użytkownika [Wymagane] [2]: Stan testu akceptacji użytkownika.

    • Zakończony powodzeniem

    • Niepowodzenie

    • Nie gotowy (domyślnie)

    • Gotowe

    • Pominięto

    • Otrzymane informacje

    Określ Nie gotowy, kiedy wymaganie jest Aktywne, i Gotowe, kiedy wymaganie jest Rozwiązane.

  • Początkowe oszacowanie (3): liczba godzin lub dni potrzebnych do wykonania zadania.

  • Eksperci merytorycznych: Nazwy członków zespołu, którzy są zaznajomieni z obszarem klienta, który reprezentuje ten wymóg.

  • Data rozpoczęcia, Data zakończenia (3): Docelowe daty rozpoczęcia lub zakończenia pracy.Te pola są wypełniane przez Program Microsoft Project, jeśli zostanie on użyty do planowania.

Uwagi:

  1. Aby zmienić przydział pola, zobacz Konfigurowanie i dostosowywanie narzędzi planowania Agile do projektu zespołowego.

  2. Aby zmienić wybór menu, zobacz dostosować listę pobrania.

  3. Możesz określić prace w godzinach lub w dniach.Nie ma nieodłącznych jednostek czasu powiązanych z tym polem.

    Jeśli używasz programu Microsoft Project do przypisywania zasobów i śledzenia zgodności z harmonogramem, można zaktualizować te pola w programie Project.

Śledzenie postępu

Zespoły mogą korzystać z tablicy Kanban w celu śledzenia postępu wymagań i błędów i tablicy zadań sprint w celu śledzenia postępu zadań.Przeciąganie elementów na nową kolumnę stanu aktualizuje przepływ pracy w polach Stan i Przyczyna.

Zaległości wymagania tablicy Kamban

Możesz dostosować tablicę Kanban, aby obsługiwała dodatkowe tory lub kolumny.Lub możesz dostosować przepływ pracy do typów elementów roboczych wymagań i zadań, co zmieni domyślne nagłówki kolumn.

Typowy postęp przepływu pracy dla wymagania:

  • Właściciel produktu tworzy wymaganie w stanie Proponowane z domyślną przyczyną Nowe wymaganie.

  • Właściciel produktu aktualizuje stan do wartości Aktywne, gdy zaczyna pracę nad jego implementacją.

  • Zespół aktualizuje stan rozwiązany po zakończeniu tworzenie kodu i testów systemowych zostały zakończone pomyślnie.

  • Wreszcie, właściciel zespołu lub produktu przenosi wymóg Zamknięty, kiedy właściciel produktu zgadza się, że został on zrealizowany zgodnie z kryteriami przyjęcia i przeszedł wszystkie testy sprawdzania poprawności.

Mapowanie wymagań do funkcji

Podczas zarządzania pakietem produktów lub doświadczeniami użytkownika, możesz chcieć wyświetlić zakres i postęp prac dla całego portfolio produktu.Można to zrobić poprzez określenie funkcji i mapowanie wymagań do funkcji.

Na stronie zaległości Funkcja można szybko dodać funkcje w taki sam sposób jak dodano wymagania.

Szybkie dodawanie panelu strony zaległości portfolio funkcje

Element pracy funkcji zawiera podobne pola zapewnione dla wymogów i zawiera dodatkowe pola, zgodnie z opisem w poniższej tabeli.

Funkcja formularza elementu pracy dla CMMI

Karta Wymagania zawiera łącza do mapowanych wymagań.

Pole

Użycie

Wartość firmy

Określ liczbę, która przechwytuje wartość względną funkcji w porównaniu z innymi funkcjami.Im wyższa liczba, tym większe wartości biznesowej.

Data docelowa

Określ datę, przed którą funkcja powinna zostać zaimplementowana.

Ze strony zaległości z włączoną funkcją Mapowanie można przeciągnąć wymagania do funkcji, którą implementują.

Mapa wymóg funkcji

To mapowanie tworzy łącza nadrzędny-podrzędny pomiędzy funkcją a wymaganiami, co jest przechwytywane w karcie Wymagania.

Używając zaległości portfolio, można drążyć z jednej zaległości do innej w celu obejrzenia preferowanego poziomu szczegółowości.Ponadto można użyć portfolio zaległości, aby przejrzeć pakiet zbiorczy w toku dla kilku zespołów, kiedy użytkownik skonfiguruje hierarchię zespołów.

Zdefiniuj zadania wymagane do wdrożenia wymogów i śledzenia wydajności zespołu i postępu

Gdy zespół zarządza swoją pracą w szeregu iteracji, może użyć strony zaległości sprintu do podziału pracy wymagającej wykonania na różne zadania.

Dodaj łącze zadania na stronie zaległości sprint

Nadaj nazwę zadaniu i oszacuj pracę, jaką zajmie.

Formularz elementu roboczego zadania CMMI

Zespoły, szacując pracę, określają zadania i szacują godziny lub dni potrzebne na ukończenie zadania.Zespoły przewidują pracę i określają zadania na początku iteracji, a każdy członek zespołu wykonuje część tych zadań.Zadania mogą obejmować projektowanie, testowanie oraz inne rodzaje pracy.Na przykład deweloper może zdefiniować zadania do implementowania wymagań, a tester może zdefiniować zadania do pisania i uruchamiania przypadków testowych.Łącząc zadania z wymaganiami i błędami można obserwować postępy związane z tymi elementami.Aby uzyskać dodatkowe wskazówki, zobacz Działania iteracyjne.

Pole

Użycie

Typ zadania (patrz Uwaga 1)

Wybierz typ zadania do wykonania z wartości dopuszczalnych:

  • Działania naprawcze

  • Akcja ograniczenia

  • Planowane

Dyscyplina (1)

Wybierz dyscyplinę przedstawianą przez to zadanie, gdy zespół oszacowuje wydajność sprintu według działań.

  • Analiza

  • Tworzenie

  • Test

  • Edukacja użytkownika

  • Doświadczenie użytkownika

To pole jest również używane do obliczania przepustowości dla dyscypliny.Jest przypisany do type="Activity" w pliku ProcessConfiguration.(2)

Aby uzyskać dodatkowe wskazówki, zobacz Implementowanie zadań programistycznych.

Początkowe oszacowanie (3)

Szacowana ilość pracy wymagana do ukończenia zadania.Zazwyczaj pole to nie zmienia się po przypisaniu.

Pozostała praca (3)

Wskazuje, ile godzin lub dni pracy pozostają do wykonania zadania.W miarę postępów prac aktualizuj to pole.Jest używana do obliczania zdolności wykresów na wykresie wypalenia w sprincie i Raport dotyczący wypalenia i szybkości spalania raporcie.

Jeśli dzielisz zadanie na podzadania, należy określić tylko godziny podzadań.Można określić pracę w jakiejkolwiek jednostce miary, jaką zespół wybiera.

Praca wykonana (3)

Ilość pracy, która została zastosowania do wykonania zadania.

Uwagi:

  1. Aby zmienić wybór menu, zobacz dostosować listę pobrania.

  2. Aby zmienić przydział pola, zobacz Konfigurowanie i dostosowywanie narzędzi planowania Agile do projektu zespołowego.

  3. Możesz określić prace w godzinach lub w dniach.Nie ma nieodłącznych jednostek czasu powiązanych z tym polem.

    Jeśli używasz programu Microsoft Project do przypisywania zasobów i śledzenia zgodności z harmonogramem, można zaktualizować te pola w programie Project.

Śledź postęp testów na przypadkach użycia i przechwytuj usterki kodu

Przetestowane wymagania

Za pomocą Menedżera testów lub programu TWA można tworzyć przypadki testowe, które automatyczne łączą się z wymaganiem lub błędem.

Zaznacz zestaw testów i Dodaj przypadek testowy

Przypadek testowy zawiera kilka pól, z których wiele jest zautomatyzowanych i zintegrowanych z Test Manager i procesem kompilacji.Opis wszystkich pól, zobacz: Odwołanie do pól kompilacji i integracji testowania.

Formularza elementu pracy przypadek testowy

Karta Przetestowane wymagania wymienia wszystkie wymagania i błędy w przypadku testowym.Za pomocą łączenia zespół może śledzić postęp osiągnięty podczas badania każdego elementu i obsługiwać informacje, które pojawiają się w raporcie Przegląd wymagań — Raport (CMMI).

Śledź usterki kodu

Można utworzyć błędy z TWA, Visual Studio lub podczas testów przy użyciu Menedżera Testów.Aby uzyskać dodatkowe wskazówki, zobacz Śledzenie błędów.

Usterki dla projektu zespołowego CMMI (formularza elementu pracy)

Pole/karta

Użycie

Przyczyna główna

Wybierz przyczynę błędu z wartości dopuszczalnych:

  • Błąd kodowania

  • Błąd projektu

  • Błąd specyfikacji

  • Błąd komunikacji

  • Nieznany

Aby zmienić wybór menu, zobacz dostosować listę pobrania.

Kroki do odtworzenia

Przechwyć wystarczające informacje, tak aby inni członkowie zespołu mogli zrozumieć całkowity wpływ problemu, a także, czy naprawili błąd.Dotyczy to działań podjętych w celu znalezienia lub odtworzenia błędu i oczekiwanego zachowania.

Opisz kryteria, których powinien użyć zespół, aby sprawdzić, czy wada kodu została rozwiązana.

Ważności

Wybierz jedną z wartości dopuszczalnych, które reprezentują subiektywną ocenę wpływu błędu na projekt:

  • 1 - Krytyczny

  • 2 - Wysoki

  • 3 - Średni

  • 4 - Niski

Aby zmienić wybór menu, zobacz dostosować listę pobrania.

Informacje o systemie

Znaleziono w kompilacji

Zintegrowane w kompilacji

Gdy Test Manager tworzy błędy, automatycznie wypełnia Informacje o systemie i Znaleziono w kompilacji informacjami o środowisku oprogramowania i kompilacji, w których wystąpił błąd.Aby uzyskać więcej informacji na temat definiowania środowiska oprogramowania, zobacz Konfigurowanie maszyn testowych do potrzeb uruchamiania testów lub zbierania danych.

Podczas rozwiązywania problemu użyj opcji Zintegrowane w kompilacji, aby wskazać nazwę kompilacji zawierającej kod lub naprawiającej błąd.

Aby uzyskać dostęp do menu rozwijanego, wszystkie kompilacje, uruchomionych, można zaktualizować FIELD definicje znalezione w kompilacji i zintegrowany w kompilacji, można odwoływać się do globalnej listy.Globalna lista jest aktualizowana automatycznie każdego kompilacji, który jest uruchamiany.Aby dowiedzieć się więcej, zobacz Pola obsługujące integrację z testowaniem, kompilowaniem i kontrolą wersji.

Informacje na temat do definiowania nazw kompilacji, zobacz Użycie numerów kompilacji jako opisowych nazw zakończonych kompilacji.

Śledź żądania zmian, ryzyko, problemy i notatki przechwycone podczas spotkań przeglądowych

Dzięki poniższym WIT zespoły mogą śledzić informacje zalecane przez proces CMMI.

  • Utwórz żądanie zmiany, gdy proponuje się wprowadzenie zmiany do każdego produktu pracy, który jest pod kontrolą zmian.Aby uzyskać dodatkowe wskazówki dotyczące użycia, zobacz Zarządzanie zmianami i Odwołanie do pola zmiany żądania (CMMI).

    Żądanie zmiany CMMI formularza elementu pracy - karty

    Na karcie Analiza podaj szczegóły dotyczące wpływu tego żądania zmiany na architekturę, wrażenia użytkownika, test, projekt/wdrożenie lub publikacje techniczne.

  • Utwórz problem, aby śledzić zdarzenie lub sytuację, która może spowodować zablokowanie pracy lub blokuje prace nad produktem.Problemy różnią się od ryzyka w tym, że zespoły identyfikują problemy spontanicznie, zazwyczaj podczas dziennych spotkań zespołu.

    Formularza elementu pracy problem CMMI - karty

    Aby uzyskać dodatkowe wskazówki, zobacz Zarządzanie problemami i Odwołania do pól z błędami, usterkami i ryzykami (CMMI).

  • Utwórz ryzyko, aby śledzić zdarzenie lub sytuację, która może spowodować zablokowanie pracy lub blokuje prace nad produktem.Problemy różnią się od ryzyka w tym, że zespoły identyfikują problemy spontanicznie, zazwyczaj podczas dziennych spotkań zespołu.

    Formularza elementu pracy ryzyko CMMI - karty

    Aby uzyskać dodatkowe wskazówki, zobacz Zarządzanie ryzykiem i Odwołania do pól z błędami, usterkami i ryzykami (CMMI).

  • Utwórz ocenę, aby udokumentować wyniki przeglądu projektu lub kodu.Członkowie zespołu mogą rejestrować szczegóły dotyczące tego, jak projekt lub kod spełnia normy w zakresie poprawności nazwy, znaczenia kodu, rozszerzalności, złożoności kodu, złożoności algorytmicznej i bezpieczeństwa kodu.

    Formularz przeglądu CMMI do elementu pracy - karty

    Aby uzyskać dodatkowe wskazówki, zobacz Implementowanie zadań programistycznych i Przegląd odwołań pola spotkań (CMMI).

Definiuj pola i karty wspólnych elementów roboczych

Poniższe pola i karty pojawiają się w większości formularzy elementów roboczych.Każda karta jest używana do śledzenia określonych informacji, takich jak Historia, Łącza lub Załączniki.Te trzy pola zawierają historię zmian i widok połączonych elementów roboczych oraz dają możliwość przeglądania i dołączania plików.

Jedyne wymagane pole to Tytuł.Po zapisaniu elementu roboczego system przypisuje do niego unikatowy Identyfikator.

Pole/karta

Użycie

Tytuł (wymagany)

Wprowadź opis nie dłuższy niż 255 znaków.Nazwę tę można później zmienić.

Przypisane do

Przypisz element roboczy do członka zespołu, który będzie odpowiedzialny za wykonanie prac.W zależności od kontekstu, w którym pracujesz, menu rozwijane wyświetli tylko listę członków zespołu lub współtwórców projektu zespołowego.

Stan

Użyj najpierw wartości domyślnej.W miarę postępów prac przeprowadzaj aktualizacje, aby odzwierciedlić bieżący stan.

Aby zmienić listę rozwijaną stanów, zobacz Zmiana przepływu pracy dla typu elementu pracy.

Przyczyna

Użyj najpierw wartości domyślnej.Aktualizuj po zmianie stanu.Każdy stan jest związany z powodem domyślnym.

Aby zmienić listę rozwijaną przyczyn, zobacz Zmiana przepływu pracy dla typu elementu pracy.

Obszar

Wybierz ścieżkę obszaru skojarzoną z produktem lub zespołem bądź pozostaw puste do momentu przydzielenia podczas planowania spotkania.

Aby zmienić listę rozwijaną obszarów, zobacz Dodawanie i modyfikowanie obszaru i ścieżek iteracji.

Iteracja

Wybierz sprint lub iterację, w których ma się odbyć praca, lub pozostaw to pole puste i przypisz je później, podczas planowania spotkania.

Aby zmienić listę rozwijaną iteracji, zobacz Dodawanie i modyfikowanie obszaru i ścieżek iteracji.

Wszystkie łącza

Dodaj wszystkie typy łączy, takie jak hiperłącza, zestawy zmian, pliki źródłowe i tak dalej.

Ta karta zawiera również listę wszystkich łączy zdefiniowanych dla elementu pracy, nawet tych zdefiniowanych na innych kartach formantów łączy.

Załączniki

Udostępnij bardziej szczegółowe informacje przez dodanie do elementu roboczego plików, takich jak wątki wiadomości e-mail, dokumenty, obrazy, pliki dziennika lub inne typy plików.

Historia

Przejrzyj dziennik inspekcji przechwytywany przez system oraz dodatkowe przechwycone informacje.

Ilekroć dany element roboczy jest aktualizowany, informacje są dodawane do historii.Historia zawiera datę zmiany, kto wprowadził zmianę i które pola zostały zmienione.Możesz również dodać sformatowany tekst do pola historii.

Aby wyszukać informacje o innych polach, zobacz Indeks pól elementu roboczego.

Uruchom śledzenie pracy

Przed rozpoczęciem pracy śledzenia, musi mieć projektu zespołowego.Przejdź tutaj o jego utworzenie.

Aby rozpocząć śledzenie pracy, wykonaj co najmniej jedną z następujących czynności:

Pytania i odpowiedzi

Q: stany jakie przepływu pracy czy obsługuje CMMI?

Odp tych diagramów Pokaż głównego postęp i regresji stanów funkcji, wymagania, usterki i zadania.Aby dostosować przepływu pracy, przejdź tutaj.

Funkcja

Funkcja Stany przepływu pracy, CMMI szablonu procesu.

Wymaganie

Stany przepływu pracy wymagań, CMMI szablonu procesu.

Usterka

Stany przepływu pracy usterkę, CMMI szablonu procesu.

Zadanie

Zadanie Stany przepływu pracy, CMMI szablonu procesu.

Pyt jak Rozwiąż usterkę jako duplikat?

Odp ustawioną stan usunięte i określić powód jako duplikat.

Pyt jak połączyć z usterki z narzędzie Test Runner?

Odp zobacz aktualizacji usterki podczas używania narzędzia Test Runner.