Pożegnaj się z długiem technicznym: rozwiązania Agile dla czystego rozwoju

Dług techniczny to koncepcja w rozwoju oprogramowania, która polega na porównaniu przyszłego kosztu związanego z wybraniem teraz szybkiego lub łatwego rozwiązania lub z lepszym, ale bardziej czasochłonnym podejściem.

Gdy programiści przedkładają szybkość nad jakość kodu, skutkiem są nieoptymalne rozwiązania, które wymagają refaktoryzacji lub udoskonalenia w przyszłości. Podwaja to nakład pracy zespołów, pochłaniając ich budżety, zasoby i osie czasu projektów.

Przykładem może być użycie przestarzałej biblioteki, ponieważ jest znana, lub wprowadzenie do kodu stałych wartości, które powinny być konfigurowalne. W danej chwili takie rozwiązanie może się wydawać skuteczne, ale później doprowadzi ono do kosztownych przeróbek, takich jak:

• przepisywanie słabego kodu, który ulega uszkodzeniu, gdy zmienia się powiązana funkcja;

• refaktoryzacja modułu, który nie skaluje się wraz ze wzrostem ilości użytkowników lub danych;

• zastępowanie nieaktualnych zależności, które nie otrzymują już aktualizacji zabezpieczeń;

• porządkowanie ściśle połączonych komponentów, dzięki czemu funkcje można tworzyć i wdrażać niezależnie.

W przypadku tworzenia tradycyjnych programów komputerowych często stosuje się podejście fazowe: najpierw opracowanie funkcji, a potem wersje alfa, beta i golden master (GM).

Każde wydanie oprogramowania rozpoczyna się od fazy opracowania nowych funkcji, a (najlepiej) także rozwiązania problemów, jakie pozostały po ostatnim wydaniu.

• Alfa: Gdy poszczególne funkcje zostają wdrożone i są gotowe do przetestowania. 

• Wersja beta zaczyna się wtedy, gdy usunięto dostatecznie dużo błędów, aby można było zwrócić się o opinię do klientów. Niestety w miarę jak zespół stara się usunąć dostateczną ilość błędów, aby udostępnić wersję beta, pojawiają się nowe błędy przyczyniające się do powstania długu technicznego. Jest to klasyczny przypadek gry w „walnij kreta”: naprawiasz jeden błąd, a pojawiają się dwa kolejne. 

• Zerową liczbę otwartych błędów uzyskuje się zazwyczaj przez naprawienie pewnych znanych błędów i przekierowanie pozostałych do kolejnego wydania. 

Odkładanie usuwania błędów powoduje narastanie długu technicznego i efekt kuli śnieżnej. Wraz ze wzrostem backlogu, ich likwidacja staje się coraz trudniejsza. Prace zwalniają, terminy się przesuwają, a klienci cierpią z powodu utrzymujących się wad. Zamiast pozwolić, aby dług techniczny wymknął się spod kontroli, przyjęcie praktyk Agile może zapewnić bardziej zrównoważone podejście.

Zrozumienie długu technicznego oznacza uznanie, że nie cały dług jest jednakowy. Główne kategorie długu technicznego:

• Celowe zadłużenie: kiedy zespoły świadomie idą na skróty, aby dotrzymać terminów lub szybciej wysyłać funkcje. To świadoma decyzja, gdy programiści rozumieją, że generują pracę na przyszłość, ale stawiają na szybkość zamiast doskonałości.

• Przypadkowy dług: niska jakość kodu może być spowodowana nieumyślnie. Programista może błędnie zinterpretować wymagania albo zespołowi może brakować doświadczenia w określonej technologii. Ten rodzaj długu technicznego wynika raczej z niezamierzonych błędów niż ze strategicznych wyborów.

• Degradacja danych: nawet dobry kod może z czasem stać się problematyczny. Wraz z ewolucją systemów, zmieniającymi się zależnościami i dodawaniem nowych funkcji, wcześniej stabilny kod może stać się przestarzały lub niekompatybilny z nowszymi komponentami.

Zespoły akumulują dług techniczny z kilku powodów, często nie zdając sobie sprawy, że tak się dzieje. Typowe przyczyny długu technicznego to: 

• Krótkie terminy: Kiedy menedżerowie produktu naciskają na szybsze dostarczanie, pojawiają się niedociągnięcia. Zamiast właściwych rozwiązań stosowane są szybkie poprawki, powodując narastanie długu w miarę upływu czasu. 

• Brak testów: Pominięcie testów może początkowo zaoszczędzić czas, ale przeoczone błędy powodują ciągłe obciążenia związane z konserwacją, które spowalniają przyszły rozwój. 

• Słaba komunikacja: Gdy praktyki zarządzania projektami oparte na metodologii Agile przestają działać, programiści mogą źle zrozumieć wymagania lub wysnuwać założenia, które prowadzą do konieczności ponownej pracy. 

• Luki w umiejętnościach: Zespoły pracujące z nieznanymi technologiami często opracowują rozwiązania, które nie są optymalne i wymagają udoskonalenia w miarę zdobywania wiedzy specjalistycznej. 

• Zmieniające się wymagania: wraz ze zmianą strategii produktu kod, który kiedyś miał sens, może przestać być zgodny z obecną wizją, faktycznie przekształcając się w dług techniczny.

Największym wyzwaniem w przypadku długu technicznego jest to, że często jest on niewidoczny, dopóki nie zacznie powodować prawdziwych problemów. A wtedy masz już zaległości. Na szczęście istnieją proste sposoby, aby go zidentyfikować, zanim stanie się poważnym problemem.

Oto najskuteczniejsze metody wczesnej identyfikacji długu technicznego:

• Przeglądy kodu: regularne weryfikacje przeprowadzane przez współpracowników często ujawniają obszary, w których ktoś poszedł na skróty lub złożoność osiągnęła poziom niemożliwy do opanowania.

• Wskaźniki złożoności: narzędzia do pomiaru złożoności kodu mogą pomóc w identyfikacji problematycznych sekcji, które wymagają uwagi. Wysoka złożoność cykliczna lub głębokie zagnieżdżenie często wskazują na obszary wymagające refaktoryzacji.

• Opinie programistów: członkowie zespołu pracujący codziennie nad kodem dostrzegają wzorce i bolączki, których wskaźniki mogą nie wykazać. Ich spostrzeżenia są nieocenione przy identyfikacji problemów, które spowalniają proces rozwoju.

• Monitorowanie wydajności: długi czas reakcji lub nagłe skoki wykorzystania zasobów mogą wskazywać na ukryte problemy techniczne, które wymagają uwagi.

Powtarzające się błędy lub nieoczekiwane opóźnienia również sygnalizują ukryty dług, który spowalnia postęp. Gdy wciąż pojawiają się problemy tego samego rodzaju lub wprowadzanie prostych zmian trwa dłużej niż oczekiwano, zwykle jest to znak, że dług techniczny wpływa na prędkość pracy zespołu.

Dług techniczny może rosnąć w efekcie szybkich rozwiązań wprowadzanych przy napiętych terminach, zmieniających się wymagań czy przestarzałych systemów. Zdarza się też odziedziczenie części tego długu w przypadku pracy ze starszym kodem.

Jednak poniższe porady pomogą Ci zarządzać istniejącym długiem technicznym i umożliwią Twojemu zespołowi skoncentrowanie się na ciekawszych zagadnieniach, takich jak opracowywanie nowych funkcji.

1. Określenie jasnej definicji długu technicznego

Czasami programiści i menedżerowie produktów nie zgadzają się co do elementów składających się na dług techniczny. Pozbądźmy się zatem wszelkich kontrowersji:

W zespole programistycznym może pojawić się pokusa opisywania prac związanych z architekturą jako długu technicznego. Zmiana może stanowić dług techniczny lub go nie stanowić w zależności od jej charakteru, np. zastąpienie skrótu „prawdziwym” rozwiązaniem na tle podziału monolitycznej bazy kodu na mikrousługi.

Z drugiej strony menedżerowie produktów często traktują prace związane z tworzeniem nowych funkcji jako bardziej pilne niż te dotyczące usuwania błędów czy naprawiania spowolnienia działania. 

Aby uniknąć niewłaściwej interpretacji, każdy musi znać różnicę między długiem technicznym, pożądanymi zmianami w zakresie architektury w bazie kodu i nowymi funkcjami. Skuteczna komunikacja między menedżerami ds. tworzenia oprogramowania i menedżerami produktów jest równie ważna dla ustalania priorytetów elementów backlogu i rozwijania bazy kodu. 

2. Włącz testy do swojego przepływu pracy

Upewnij się, że testy zostały włączone do cyklu programowania początkowego w celu identyfikacji i rozwiązywania problemów na wczesnym etapie. Zacznij od ustalenia jasnej definicji ukończenia i unikaj odkładania testów na później.

Zgodnie z tą definicją „ukończony” produkt nie tylko ma gotowe funkcje, ale także jest przetestowany i gotowy do wydania. Oznacza to dodanie odrębnego zadania testowania do pierwotnej historyjki użytkownika. Jeśli testy nie zostaną ukończone w ramach pierwotnej historyjki lub poprawki błędu, taka historyjka lub poprawka nie jest ukończona.

Zbyt łatwo można odraczać takie zadania, co jedynie sprzyja pojawianiu się długu technicznego.

3. Automatyzacja usuwania błędów

Gdy ktoś wykryje błąd w oprogramowaniu, warto poświęcić czas, aby dodać test automatyczny, który pozwoli go ujawnić. Po usunięciu błędu ponownie uruchom test, aby się upewnić, że zakończy się on powodzeniem.

Jest to podstawa programowania sterowanego testami — tradycyjnej metodyki utrzymywania jakości w programowaniu Agile.

Niełatwo jest zmienić filozofię zespołu (oraz jego interesariuszy) w zakresie zarządzania długiem technicznym. Czasami pierwszeństwo ma skrócenie czasu prac programistycznych, aby wprowadzić produkt na rynek szybciej. Mając to na uwadze, przyjrzyjmy się krótko kilku czynnościom do wykonania w celu ograniczenia długu technicznego:

• Poinformuj product ownera o rzeczywistych kosztach długu technicznego: zapewnij dokładność wartości punktów przyszłych historyjek wymagających usunięcia istniejącego długu technicznego.

• Nadaj architekturze charakter modułowy: zajmij zdecydowane stanowisko w sprawie długu technicznego w nowych komponentach lub bibliotekach w aplikacji. Gdy elastyczność będzie widoczna w tych nowych komponentach, zespoły będą oczywiście chciały rozszerzyć te praktyki na inne części kodu.

• Utwórz zautomatyzowane testy: nic nie zapobiega błędom lepiej niż zautomatyzowane testy i ciągła integracja. W przypadku wykrycia nowego błędu opracuj nowy test, aby go odtworzyć, a następnie naprawić. Jeśli podobny błąd jeszcze się kiedyś pojawi, zautomatyzowane testy wychwycą go, zanim zrobi to klient.

Pojęcie długu technicznego można zilustrować kilkoma prostymi przykładami:

Weźmy zespół, który zamiast korzystać z systemu konfiguracyjnego, stosował stałe połączenia z bazą danych. Początkowo pozwala to zaoszczędzić czas, ale powoduje problemy podczas wdrażania w różnych środowiskach. 

Innym przykładem jest pominięcie prawidłowego postępowania w przypadku błędów, aby dotrzymać terminu, co sprawia, że system jest podatny na awarie wymagające późniejszego wprowadzenia awaryjnych poprawek. 

Dobre zarządzanie długiem może polegać na świadomym wyborze prostszego algorytmu, który jest łatwiejszy do zrozumienia i utrzymania, nawet jeśli jest nieco mniej wydajny. Kiepskie zarządzanie to wielokrotne doraźne łatanie problemu zamiast zajęcia się jego podstawową przyczyną. 

Obok zwykłej pracy nad funkcjami zespoły mogą używać Jiry do śledzenia, ustalania priorytetów i usuwania długu technicznego. Utwórz określone typy zgłoszeń dla elementów długu technicznego i uwzględnij je w swoim zwykłym procesie planowania sprintu.

Używaj funkcji planowania zasobów do przydzielania czasu na redukcję zadłużenia i wykorzystuj narzędzia do zarządzania zasobami do śledzenia procesów. Skonfiguruj przepływy pracy tak, aby dług techniczny był widoczny dla wszystkich interesariuszy, a nie tylko dla programistów.

Za pomocą Rovo Dev zespoły mogą posunąć się jeszcze dalej, używając sztucznej inteligencji do automatyzacji rutynowych zadań kodowania i przyspieszenia refaktoryzacji. Rovo Dev może tworzyć wieloetapowe przepływy pracy, odkrywać wiedzę oraz planować, generować i przeglądać kod w odpowiedniej skali. Ograniczając ilość ręcznej pracy przy identyfikowaniu, planowaniu i usuwaniu długu technicznego, Rovo Dev pomaga zespołom szybciej dostarczać oprogramowanie wyższej jakości.

Ta przejrzystość ułatwia menedżerom produktów zrozumienie rzeczywistego kosztu skumulowanego długu i uzasadnienie czasu przeznaczanego na prace konserwacyjne.

Wypróbuj Jira

Czym jest dług techniczny w Scrum?

W metodologii Scrum dług techniczny oznacza pracę, którą należy wykonać, aby utrzymać jakość kodu i sprawność systemu. Zespoły pracujące według metodyki Scrum radzą sobie z tym problemem, uwzględniając długi techniczne w backlogach sprintów i traktując je z takim samym priorytetem jak inne zadania. 

Jak można zapobiegać powstawaniu długu technicznego?

Zapobieganie długowi technicznemu zaczyna się od odpowiedniego planowania, regularnych przeglądów przez innych specjalistów i automatycznych testów. Budowanie kultury, która przedkłada długoterminową jakość kodu nad krótkoterminową szybkość, pomaga zespołom podejmować lepsze decyzje architektoniczne od samego początku. 

Czy dług techniczny jest zawsze zły?

Niekoniecznie. Strategiczny dług techniczny może być akceptowalny, gdy zespoły świadomie wybierają szybkość zamiast perfekcji z ważnych powodów biznesowych. Kluczem jest świadome zarządzanie nim, a nie pozwalanie, aby narastał przypadkowo.

Kto spłaca dług techniczny?

Każdy płaci za dług techniczny. Zespoły inżynierów poświęcają więcej czasu na konserwację, zespoły produktowe wolniej dostarczają nowe funkcje, a klienci napotykają więcej błędów. Zarówno inżynierowie, jak i osoby odpowiedzialne za produkt ponoszą wspólną odpowiedzialność za skuteczne zarządzanie długiem. 

Jak mierzyć dług techniczny?

Korzystaj z narzędzi takich jak Jira, aby śledzić dług, mierzyć czas rozstrzygnięcia i monitorować trendy. Regularne audyty kodu, wskaźniki złożoności i ankiety dla programistów mogą pomóc w oszacowaniu zakresu i wpływu nagromadzonego długu.