Dług techniczny (technologiczny)

Jako zespół developerski powinniście dostarczyć nowe funkcjonalności do Waszego systemu (aka produktu). Widzicie dwie drogi. Pierwsza jest szybka, ale jako zespół jesteście pewni, że podążając nią, w przyszłości będziecie pracować wolniej i wolniej. Druga droga jest trudniejsza, zajmie Wam więcej czasu, ale zrobiony kod będzie wolny od długu technicznego.

Często jako zespół stawiacie sobie to pytanie – droga A czy też droga B?  Odpowiedź na to pytanie wydaje się prosta i oczywista, ale chyba jednak taka nie jest.

Ale zacznijmy od tego, co to w ogóle jest dług techniczny i jak go możemy zdefiniować:

Jest to cokolwiek w Waszym kodzie i środowisku (developerskim, testowym, produkcyjnym), co powoduje, że jesteście w swojej pracy wolniejsi.

Reklama


Na przykład:

  • nieczytelny kod,
  • brak testów automatycznych, brak automatyzacji wdrożeń,
  • zduplikowany kod,
  • powolne narzędzia, brak efektywnych narzędzi,
  • kod, który nie został “scommitowany”,
  • brak środowiska testowego,
  • nieefektywne środowisko testowe, powolne z brakiem pełnej funkcjonalności środowiska produkcyjnego.

Istotną kwestią jak także to, czy dług techniczny jest zawsze zły. Henrik Kniberg próbuje odpowiedzieć na to zagadnienie.

Dług techniczny w złym rozumieniu, nad którym się tutaj pochylamy,  to kod zrobiony zgodnie z przykładami, które Wam dałem w definicji. Widziałem firmy, które z uwagi na wielkość długu technicznego podejmowały (trwało to bardzo długo) decyzję o zaprzestaniu rozwoju produktu na rzecz konieczności jego stworzenia od nowa. Zapytacie „Dlaczego?” Ponieważ koszt utrzymania, a zwłaszcza wprowadzania nowych funkcjonalności do obecnego kodu, był tak duży, że stawał się tak bardzo długotrwały, że aż nieopłacalny.

Skąd się bierze dług techniczny?

Odpowiedź na to pytanie jest dość prosta i dość bezpośrednia. Dług techniczny (ang. crappy code/ technical debt) powstaje, ponieważ programiści go stworzyli. Innymi słowy cały dług techniczny jest efektem pracy zespołu developerskiego. Odpowiada on za kod, odpowiada on za produkt. To w gestii zespołu leży fakt, aby zauważyć, że dana funkcjonalność, również biznesowa, jest już nieużywana i należy tego kawałka kodu się pozbyć.

Powstawanie

Dług techniczny powstaje z dwóch podstawowych przyczyn.

Pierwszą jest fakt, że jako ludzie zaczynamy się zachowywać tak, jak zachowuje się nasze otoczenie. Niejednokrotnie czytaliście albo widzieliście doświadczenia pokazujące, że dana jednostka zaczyna się zachowywać wg norm ustalonych przez większość albo, co jest pewnie częstsze,  już zastanych reguł, nawet jeśli wydają się delikatnie mówiąc “nieprzystające”. Podobnie jest z długiem technicznym. Ludzie dążą do przystosowania swojego kodu do już obowiązujących standardów. Jeżeli dany produkt posiada dług techniczny, nowe osoby z zespołu go rozwijającego będą w tym kierunku również podążały (będą tworzyły nowy dług techniczny). Jak długo ktoś z zespołu głośno nie powie, że potrzebne są standardy pracy, tak długo opisywana sytuacja będzie trwała.

Drugą przyczyną jego powstawania jest presja. Product Owner wywiera na zespół presję, ktoś inny wywiera presję na niego. Wyjaśnia to zagadnienie poniższy rysunek.

Tworzycie jako zespół rozwiązanie, oszacowaliście, kiedy mniej więcej skończycie (mając oczywiście na uwadze, że prawdopodobnie nigdy nie skończycie, ponieważ rozwijacie produkt, a nie realizujecie projekt), i w pewnym momencie dostajecie informację, że macie się z wdrożeniem spieszyć, jak najszybciej skończyć wytwarzaną funkcjonalność / produkt.

Jeżeli pozwolicie sobie na pójście na skróty (ang. cut corners), jeżeli będziecie poszukiwać rozwiązań tańszych i szybszych, jeżeli nie będziecie  dbali o kwestie wymienione na początku artykułu, stworzycie dług techniczny.

Rzadko, ale zdarza się sytuacja, że jednak dług techniczny jest akceptowalny. Czasami “biznes” już podpisał jakąś umowę z krytyczną datą jej wejścia w życie, czasami Product Owner chce na szybko zweryfikować pomysł tworząc rozwiązanie, które za chwilę i tak będzie “zaorane”. W takich sytuacjach liczy się czas i zespół stara się, aby szybko wdrożyć tymczasowe rozwiązanie.

Symptomy

Kiedy mamy do czynienia z długiem technicznym? Po jakich symptomach możemy go rozpoznać? Poniżej znajdziecie listę rzeczy (za prezentacją Lemi Orhan Ergin), które mogą wskazywać na jego istnienie:

  • utrata produktywności, w tym utrata motywacji i spadek morale w zespole,
  • wzrost ilości pracy związanej z testami, zwłaszcza testami manualnymi,
  • przekładane wdrożenia,
  • zduplikowanie kodu,
  • wzrost liczby błędów,
  • wysoki poziom stresu w zespole związany ze zbliżającym się wdrożeniem,
  • strach przed jakimikolwiek zmianami w kodzie,
  • nieczytelny / niezrozumiały kod,
  • spadająca prędkość (ang. velocity) zespołu,
  • raporty z Sonara,
  • bad smells (pol. zapachy kodu),

Powiedz stop długowi technicznemu

Dług techniczny oznacza, że jesteście coraz wolniejsi. Poświęcacie coraz więcej czasu na “walkę” z kodem, próbując go ominąć. Jako zespół współdecydujecie, jak wygląda Wasz produkt. Decydujecie m.in., ile pracy weźmiecie na iterację (zespół pracujący Scrumem), lub ile wynoszą Wasze WIP (ang. work in progress, dla zespołów używających Kanbana). Dodatkowo decydujecie, czym aktualnie się zajmujecie (albo przynajmniej współdecydujcie). Macie jako zespół pełną władzę, aby długowi zapobiegać. Może zrobić mniej wymagań biznesowych w ciągu iteracji, inaczej spriorytetyzować zadania do realizacji. Oczywiście, będzie to wymagało dodatkowej pracy, może czasami twardych dyskusji z Ownerem lub biznesem. Ale jeżeli wszyscy się zgadzamy, że mamy dług techniczny, że dalsza realizacja złego kodu może ten dług pogłębić, że jeżeli nie zaczniemy z nim walczyć od razu, to problem będzie narastał. Oczywiście, zawsze padnie argument, dlaczego zespół realizujący do tej pory ok. 10 wymagań od teraz zobowiązuje się do realizacji tylko 6, poświęcając resztę czasu na zadania mocno techniczne. Musimy się tego spodziewać i odpowiednio się jako zespół do takiej dyskusji przygotować. Z tym punktem wiąże się jeszcze jedno. Poprawa jakości kodu nigdy nie jest widoczna w krótkim terminie. Jako zespół (pewnie cały zespół scrumowy, czyli zespół developerski, Product Owner, Scrum Master) powinniśmy poświęcić wiele czasu na przekazanie i pokazanie informacji, z czym mamy do czynienia, jakie mogą być konsekwencje naszych działań lub ich braku. I tylko pełne zrozumienie sytuacji przez nas jak i przez “biznes” może pozwolić rozwiązać ten problem.

Podsumowując

Odpowiedzialność za jakość kodu, rozwiązań, które zespół tworzy, leży po stronie tegoż zespołu. Product Owner może w tej sytuacji (zapobiegania lub poprawienia już powstałego długu technicznego) pomóc, poprzez na przykład odpowiednie priorytetyzowanie zadań, itd., ale pełna decyzyjność jest po stronie zespołu. Może w tym pomóc lepszy planning, inne limity WIP, Definition of Done czy w końcu priorytetyzacja zadań.

Warto powtórzyć jedna rzecz – dług techniczny nie zawsze jest jednoznaczny. Znalazłem ciekawą metaforę stworzoną przez Warda Cunninghama. Mianowicie traktujmy dług techniczny jak dług finansowy. Z jednej strony pozwala on nam kupić rzeczy, które chcemy / musimy mieć. Pozwala nam także funkcjonować na pewnym oczekiwanym poziomie. Z drugiej strony jest on niebezpieczny, jeśli nie spłacimy go w odpowiednim czasie. 

 

Jeżeli chcesz poznać więcej wskazówek (hintów), dotyczących danego tematu oraz całego Agile’a (począwszy od kontraktowania po techniki deweloperskie), sięgnij do książki AgileHints.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X