Metryki dostarczania, które kłamią, gdy kod piszą agenci

Kwartał po tym, jak zespół zaczął używać agentów kodujących, pulpit inżynierski wygląda jak sukces. Więcej pull requestów, więcej zamkniętych zgłoszeń, więcej scalonego kodu, prędkość w górę. Zarząd pyta, czy to działa, a pulpit odpowiada, że tak.

Pulpit mierzy aktywność, a aktywność jest dokładnie tym, co agenci uczynili tanim.

To nie jest nowy problem — każda liczba, którą łatwo poruszyć, prędzej czy później zostaje poruszona. Nowe jest to, że agenci przesuwają akurat te liczby bardzo daleko, choć nikt nie zamierza niczego naciągać.

Dlaczego znajome liczby puchną

Metryki wyjścia liczą to, co potaniało. Wiersze kodu, pull requesty i zamknięte zgłoszenia zawsze były przybliżeniem ludzkiego wysiłku, a wysiłek był znośnym przybliżeniem postępu, dopóki był ograniczeniem. Już nie jest. Te liczby liczą teraz generowanie.

Czas cyklu zaczyna się w złym momencie. Mierzony od pierwszego commita albo od otwarcia pull requesta pomija to, co stało się trudniejsze, czyli precyzyjne rozstrzygnięcie, co ma powstać, i daje za małą wagę temu, co zwolniło, czyli przeglądowi.

Prędkość jest deklarowana. Punkty szacują ci sami ludzie, których pracę te punkty mają mierzyć. Gdy praca przyspiesza, szacunki się przesuwają, a trend mówi więcej o kalibracji niż o dostarczaniu.

Nie znaczy to, że te liczby są bezużyteczne dla zespołu planującego własny tydzień. Znaczy, że są bezużyteczne jako dowód, że metoda działa.

Co nadal coś znaczy

Większość tego, co poniżej, to znany zestaw DORA (częstotliwość wdrożeń, czas realizacji zmian, odsetek nieudanych zmian i czas przywrócenia usługi) z dwiema poprawkami, które mają znaczenie, gdy w grę wchodzą agenci: zegar rusza w chwili decyzji, a każda liczba jest dzielona według tego, kto napisał zmianę.

Czas od zatwierdzonej specyfikacji do produkcji. Zegar rusza, gdy zapada decyzja, a nie gdy zaczyna się generowanie, i staje, gdy użytkownicy mają zmianę u siebie. To właśnie tę liczbę agenci mają poprawiać. Jeśli się nie ruszyła, szybkość poszła gdzie indziej.

Odsetek nieudanych zmian według pochodzenia. Udział zmian, które kończą się incydentem albo wycofaniem, raportowany osobno dla zmian wygenerowanych przez agentów i pisanych ręcznie. Bez tego podziału pogorszenie w jednej grupie chowa się za drugą.

Przeróbki. Ile scalonego kodu zostaje ponownie zmienione w ciągu kilku tygodni z powodów innych niż nowe wymagania. Wiarygodny i subtelnie błędny kod widać tutaj na długo przedtem, zanim trafi do raportów z incydentów.

Defekty, które uciekły, według miejsca, w którym powinny zostać złapane. Specyfikacja, testy, bramki w potoku albo przegląd. Sama liczba defektów mówi, że coś jest nie tak; klasyfikacja mówi, którą część procesu naprawiać.

Obok nich stoją miary przeglądu — liczba zmian przejrzanych dziennie i wielkość zaległego stosu do przeglądu — które utrzymują w polu widzenia prawdziwe ograniczenie.

Infografika

Co mierzyć, gdy kod piszą agenci

Aktywność

• –Liczba otwartych i scalonych pull requestów
• –Wiersze kodu
• –Punkty w sprincie
• –Czas od pull requesta do scalenia

Dostarczanie i jakość

• →Czas od zatwierdzonej specyfikacji do produkcji
• →Odsetek nieudanych zmian: generowane i pisane ręcznie
• →Przeróbki w ciągu kilku tygodni od scalenia
• →Defekty według etapu, który je przepuścił

Podział według rodzaju pracy

Agenci pomagają nierówno. Przy pracy dobrze wyspecyfikowanej i powtarzalnej, takiej jak integracje, adaptery czy migracje, zysk jest realny. Przy pracy nowatorskiej albo słabo rozumianej napisanie precyzyjnej specyfikacji potrafi zająć więcej czasu, niż wcześniej zajmowało napisanie kodu.

Średnia z obu rodzajów ukrywa jedyne pytanie warte odpowiedzi: gdzie agenci się zwracają, a gdzie kosztują. Oznaczajcie rodzaj pracy przy planowaniu, a nie po fakcie, i raportujcie każdą liczbę w tym podziale.

Zmierzcie, zanim przełączycie

Najczęstszą luką jest punkt odniesienia. Jeśli nikt nie zmierzył czasu realizacji i odsetka nieudanych zmian, zanim pojawili się agenci, jedynym porównaniem jest pamięć zespołu, a pamięć to kiepski punkt odniesienia.

Miesiąc pomiarów przed wdrożeniem kosztuje niewiele. Po fakcie nie da się go kupić za żadne pieniądze.

Potem mierzcie dokładnie tak samo. Zmiana definicji czasu realizacji w tym samym kwartale co zmiana narzędzi odbiera porównaniu jakikolwiek sens, nawet jeśli wypada ono korzystnie.

Test dla każdej metryki

Liczba, która rośnie, gdy po prostu generujecie więcej, nie jest metryką dostarczania. Zadajcie to pytanie każdej pozycji na pulpicie.

W rozwoju sterowanym specyfikacją poziom błędów mierzymy otwarcie od pierwszej pętli i to te liczby, a nie entuzjazm, rozstrzygają, czy metoda obejmie większą część kodu, czy zostanie przerwana. Przerwanie jest uprawnionym wynikiem i lepiej poznać je po czterech tygodniach niż po czterech kwartałach.