Zrozumieć czas do jakości

Obecnie do śledzenia postępów kontroli jakości wykorzystuje się wiele wskaźników. Większość z nich jest całkiem użyteczna, ale wszystkie mają tendencję do bycia jednowymiarowymi, ponieważ stanowią migawkę określonego momentu lub sprintu w czasie. Dotyczy to nawet wskaźników tempa i trendów, które są niezwykle ważne, ale również stanowią migawki w czasie.

Kiedy pracowałem w firmie Symantec, zauważyłem następującą rzecz:

Stosowano wiele wskaźników do określenia rzekomego poziomu jakości osiągniętej do dnia premiery. Nie gromadzono jednak żadnych wskaźników, ani w trakcie procesu, ani retrospektywnie, aby zmierzyć koszt osiągnięcia tej jakości.

Innymi słowy, nie obchodziło nas, jak efektywnie osiągnięto tę jakość w całym cyklu życia projektu.

Wasz produkt mógł zostać wydany z wysoką jakością, ale czy osiągnięcie jej musiało wymagać aż tyle czasu i wysiłku?

To pytanie dotyczące efektywności, a nie jakości jako takiej, ale te dwa aspekty są ze sobą bardzo silnie powiązane.

Punkt styku jakości i efektywności

Jakość i efektywność krzyżują się ze sobą, ponieważ jednym z głównych powodów, dla których projekty oprogramowania często znacznie przekraczają uzgodniony harmonogram (a często staje się to nieoczekiwanym „problemem” w końcowej fazie projektu), jest niska jakość kodu. Nie tylko początkowa jakość kodu, ale jakość utrzymywana w całym projekcie.  

Innym powodem, będącym właściwie nieuniknioną konsekwencją niskiej jakości kodu, są defekty, które wymagają wielu prób naprawy, obejmujących wiele przebiegów testów lub sprintów, zanim defekt zostanie faktycznie usunięty. Jeśli w ogóle.  

Te niekończące się iteracje naprawiania, testowania i ponownego kończenia się niepowodzeniem dodają niezliczone tygodnie pracy do niemal każdego projektu oprogramowania.

A jednak, co ciekawe, ten wzorzec niepowodzeń nie jest odrębnie uwzględniany w żadnych innych znanych mi wskaźnikach projektu ani jakości. Ponieważ, jak wspomniano powyżej, wszystkie te wskaźniki są migawkami w czasie, przez co nie rejestrują tego zjawiska.

Uświadomiłem sobie, że istnieje prosty sposób na uchwycenie tego wzorca niepowodzeń. Opracowałem wskaźnik, który nazwałem „Czas do jakości”, czyli TTQ.

Przedstawiamy nowy wskaźnik: Czas do jakości (TTQ)

Sam wskaźnik jest bardzo prosty. Działa następująco:

Dla każdego przebiegu testów (niezależnie od tego, jak jest on definiowany) śledź nie tylko liczbę testów zakończonych powodzeniem lub niepowodzeniem, ale także liczbę testów zakończonych powodzeniem za pierwszym podejściem. Uwzględniaj również to, ile testów wymagało dwóch, trzech lub większej liczby prób, zanim ostatecznie zakończyły się powodzeniem.

Jako prosty przykład: jeśli uruchomisz 20 testów, a 5 z nich zakończy się powodzeniem za pierwszym podejściem, Twój współczynnik TTQ wynosi 25%. Im wyższa liczba, tym lepiej. To prosty, możliwy do obliczenia i łatwo dostępny wskaźnik ogólnej jakości kodu.

Ten wskaźnik bardzo dobrze pokazuje początkową jakość kodu.

Dzieje się tak dlatego, że im wyższa jakość kodu, tym mniej razy trzeba będzie przeprowadzać testy względem niego, zanim zakończą się powodzeniem. I odwrotnie. Ten wskaźnik jest znacznie dokładniejszy niż liczba błędów i trendy dotyczące błędów.

TTQ jest również niezwykle użytecznym wskaźnikiem monitorowania projektu.

Na przykład, jeśli podczas pierwszego przebiegu testów 70% testów zakończyło się powodzeniem, a 30% niepowodzeniem, można rozsądnie założyć, że projekt nadal mieści się w harmonogramie. Ale jeśli, powiedzmy, tylko 20% testów zakończyło się powodzeniem przy pierwszym uruchomieniu, to mówiąc językiem technicznym: „Dziewczyno, masz kłopoty! ”

Oznacza to, że w rzeczywistości nie przeprowadzono pomyślnego pierwszego przebiegu. A ten czas trzeba będzie doliczyć do przyszłego przebiegu jako dług jakości.

Wskaźnik TTQ jest niezwykle użyteczny jako coś, co lubię nazywać wskaźnikiem „potykacza”.

Jeśli używasz go konsekwentnie, dostarcza bardzo dokładnych danych, które pozwolą kierownikowi projektu stwierdzić, czy projekt zaczyna wymykać się spod kontroli, na długo zanim pociąg rzeczywiście wypadnie z torów. 

Oznacza to, że znacznie wcześniej można podjąć działania wyprzedzające, aby ponownie przejąć kontrolę nad sytuacją. Pozwala to uniknąć krępujących przyznań, bardzo późno w toku prac, że harmonogram projektu jest w strzępach. Innymi słowy, użyj progu TTQ, aby określić, czy projekt nadal znajduje się w strefie zielonej, żółtej, czy też zmierza w stronę czerwonej. Uczyń go integralną częścią statusu projektu.

Bo spójrzmy prawdzie w oczy: jedną z typowych patologii działań związanych z tworzeniem oprogramowania jest uporczywe zaprzeczanie temu, że coś idzie źle — i to na dużą skalę — gdy po raz pierwszy staje się oczywiste, że tak właśnie jest. Wszyscy boją się, że zostaną napiętnowani jako „negatywnie nastawieni”, że uzna się ich za zbyt leniwych lub niezainteresowanych naprawieniem sytuacji albo za osoby, które nie są „graczami zespołowymi”. Podobieństwo do dysfunkcyjnych rodzin jest niepokojąco oczywiste.

To zaprzeczanie i wypieranie tego, co wszyscy naprawdę wiedzą, prowadzi do wzorca niepowodzeń polegającego na odmowie przyznania, że projekt jest bardzo, bardzo opóźniony — aż do ostatniej chwili.

Gdy nie da się już tego ukryć przed kierownictwem wyższego szczebla, niepożądana niespodzianka, którą to dla nich stanowi, tylko podważa — czasem na stałe — ich zaufanie do własnych zespołów deweloperskich. I trudno ich za to winić.

Jeśli jednak konsekwentnie włączysz TTQ do swoich wskaźników i zarządzania projektem —oraz podejmiesz działania na podstawie tego, co mówi Ci ten wskaźnik— możesz tego uniknąć.

Pomiar czasu do jakości depersonalizuje decyzję o uznaniu, że ryzyko związane z harmonogramem i jakością narasta w projekcie już w jego najwcześniejszych fazach.

Staje się to bardzo jednoznaczne, jest kwestią liczb. Nie osobistego bohaterstwa, które często wiąże się z ogromnym kosztem dla danej osoby. 

Metryka TTQ jest również bardzo przydatna podczas retrospektywy projektu lub analizy po zakończeniu projektu.

Pozwoli zespołowi dokładnie wskazać, które fragmenty kodu były i pozostały słabe w trakcie całego projektu. A co za tym idzie, jak skuteczny był zespół w tworzeniu jakościowego kodu. Albo jak kosztowne to było.

To pytanie jest w dużej mierze pomijane podczas retrospektyw projektów. Częściowo dlatego, że zespoły nie mają odpowiedniego słownictwa pojęciowego, aby je sformułować, a częściowo dlatego, że wskazywanie na stale niską jakość kodu tworzonego przez zespół inżynieryjny jest często politycznie wrażliwe.

Podsumowanie

TTQ zapewni Twoim projektom ogromną przejrzystość i przewidywalność przy niemal zerowym koszcie czasu lub wysiłku, ponieważ jest po prostu metaanalizą metryk, które już zbierasz.

Używam TTQ w moich projektach QA od dwóch dekad i zyskało ono szeroką akceptację wśród kierowników projektów, których przeszkoliłem w jego stosowaniu, ze wszystkich powodów wymienionych powyżej.

Wypróbuj je, a sami się przekonacie. To naprawdę może odmienić pracę Waszego zespołu. Jak zawsze, powodzenia.

P.S. Jeśli chcesz usłyszeć więcej historii z życia i poznać powody stojące za TTQ, rozmawiałem z Jonathonem Wrightem w podcaście QAL.