Z każdym kolejnym wpisem Moniki Dzingielewskiej coraz bliżej nam do „JAKOŚĆ” a nie „JAKOŚ”. W piątej serii dowiemy się jak przeanalizować wyniki naszych pomiarów i raportów i jak wyciągać z nich wnioski.

„Sprawdzaj i Analizuj”, czyli co nam to wszystko daje

Po planowaniu i działaniu przychodzi czas na refleksję. W różnych metodykach różnie się to nazywa: retrospektywa, sprzężenie zwrotne, czy też „lessons learned”. Jedno jest pewne: bieżące obserwowanie metryk i statystyk projektowych umożliwia:

  • z jednej strony zweryfikowanie, czy wszystko idzie zgodnie z planem i z naszymi oczekiwaniami,
  • z drugiej strony pozwala zidentyfikować obszary obarczone największymi problemami, a także przewidywać jakich problemów się jeszcze możemy spodziewać.

Trzeci krok z cyklu Deminga – „SPRAWDŹ”

Trzeci krok cyklu Deminga, czyli tzw. „sprawdzam” na pewno wymaga pewnego doświadczenia, dobrej znajomości własnego zespołu, a także rzetelnej oceny faktów. Bez tego trudno powiedzieć, czy posiadanie jednego krytycznego błędu oznacza, że funkcjonalności są w bardzo dobrym stanie, czy może nikt ich nie testuje i nie udało się zidentyfikować jeszcze innych błędów, a może ten jeden błąd oznacza, że nie można się zalogować do aplikacji.

Niektóre metody i metodyki, jak chociażby Scrum same narzucają cykliczne sprawdzanie, co się dzieje w naszym projekcie i czy są jakieś przestrzenie do korekt i usprawnień. Natomiast nawet jeśli pracujemy w mniej zwinnych projektach, analiza bieżącej sytuacji to kwestia wyrobienia dobrych nawyków poprzez cykliczne sprawdzanie sytuacji w projekcie (czy to w określonych odstępach czasu, czy to po osiągnięciu pewnych kamieni milowych) oraz po zakończeniu projektu (poprzez zrobienie retrospekcji poprojektowej, która posłuży jako zbiór doświadczeń i praktyk przydatnych w przyszłych przedsięwzięciach).

A jak się ma to do naszych metryk?

Przykład 1 – koszty błędów wykrywanych przez klienta

Przykładowo zdecydowaliśmy, że istotna jest dla nas informacja ile błędów wykrywanych jest dopiero przez klienta oraz jak przekłada się to na ponoszone przez nas koszty. W poniższym przykładzie widać, że błędy wykryte przez klienta stanowią 15% wszystkich błędów, ale koszt ich obsługi (dla uproszczenia w godzinach) jest ponad 1,5 razy większy niż w przypadku błędów wewnętrznych

 OdsetekŚrednia praca związana z naprawą błędu [godz]
Błędy wykryte przez klienta15%3,1
Błędy wykryte wewnętrznie85%1,9

Po pierwsze musimy sobie odpowiedzieć na dwa pytania:

  1. Czy ta metryka jest dla nas przydatna?
  2. Czy z tej metryki wynikają jakieś istotne informacje dające przestrzeń do usprawnień?

Być może uznamy, że takie dane są dla nas satysfakcjonujące i przy kolejnych wydaniach będziemy je tylko monitorować, czy nie zwiększa się odsetek błędów wykrywanych przez klienta. Ale być może już dziś uznamy, że jednak te statystyki są niepokojące i chcemy popracować nad większą wykrywalnością błędów na etapie testów wewnętrznych, a co za tym idzie nad zmniejszeniem kosztów obsługi błędów (z ang. „Cost of Poor Quality”)

Przykład 2. – analiza kosztów

Po wdrożeniu pewnego etapu projektu dokonaliśmy podsumowania kosztów z podziałem na rodzaj prac, które zostały wykonane.

Rodzaj pracyPracochłonność [osd]% pracochłonności
Prace analityczne i dokumentacja30416,54 %
Implementacja i testy52128,35 %
Poprawa defektów52828,67 %
Prace administracyjne dot. środowisk21311,59 %
Zarządzanie27314,85 %
Razem1839100%

W przykładowym zestawieniu bardzo niepokojące okazują się niemalże równe koszty wytworzenia oprogramowania (implementacji i testów) oraz koszty poprawy defektów – niewątpliwie nie jest to sytuacja, wobec której można przejść obojętnie. Wniosek oczywisty: „programiści wypuszczają kod o niskiej jakości”. Ale czy na pewno?

Dla mnie te dane byłyby niewystarczające – skłoniłyby mnie do poszukania innych metryk, które dokładniej by pomogły przeanalizować sytuacje: czy na pewno wszystkie błędy były zasadne? Czy część z nich nie były to tak naprawdę zmiany? A może w ramach tego wydania likwidowaliśmy dług technologiczny z poprzedniego wydania?

Podsumowanie

Tak naprawdę na etapie „Sprawdzaj” przyglądamy się nie tylko samym danym, ale również i metrykom, które stosujemy: czy odpowiednio mierzą nasz proces i nasz produkt, czy pozwalają zidentyfikować obszary do usprawnień i czy prowadzą nas do działań, które poprawią jakość naszej pracy. Bo o to przecież wszystkim chodzi – o ciągłe doskonalenie. Ale o tym już w kolejnej części artykułu.

 

Monika Dzingielewska – kierownik zespołu programistów

Moje doświadczenia skupia się głównie wokół koordynowania prac zespołów programistycznych w dużych i złożonych projektach informatycznych. Od początku pracy zawodowej fascynują mnie zagadnienia związane z procesem wytwórczym, planowaniem wydań oraz zarządzaniem konfiguracją oprogramowania.

 

.