Przykładowe raporty dotyczące programowania iteracyjnego

Ta kategoria zawiera raporty śledzące szybkość programowania. Te raporty monitorują takie parametry, jak liczba kompilacji, czas zamykania defektów, liczbę zadań na iterację i metryki wydajności projektu.

Defekty blokujące

Ten raport pokazuje liczbę defektów, które opóźniają inne elementy pracy. Defektem blokującym nazywamy defekt o wysokim priorytecie, który jest aktualnie otwarty (niezamknięty) i jest z nim powiązane wymaganie. Zakłada się, że praca nad wymaganiem nie może być kontynuowana dopóki defekt nie zostanie rozwiązany. Linia wykresu powinna opadać. Linia wznosząca oznacza, że praca nad rosnącą liczbą wymagań jest opóźniona.

Poprawność kompilacji

Ten raport przedstawia statystykę kompilacji produktu, np. liczbę wszystkich prób kompilacji, liczbę tych, które się powiodły, i tych, które zakończyły się niepowodzeniem. Zazwyczaj duża lub wzrastająca liczba awarii (szczególnie w późniejszej fazie projektu) może wskazywać na problem, który powinien zostać zbadany.

Czas życia defektów

Ten raport pokazuje dwie statystyki dotyczące defektów. Ważnym wskaźnikiem jest czas, w którym defekt pozostaje w każdym stanie. Sprawdź, czy średni czas jest akceptowalny i czy nie ma nadmiernej ilości czasów maksymalnych. Wartość średnia niekoniecznie musi być taka sama dla wszystkich stanów, ponieważ jeśli proces działa prawidłowo, defekt powinien szybko przechodzić ze stanu Submitted (wprowadzony) do Assigned (przydzielony). Wykres czasu obsługi pokazuje, jak długo trwało rozwiązanie defektu (według istotności). Defekty o wyższej istotności powinny być rozwiązywane szybciej niż te o mniejszej istotności. Średni czas powinien być akceptowalny i nie powinny występować nieuzasadnione wartości maksymalne.

Status i rozkład defektów

Ten raport pokazuje liczbę defektów w różnych ujęciach, co pomaga w zrozumieniu stanu projektu. Wykres stanu może wskazywać na problem procesu, jeśli większość defektów nie jest rozwiązana albo zamknięta. Wykres istotności powinien pokazywać mniej krytycznych lub poważnych defektów, jeśli projekt przebiega dobrze. Wykres priorytetu przypomina wykres istotności pod tym względem, że zbyt wiele defektów wymagających natychmiastowej lub wysokiej uwagi może oznaczać problem. Wykresy istotności i priorytetów pokazują tylko defekty w stanie Assigned (przydzielony), Opened (otwarty), Submitted (wprowadzony) lub Postponed (opóźniony).

Szybkość iteracji

Ten raport pokazuje liczbę zakończonych zadań przypadających na iterację. Można go użyć do ustalenia, jak dużo pracy można zakończyć w każdym cyklu iteracji. Zasadniczo linia powinna mieć dość stały przebieg. Znaczące wzrosty lub spadki mogą być oznaką zewnętrznej presji na projekt, co wydaje się zrozumiałe. Jednak na wykresie przyjęto, że wszystkie zadania wymagają mniej więcej tej samej ilości pracy. Zdefiniowanie zadań wymagających znacznie więcej lub mniej pracy może wpływać na liczbę zadań zakończonych w ustalonym czasie.

Wykonanie projektu

Ten raport pokazuje liczbę zadań przypisanych do iteracji, które nie zostały zamknięte, przez co uważa się je za niezakończone. W zasadzie linie powinny być bliskie zera przy każdej iteracji. Jeśli nie są, to być może dla niektórych iteracji zaplanowano zbyt dużo pracy lub często praca jest niedoszacowana.

Wydajność projektu

Ten raport pokazuje różne metryki budżetu i kosztu rzeczywistego. Wykresy przedstawiają w sposób ogólny, jak rzeczywiste lub oszacowane wartości różnią się od planowanych w budżecie (planie bazowym) w miarę postępów w projekcie. Szacowanie kosztu całkowitego liczy się przy użyciu dotychczasowego rzeczywistego kosztu wykonanej pracy (ACWP) i kosztu ujętego w budżecie dla pozostałych prac projektowych. Budżet całkowity powinien przebiegać poziomo, jeśli plan bazowy budżetu (BWCS) nie zmienia się podczas projektu. Odchylenie całkowite jest to szacowana różnica pomiędzy budżetem a szacowanym kosztem całkowitym dla każdego punktu w projekcie. Liczby ujemne wskazują na przekroczenie budżetu projektu. Wskaźnik efektywności kosztowej liczy się, dzieląc planowany koszt wykonanej pracy (BCWP) przez rzeczywisty koszt wykonanej pracy (ACWP). Ta linia powinna być w miarę pozioma i bliska wartości 1, jeśli projekt jest realizowany w ramach budżetu. Wskaźnik wydajności harmonogramowej (SPI) jest równy planowanemu kosztowi wykonanej pracy (BCWP) podzielonemu przez planowany koszt zaplanowanej pracy (BCWS), a więc powinien zbliżać się do 1, gdy planowany koszt wykonanej pracy zbliża się do stałego planowanego kosztu zaplanowanej pracy (BCWS) dla projektu z planu bazowego. Odchylenie kosztowe stanowi różnicę pomiędzy dotychczasowym planowanym kosztem wykonanej pracy (BCWP) a jej kosztem rzeczywistym. Liczby ujemne wskazują na przekroczenie budżetu projektu.

Gotowość wersji (defekt)

Zazwyczaj kluczowym czynnikiem decydującym o tym, czy jakość projektu jest wystarczająca do wydania wersji, jest liczba otwartych defektów. Konieczna jest zatem wiedza na temat aktualnej liczby otwartych defektów w rozbiciu na istotność. Projekt może nie być gotowy, jeśli istnieją krytyczne lub poważne defekty, ale większa liczba drobnych defektów może nie uzasadniać opóźnienia wersji.

Trendy żądań

Dane na tym wykresie są podobne do ścieżki przebiegu projektu. Pokazuje on, jak wiele rozszerzeń i defektów pojawia się lub jest zamykanych w danym czasie. Na początku projektu linia powstałych defektów może przewyższać linię zamkniętych defektów. W późniejszej fazie projektu mogłoby to jednak wskazywać na problem.

Tempo pracy

Ten raport pokazuje szybkość, z jaką prace (działania) są planowane i kończone. Obie linie powinny biec blisko siebie, gdyż w iteracji nie należy planować więcej pracy niż da się zakończyć.

Zadania według projektów

Ten raport zawiera wszystkie zadania powiązane z projektem. Są one pogrupowane według żądań, których są częścią.

Zadania według stanu, typu, właściciela

To jest podział zadań dla każdej iteracji według stanu, typu i właściciela. Większość zadań dla wcześniejszych iteracji powinna być w stanie zakończonym. Zbyt wiele niezakończonych zadań, które są przenoszone pomiędzy iteracjami, może wskazywać na błędne założenie odnośnie szybkości. Duża liczba zadań typu defekt może także wyjaśniać niższą od oczekiwań szybkość, gdyż zabierają one czas przewidziany na rozszerzenia. Analogicznie powinna istnieć względna równowaga pomiędzy zadaniami różnych właścicieli, uwzględniająca poziom umiejętności i inne zobowiązania.

Obciążenie

Tabela przekrojowa pokazuje, ile działań jest przypisanych do każdej osoby dla każdej iteracji. Liczby te powinny być w miarę spójne, więc poszukaj znacznych wzrostów lub spadków, których nie da się wyjaśnić ilością pracy wymaganej dla pewnych działań ani wyjątkowo dużymi lub małymi zobowiązaniami, które dana osoba może mieć poza projektem.


Opinia