Problem z kodem polega na tym, że jest on stosunkowo słabo mierzalny. Co prawda mamy dostępne różne metryki, które pozwalają nam na opisanie kodu, ale nie wszystkie one są wystarczające dla biznesu. Powiedzmy to w prost – większość metryk, które stosujemy do pomiaru kodu nie ma wartości dla biznesu. Dlaczego? Cóż, odpowiem słowami pewnego managera z którym kiedyś współpracowałem

QA team nie jest potrzebny. Programiści powinni tworzyć dobry kod.

To podejście wynika z różnic pomiędzy klasycznymi projektami przemysłowymi, a projektami IT. O tych różnicach będę mówił na tegorocznym DevCrowdzie, ale na razie wystarczy nam wiedzieć, że te różnice są i są duże. Wróćmy jednak do tematu metryk. Jakie metryki należy zastosować, by projekt sprzedać biznesowi?

Time to market

Czyli czas dostarczenia. Od kiedy mierzony? Najlepiej od momentu gdy kończymy implementację. Mówimy klientowi „zadanie gotowe” i zegar startuje. Teraz zaczyna się najtrudniejszy etap, czyli testy funkcjonalności prowadzone przez klienta.

Dlaczego ta metryka jest ważna?

Ponieważ pokazuje klientowi ile czasu zajmie nie tylko przygotowanie produktu, ale też sprawdzenie go pod kątem zgodności z oczekiwaniami. Bardzo często jest tak, że planując jakąś funkcjonalność estymujemy czas potrzebny na wyklepanie kodu, ale zupełnie ignorujemy czas potrzebny po stronie klienta na sprawdzenie dostarczonego produktu.

Co tak na prawdę mierzymy?

Ta metryka przykrywa w rzeczywistości coś co znamy pod pojęciem pokrycia kodu testami. Przy czym chodzi tu przede wszystkim o automatyczne testy akceptacyjne. Dobrze przygotowane automaty będą wstanie zastąpić większość testowania ręcznego. Tym samym skrócić czas potrzebny na weryfikację. Przydatnymi narzędziami są Continuous Delivery i Continuous Deployment.

Błędy z produkcji

Czyli co znaleźli użytkownicy w dostarczonym produkcie. Idealnie to oczywiście 0, ale pamiętajmy, że osobną klasę błędów stanowią te wynikające z niezrozumienia działania aplikacji. Gdy wiele lat temu po raz pierwszy siadłem do Windowsa 95 to chwilę zajęło mi zrozumienie idei „Kosza”. Później poszło już gładko. Dlatego warto wprowadzić jakiś mechanizm kwalifikacji błędów.

Dlaczego ta metryka jest ważna?

Ponieważ mówi biznesowi o jakości naszej pracy oraz o jakości analizy. Jeżeli mamy pogrupowane błędy to niewiele błędów typu „bug” jest dobre. Ilość błędów typu „misunderstand” świadczy o tym jak komunikujemy się z klientami i jak działa analiza. No i zostają jeszcze „new feature” 😉

Co tak na prawdę mierzymy?

Mierzymy tu nie tyle co pokrycie testami, a jakość samych testów. Można napisać system o pokryciu na poziomie 100%, który będzie zawierać błędy z powodu nieprawidłowo dobranych przypadków testowych, albo dlatego, że pokrycie jest typu „smoke” – odpalamy i nic nie weryfikujemy.

Directory Tangle Index

Metryka specyficzna dla sonara, ale jednocześnie jest to techniczna metryka która najsensowniej działa na biznes. Mówi ona o ilości „zależności zwrotnych” w design structure matrix. Prościej określa ona w ilu miejscach w systemie komponenty wpadają w cykle zależności. W idealnym projekcie zależności pomiędzy komponentami są jednokierunkowe. W życiu nie zawsze się to sprawdza. Przykładowo mamy klasę, która sprawdza email użytkownika i jeżeli go nie ma to go rejestruje. W celu rejestracji korzysta z metody serwisu. Jednocześnie serwis ten wykorzystuje tą klasę do innych swoich operacji. Klasy są między sobą zależne w obu kierunkach. Zmiana w jednej może spowodować problemy w drugiej.

Dlaczego ta metryka jest ważna?

Jest to jedyna ważna dla biznesu techniczna metryka ponieważ pozwala ona oszacować jak bardzo wrażliwy na zmiany jest nasz kod. Wysoka wartość oznacza, że mamy w kodzie wiele zależności. To niewiele mówi biznesowi. Można jednak przenieść tą metrykę na poziom komponentów i funkcjonalności. Dzięki temu może on określić jaki wpływ na cały system będzie miało np. wyłączenie jednej z usług. Pozwala to też szacować czas potrzebny na zmiany w istniejących komponentach oraz ryzyko z tym związane.

Co tak na prawdę mierzymy?

To co tu na prawdę mierzymy to poziom zepsucia architektury. Ilość naruszeń zasad SOLID, duplikację kodu, nieprawidłowy podział na moduły. Jest to ważne z punktu widzenia biznesu, bo jak pisałem pozwala na określenie ryzyk.

Podsumowanie

To oczywiście nie wszystko. Istnieje cała gama innych metryk, które są przydatne dla biznesu. Większość z nich to pochodne klasycznych, stosowanych przez programistów, metryk w rodzaju pokrycia testami czy ilości dokumentacji. Warto jednak zaprzyjaźnić się z tymi wymienionymi wyżej, ponieważ pozwalają one na dostarczenie biznesowi wartościowych informacji w formie zrozumiałej dla nietechnicznych.