Ocena długu technicznego dla zespołów inżynierskich

Oceńcie, gdzie dług techniczny spowalnia wasz zespół i czy go spłacacie.

Wypróbuj tę analizę stanu zdrowia w czasie rzeczywistym

Co mierzy ocena długu technicznego?

Ward Cunningham ukuł metaforę długu technicznego w swoim raporcie z doświadczeń przedstawionym na konferencji OOPSLA w 1992 roku, pisząc, że „wypuszczenie kodu napisanego po raz pierwszy jest jak zaciągnięcie długu”. Niewielki dług może przyspieszyć pracę. Kłopoty zaczynają się, gdy nie jest spłacany, a każda godzina spędzona na obchodzeniu nie do końca poprawnego kodu staje się odsetkami. Skanery kodu mierzą kod. Ta ocena mierzy to, z czym zespół żyje na co dzień: czy widzicie dług, jak bardzo spowalnia dostarczanie, w jakiej kondycji są waszym zdaniem kod i systemy oraz czy go spłacacie. Każdy ocenia poszczególne stwierdzenia indywidualnie, a potem omawiacie najniższe wyniki na retrospektywie i ustalacie, co naprawić najpierw.

Wymiary

Widoczność

Czy zespół wie, gdzie jest jego dług, i traktuje go jako prawdziwą pracę.

  • Znane punkty zapalne

    Wiemy, które części naszego systemu są najbardziej obciążone długiem.

  • Śledzony razem z inną pracą

    Dług jest śledzony w tym samym backlogu co funkcje i błędy.

  • Znany koszt

    Potrafimy wyjaśnić, ile czasu lub ryzyka kosztują nas nasze największe długi.

Wpływ na dostarczanie

Jak bardzo dług spowalnia pracę, którą zespół stara się dostarczyć.

  • Tempo pracy nad funkcjami

    Dług rzadko spowalnia funkcje, które budujemy.

  • Bezpieczne zmiany

    Zmiana w jednej części naszego systemu rzadko psuje część z nią niezwiązaną.

  • Szybkie i niezawodne buildy

    Nasze buildy i testy są szybkie i niezawodne.

Kondycja kodu i systemów

Jak łatwo pracuje się dziś z kodem, systemami i zależnościami.

  • Łatwość zmian

    Większość naszego kodu jest łatwa do zrozumienia i zmiany.

  • Aktualne zależności

    Nasze zależności i platformy są w miarę aktualne.

  • Testy wspierają refaktoryzację

    Nasze testy dają nam pewność przy refaktoryzacji.

Spłacanie długu

Czy zespół robi stałe, uzgodnione postępy w zmniejszaniu długu.

  • Zarezerwowany czas

    Regularnie rezerwujemy czas na spłatę długu.

  • Rejestrowanie świadomego długu

    Gdy świadomie zaciągamy dług, zapisujemy go wraz z planem spłaty.

  • Wspólne priorytety

    Produkt i inżynieria są zgodni co do podziału czasu między funkcje a dług.

Kiedy należy skorzystać z tej kontroli stanu zdrowia

  • Gdy praca nad funkcjami trwa dłużej, niż powinna, a zespół wciąż wskazuje na kod jako przyczynę.
  • Przed planowaniem kwartalnym lub planowaniem roadmapy, aby uzgodnić, ile czasu przeznaczyć na spłatę długu.
  • Po dużym wysiłku lub napiętym terminie, aby zapisać skróty, na które poszliście, zanim o nich zapomnicie.

Porady i wskazówki

  • Zacznijcie od grupy z najniższym wynikiem. Niska widoczność oznacza, że przede wszystkim potrzebujecie listy długów. Wysoka widoczność przy słabej spłacie wskazuje na problem z planowaniem, a nie z kodem.
  • Zaproście product managera do dyskusji, nawet jeśli oceniają tylko inżynierowie. Podział czasu między funkcje a dług to wspólna decyzja.
  • Zestawcie wyniki z danymi, które już macie, np. czasami buildów, liczbą niestabilnych testów czy przyczynami incydentów. Ocena pokazuje, gdzie boli, a dane pokazują, jak bardzo.
  • Przeprowadźcie ją razem z Samooceną metryk DORA, Oceną dojrzałości DevOps lub Modelem dojrzałości doskonałości inżynierskiej, aby zobaczyć, jak dług wiąże się z dostarczaniem i praktykami inżynierskimi.
  • Powtarzajcie ją co kwartał. Rosnący wynik w stwierdzeniach z grupy „Spłacanie długu” to najwcześniejszy sygnał, że wasz plan działa.

Najczęściej zadawane pytania

Jak mierzyć dług techniczny?
Nie ma jednej liczby. Zespoły łączą metryki kodu, takie jak złożoność, częstotliwość zmian i pokrycie testami, z sygnałami z dostarczania, np. czasem buildów, nieudanymi zmianami i czasem realizacji funkcji. Ocena zespołowa, taka jak ta, dodaje to, czego narzędzia nie wychwytują: gdzie dług rzeczywiście spowalnia ludzi. Śledźcie te same miary w czasie, zamiast gonić za idealnym wynikiem.
Jakie są cztery rodzaje długu technicznego?
Najbardziej znany podział to kwadrant długu technicznego Martina Fowlera. Klasyfikuje on dług według dwóch pytań: czy został zaciągnięty świadomie, czy nieświadomie, oraz czy decyzja była rozważna, czy lekkomyślna. Rozważny, świadomy dług to znany kompromis z planem spłaty, natomiast dług lekkomyślny zwykle narasta niezauważony.
Ile czasu powinniśmy poświęcać na dług techniczny?
Nie ma standardowej odpowiedzi. Niektóre zespoły rezerwują stałą część każdego sprintu, inne planują regularne porządki, a jeszcze inne naprawiają dług w kodzie, który i tak zmieniają. Wybierzcie konkretną ilość czasu, uwzględniajcie ją jawnie w planowaniu i przeprowadzajcie tę ocenę co kwartał, aby sprawdzić, czy to wystarcza.
Jak wyjaśnić dług techniczny product managerom?
Mówcie o odsetkach, a nie o kodzie. Pokażcie, jak dług spowalnia konkretne funkcje, powoduje incydenty lub obniża wiarygodność szacunków, i co uwolniłaby jego spłata. Pomaga przeprowadzenie tej oceny w obecności osób z produktu, bo obie strony widzą te same wyniki i mogą uzgodnić, co naprawić najpierw.
Jaki jest przykład długu technicznego?
Zespół kopiuje moduł, aby zdążyć z terminem, i planuje później scalić kopie. Po kilku miesiącach każdą poprawkę trzeba wprowadzać dwa razy, a kopie zdążyły się od siebie oddalić. Inne częste przykłady to przestarzałe zależności, brak testów wokół krytycznego kodu i powolny build, który wszyscy obchodzą.
Kto ukuł termin „dług techniczny”?
Ward Cunningham wprowadził tę metaforę w 1992 roku w raporcie z doświadczeń przedstawionym na konferencji OOPSLA, dotyczącym systemu zarządzania portfelem WyCash. Napisał, że „wypuszczenie kodu napisanego po raz pierwszy jest jak zaciągnięcie długu” i że niebezpieczeństwo pojawia się wtedy, gdy dług nie jest spłacany. TeamRetro nie jest powiązane z Wardem Cunninghamem.

Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).

Powiązane badania kontrolne