Autor

Monika Perendyk

Trener, wykładowca, praktyk

Dług techniczny, czym jest i dlaczego Analityk ma na niego wpływ

22 marca 2021 • 20 minut

Jeśli uczestniczysz w procesie wytwarzania oprogramowania na pewno choć raz słyszałeś pojęcie: “dług techniczny”.

Jeśli pełnisz rolę Analityka w projekcie IT zapewne nie zwracałeś na niego uwagi mimo, że jest nieodłącznym elementem każdego projektu. Być może to przeoczenie wynika z tego, że dług techniczny to przecież “to wina programistów”. Czy na pewno? Czy dług techniczny pojawia się wtedy, kiedy programiści idą na skróty?

A może jako Analityk masz wpływ na to, kiedy dług się pojawi w projekcie?

1. Czym jest dług techniczny?

Termin: “Dług techniczny” nazywany czasem “długiem technologicznym” został wprowadzony prawie 30 lat temu. Autorem tego terminu w 1992 roku był Ward Cunningham- pionier w dziedzinie wzorców projektowych, ale również współtwórca “Agile Manifesto”.

W. Cunningham zwrócił uwagę na to, jak bardzo ważne jest zachowanie równowagi pomiędzy: szybkim tworzeniem oprogramowania, aby tylko działało, a późniejszymi pracami związanymi z ulepszaniem kodu, bądź jego poprawianiem we fragmentach, które zostały pominięte, bądź ucierpiały w wyniku tego pośpiechu.

To odwieczny problem, z którym mierzymy się w każdym projekcie: rozwiązanie ma działać czy kod ma być ładny? Idealnym rozwiązaniem byłoby zachowanie tych dwóch elementów na najwyższym poziomie. Pytanie tylko czy w dobie szybkiego dostarczania produktów na rynek da się uzyskać taki stan?

W pośpiechu programiści nie skupiają się na architekturze czy wzorcach projektowych. Miałoby to miejsce, gdyby nie odczuwali presji ze strony kierownictwa, które bardziej skupione jest na “dowożeniu” działających fragmentów oprogramowania nie zwracając uwagi na to, z jak dużymi kosztami przyjdzie nam się zmierzyć w momencie kiedy przejdziemy do fazy utrzymania dostarczonego oprogramowania.

Definicja długu technicznego:


Technical Debt includes those internal tasks you choose not to do now, but it runs a risk of causing future problems if not done.

W.Cunningham, 1992

Ward Cunningham chcąc wyjaśnić dług techniczny użył metafory porównując dług techniczny do rozwoju firmy. Stwierdził bowiem, że dynamicznie rozwijająca się firma nie posiadając własnych środków finansowych musi zaciągnąć kredyt, aby dalej finansować swój rozwój.

Z jednej strony cele wyznaczone przez firmę zostały osiągnięte w krótszym czasie niż miałoby to miejsce w sytuacji kiedy firma czekałaby do momentu uzbierania funduszy na dalszy rozwój. Z drugiej strony realizując strategię firmy musimy uwzględnić również koszty związane nie tylko ze spłacaniem powstałego długu, ale również kosztem odsetek jakie są z nim związane. Im krótszy czas spłacania tym koszt odsetek jest mniejszy.

Podobnie jest z długiem technicznym w oprogramowaniu. Decydując się na szybsze osiągnięcie celu, z pominięciem dobrych praktyk oprogramowania musimy mieć świadomość, że im dłużej zwlekamy z poprawieniem jakości rozwiązania, uzupełnienia luk, tym koszt będzie większy. Będzie wymagał nie tylko dodatkowej pracy, ale czasem zatrudnienia dodatkowych osób, aby zagwarantować odpowiednią jakość rozwiązania.
Brak zajęcia się długiem technicznym tak szybko jak to tylko jest możliwe powoduje, że możemy zwiększać liczbę długów istniejących w naszej organizacji. Będzie to wpływać nie tylko na wydajność rozwiązania, ale przede wszystkim może doprowadzić do momentu, kiedy kolejna aktualizacja oprogramowania będzie wpływać destrukcyjnie na całe oprogramowanie. W najgorszym przypadku wprowadzenie modyfikacji do rozwiązania nie będzie w ogóle możliwe.

2. Kategoryzacja długu technicznego

Identyfikacja długu technicznego jest podstawową czynnością, którą musimy wykonać, aby móc nim zarządzać.
W 2009 roku Martin Fowler rozwinął koncepcję 2 rodzajów długu technicznego: celowe i niezamierzone tworząc tzw. Kwadrat zadłużenia technicznego.
Dzieli on dług techniczny na 4 kategorie ze względu na zamiar: “celowy czy nieumyślny/niezamierzony”, ale co ważniejsze kontekst: “rozsądny czy lekkomyślny”.

kwadrat długu technicznego M.Folwer (opracowanie własne)

I ćwiartka – lekkomyślny i celowy dług

Zespół może posiadać wiedzę, umiejętności a mimo to świadomie decyduje się na rozwiązanie “szybkie” bez zachowania czystości kodu przyjmując postawę: “zależy nam bardziej na realizacji niż na jakości”. Co ważne taki rodzaj długu powstaje w momencie, kiedy zespół ma poprawnie zdefiniowane wymagania oraz posiada wiedzę w jaki sposób zrealizować funkcjonalność. Najczęściej z taką postawą możemy spotkać się w projektach długoterminowych, gdzie czas “spłaty długu” nie jest tak dobrze widoczna.

W sytuacji, kiedy czas nie jest stymulatorem do korzystania z drogi na skróty warto zastanowić się i zaplanować działania niedopuszczające do powstawania długu technicznego. W przeciwnym wypadku w zespole utrwalamy postawy prokrastynacji, czyli opóźniania, odkładania czegoś na później, a tym samym w działania zespołu będą wbudowane mechanizmy tworzenia długu technicznego, które mogą doprowadzić do sytuacji skumulowania zaciągniętych zobowiązań paraliżujących działanie oprogramowania.

Przeciwdziałaniem powstawania takich postaw jest np. zdefiniowanie w ramach “Definition of Ready” elementów, jakie są związane z ryzykiem powstawania długu technicznego, np. “Czysty kod”

II ćwiartka – ostrożny i celowy dług

Ze wszystkich rodzajów długu można powiedzieć, że jest to sytuacja najbardziej pożądana. Oznacza to, że zespół projektowy ze względu na zbliżający się termin oddania produktu do Klienta, bądź braku konieczności tworzenia lepszej jakości rozwiązania świadomie decyduje się na ograniczeniu jakości rozwiązania. Wyróżniającym elementem tego rodzaju długu jest to, że zespół identyfikuje dług i jego konsekwencje oraz zaczyna zarządzanie powstałym długiem.
Z takimi sytuacjami mamy do czynienia, kiedy nie musimy walczyć o idealne rozwiązanie, bo nie niesie w sobie wartości biznesowej.

III ćwiartka – lekkomyślny i przypadkowy dług

Powstaje w sytuacji, kiedy zespół nie posiada wiedzy z zakresu dobrych praktyk projektowania. Zespół może nawet nie ma świadomości, że robi źle. Co więcej nie wie, że za chwilę konsekwencje będą nie tylko kosztowne, ale również dotkliwe dla całego tworzonego rozwiązania.
Inną przyczyną może być to, że zespół nie znajduje sposobu, aby zlikwidować istniejący dług. Jest to sytuacja, kiedy doszliśmy w swoich działaniach do tzw. “ściany”. Koszt likwidacji długu przewyższają nasze możliwości finansowe, bądź czasowe i rozwiązanie takiego impasu nam się nie opłaca. Dlatego doprowadzenie do takiej sytuacji jest nieodpowiedzialne. Wpływa bowiem nie tylko na sprzedaż, bądź brak możliwości rozwoju oprogramowania, ale przede wszystkim mocno nadwyręża reputację firmy tworzącej oprogramowanie.

Aby zapobiec takiej sytuacji, zespół przed przystąpieniem do prac projektowych powinien zastanowić się czy istnieje ryzyko powstania długu technicznego. Dodatkowo należy zidentyfikować z jakim rodzajem długu mamy do czynienia oraz próbować go zminimalizować. W przypadku braku umiejętności będzie to zatrudnienie osoby o odpowiednich umiejętnościach oraz transfer wiedzy od specjalisty do zespołu. Dzięki temu zespół idzie w kierunku samodoskonalenia się.
Jest to również odpowiedni moment, aby zastanowić się czy jesteśmy gotowi i świadomi konsekwencji zwiększania długu technicznego, który w końcu trzeba zacząć spłacać. A może jest to już ten moment, kiedy musimy rozpocząć spłacanie wcześniej zaciągniętego długu technicznego.

IV ćwiartka – ostrożny i przypadkowy dług

Taka sytuacja ma miejsce w przypadku, kiedy zespół posiada umiejętności oraz wiedzę, dba o jakość, stosuje wzorce projektowe, lecz nadal się uczy. Po zakończeniu projektu zespół zdaje sobie sprawę, że daną funkcjonalność mógł zaprojektować inaczej, jednocześnie tworząc lepszą jakość rozwiązania.

W takiej sytuacji szczególną rolę odgrywa etap retrospekcji projektowej. Dzięki retrospekcji projektowej wypracowujemy dobre praktyki pracy szczególnie na początku pracy nad projektem. Uczymy się minimalizować ryzyko powstania długu technicznego.

3. Rola Analityka w powstawaniu długu technicznego

Pytając o “dług techniczny” najczęściej słyszymy: “Bezpośrednią przyczyną jest brak testów i pójście na skróty jeśli chodzi o implementację kodu oraz brak refaktoryzacji”, mówiąc krótko – wina programistów. Owszem dług techniczny jest widoczny od razu po zaistnieniu wyżej wymienionych elementów, lecz jego zalążki oraz rozwój rozpoczyna się na wcześniejszych etapach.

Kluczem do sukcesu w projekcie jest dobrze wykonana analiza potrzeb Klienta. A co za tym idzie poprawnie zidentyfikowane wymagania systemowe, które są odpowiedzią na potrzeby Klienta.

Niepoprawnie wykonana analiza potrzeb oraz identyfikacja wymagań systemowych wpływa na pojawienie się i dalszy rozwój długu technicznego w projekcie. Brak skupienia się na wymaganiach biznesowych, na wyzwaniach i potrzebach Klienta, które za nim stoją powoduje, że nasza propozycja rozwiązania nie zawsze będzie wspierała rozwiązanie problemu. W najlepszym przypadku będziemy kilkukrotnie wracać do tego samego problemu biznesowego, ponieważ dotychczasowe rozwiązanie jest niewystarczające ze względu na dynamiczny rozwój organizacji.

W jaki sposób Analityk wpływa na pojawienie się długu technicznego?

Wystarczy, że podczas wymagań Analityk skupi się głównie na wymaganiach funkcjonalnych, tym samym pomijając wymagania pozafunkcjonalne. Może się zdarzyć również sytuacja, kiedy doświadczony Analityk traci czujność w pracy z wymaganiami, ponieważ rozmawia z Klientem o potrzebie, dla której rozwiązanie już istnieje i wiemy, że będziemy go oferować Klientowi jako część rozwiązania. Skoro rozwiązanie istnieje, zakładamy, błędnie, że zostało ono wystarczająco przeanalizowane.

Najprostszym przykładem jest zadanie: “Dodanie formatki umożliwiającej Użytkownikowi uzupełnienie danych firmy”.

W takiej sytuacji skupiamy się głównie nad wyglądem formatki. Pytanie czy zastanowiliśmy się nad wymaganiami pozafunkcjonalnymi dla niej, np. :

“W jaki sposób zabezpieczymy formatkę przed nieuprawnionym dostępem?”

“Gdzie przechowywać informacje o wprowadzonych zmianach?”

“W jaki sposób zabezpieczymy formatkę przed próbą modyfikacji danych, które nie powinny podlegać modyfikacji?”

“Skąd będziemy wiedzieć, że została dokonana zmiana danych?”

“W jaki sposób system ma zareagować, jeśli nie uda się wprowadzić zmiany? Powinien wyświetlić ostatnio zapisane dane, czy wyczyścić formatkę?”

Pytań jest o wiele więcej.

Jeśli rozwiązanie istnieje, tym bardziej musisz je przeanalizować pod kątem wymagań pozafunkcjonalnych. Dzięki temu upewnisz się, że rozwiązanie, które dostarczysz Klientowi będzie wysokiej jakości. Ponowne użycie rozwiązania dla innego Klienta nie jest złe, ale przed jego użyciem musisz sprawdzić, czy to co było oczekiwaniem Klienta A również sprawdzi się u Klienta B. Dodatkowo zastanów się czy nie pojawiły się nowe elementy związane np. zabezpieczeniem rozwiązania czy jego wydajnością, które z punktu widzenia projektu są nowymi wymaganiami.
W przypadku analizy nowego rozwiązania pominięcie wymagań pozafunkcjonalnych, bądź ich bagatelizowanie powoduje, że szacowanie prac programistycznych i testerskich będzie opierało się na odpowiednio: oprogramowaniu i przetestowaniu jedynie formatki i pól, które opisaliśmy w naszym przykładowym wymaganiu funkcjonalnym.

Nasza analiza stanie się niekompletna, czas na rozmowy z Klientem celem zebrania odpowiedzi na tak powstałe pytania już dawno minął, a co za tym idzie pojawia się silna presja czasowa w zespole projektowym, aby dowieźć rozwiązanie, które jakościowo nie będzie dobre. Zaczynamy iść na skróty tworząc tym samym zalążek długu technicznego.

W pracy nad rozwojem dużych systemów często mamy do czynienia z pojawiającym się długiem technicznym, który spowodowany jest brakiem informacji o już istniejącym rozwiązaniu. Przez co powstają w oprogramowaniu bliźniaczo podobne rozwiązania, zamiast rozwijania już istniejącego rozwiązania o dodatkowe przypadki.
Tutaj “winę” nie można przypisać tylko Analitykowi, lecz całemu zespołowi produktowemu.

Przyczyn jest kilka, z których najczęściej wyłania się brak aktualizacji dokumentacji, brak czasu na przekazywanie informacji oraz “trzymanie wiedzy u jednego człowieka”, który był przy rozwoju aplikacji, zna ją doskonale, ale ze względu na uczestniczenie w innych projektach nie ma czasu, aby zaktualizować dokumentację projektową a tym bardziej na edukowanie innych członków zespołu.

Powyższy objaw wynika z braku zarządzania wewnątrz organizacji. Jeśli takie sytuacje spotykasz w swojej organizacji, oznacza to, że kuleje mocno zarządzanie projektami oraz wytwarzanie produktów.

4. Jak rozpoznać symptomy zbliżającego się długu technicznego?

Wdrożenie leczenia w momencie pojawienia się pierwszych symptomów zbliżającej się choroby skutkuje szybszym wyzdrowieniem. Co do tego stwierdzenia, szczególnie w dobie obecnych czasów pandemii chyba nie muszę nikogo przekonywać.
Tak samo powinniśmy postępować z długiem technicznym. Czyli reagować w momencie zauważenia pierwszych symptomów, które mogą skutkować pojawieniem się długu technicznego.
Symptomy możemy podzielić ze względu na architekturę rozwiązania, umiejętności zespołu wytwórczego czy te wynikające z samego procesu.

Symptomy wynikające z architektury rozwiązania

  1. Brak wykorzystania standardowego podejścia podczas integracji systemów
  2. Brak spójnego modelu danych
  3. Oprogramowanie jest nieelastyczne i dodatkowo posiada dużo dopasowanych elementów “pod Klienta” ze złożonymi regułami biznesowymi trudnymi do modyfikacji
  4. Brak motywacji do zajmowania się redukcją długu technicznego
  5. Brak spójności w architekturze rozwiązania czy nawet stosowanych wzorcach projektowych
  6. Duża liczba nieużywanego kodu
  7. Nieczytelny kod
  8. Zduplikowany kod

Symptomy wynikające z umiejętności zespołu wytwórczego

  1. Braki w wiedzy w zespole wytwórczym szczególnie na stanowiskach związanych z analizą i programowaniem rozwiązań
  2. Niechęć do spotkań wśród członków zespołu, co powoduje pojawienie się luki komunikacyjnej
  3. Zewnętrzne ograniczenia dostępności członków zespołu ( zespoły są współdzielone na wiele projektów, przez co opóźnienie w jednym projekcie powoduje brak dostarczenia rozwiązania w zadeklarowanym czasie w drugim projekcie, do którego został przypisany zespół).

Symptomy wynikające z procesu

  1. Brak procesu weryfikacji jakości tworzonego kodu,
  2. Testy manualne przy złożonych funkcjonalnościach
  3. Brak testów, bądź ich niewystarczająca liczba
  4. Słabo rozwinięte procesy rozwoju i utrzymania (brak dedykowanego działu R&D)
  5. Brak narzędzi dedykowanych do zarządzania wymaganiami
  6. Brak narzędzi wspierających odzyskiwanie utraconych danych
  7. Brak narzędzi do mierzenia czasu, jaki potrzebujemy na obsługę błędu:(identyfikacja błędu, analiza błędu, implementacja poprawki, testy poprawki, wdrożenie poprawki do nowej wersji)
  8. Słaba priorytetyzacja projektów względem wartości biznesowej (realizujemy wiele projektów na raz, przez co oszczędzamy na jakości analizy oraz testach rozwiązania. Dodatkowo presja czasu, jaka się w takim przypadku pojawia powoduje, że częściej sięgniemy po najprostsze rozwiązania programistyczne bez przeanalizowania najlepszego rozwiązania z punktu widzenia dostarczania wartości dla wielu klientów).
  9. Tworzenie bardzo złożonych i skomplikowanych produktów bez standaryzacji operacji i procesów (duplikowanie rozwiązań, bądź skupianie się na dostosowaniu “pod jednego Klienta” aplikacji oferowanej dla wielu odbiorców. Poprzez złożoność rozumiemy w tym przypadku sytuację, kiedy dodawane są nadmiarowe funkcjonalności, które można uprościć w działaniu).
  10. Niedoszacowywane projekty (chodzi o sytuację, kiedy już na początku wyceny wiemy, że projekt jest niedoszacowany przez co organizacja narzuca presję czasu na członków zespołu wytwórczego na dostarczenie produktu. W takiej sytuacji Analityk zaczyna popełniać błędy podczas analizy, ponieważ “nie ma czasu”, aby swoją pracę wykonać porządnie i zgodnie z dobrymi praktykami. Programista otrzymując słabej jakości produkt Analityka, czyli specyfikację, zaczyna szukać najprostszych rozwiązań, ponieważ “nie ma czasu”. )

Jeśli jakikolwiek z powyższych symptomów pojawia się w Twoich projektach, albo co gorsza widzisz je w każdym projekcie, w którym uczestniczysz, to oznacza, że dług techniczny już rozpoczął swoją ekspansję w Twojej organizacji.

To, że zespół nie zajmuje się jeszcze redukcją długu technicznego prawdopodobnie wynika z tego, że “nie ma na to czasu” w organizacji. Rozpoczynamy błędne koło powiększając już zaciągnięty dług techniczny. Prawdopodobnie zespół zajmie się rozwiązywaniem tej kwestii w momencie, kiedy dojdzie do tzw. “ściany”, czyli sytuacji, kiedy aby dodać najprostszą funkcjonalność będzie trzeba przebudować spory kawałek oprogramowania. Tym samym czas dostarczenia małej funkcjonalności dla Klienta zauważalnie się wydłuży, podniosą się koszty jej dodania, jednocześnie nie gwarantując lepszej jakości całego produktu.

5. Odczuwalne skutki długu technicznego

Pojawienie się długu technicznego, który nie jest zamierzony skutkuje stratą finansową firmy, która wytwarza oprogramowanie.
Wymiar finansowy to nie jedyny skutek, a na pewno nie jest najważniejszym. Dużo większym wyzwaniem jest stan naszego oprogramowania, który uzyskaliśmy w wyniku naszego długu technicznego. Liczne awarie oprogramowania, długi czas diagnozowania przyczyny takiej awarii, błędy, spadek wydajności czy nawet obniżenie poziomu bezpieczeństwa mogą skończyć się decyzją o zamknięciu rozwoju danego oprogramowania, a wręcz wycofania go z rynku.
Dodatkowo spada sama wydajność zespołu programistycznego, który musi się mierzyć z rosnącymi ograniczeniami oprogramowania, aby utrzymać jego względną stabilizację.
Trend ten jest mocno zauważalny, jeśli zaczniemy porównywać czas wdrażania funkcjonalności o podobnej wielkości przez dany zespół. Wdrożenie 5 funkcjonalności przez zespół na początku pracy z oprogramowaniem, gdzie długu technicznego jeszcze nie było, mogło zająć nam 1 iterację, podczas gdy próba wdrożenia 2 podobnych, pod względem wielkości, funkcjonalności rozciąga się na 2 iteracje. Wynika to z tego, że przez większość czasu zespół będzie walczył z rosnącym długiem technicznym, próbując “łatać” system.
Dodatkowym utrudnieniem jest to, że nie do końca jesteśmy w stanie przewidzieć zachowania systemu po dodaniu nowej funkcjonalności. Nagle czas reakcji aplikacji wydłuża się (wymagania wydajności), zespół poświęca dużo czasu, aby zrozumieć jak działa aplikacja, jak ją usprawnić (wymagania przenośności), dodatkowo dodanie nawet najmniejszej funkcjonalności powoduje destabilizację części aplikacji (wymagania niezawodności).
Jeśli z takimi sytuacjami spotykasz się w swoim projekcie to wiedz, że to ostatni moment, aby rozpocząć pracę nad zarządzaniem długiem technicznym.

6. Zarządzanie długiem technicznym

Dług techniczny jest nieodłącznym elementem tworzenia oprogramowania. Dlatego należy nim zarządzać podobnie jak firmy zarządzają swoimi finansami. Są w stanie świadomie inwestować, czasem decydują się na ryzykowne decyzje, ale wcześniej wykonują analizę ryzyka oraz możliwych konsekwencji.

Celem zarządzania długiem technicznym jest przede wszystkim:

  • zapobieganie sytuacji kumulowania długu technicznego ( identyfikacja i uświadomienie rodzaju długu jaki jest w organizacji oraz wdrożenie odpowiednich procedur naprawy),
  • spłacanie długu poprzez ustalenie priorytetów ( wyznaczenie standardów tworzenia kodu oraz pracy nad projektem oraz systematyczna refaktoryzacja).

Zarządzanie długiem technicznym składa się z dwóch etapów:
Etap 1: projektowanie procesu radzenia sobie z długiem technicznym
Etap 2: tworzenie i wykorzystanie wskaźników mierzenia długu technicznego.

Redukcja długu technicznego może być wpisana w stałą część pracy zespołu wytwórczego przy danym projekcie i być “wkalkulowana” w czas projektu.
Aby nie zaburzać pracy zespołu nad pracą projektową można wyznaczyć, bądź powołać dedykowane osoby do prac nad długiem technicznym. W przypadku wyznaczania członka, bądź członków zespołu do tego zadania pamiętaj, aby te osoby się zmieniały. Pozwoli to uniknąć sytuacji, kiedy programista próbując zredukować dług techniczny będzie go pogłębiał. Wynika to z kwestii zmęczenia pracą w dłuższym czasie nad tym samym tematem. Pracując rotacyjnie nad danym aspektem zyskujemy świeże spojrzenie a zatem jesteśmy w stanie wypracować najlepsze z możliwych rozwiązań.

Innym z przykładów jest wyznaczenie określonego dnia w tygodniu, bądź dni w tygodniu, kiedy poświęcamy swój czas na rozwiązanie problemów wynikających z długu technicznego.

Od czego zacząć zarządzanie długiem technicznym? Od jego zmierzenia. Nic tak nie działa na wyobraźnie jak liczby. Dlatego warto skorzystać ze wskaźnika zadłużenia technicznego. Jest to stosunek kosztu naprawy oprogramowania do kosztu jego opracowania/rozwoju.

Wskaźnik zadłużenia technicznego=(koszt naprawy/koszt rozwoju)x100%.

Jak odczytać wskaźnik?

Jeśli koszt naprawy i koszt rozwoju będziesz przyjmował w jednostce czasu, to wskaźnik zadłużenia technicznego pokaże ile zajmie zespołowi przywrócenie kodu do pożądanego stanu jakości.
Dlatego wiele zespołów dąży do uzyskania jak najmniejszych wartości wskaźnika, czyli osiągnięcia jak najkrótszego czasu pracy nad redukcją długu technicznego w swojej aplikacji.

Warto pamiętać, że czas potrzebny na naprawienie problemów w zaimplementowanej funkcji jest wprost proporcjonalny do złożoności tej funkcji.
Koszt rozwoju to nic innego jak koszt napisania linii kodu oprogramowania.

Przykład:

Czas potrzebny na napisanie 1 linii kodu wynosi 12 minut, co stanowi 0,2 godziny.
Jeśli nasz kod wynosi 58 linii to koszt rozwoju wynosi:
(0,2 godziny/linia) x 58 linii = 11,6 godzin.

Przykład obliczania wskaźnika zadłużenia technicznego:

Czas naprawy został obliczony na 58 dni co daje nam 1392 godziny
Linii kodu -36 200
Koszt napisania 1 linii kodu przyjmijmy jak w poprzednim przykładzie, czyli 12 minut, czyli 0,2 godziny

Koszt rozwoju: (0,2 h/linię)*36 200 linii = 7 240 h

Podstawiając do wzoru na wskaźnik zadłużenia technicznego:
Wskaźnik zadłużenia technicznego = (koszt naprawy/koszt rozwoju)x100%.

Otrzymujemy:

Wskaźnik zadłużenia technicznego = (1392 h/7 240 h) *100%= 19,2 %

Możesz skorzystać też z programu, który wyliczy koszty Twojego długu technicznego: https://www.stepsize.com/tech-debt-calculator

Programem wartym uwagi jest Sonarqube, który sprawdza czystość kodu pisanego przez programistów: https://www.sonarqube.org/

SQALE jako metoda zarządzania długiem technicznym

W 2012 roku została opublikowana metoda SQALE (Software Quality Assesment based on Lifecycle Expectations), która od tamtej pory stała się standardową metodą zarządzania długiem technicznym. Jest to metoda wspierająca ocenę kodu źródłowego tworzonego oprogramowania. Jest to metoda niezależna od języka tworzonego oprogramowania i jest udostępniana na zasadzie licencji Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.

Model zbudowany jest na 3 hierarchicznych poziomach.

General Struture SQALE model (źr: http://www.sqale.org)

Poziom 1 składa się z cech, w poziomie 2 zdefiniowane są subcharakterystyki. Wymagania, które odnoszą się do wewnętrznych atrybutów kodu źródłowego, które zależą od języka oprogramowania zdefiniowane są na poziomie 3.

Przykład wybranych cech zdekomponowanych na poziomy wg. Modelu SQALE dla języka Java.

przykład dekompozycji SQALE (opracowanie własne)

Model SQALE możemy traktować jako odwzorowanie modelu ISO 25010 cyklu życia aplikacji.

Model bazuje na podstawowych zasadach (wybrane z nich):

Zasada 1: Jakość kodu źródłowego jest wymaganiem niefunkcjonalnym
Projekt rozwoju aplikacji, bądź utrzymania oprogramowania ma cele, które muszą być osiągnięte i dotyczą terminów, kosztów, funkcjonalności oraz jakości. Aby cel został osiągnięty musi zostać sformalizowany, czyli zdekomponowany na wymagania.

Zasada 2: Wymagania dotyczące jakości kodu muszą być sformowalizowane, podobnie jak inne wymagania funkcjonalne.
Wymóg jakości dotyczący kodu źródłowego mus być co najmniej:

  1. Atomowy
  2. Jednoznaczny
  3. Mieć uzasadnienie
  4. Akceptowalny
  5. Wykonalny
  6. Nie stać w sprzeczności z innym wymaganiem
  7. Weryfikowalny
  8. Niezbędny

Zasada 3: Ocena jakości kodu źródłowego polega na ocenie rozbieżności między stanem obecnym a oczekiwanym.
Zasada 4: Metoda SQALE ocenia zgodność z wymaganiami biorąc pod uwagę niezbędne koszty naprawcze doprowadzenia kodu źródłowego do tej zgodności.
Zasada 5: Metoda SQALE ocenia znaczenie, wpływ niezgodności, biorąc pod uwagę koszty dostarczenia kodu źródłowego po naprawie.

Więcej o zasadach przeczytasz w: http://www.sqale.org/details/details-principles

7. W jaki sposób mogę zminimalizować dług techniczny?

  1. Zrozum i rozpowszechnij wiedzę na temat długu technicznego w zespole
  2. Uświadom swoich klientów jakie są skutki długu technicznego, który może się pojawić jeśli zaczniecie skracać czasy na analizę, programowanie i testy w projekcie.
  3. Przestrzegaj dobrych praktyk projektowych (zarządzania, analizy, programowania i testowania)
  4. Stosuj tylko dobrze przeanalizowane rozwiązania
  5. Powołaj architekta w zespole, ale również w organizacji, który będzie czuwał nad spójnością rozwiązań i czystością kodu
  6. Wykonuj refaktoryzację
  7. Wykonuj testy regresywne, dzięki czemu wykryjesz, kiedy błędy wprowadzane są do kodu (więcej o testach przeczytasz tu: https://ttpsc.com/pl/blog/testy-regresyjne-komu-sa-potrzebne-i-po-co-je-stosowac/)
Udostępnij




Aby pogłębić wiedzę po artykule zalecam szkolenie:

Wprowadzenie do analizy biznesowej i inżynierii wymagań

Zobacz