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
|
Możesz użyć tego pulpitu nawigacyjnego do udzielenia odpowiedzi na następujące pytania:
|
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:
[!UWAGA]
Wykresy postępu, trendu i słupkowe oraz raporty od do 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 |
---|---|---|
Wizualna reprezentacja łącznej liczby wszystkich błędów, zgrupowanych według ich statusu dla ostatnich czterech tygodni. |
||
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. |
||
Wizualna reprezentacja łącznej liczby wszystkich błędów, zgrupowanych według ich priorytetu dla ostatnich czterech tygodni. |
||
Poziomy wykres słupkowy z całkowitą liczbą błędów aktywnych, pogrupowanych według priorytetu, przypisanych do każdego członka zespołu. |
||
Lista aktywnych usterek.Ta lista pochodzi ze składnika Web part Team Web Access. |
Nie dotyczy |
|
Lista nadchodzących zdarzeń.Lista pochodzi od składnika sieci Web programu SharePoint. |
Nie dotyczy |
|
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. |
Typy elementów szablonów roboczych procesu CMMI oraz przepływ pracy |
|
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. Legenda: : Kompilacja nie została rozpoczęta : Kompilacja w toku : Kompilacja powiodła się : Kompilacja zakończyła się niepowodzeniem : Kompilacja została zatrzymana : Kompilacja zakończona częściowym sukcesem |
||
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. |
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. |
|
Liczba aktywnych błędów nie jest wymiana.Płaski trend liczby aktywnych błędów wskazuje, zespół nie znajduje 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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|