Pięć najlepszych KPI inżynierii oprogramowania i jak są oszukiwane

By Bill Harding,Programista/CEO
Published March 31, 2020.Last updated April 17, 2020.

Gdy ludzie mówią o inżynierskich KPI, często słyszy się dwa sprzeczne truizmy:

To, co zmierzone, poprawia się.-Peter Drucker

I

Kiedy środek staje się celem, przestaje być dobrym środkiem.-Prawo Goodharta

Kiedy środek staje się celem, przestaje być dobrym środkiem.Prawo Goodharta

Oba te stwierdzenia częściowo opisują inżynierskie wskaźniki KPI, ale razem sugerują, że niemożliwe jest wykorzystanie pomiaru do poprawy. Zła wiadomość jest taka, że wymaga to pewnego zaangażowania w naukę, szczególnie w przypadku osób wywodzących się z odległych (tj. nietechnicznych) ról. Dobra wiadomość jest taka, że starannie dobrane metryki mogą i nadal działają pomimo „stania się celem”. W rzeczywistości, w przypadku wielu metryk, które będziemy rekomendować, im bardziej pracownik „gra w system”, tym bardziej służy to długoterminowym interesom firmy. Celem końcowym są metryki, które nadal dobrze funkcjonują, mimo że są „ogrywane”. Istnieje pięć metryk, które spełniają tę poprzeczkę.

Grupa docelowa: Action-minded Manager

Każdy menedżer, który próbował wydobyć więcej ukończonych ticketów od swojego zespołu inżynierskiego, zna tę walkę.Chcą podjąć uczciwe, poparte danymi działania, które poprawią ich szybkość. Wiedzą, że podejmowanie decyzji na podstawie przeczuć jest kosztowne i nieskalowalne. Jednak, kiedy patrzą na swoją listę rzeczy do zrobienia, jest ona pełna zadań, które wydają się bardziej pilne niż „poprawa pomiarów”. W praktyce, rozpoczęcie mierzenia często następuje po katastrofalnej porażce, takiej jak błąd w wydaniu lub zauważenie, że programista nie zamknął żadnego zgłoszenia w ciągu miesiąca.

Nawet wtedy, gdy jest jasne, że mierzenie musi się wydarzyć, jest niejednoznaczne, od czego zacząć. Możesz wpisać w Google „inżynierskie KPI”, przeklikać się przez całą pierwszą stronę wyników i nie mieć pewności, jakie kolejne kroki należy podjąć. Weźmy jako przykład często przywoływaną metrykę „Team Velocity”. Prawie każdy wynik Google zaleca pomiar „Team Velocity”, ale nikt nie chce powiedzieć, czy jest on mierzony w… zamkniętych biletach? Linie kodu? Punktach opowieści? Cokolwiek to jest, menadżerowie nie mają czasu, aby to rozgryźć. Potrzebują zebrać z tej góry teorii o wysokości 15 000 stóp coś, co mogą zrozumieć, zaufać i skorzystać z tego… najlepiej natychmiast.

Założeniem organizacyjnym tego artykułu jest to, że jesteś menedżerem, który chce zrozumieć mierniki inżynierii oprogramowania na tyle dobrze, aby uczynić swój zespół bardziej efektywnym. Bycie menedżerem oznacza, że jesteś zbyt zajęty, aby poznać teorię, z wyjątkiem sytuacji, w której jest ona związana bezpośrednio z tym, jak możesz skorzystać z tej teorii.

Mierniki muszą być praktyczne, aby prawdziwe firmy mogły je wypróbować

Przed napisaniem tego artykułu, przeanalizowaliśmy metryki zaproponowane przez 20 najlepszych wyników Google w dziedzinie metryk oprogramowania. Jak można sobie wyobrazić, każde źródło miało swoje własne teorie na temat tego, które metryki miały największe znaczenie. Ich artykuły często dzieliły metryki na grupy takie jak „metryki procesowe” i „metryki projektowe”. Podążymy za ich wskazówkami dotyczącymi grupowania metryk, ale naszymi grupami będą „metryki jakości” i „wszystko inne.”

Oto, co kwalifikuje się jako metryka jakości:

  • Wartość biznesowa.Czy można narysować linię prostą od metryki => stworzonej wartości biznesowej?
  • Mierzalność.Czy możemy zdefiniować konkretną liczbę i jej jednostki miary (np, punkty, procenty), tak aby można ją było śledzić w czasie i skorelować z wydarzeniami i eksperymentami?
  • Actionable.Czy może ona regularnie informować o działaniach, które prowadzą do pozytywnych rezultatów? Najlepiej z minimalną ilością fałszywych pozytywów?
  • Dostępny/wygodny.Czy przeciętny zespół inżynierów oprogramowania może uzyskać dostęp do tej metryki bez zmiany istniejących procesów rozwoju?
  • Popularny.Czy ma wystarczająco dużo zwolenników, aby być dobrze udokumentowanym i wiarygodnym?
  • Włączenie do wiadra „Metryki jakości” wymaga wszystkich pięciu powyższych cech, plus satysfakcjonującej odpowiedzi na nasze pytanie: jeśli zaufamy tej metryce, a programiści będą ją optymalizować, co się wtedy stanie? Przez lata budowania i iteracji naszej własnej metryki rozwoju („Line Impact”) nauczyliśmy się, że toksyczne produkty uboczne są oczekiwaną konsekwencją pomiaru, chyba że metryka jest dokładnie dopasowana do długoterminowej wartości biznesowej.Jako przykład, pokażemy później, jak deweloperzy próbujący grać metryką „Lead Time” powodują zmniejszenie przejrzystości dla kierownictwa.

    Kapitalne wskaźniki KPI inżynierii jakości

    Oto pięć metryk oprogramowania, które sprawdzają wszystkie pola, aby pomóc menedżerom w prowadzeniu bardziej wydajnego zespołu.

    🏦 OKR-driven

    Przykładowy szablon OKR

    Jeden z wielu przykładowych szablonów OKR dostępnych przez Weekdone na Okrexamples.com

    Każda lista, która jest skoncentrowana na maksymalizacji wartości biznesowej powinna zaczynać się tutaj. Wiodące firmy, takie jakGoogle, używają OKR jako głównej osi, na której oceniają starszych inżynierów. Wadą metryk opartych na OKR jest to, że są one z definicji specyficzne dla specyfiki biznesowej. To sprawia, że niemożliwe jest uogólnienie formuły, za pomocą której można je uchwycić, lub uogólnienie ścieżki, za pomocą której zostaną oszukane.

    Jak to rozegrać? Ryzyko, że OKR zostaną oszukane jest niskie, ponieważ są one zazwyczaj skoncentrowane na biznesie. Głównym niebezpieczeństwem związanym z metrykami opartymi na OKR jest to, że ponieważ są one zazwyczaj formułowane jednorazowo (lub okresowo), mogą być mniej wiarygodne niż metryki, które były sprawdzane przez lata. Na przykład, ustalenie OKR na poziomie „wprowadzać mniej niż 10 błędów miesięcznie” może zostać oszukane poprzez nie wprowadzanie żadnych nowych funkcji. Zakładając, że obie strony działają w dobrej wierze, gry OKR powinny być w praktyce rzadkie.

    Jak je zdobyć? Poprzez istniejące pulpity pomiarowe lub poprzez współpracę z firmami takimi jak Weekdon, które pomagają w dostarczaniu inspiracji OKR.

    📐Line Impact

    Przykładowy inżynierski KPI Line Impact: wiarygodna metryka kodu źródłowego

    10 repozytoriów przedstawionych na wykresie według ich Line Impact, metryki, która określa tempo, w jakim kod źródłowy ewoluuje, obraz dzięki uprzejmości GitClear

    Line Impact jest metryką zaprojektowaną do pomiaru, ile energii poznawczej jest wkładane w rozwój oprogramowania.Ten film oferuje ilustrowane wyjaśnienie, jak to jest możliwe. Krótkie wyjaśnienie jest takie, że Line Impact niweluje wszelką aktywność przerywnikową („churn”), która ma miejsce, gdy funkcja jest rozwijana, pozostawiając skoncentrowane ucieleśnienie pracy, która miała miejsce. Line Impact jest zachowywany we wszystkich językach, więc wygenerowanie Line Impact zajmuje tyle samo czasu, niezależnie od tego, czy deweloper pisze w Javie, Pythonie, Javascript czy innym głównym języku programowania (30+ obsługiwanych).

    Pod względem wartości biznesowej, Line Impact jest podobny do Story Points: ilustruje, jak koszt zadania zmienia się w zależności od dewelopera, do którego jest przypisany. Na tej podstawie zaangażowany menedżer może użyć raportu Domain Experts, aby dopasować Jiras do ekspertów w danej dziedzinie, co może znacznie przyspieszyć szybkość produktu.

    Jak w to grać? Do każdej metryki, która podaje „Lines of Code” (LoC) jako źródło danych (tak jak Line Impact), należy podchodzić z ostrożnością. Wdrożona niedbale, subtelne niedoskonałości w przetwarzaniu ulegają powiększeniu do poziomu, który zagłusza sygnał.Dlatego właśnie GitClear zbudował najlepsze na rynku narzędzia do przeglądania kodu: aby menedżerowie i programiści mogli sprawdzić, w jaki sposób Line Impact jest przyznawany na podstawie każdego polecenia i pliku.Przejrzystość jest silnym antidotum w walce z grywalizacją.

    Dodatkowa ochrona ma postać powiadomień, które są uruchamiane, gdy programista wykonuje pracę z niezwykłą szybkością. Te i inne środki sprawiają, że gra w Line Impact jest na tyle trudna, że firma GitClear nie otrzymała jeszcze zgłoszenia od klienta, że Line Impact został z powodzeniem wykorzystany przez jego zespół.To powiedziawszy, byłoby nieuczciwe twierdzić, że metryka jest w jakiś sposób odporna na grę, więc oto lista znanych ścieżek, dzięki którym można zgromadzić szybki Line Impact.Istota jest taka, że jeśli programista pisze testy, usuwa stary kod i dodaje dokumentację, zarobi dużą część Line Impact.

    Jak go zdobyć? Zapisz się na bezpłatny 15-dniowy okres próbny. Jeśli Ci się spodoba, ceny zaczynają się od 9 dolarów za aktywnego dewelopera.Zobacz krótki film wyjaśniający na temat Line Impact tutaj.Dostępna wersja On prem.

    🎲 Story Points

    engineering KPIs: Jira burndown report

    Raport „release burndown” oparty na Story Point, dostępny przez Jira

    Story Points mogłyby pretendować do miana najbardziej „klasycznego” z inżynierskich KPI. Istnieje wiele różnych sposobów obliczania Story Points. Wszystkie formy odwzorowują szacunkowy oczekiwany czas dewelopera na ukończenie jakiegoś zadania. Menedżerowie mogą używać Story Points do obliczania kosztów związanych z zadaniem, np. jeśli deweloper zarabia $10k/miesiąc, bilet jest szacowany na 10 Story Points = połowa miesiąca, wtedy koszt wynosi $10,000 * 0.5 = $5,000.Użycie jakiejś wersji tej kalkulacji pomaga nadawać priorytety zadaniom w oparciu o to, które przynoszą najwyższy stosunekProjected Value/Projected Implementation Cost.

    Jak w to grać? Najwięcej uwagi należy poświęcić temu, jak obliczane są Story Points. Najłatwiejszym sposobem „gry” Story Points jest dla zespołu deweloperskiego do stronniczości skali oceny, zwykle w kierunku przeceniania trudności. Jedną z możliwości rozwiązania tego problemu jest pozwolenie na wybieranie zadań na „rynku zadań”, gdzie przecenione zadania mogą być równomiernie rozłożone pomiędzy deweloperów, aby zachować względną kalibrację. Innym sposobem na rozwiązanie tego problemu jest regularne rekalibrowanie stałej używanej do przeliczania Punktów Historii na „dni dewelopera”. Zauważ, że ponieważ implementacja Story Points często różni się w zależności od zespołu, nie jest zalecane używanie ich do porównywania wydajności między zespołami.

    Jak to zrobić? Większość issue trackerów po tej stronie GitHuba pozwala na określanie Story Points. Jeśli chodzi o ich przeglądanie, Jira oferuje „next-gen velocity report” dedykowany do pokazywania ukończonych Story Points w czasie.Oferuje również „release burndown report”, który używa Story Points do oszacowania, jak zespół podąża w kierunku swoich celów dla sprintu. GitClear oferuje również podstawowe (na chwilę obecną) wykresy, które ilustrują ukończone Story Points w czasie.

    🐞 Bug Rate / Escaped Defects

    Ta metryka jest definiowana w różny sposób przez różne źródła, ale wszystkie one zmierzają do tego samego zasadniczego pytania: ile błędów wydostaje się na świat i jak dobrze na nie reagujemy?Stackify odnosi się do tego w konkretnych kategoriach liczbowych:

    Twój współczynnik unikania defektów jest wyrażony jako procent w oparciu o to, ile defektów znajdziesz zanim trafią na produkcję lub ile z nich trafi na produkcję, jakkolwiek wolisz. Każdy projekt programistyczny i każdy zespół będzie inny, ale sugerujemy dążenie do znalezienia 90% wszystkich defektów zanim trafią one na produkcję.

    Definicja Stackify zakłada, że ktoś wyznaczy pole w swoim issue trackerze, aby uchwycić, w jakiej fazie rozwoju pojawił się błąd. Dla zespołów, które nie mają czasu na tworzenie i śledzenie faz rozwoju, zastępczą definicją może być:

    Jak często kod napisany w nowej funkcjonalności staje się kodem zmienionym w trakcie rozwiązywania błędu?

    Powiązana z danymi odpowiedź na to pytanie jest dostarczana użytkownikom GitClear, ale jest trudna do obliczenia ręcznie (jeśli nie jesteś użytkownikiem GitClear).Gwarantowaną, dostępną miarą awaryjną wskaźnika błędów może być „jaki jest stosunek błędów stworzonych do błędów rozwiązanych”?

    Jak to rozegrać? Ta metryka jest trudna do rozegrania. Deweloper może wziąć na siebie więcej małych zgłoszeń, ale każde zgłoszenie wprowadza zwiększone ryzyko wystąpienia błędów, jeśli nie jest ostrożny. Ryzyko użycia Bug Rate polega na tym, że potrzebuje on przeciwwagi dla „postępu”, takiej jak Story Points lub Line Impact, w przeciwnym razie deweloper mógłby pozostać przy jednej sprawie przez cały sprint, zapewniając 0% wskaźnik błędów.

    Jak go uzyskać? Jeśli twój zespół ma przepustowość, aby oznaczać sprawy według fazy rozwoju, w której wystąpiły, wtedyEscaped Defects może być obliczany ręcznie przez dowolny issue tracker. GitClear jest inną dostępną opcją do obliczenia procentu cech, które stają się błędami.

    ✅ Pull Request Completion Rate

    Przykładowy inżynierski KPI Pull Requests: statystyki na GitClear

    Próbka statystyk pull requestów dostarczonych przez GitClear

    Jaki procent pull requestów został zamknięty w ciągu tygodnia od otwarcia? To zwija kilka bardziej szczegółowych pytań, takich jak „czy zespół jest zaangażowany w szybkie odpowiadanie na nowe pull requesty”, „czy są w stanie współpracować” i „czy programiści doszlifowali swój kod przed wysłaniem go do scalenia?”

    Jak w to grać? Zaliczenie testu „Pull request completion rate” oznacza zawsze zamykanie PR-ów w ciągu tygodnia. Jest to stosunkowo trudne do osiągnięcia, ale musi być zrównoważone przez siłę napędową, taką jak Story Points lub Line Impact, w przeciwnym razie wszystkie bodźce zespołu będą polegały na dopracowaniu pracy, a nie jej wysłaniu (lub przedłożeniu do przeglądu PR).

    Jak to zdobyć?Wszyscy „markowi” dostawcy Engineering Insight (GitClear, Pluralsight, Code Climate, Pinpoint) oferują statystyki, które ilustrują efektywność procesu pull request zespołu. Pomagamy porównać dostawców tutaj.

    Honorowe wzmianki

    Pod metrykami „najwyższego poziomu”, znajdujemy poziom pośredni. Są to metryki, które posiadają pożądane cechy obok ważnych niedociągnięć. Mogą one nadal dostarczać wartość, tak długo jak menedżer wie wystarczająco dużo, aby uwzględnić ich ograniczenia.

    Lead Time/Cycle Time

    Wykres Lead Time jako wizualizacja przez Azure Devops

    Choć jest on wymieniony (dwukrotnie!) na liście Top 5 Metryk Pluralsight, Czas Cyklu jest dobrym pomysłem, który jest bardzo podatny na grę.

    „Lead Time” jest najczęściej definiowany jako „Jaki jest odstęp czasu pomiędzy tym, kiedy zadanie jest zgłaszane w issue tracker i kiedy jest dostarczane do klienta?”. Jego kuzyn, „Cycle Time”, jest podzbiorem Lead Time, definiowanym jako „czas pomiędzy momentem, w którym zespół produktowy wyrwał zadanie z kolejki, a momentem, w którym trafiło ono na produkcję.”

    Jak w to grać? Wydajność Lead Time zależy w pewnym stopniu od mechanizmu, za pomocą którego Jiras jest zgłaszany, co oznacza, że jego stosowalność w różnych zespołach jest niska. Cycle Time zależy od konwencji, dzięki którym commitujący decyduje się na swój pierwszy commit. W związku z tym, metryka ta jest łatwa do oszukania, jeśli programista zapisuje swoje commit’y lokalnie i wypuszcza je w jednym zrywie pracy bezpośrednio przed wysłaniem PR. Ta porażka jest tym, co releguje Cycle Time do sekcji „Honorable mentionions”. Nie jest to również idealne rozwiązanie: poprzez zachęcanie programisty do zapisywania commitów bez naciskania, niemożliwe jest, aby koledzy z zespołu interweniowali, gdy praca jest w toku.Ten efekt uboczny zmniejsza przejrzystość pomiędzy menedżerem a jego programistami.

    Jak go uzyskać?Azure Devops Services dostarcza wykres opisany powyżej.Jira również oferuje jego wersję.Wszystkie główne ofertyEngineering Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementują jakąś wersję kalkulacji Lead Time.

    Pokrycie testowe

    Próbowanie uchwycenia jakiejś miary pokrycia testowego jest rozsądnym celem do rozważenia. Jednakże, itdoesn’t quite make the cut as a Top Tier metric for two reasons:

  1. It’s an incomplete solution. Odpowiednie testowanie musi zawierać testy funkcjonalne i integracyjne obok testów jednostkowych, a żadne zautomatyzowane rozwiązanie nie może wiedzieć, które strony muszą być odwiedzone w aplikacji lub witrynie, to nadal wymaga ludzkiego kierunku
  2. To jest bardzo trudne do powiązania z metrykami biznesowymi. Pokrycie testowe jest warte oceny jako część planu Lead Developer’a do monitorowania jakości kodu, ale nie łączy się bezpośrednio z wartością biznesową na tyle, aby samo w sobie mogło być brane pod uwagę. Powiązana, ale bardziej funkcjonalna metryka do śledzenia defektów kodu to „Bug Rate / Escaped Defects.”

„Everything Else” Metrics

Powyższa lista jest stosunkowo krótka w porównaniu z korpusem metryk, które zostały zaproponowane przez innych autorów.Ze względu na kompletność, przejrzyjmy niektóre z najczęściej wymienianych metryk gdzie indziej, oraz dlaczego nie znalazły się na liście.

Team Velocity

To była jedna z najbardziej popularnych metryk cytowanych przez inne artykuły. Jest zalecana przezTechBeacon, InfoPulse iSeaLights.io.Jednak autorzy wydają się ostrożni w definiowaniu jednostek tej ważnej metryki.TechBeacon definiuje ją jako „ile 'jednostek’ oprogramowania zespół zazwyczaj kończy w iteracji”. Nie sotangible. InfoPulse nie próbuje określać jednostek. SeaLights mówi, że jednostkami są „Story Points”. Tak więc, doszliśmy do wniosku, że pojęcie „szybkości” jest odpowiednio uchwycone przez Story Points lub Line Impact przez proxy.

Code Churn

CEO GitPrime (obecnie przejęty przez Pluralsight) był jednym z tych, którzy opowiadali się za rozważeniem Code Churn.W odpowiedzi twierdzimy, że implikacje Code Churn są na całej mapie, co sprawia, że bardzo trudno jest działać w przypadku wysokiego churn. Metryka musi być możliwa do zastosowania.

Release/Sprint Burndown

SeaLights i InfoPulse zalecają zwracanie uwagi na to, jak zespół zmierza w kierunku swoich celów sprintu.

Średni czas do naprawy / Średni czas między awariami

Wśród kilku artykułów, które są mistrzami w tej metryce, żaden nie odważył się opisać, w jakich jednostkach jest ona oparta lub jakiej usługi można użyć do zebrania tych punktów danych.Badania wykazały, że Atlassian oferuje artykuł pomocy na ten temat.Gdyby ten artykuł nie był już długi na 2500 słów, MTTR mógłby znaleźć się w sekcji „Honorowe wyróżnienia”. Ale nie jest to łatwe do powiązania z wartością biznesową i nie jest to proste dla przeciętnego zespołu, aby uzyskać dostęp bez zmiany ich rutynowych czynności.

Czy coś przeoczyliśmy?

.

Leave a Reply

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.