Retrospektywa długu technicznego

Znajdź, uszereguj i zaplanuj spłatę długu technicznego

Zapraszamy do obejrzenia tej retrospektywy na żywo

Źródła długu

W których obszarach kodu narósł dług techniczny?

Moduł uwierzytelniania użytkowników jest nadmiernie skomplikowany i trudny w utrzymaniu przez liczne hacki i obejścia dodawane latami.
Mamy mnóstwo zduplikowanego kodu w różnych komponentach, który powinien zostać przeniesiony do wspólnych narzędzi.
Wiele naszych kluczowych modeli danych jest ze sobą ściśle powiązanych, więc rozszerzanie lub zmiana funkcjonalności grozi regresjami.
Wpływ i ryzyka

Jak ten dług techniczny wpływa na zespół i produkt?

Wdrażanie nowych programistów jest niezwykle trudne ze względu na złożoność i brak dokumentacji w niektórych obszarach.
Ciągle gasimy pożary i nie jesteśmy w stanie dostarczać nowych funkcji w rozsądnym tempie, bo dług powoduje niestabilność.
Nasz proces wdrożeń jest kruchy i podatny na błędy, co prowadzi do częstych problemów na produkcji i awarii.
Priorytetyzacja

Którymi obszarami długu zająć się najpierw?

Powinniśmy zacząć od modułu uwierzytelniania, bo to kluczowa zależność, która wpływa na wiele obszarów aplikacji.
Lepsze pokrycie testami najbardziej zmiennych komponentów dałoby solidną podstawę pod przyszłą refaktoryzację.
Aktualizacja frontendu do najnowszej wersji Reacta powinna być najwyższym priorytetem, żeby skorzystać z poprawek wydajności i nowych funkcji.
Plan działania

Jak systematycznie spłacać dług, który uznaliśmy za priorytetowy?

Przeznaczymy 20% każdego sprintu na najważniejsze elementy długu, zaczynając od refaktoryzacji modułu uwierzytelniania.
Co dwa tygodnie zrobimy dzień „wpłaty na poczet długu”, w którym będziemy wprowadzać drobne usprawnienia zgodnie z priorytetami.
Przez następny kwartał jeden starszy programista zajmie się wyłącznie prowadzeniem prac nad redukcją długu technicznego.

Czym jest retrospektywa długu technicznego?

Retrospektywa długu technicznego to sesja, podczas której zespół mapuje dług w swoim kodzie lub systemie, uzgadnia, ile ten dług kosztuje, i decyduje, co spłacić w pierwszej kolejności. Kończy się planem z przypisanymi osobami i terminami. Dług techniczny to nagromadzone w kodzie skróty i nie do końca dobre rozwiązania. Część wynika z przedkładania szybkiego dostarczenia nad długoterminową jakość, część z luk w zrozumieniu, a część z refaktoryzacji, którą ciągle odkładano. Pozostawiony sam sobie sprawia, że każda zmiana jest wolniejsza i bardziej ryzykowna. Tablica ma cztery kolumny. W kolumnie „Źródła długu” uczestnicy wskazują konkretne obszary problemowe: splątane moduły, zduplikowany kod, brakujące testy, przestarzałe frameworki. Kolumna „Wpływ i ryzyka” opisuje, jak dług odbija się na dostarczaniu, jakości, wdrażaniu nowych osób i morale. W kolumnie „Priorytetyzacja” elementy są szeregowane według wpływu, nakładu pracy i ważności. „Plan działania” zamienia najważniejsze z nich w zadania z właścicielami, terminami i punktami kontrolnymi, na przykład stałą część każdego sprintu przeznaczoną na spłatę długu. Przeprowadzaj tę retrospektywę mniej więcej raz na kwartał albo zawsze, gdy zespół czuje, że dług go spowalnia, aby dług pozostawał widoczny i niewielki.

Format retrospektywy długu technicznego

Źródła długu

W których obszarach kodu narósł dług techniczny?

Poproś uczestników, aby konkretnie określili rodzaj długu i miejsce, w którym występuje: code smells, problemy architektoniczne, brakujące testy, przestarzałe zależności.

Wpływ i ryzyka

Jak ten dług techniczny wpływa na zespół i produkt?

Porozmawiajcie o tym, ile dług faktycznie kosztuje: wolniejsze dostarczanie, błędy widoczne dla klientów, uciążliwe wdrażanie nowych osób, sfrustrowani programiści. Konkretne koszty są najlepszym argumentem za spłatą długu.

Priorytetyzacja

Którymi obszarami długu zająć się najpierw?

Uszeregujcie elementy długu według wpływu, nakładu pracy i tego, jak bardzo blokują inne prace. Szybka macierz wpływ–nakład pomaga zespołowi dojść do porozumienia.

Plan działania

Jak systematycznie spłacać dług, który uznaliśmy za priorytetowy?

Zbudujcie konkretny plan: kto co robi, do kiedy i kiedy sprawdzicie postępy. Ustalcie, jaka część możliwości każdego sprintu idzie na spłatę długu.

Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego

  • Gdy z każdą zmianą coraz trudniej utrzymywać i rozwijać kod.
  • Gdy zespół spędza czas na gaszeniu pożarów, a nowe funkcje ciągle się opóźniają z powodu niestabilności.
  • Gdy wdrażanie nowych programistów trwa długo, bo niektóre obszary są zawiłe lub nieudokumentowane.
  • Gdy utrzymanie i poprawki błędów zajmują więcej czasu niż nowa praca.
  • Gdy programistów sprint po sprincie frustrują te same problematyczne obszary.

Proponowane pytania lodołamacze

  • Gdyby nasz kod był budynkiem, jak by wyglądał i dlaczego?
  • Jakie było Twoje najzabawniejsze albo najbardziej bolesne spotkanie z długiem technicznym?

Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →

Pomysły i wskazówki dotyczące spotkania retrospektywnego

  • Prowadźcie dyskusję bez szukania winnych. Dług narasta w każdym kodzie, a pytanie brzmi, co z nim teraz zrobić.
  • Upewnij się, że osoby nietechniczne obecne na spotkaniu rozumieją, czym jest dług techniczny i dlaczego ma znaczenie dla dostarczania.
  • Szeregujcie dług według wpływu, nakładu pracy i ważności, zamiast próbować naprawić wszystko naraz.
  • Nadajcie planowi terminy, właścicieli i regularne punkty kontrolne, żeby nie utknął w miejscu.
  • Zarezerwujcie stałą część każdego sprintu lub cyklu na spłatę długu.
  • Zautomatyzujcie linting, testy i część code review, żeby do kodu trafiało mniej nowego długu.

Najczęściej zadawane pytania

Czym jest retrospektywa długu technicznego?
To spotkanie zespołu poświęcone znalezieniu miejsc, w których narósł dług techniczny, omówieniu jego kosztów, ustaleniu, czym zająć się najpierw, i zaplanowaniu jego spłaty.
Kiedy przeprowadzić retrospektywę długu technicznego?
Przeprowadź ją, gdy zauważysz spowolnienie dostarczania, powracające błędy lub stertę skrótów po wcześniejszych decyzjach. Wiele zespołów organizuje ją też regularnie, na przykład raz na kwartał, obok zwykłych retrospektyw sprintu.
Jak ustalać priorytety długu technicznego podczas retrospektywy?
Oceń każdy element pod kątem wpływu, nakładu pracy i ważności, zamiast brać się za wszystko naraz. Następnie zamień najważniejsze elementy w plan działania z właścicielami i terminami.
Kto powinien uczestniczyć w retrospektywie długu technicznego?
Programiści pracujący z kodem oraz Product Owner lub osoba ustalająca priorytety. Jeśli nie ma osoby, która decyduje o tym, co powstaje, plan rzadko dostaje czas w sprincie.
Ile czasu poświęcać na spłatę długu technicznego?
Nie ma jednej właściwej liczby. Wiele zespołów rezerwuje stałą część każdego sprintu, dzięki czemu dług jest spłacany regularnie, zamiast czekać na osobny sprint porządkowy, który nigdy nie nadchodzi.

Powiązane szablony

Retrospektywa procesu rozwoju produktu

Oderwij się od sprintów i sprawdź, jak tworzycie produkty.

Retrospektywa naprawy błędów

Dowiedz się, skąd biorą się błędy, i nie dopuść do ich powrotu

Retrospektywa code review

Spraw, by przeglądy kodu w zespole były szybsze i bardziej przydatne

Retrospektywa DevOps

Przeanalizujcie wdrożenia, incydenty i przekazywanie pracy między dev a ops.

Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo