9 metryki, które mogą mieć znaczenie dla dzisiejszych zespołów programistycznych

jak zauważyłam w artykule „Dlaczego metryki nie mają znaczenia w rozwoju oprogramowania (o ile nie łączysz ich z celami biznesowymi)”, wybór metryki wymaga znacznego przemyślenia i staranności, aby wspierać konkretne pytania, na które firma naprawdę musi odpowiedzieć. Oto punkt krytyczny: pomiary powinny być zaprojektowane tylko jako sposób na udzielenie odpowiedzi na pytania biznesowe. A te pytania nigdy nie brzmią: „ile mamy klocków?”

ten artykuł rozpoczyna się w miejscu, w którym zakończył się poprzedni, omawiając najpierw konkretne wskaźniki, z których każdy zespół powinien zacząć korzystać, lub przynajmniej planuje użyć ich wkrótce jako sposobu na poprawę zauważalnej wydajności. Zauważ, że tytuł tego artykułu mówi, że istnieje „9 wskaźników, które mogą coś zmienić…” – ponieważ to, co jest naprawdę ważne, co naprawdę zrobi różnicę, to sposób, w jaki te wskaźniki są rzeczywiście wykorzystywane do poprawy wartości biznesowej. To zależy od Ciebie. Następnie ten artykuł kończy się wyjaśnieniem, w jaki sposób można połączyć te wskaźniki, aby stworzyć znaczenie, a także sformułować i przetestować hipotezę wartości biznesowej.

zacznij od pomiaru właściwych rzeczy

oto dziewięć obiektywnych wskaźników (oznaczonych punktorami), które należy monitorować w sposób ciągły, aby wprowadzać stopniowe ulepszenia procesów i środowisk produkcyjnych. Poprawa tych liczb nie gwarantuje, że poziom zadowolenia klienta wzrośnie skokowo. Ale przynajmniej są to właściwe rzeczy do zmierzenia. W dalszej części tego artykułu, „składając to wszystko razem”, zobaczysz, dlaczego.

zwinne wskaźniki procesów

w przypadku procesów zwinnych i lean podstawowymi wskaźnikami są czas realizacji, Czas cyklu, prędkość zespołu oraz szybkość otwierania/zamykania. Te wskaźniki pomagają w planowaniu i informowaniu o decyzjach dotyczących poprawy procesu. Chociaż nie mierzą sukcesu ani wartości dodanej i nie mają nic wspólnego z obiektywną jakością oprogramowania,powinieneś je mierzyć. Wyjaśnię dlaczego poniżej.

• Leadtime—jak długo trwa przejście od pomysłu do dostarczonego oprogramowania. Jeśli chcesz lepiej reagować na potrzeby swoich klientów, staraj się skrócić czas realizacji zamówień, zazwyczaj upraszczając proces podejmowania decyzji i skracając czas oczekiwania. Czas realizacji obejmuje czas cyklu.
• czas cyklu—ile czasu zajmuje wprowadzenie zmian w systemie oprogramowania i dostarczenie tych zmian do produkcji. Zespoły korzystające z ciągłej dostawy mogą mierzyć czas cyklu w minutach, a nawet sekundach zamiast miesięcy.
• Team velocity—ile „jednostek” oprogramowania zespół zazwyczaj wykonuje w iteracji (aka „sprint”). Liczba ta powinna być używana tylko do planowania iteracji. Porównywanie prędkości zespołu jest nonsensem, ponieważ metryka opiera się na nieobiektywnych szacunkach. Traktowanie prędkości jako miary sukcesu jest niewłaściwe, a przekształcenie określonej prędkości w cel zniekształca jej wartość do oszacowania i planowania.
• szybkość otwierania / zamykania—ile problemów produkcyjnych jest zgłaszanych i zamykanych w określonym czasie. Ogólny trend ma większe znaczenie niż konkretne liczby.

gdy którekolwiek lub wszystkie z tych wskaźników są poza oczekiwanym zakresem lub trendem w niepokojących kierunkach, nie zakładaj przyczyny. Porozmawiaj z zespołem, poznaj całą historię i pozwól zespołowi zdecydować, czy jest powód do niepokoju, a jeśli tak, to jak to naprawić.

nie możesz znać lub zakładać przyczyn źródłowych z liczb, ale te wskaźniki dają ci wgląd w to, gdzie Twoje podstawowe procesy wymagają uwagi. Wysoki wskaźnik otwarcia i niski wskaźnik zamknięcia w kilku iteracjach może na przykład oznaczać, że problemy produkcyjne są obecnie priorytetem niższym niż nowe funkcje, lub że zespół koncentruje się na zmniejszeniu zadłużenia technicznego, aby naprawić całe klasy problemów, lub że jedyna osoba, która wiedziała, jak je naprawić, odeszła lub coś innego. Nie możesz znać lub zakładać przyczyn źródłowych z liczb.

analiza produkcji

• średni czas między awariami (MTBF)
• średni czas odzyskiwania / naprawy (MTTR)

oba są ogólnymi miarami wydajności systemu oprogramowania w jego obecnym środowisku produkcyjnym.

• crash rate aplikacji—ile razy aplikacja nie powiodła się podzielona przez ile razy została użyta. Ta metryka jest związana z MTBF i MTTR.

zauważ, że żadna z tych trzech metryk nie informuje o poszczególnych funkcjach lub użytkownikach, których to dotyczy. Im mniejsze liczby, tym lepiej. Nowoczesne oprogramowanie do monitorowania operacji sprawia, że zbieranie szczegółowych danych dotyczących poszczególnych programów i transakcji jest dość łatwe, ale ustawienie odpowiednich zakresów alertów i/lub wyzwalaczy w celu skalowania w górę lub w dół (dla systemów opartych na chmurze) wymaga czasu i starannego przemyślenia.

chcielibyśmy, aby nasze oprogramowanie nigdy nie zawodziło, ale jest to statystycznie nieprawdopodobne. Gdy nasze oprogramowanie ulegnie awarii, chcielibyśmy, aby nigdy nie straciło żadnych krytycznych danych i natychmiast je odzyskało, ale może to być niezwykle trudne do osiągnięcia. Jeśli jednak twoje oprogramowanie jest źródłem przychodów, wysiłek jest wart zachodu.

poza MTBF i MTTR, bardziej drobnoziarniste pomiary są oparte na indywidualnych transakcjach, zastosowaniach itp.i odzwierciedlają dostarczoną wartość biznesową i koszt usuwania awarii. Jeśli aplikacja przetwarzająca transakcje zawiesza się raz na sto, ale odzyskuje się w ciągu sekundy lub dwóch i nie traci żadnych krytycznych informacji, wskaźnik awarii 1% może być wystarczająco dobry. Ale jeśli każda awaria dotyczy aplikacji, która uruchamia 100 000 transakcji dziennie, traci sprzedaż za 100 USD i kosztuje 50 USD na naprawę na zapleczu, ten procent awarii 1 będzie priorytetem. Naprawienie go znacząco wpłynie na wynik finansowy.

wskaźniki bezpieczeństwa

bezpieczeństwo jest aspektem jakości oprogramowania, który jest często pomijany aż do późnej (lub zbyt późnej). Narzędzia do analizy bezpieczeństwa mogą być wykorzystywane w procesie budowania, oprócz bardziej specjalistycznych ocen i testów warunków skrajnych. Wymagania bezpieczeństwa są często proste i powszechne, ale zespół programistów musi mieć na uwadze je i wynikające z nich wskaźniki.

pełny zakres praktyk w zakresie bezpieczeństwa i powiązanych wskaźników wykracza poza zakres tego artykułu, ale podobnie jak w przypadku wskaźników zwinnych procesów i wskaźników produkcji, istnieje kilka konkretnych wskaźników, które mogą znacznie wpłynąć na ogólną satysfakcję Twoich klientów.

• incydenty końcowe—ile punktów końcowych (urządzenia mobilne, stacje robocze itp.) czy w danym okresie czasu wystąpiła infekcja wirusowa?
• MTTR (mean time to repair)—w metrykach bezpieczeństwa jest to czas między wykryciem naruszenia bezpieczeństwa a wdrożonym, działającym środkiem zaradczym. Podobnie jak w przypadku metryki MTTR dla produkcji, o której mowa powyżej, MTTR dla bezpieczeństwa powinien być śledzony w określonych przedziałach czasowych. Jeśli wartość MTTR zmniejsza się z czasem, Programiści stają się bardziej skuteczni w zrozumieniu problemów związanych z bezpieczeństwem, takich jak błędy i sposoby ich naprawiania.

dla obu tych wskaźników, mniejsze liczby w czasie oznaczają, że zmierzasz we właściwym kierunku. Mniej incydentów końcowych mówi samo za siebie. Ponieważ wartość MTTR maleje, Programiści stają się bardziej skuteczni w zrozumieniu problemów związanych z bezpieczeństwem, takich jak błędy i sposoby ich naprawiania.

więcej sposobów na zastosowanie wskaźników bezpieczeństwa w tworzeniu oprogramowania można znaleźć w artykułach Bezpieczeństwo aplikacji w projektach zwinnych i modelach zagrożeń bezpieczeństwa: wprowadzenie zwinne.

notatka o metrykach kodu źródłowego

dzisiaj łatwo jest podłączyć skaner kodu źródłowego do potoku kompilacji i utworzyć ryzy obiektywnych metryk. Istnieją średnie empiryczne i sugerowane zakresy oraz logiczne argumenty na temat względnego znaczenia tych metryk. Jednak w praktyce narzędzia te są najbardziej pomocne w egzekwowaniu stylów kodowania, oznaczaniu pewnych anty wzorców oraz identyfikowaniu wartości odstających i trendów.

po prostu nie warto się czepiać liczb. Oto przykład, jako wyjaśnienie.

przypuśćmy, że znajdziesz metodę w klasie o absurdalnej metryce, takiej jak złożoność npath wynosząca 52 miliony. Oznacza to, że potrzeba 52 milionów przypadków testowych, aby w pełni przećwiczyć każdą ścieżkę przez kod. Możesz przekształcić kod w prostszą strukturę, ale zanim to zrobisz, zastanów się, jaki będzie wpływ na biznes. Są szanse, że stary, brzydki kod działa wystarczająco dobrze (choć jego zasięg testowy może być niewystarczający). Wywołanie anty-wzorca zespołowi, aby uniknąć powtarzania go, jest cenną nauką, ale naprawienie go prawdopodobnie nie poruszyłoby igły w żadnym odpowiednim metryce biznesowej.

najlepiej, jeśli zespół zgadza się na poziom zgodności i zasad, którym podlega ich kod, ale należy pamiętać, że badanie wartości odstających i przejmowanie się blipami trendu może marnować dużo czasu.

to poskładaj wszystko do kupy: Sukces jest ostatecznym wskaźnikiem

radość z używania zautomatyzowanych narzędzi do śledzenia i mierzenia wskaźników jakości oraz analizy użytkowników polega na tym, że pozwala to zaoszczędzić czas na skupieniu się na liczbach, które naprawdę mają znaczenie: wskaźnikach sukcesu.

jak wykorzystać metryki do sukcesu

firmy mają cele. Cele wiążą się z pytaniami, takimi jak ” Jak wygląda sukces?”lub” jak wpłynie to na zachowanie klientów?”Właściwie skwantyfikowane pytania implikują metryki.

mówiąc inaczej, metryki powinny być używane tylko do odpowiedzi na pytania, do testowania hipotez, które wspierają konkretny cel biznesowy. A powinno się to robić tylko tak długo, jak pytania i odpowiedzi pomagają napędzać pozytywne zmiany.

czy wszystkie projekty w ogóle nie mają jakiegoś zbioru niezmiennych celów, pytań i hipotez, a co za tym idzie metryk?

tak, ale tylko z punktu widzenia biznesu. Miary na poziomie biznesowym, takie jak zaangażowanie użytkowników, wskaźniki zamknięcia, generowanie przychodów itp., dostarczają informacji zwrotnych na temat tego, jak firma radzi sobie w prawdziwym świecie. Zmiany w oprogramowaniu, które mają wpływ na firmę, również wpłyną na tego rodzaju wskaźniki.

przy drobniejszym poziomie rozdzielczości każda funkcja i historia użytkownika może mieć swój własny wskaźnik sukcesu—najlepiej tylko jeden i taki, który jest bezpośrednio związany z miarą wartości dostarczonej klientowi. Ukończenie dziewięciu na dziesięć historii w sprincie dla funkcji, które nigdy nie są dostarczane, to strata, nie sukces. Dostarczanie historii, których klienci nie chcą lub których nie używają, jest marnotrawstwem, a nie sukcesem. Dostarczanie historii, która poprawia pewien aspekt szczęścia użytkowników, jest sukcesem. Dostarczanie historii, która wyraźnie nie poprawia zaangażowania użytkowników, jest również sukcesem, ponieważ nauczysz się czegoś, co nie działało, unieważnisz hipotezę biznesową i uwolnisz zasoby, aby podążać innymi ścieżkami.

jak sformułować hipotezę wartości

hipoteza wartości to stwierdzenie o tym, co Twoim zdaniem stanie się w wyniku dostarczenia określonej cechy. Związek między oprogramowaniem, pożądanym rezultatem i metrykami tworzy hipotezę wartości dla funkcji (lub systemu, historii lub aktualizacji itp.). Hipoteza powinna wyrażać, w jaki sposób docelowa metryka ma się zmienić, w jakim przedziale czasowym i o ile należy ją uznać za skuteczną. Będziesz musiał porozmawiać z zespołem i właścicielem produktu, co najmniej, aby dowiedzieć się konkretnej rzeczy, którą ta funkcja lub historia ma na celu stworzenie lub ulepszenie w odniesieniu do firmy, aby sformułować hipotezę wartości. Być może trzeba będzie zapytać” dlaczego ” kilka razy (jak trzylatek), aby oderwać warstwy nie sprecyzowanych założeń; bądź cierpliwy. Kiedy zrozumiesz, jaka powinna być wartość biznesowa, możesz zacząć zadawać pytania, które doprowadzą cię do wskaźników, które odpowiedzą na to pytanie.

na przykład „techniczna” historia poprawiająca szybkość procesu realizacji transakcji e-commerce może mieć za podstawę założenie, że szybsza realizacja transakcji doprowadzi do większej sprzedaży. Ale dlaczego tak myślimy? Czy Wiele osób porzuca swoje wózki podczas realizacji zakupu? Jeśli taki jest konsensus (ponieważ konsensus ten jest poparty danymi bazowymi), hipoteza wartości może brzmieć: „wierzymy, że szybszy proces realizacji transakcji spowoduje zmniejszenie wskaźnika porzucania koszyka, co doprowadzi do wyższej sprzedaży i lepszego doświadczenia użytkownika.”

prawdopodobnie możesz założyć, że użytkownicy polubią szybsze kasy, ale nie zaszkodzi zapytać, czy zauważyli. Wskaźniki porzucania koszyka i sprzedaży mogą być mierzone przed i po wprowadzeniu nowego procesu, przez pewien czas. Jeśli wskaźnik porzucania koszyka spadnie, a sprzedaż wzrośnie (poza fluktuacjami statystycznymi), dowody potwierdzają tę hipotezę i możesz rozważyć, czy nawet dalsza poprawa prędkości jest uzasadniona. Jeśli tak nie jest, niech ta metryka zniknie w tle (lub usunie ją, jeśli rozprasza) i zwróci uwagę na następną hipotezę. Jeśli wskaźnik porzucania koszyka maleje, ale sprzedaż pozostaje niezmieniona, należy zmierzyć przez dłuższy okres czasu lub ponownie przemyśleć zakładany związek między porzucaniem koszyka a sprzedażą. Innymi słowy, używaj metryk do nauki i tylko pod warunkiem, że okażą się przydatne do ulepszania jazdy.

w niektórych przypadkach hipoteza może być wyraźnie błędna, więc odrzucamy metryki (i cofamy zmiany w oprogramowaniu!) po kilku dniach. W innych przypadkach hipoteza może być poprawna, więc przez lata kontynuujemy ulepszenia w tej dziedzinie.

sześć heurystyk do efektywnego wykorzystania wskaźników

widzieliśmy, jak subiektywne wskaźniki oprogramowania mają większe znaczenie dla sukcesu biznesowego niż tradycyjne, obiektywne wskaźniki jakości. Wysiłek wymagany do znalezienia i zmierzenia odpowiednich wskaźników biznesowych dla funkcji jest przeważany przez zdobyte informacje i możliwości uczenia się. Warunki biznesowe i możliwości zmieniają się stale, więc zamiast podsumować formułę do naśladowania, która może być krucha, oto sześć zasad kciuka lub heurystyki, aby pomóc utrzymać koncentrację i elastyczność. Niech pomogą Ci w podróży do wysokiej jakości oprogramowania i sukcesu biznesowego!

1. Metryka nie może Ci opowiedzieć historii, tylko zespół może to zrobić (z końcówką kapelusza do Todda Decapuli).
2. porównywanie płatków śniegu to odpad.
3. możesz zmierzyć prawie wszystko, ale nie możesz zwracać uwagi na wszystko.
4. wskaźniki sukcesu biznesowego usprawniają oprogramowanie, a nie odwrotnie.
5. każda funkcja dodaje wartość; zmierz ją lub nie rób tego.
6. Zmierz tylko to, co teraz ma znaczenie.