Objaśnienie długu technicznego: strategie Agile zapewniające cykl rozwoju bez zadłużenia

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

Każde wydanie rozpoczyna się od fazy opracowania nowych funkcji, a (najlepiej) także rozwiązania zgłoszeń, jakie pozostały po ostatnim wydaniu (jednak spójrzmy prawdzie w oczy, to rzadko się udaje). Cykl tworzenia oprogramowania osiąga fazę wersji „alfa”, gdy poszczególne funkcje zostają wdrożone i są gotowe do przetestowania. Z wersją beta mamy do czynienia 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. Jest to klasyczny przypadek gry w „walnij kreta”: naprawiasz jeden błąd, a pojawiają się dwa kolejne. Wreszcie wydanie osiąga kamień milowy wersji golden master, w której nie ma żadnych otwartych błędów. „Zerową liczbę otwartych błędów” uzyskuje się zazwyczaj przez naprawienie pewnych znanych błędów i przekierowanie pozostałych (większości?) do kolejnego wydania.

Ciągłe przekładanie na później błędów, które trzeba naprawić, nie jest bezpiecznym sposobem tworzenia oprogramowania. Im więdzej błędów się nagromadzi, tym trudniej się z nimi uporać, co skutkuje błędną spiralą długu technicznego. Na domiar złego trudno dotrzymać harmonogramów, ponieważ pisanie kodu w ramach poprawiania błędów spowalnia programistów. Tymczasem nienaprawione usterki doprowadzają klientów do szału. I z pewnością niektórzy z nich Cię opuszczą.

Musi być lepszy sposób.

Metodyka Agile wzbogaca iteracyjne podejście do programowania o aspekt jakościowy, dzięki czemu zespół może utrzymać stały poziom jakości między kolejnymi wydaniami. Jeśli funkcja nie spełnia wymagań, nie jest dostarczana. Trudno w to uwierzyć? Jest na to sposób: określenie lub zmiana definicji ukończenia.

Dla tradycyjnych zespołów stan ukończenia oznacza, że produkt jest dość dobry, aby przystąpić do QA. Problem z tą definicją jest taki, że błędy wkradają się już na wczesnych etapach cyklu wydawania, a później wcale nie przestają. W rezultacie zanim zespół QA zabierze się do pracy, produkt będzie pokryty kolejnymi warstwami usterek. Z kolei zespoły Agile definiują ukończenie, jako gotowość do wydania, co oznacza, że programiści nie przechodzą do kolejnej historyjki lub funkcji, dopóki bieżący element nie znajdzie się faktycznie w rękach klientów. Aby przyspieszyć ten proces, wykorzystują oni techniki, takie jak przepływy pracy obejmujące tworzenie gałęzi funkcji, automatyczne testowanie oraz ciągła integracja, w trakcie całego cyklu programistycznego.

Główna gałąź bazy kodu powinna być zawsze gotowa do dostarczenia. To priorytet numer jeden. Życie nowych funkcji rozpoczyna się zatem w gałęzi zadania zawierającej kod samej funkcji, a także zautomatyzowane testy. Gdy funkcja jest gotowa, a zautomatyzowane testy zostaną ukończone pomyślnie, gałąź można scalić z gałęzią główną. Pasek jakości jest zawsze stały (i utrzymuje się na wysokim poziomie), dzięki czemu dług technologiczny pozostaje pod kontrolą.

Dla wielu organizacji jest to ogromna zmiana kulturowa. Metodyka Agile przesuwa ośrodek skupienia z harmonogramów na sprawdzone oprogramowanie wysokiej jakości. Product owner ma możliwość skoncentrowania wysiłków zespołu w pierwszej kolejności na najważniejszych pracach, ograniczając zakres wydania, a nie przyzwalając na obniżenie jakości.

Nie można zapominać, że im dłużej istnieją błędy, tym trudniej je naprawić.

Jeśli pracujesz ze starszym kodem, istnieje prawdopodobieństwo, że trafił do Ciebie odziedziczony dług techniczny. Poniższe tematy pomogą Ci uporać się z istniejącym długiem technicznym i umożliwią Twojemu zespołowi skoncentrowanie się na ciekawszych zagadnieniach, takich jak opracowywanie nowych funkcji.

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:

Obejmuje on wszelkie obejścia techniczne zastosowane w celu dotrzymania terminów.

Po stronie zespołu programistycznego może pojawić się pokusa opisywania prac związanych z architekturą jako długu technicznego. Mogą, ale nie muszą one stanowić długu technicznego — to zależy od charakteru zmiany (np. zastąpienia obejścia „rzeczywistym” rozwiązaniem w odróżnieniu od 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 opinii tej drugiej strony, 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 ma krytyczne znaczenie dla ustalania priorytetów elementów backlogu i rozwijania bazy kodu.

Należy zwalczać pokusę rozszerzenia definicji ukończenia przez dodawanie odrębnego zadania testowania do pierwotnej historyjki użytkownika. Zbyt łatwo odraczać takie zadania, co jedynie sprzyja pojawianiu się długu technicznego. Jeśli testy nie zostaną ukończone w ramach pierwotnej historyjki lub poprawki błędu, taka historyjka lub poprawka błędu nie jest ukończona. Zadbaj o ścisłe przestrzeganie definicji ukończenia w programie i uwzględnienie w niej kompletnego automatycznego testowania. Nic nie ogranicza zwinności zespołu bardziej niż ręczne testowanie i baza kodu obfitująca w błędy.

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ę powodzeniem. Jest to podstawa programowania sterowanego testami — tradycyjnej metodyki utrzymywania jakości w programowaniu Agile.

Niełatwo jest zmienić filozofię zespołu (oraz interesariuszy powiązanych z zespołem) w zakresie zarządzania długiem technicznym. Czasami potrzeby biznesowe wymagają skrócenia czasu prac programistycznych, aby wprowadzić produkt na rynek szybciej. Mając to na uwadze, przyjrzyjmy się krótko kilku czynnościom, które można wykonać w celu ograniczenia długu technicznego:

• Informuj product ownera o rzeczywistych kosztach długu technicznego. Zapewnij dokładność wartości punktów historyjek w przyszłych historyjkach wymagających rozwiązania istniejącego długu technicznego.
• Nadaj architekturze charakter modułowy i zajmij zdecydowane stanowisko w sprawie długu technicznego w nowych komponentach lub bibliotekach w aplikacji. Gdy zespół oraz firma dostrzegą zwinność w tych nowych komponentach, w naturalny sposób będą chcieli rozszerzyć te praktyki na inne części kodu.
• Twórz zautomatyzowane testy! Nic nie zapobiega błędom lepiej niż testy zautomatyzowane 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 kiedyś wypłynie, zautomatyzowane testy wychwycą go, zanim zrobi to klient.

Pamiętaj, że dług techniczny jest elementem rzeczywistości każdego zespołu programistycznego. Nikt nie jest w stanie całkowicie go uniknąć. Najważniejsze, aby nie wymknął się on spod kontroli.