Wpis gościnny Moniki Dzingielewskiej.
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 klienta | 15% | 3,1 |
| Błędy wykryte wewnętrznie | 85% | 1,9 |
Po pierwsze musimy sobie odpowiedzieć na dwa pytania:
- Czy ta metryka jest dla nas przydatna?
- 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 pracy | Pracochłonność [osd] | % pracochłonności |
| Prace analityczne i dokumentacja | 304 | 16,54 % |
| Implementacja i testy | 521 | 28,35 % |
| Poprawa defektów | 528 | 28,67 % |
| Prace administracyjne dot. środowisk | 213 | 11,59 % |
| Zarządzanie | 273 | 14,85 % |
| Razem | 1839 | 100% |
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.
Zobacz wszystkie wpisy z serii:
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.
