Udostępnij za pośrednictwem


Pulpit nawigacyjny usterek (CMMI)

Możesz monitorować działanie błędu dla projektu zespołowego przy użyciu pulpitu nawigacyjnego Błędy, który pokazuje następujące wykresy:

  • postęp dotyczący usterki

  • szybkość, z którą zespół znajduje, rozpoznaje i zamyka błędy

  • liczba błędów o wysokim priorytecie w czasie

  • bieżąca liczba aktywnych błędów, które są przypisane do każdego członka zespołu

    [!UWAGA]

    Masz dostęp do pulpitów nawigacyjnych za pośrednictwem portalu projektu zespołowego.Możesz uzyskać dostęp do pulpitu nawigacyjnego Błędy tylko wtedy, gdy ten portal został włączony i jest przygotowany do korzystania z SharePoint Server Enterprise Edition.Aby uzyskać więcej informacji, zobacz Pulpity nawigacyjne (CMMI).

W tym temacie

  • Dane wyświetlane na pulpicie nawigacyjnym

  • Działania wymagane dla śledzenia usterek

  • Monitorowanie aktywnych usterek i tendencji usterek

Możesz użyć tego pulpitu nawigacyjnego do udzielenia odpowiedzi na następujące pytania:

  • Jak szybko zespół rozwiązuje i zamyka usterki?

  • Czy zespół naprawia usterki na tyle szybko, by zdażyć na czas?

  • Jak wiele błędów zespół zgłasza, rozwiązuje i zamyka na dzień?

  • Czy zespół naprawia usterki o priorytecie 1 przed usterkami o priorytetach 2 i 3?

  • Czy jakiś członek zespołu ma zaległości z priorytetem 1, które gwarantują redystrybucję?

  • Jaki jest stan kompilacji z zeszłej nocy?

  • Lista najnowszych zaewidencjowań.

Wymagane są uprawnienia

Aby wyświetlić pulpit nawigacyjny, użytkownik musi być przypisany lub należeć do grupy, która ma przypisane uprawnienia odczytu w Produkty SharePoint dla projektu zespołu.Aby zmodyfikować, skopiować lub dostosować pulpit nawigacyjny, użytkownik musi być przypisany lub należeć do grupy, która ma przypisane uprawnienia Członkowie w Produkty SharePoint dla projektu zespołu.Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników do zespołów i projektów.

Aby zmodyfikować raport w Office Excel, musisz być członkiem roli zabezpieczeń TfsWarehouseDataReaders w Analysis Services SQL Server.Użytkownik musi być przypisany lub należeć do grupy, która ma przypisane uprawnienia Członkowie dla projektu zespołu w Produkty SharePoint.Aby uzyskać więcej informacji, zobacz Udzielenie dostępu do bazy danych magazynu Visual Studio Informatykami.

Aby wyświetlić usterkę lub innego typu elementy robocze, musisz być członkiem grupy Czytelnicy lub Twoje uprawnienie Wyświetl elementy robocze w tym węźle musi być ustawione na Zezwalaj.Aby utworzyć lub zmodyfikować usterkę lub innego typu elementy robocze, musisz być członkiem grupy Współautorzy lub Twoje uprawnienie Edytuj elementy robocze w tym węźle musi być ustawione na Zezwalaj.

Dane wyświetlane na pulpicie nawigacyjnym

Zespół może użyć pulpitu nawigacyjnego Błędy, aby zrozumieć jak łatwo zespół znajduje, rozwiązuje i zamyka błędy.Pulpit nawigacyjny wyświetla części sieci Web, ukazane na poniższej ilustracji i opisane w poniższej tabeli:

Pulpit nawigacyjny usterek

[!UWAGA]

Wykresy postępu, trendu i słupkowe oraz raporty od Krok 1 do Krok 4 nie są wyświetlane, gdy serwer, który obsługuje usługi Analysis Services dla projektu zespołowego, jest niedostępny.

Aby uzyskać więcej informacji dotyczących sposobu interpretowania, aktualizowania lub dostosowywania wykresów, które pojawiają się na pulpicie nawigacyjnym błędów, zobacz tematy wymienione w poniższej tabeli.

Web part

Dane wyświetlane

Tematy pokrewne

Krok 1

Wizualna reprezentacja łącznej liczby wszystkich błędów, zgrupowanych według ich statusu dla ostatnich czterech tygodni.

Raport programu Excel dotyczący postępu usterek

Raport programu Excel dotyczący postępu usterek

Krok 2

Wykres liniowy pokazuje średnią liczbę błędów, które zespół otworzył, rozwiązał i zamknął w ciągu ostatnich czterech tygodni.Średnia krocząca jest oparta na siedmiu dniach przed datą, dla której jest obliczana.

Raport trendów usterek

Tendencje usterek — Raport programu Excel

Krok 3

Wizualna reprezentacja łącznej liczby wszystkich błędów, zgrupowanych według ich priorytetu dla ostatnich czterech tygodni.

Usterki według priorytetu wykres

Usterki według priorytetu — Raport programu Excel

Krok 4

Poziomy wykres słupkowy z całkowitą liczbą błędów aktywnych, pogrupowanych według priorytetu, przypisanych do każdego członka zespołu.

Usterki przez przypisania wykresu

Usterki przez przypisanie — Raport programu Excel

Krok 5

Lista aktywnych usterek.Ta lista pochodzi ze składnika Web part Team Web Access.

Raport trendów usterek

Nie dotyczy

Krok 6

Lista nadchodzących zdarzeń.Lista pochodzi od składnika sieci Web programu SharePoint.

Importowanie zdarzeń składnika Web part

Nie dotyczy

Krok 7

Liczba aktywnych, rozpoznanych i zamkniętych elementów roboczych.Można otworzyć listę elementów roboczych, wybierając każdy numer.Ta lista pochodzi ze składnika Web part Team Web Access.

Projekt elementów pracy

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

Krok 8

Lista ostatnich kompilacji oraz ich status.Możesz wyświetlić więcej szczegółów na temat kompilacji, zaznaczając ją.Ta lista pochodzi ze składnika Web part Team Web Access.

Ostatnia część tworzy sieci Web

Legenda:

Tworzenie w toku: Kompilacja nie została rozpoczęta

Tworzenie nie jest uruchomiona: Kompilacja w toku

Kompilacja powiodło się.: Kompilacja powiodła się

Kompilacja nie powiodła się: Kompilacja zakończyła się niepowodzeniem

Kompilacja jest zatrzymana: Kompilacja została zatrzymana

Tworzenie częściowo powiodło się.: Kompilacja zakończona częściowym sukcesem

Managing and Reporting on Builds

9

Lista najnowszych zaewidencjonowań.Można wyświetlić więcej szczegółów na temat danego ewidencjonowania, zaznaczając je.Ta lista pochodzi ze składnika Web part Team Web Access.

Ostatnia część sieci Web zaewidencjonowania

Pisanie kodu i zarządzanie oczekującymi zmianami

Działania wymagane dla śledzenia usterek

Aby raporty widoczne w pulpicie nawigacyjnym Usterki były użyteczne i dokładne, zespół musi wykonać następujące działania:

  • Zdefiniuj usterki i określ ich ścieżki Iteracja i Obszar.

  • Przypisać każdą usterkę członkowi zespołu, który pracuje nad jej rozwiązaniem lub zamknięciem.

  • Określ Priorytet każdego błędu.

  • Aktualizuj Stan każdego błędu, w miarę jak zespół naprawia, weryfikuje i zamyka te błędy.

Monitorowanie aktywnych usterek i tendencji usterek

Członkowie zespołu mogą korzystać z panelu błędów, aby określać, czy zarządzają listą aktywnych błędów według ustalonych celów zespołu i praktyk zwinnego programowania.Przez testowanie jednostkowe dla każdego przyrostu kodu przed zaewidencjonowaniem, zespół może zmniejszyć ogólną liczbę błędów, które będzie trzeba znaleźć.Zespół, który skupia się na wysyłaniu każdego kolejnego przyrostu kodu, usuwa wady stopniowo i minimalizuje bieżące błędy.

Za pomocą pulpitu nawigacyjnego błędów zespół może odpowiedzieć na następujące pytania:

  • Czy dopuszczalna liczba aktywnych błędów opiera się na celach zespołu?Czy zespół odracza zbyt wiele błędów?

  • Czy zespół znajduje, naprawia i zamyka błędy wystarczająco szybko, aby spełnić oczekiwania i z prędkością, która dorównuje poprzedniemu cyklowi rozwoju?

  • Czy zespół zajmuje się usterkami o wysokim priorytecie przed błędami o niższym priorytecie?

  • Czy jakiś członek zespołu potrzebuje pomocy w rozwiązywaniu błędów?

Wskaźniki postępu usterek

Wskaźnik

Pytania, które należy zadać

Pasmo dla aktywnych błędów staje się coraz szersze.Jeśli szerokość pasma zespołu dla aktywnych błędów wzrasta, rośnie zaległość błędów.Zespół znajduje więcej błędów niż jest w stanie rozwiązać lub zamknąć.

Poszerzenie zespołu aktywnych błędów może wskazywać, że wąskie gardło spowalnia zdolności zespołu do rozwiązania i zamknięcia błędów.

  • Czy jacyś członkowie zespołu są przydzieleni do innych, niepriorytetowych zadań?

  • Czy istnieją inne problemy z blokowaniem zdolności zespołu do rozwiązywania i naprawiania błędów?

Liczba aktywnych błędów nie jest wymiana.Płaski trend liczby aktywnych błędów wskazuje, zespół nie znajduje błędów.

  • Czy zakres testów jest wystarczający?

  • Czy istnieją inne problemy z blokowaniem zdolności zespołu do znajdowania błędów?

Liczba rozwiązanych lub zamkniętych błędów nie ulega zmianie.Gdy liczba błędów, które zespół rozwiązuje lub zamyka pozostaje niezmienna przez długi okresy czasu, członkowie zespołu mogą nie być w stanie rozwiązać lub zamknąć te błędy.

  • Czy poprawnie określono priorytety zespołu?

  • Czy są członkowie zespołu przydzieleni do innych zadań?

  • Czy członkowie zespołu poprawnie śledzą status swoich błędów?

Wskaźniki trendu usterek

Wskaźnik

Pytania, które należy zadać

Zespół rozwiązuje wiele błędów w każdym przedziale czasowym.Wskaźnik wysokiej rozdzielczości zazwyczaj wskazuje, że zespół robi postępy.

  • Czy zespół natychmiast zamyka błędy, które naprawił?Szybkość zamykania powinna być podobna do szybkości rozwiązywania.

  • Czy zespół ponownie uaktywnia usterki z akceptowalną szybkością?

Zespół szybko rozwiązuje błędy, ale ich nie zamyka.Członkowie zespołu, którzy są przypisani do sprawdzenia poprawek, mogą mieć zbyt wiele do zrobienia lub inne priorytety mogą ich odciągać od zamykania rozwiązanych błędów.

  • Są jest przydzielonych zbyt wiele zasobów testowych?

  • Czy zespół powinien wracać do priorytetów testów?

    Aby uzyskać więcej informacji o tych wskaźnikach, zobacz Testowy pulpit nawigacyjny (CMMI).

Zespół znajduje kilka błędów w każdym przedziale czasowym.Zespół może mieć problemy za znajdowaniem błędów w rozwiązaniach wysokiej jakości lub jeśli przeprowadza nieskuteczne testy.

  • Czy metryki dla pokrycia kodu, postępu dokonanego w kodzie lub postępu testów wskazują na problem z kodem lub testowaniem?

    Aby uzyskać więcej informacji o tych wskaźnikach, zobacz Jakość - pulpit nawigacyjny (CMMI).

Zespół znajduje tę samą liczbę błędów w kolejnych przedziałach czasowych.Jeśli zespół stwierdzi taką samą liczbę błędów tydzień po tygodniu lub iteracja po iteracji, warto zbadać przyczyny.Na wczesnym etapie cyklu testowania testy mogą nie być wystarczająco rygorystyczne lub zaawansowane, aby udało się znaleźć wiele błędów.W wczesnych iteracji oczekuje się tej sytuacji.Jednak jak dojrzewa produkt, testy powinny uwzględniać szersze scenariusze i integracje.

  • Czy są testy odpowiednie do testowania wymagań, które zespół rozwija?

  • Czy testy stały się nieaktualne lub czy badają niewłaściwą funkcjonalność?

  • Czy zespół testowy rygorystycznie testuje każde wymaganie?

    Aby uzyskać więcej informacji o tych wskaźnikach, zobacz Testowy pulpit nawigacyjny (CMMI).

Zespół znajduje wiele błędów w każdym przedziale czasowym.Zespół może z łatwością znaleźć błędy w niechlujnym kodzie, w kodzie nowo zintegrowanym, przeprowadzając skuteczne testy lub w trakcie specjalnego zdarzenia, takiego jak impreza poświęcona błędom.

  • Czy metryki dla pokrycia kodu, postępu dokonanego w kodzie lub postępu testów wskazują na problem z kodem lub testowaniem?

    Aby uzyskać więcej informacji o tych wskaźnikach, zobacz Jakość - pulpit nawigacyjny (CMMI).

Priorytet błędów i dystrybucji

Wskaźnik

Pytania, które należy zadać

Liczba aktywnych błędów o wyższym priorytecie jest większa niż liczba aktywnych błędów o niższym priorytecie.Gdy liczba błędów o wysokim priorytecie jest znacznie większa niż liczba błędów o niższym priorytecie, zespół może się w pierwszej kolejności koncentrować się na elementach niższego priorytetu.

  • Czy zespół naprawia błędy w kolejności priorytetów ustawionej przez zespół?

  • Czy istnieją problemy z blokowanie zdolności zespołu do naprawiania błędów o wyższym priorytecie?

Przypisania usterki nie są dystrybuowane równomiernie.Zespół może rozważyć ponowne przypisywanie pracy, gdy wiele błędów jest przypisanych do jednego lub dwóch członków zespołu a tylko kilka do innych członków zespołu.

  • Czy zespół powinien równoważyć obciążenia ponownie przypisując błędy?