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.

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. 

Źródła zdjęć:
flickr.com udostępnione na licencji CC BY-NC-ND 2.0
https://bluestonelogic.com/technical-debt-in-plain-english-4b7504eec555

Komentarze do wpisu: “Dług techniczny (technologiczny)

  1. Warto podkreślić jedną rzecz. NIE DA SIĘ uniknąć długu technicznego, ponieważ obok wymienionych przez Autora dwóch powodów powstawania długu, są dwa kolejne:
    1. Brak kompletnej wiedzy i umiejętności. Zawsze jest coś, czego nie wiemy czy to w domenie, czy też w warsztacie.
    2. Zmieniające się wymagania w czasie (np. mały produkt na 100 użytkowników rozrasta się, osiągając możliwości swojej skalowalności).

    Te dwa powody są niejako niezależne od zespołu. Podkreślanie takich powodów jest o tyle istotne, że często można się spotkać z opinią sponsorów, że skoro to zespół „odpowiada” za dług techniczny, to niech teraz sobie sam radzi, a usuwanie długu technicznego nie ma prawa znaleźć się na tablicy zespołu, podczas gdy ciągły refactoring i inspekcja kodu powinny być częścią codziennej „higieny”.

    • Dawid Lewandowicz

      Zgadzam się Filip z tym co napisałeś.
      Odnośnie punktu pierwszego to myślałem o tym. Trochę to jest twarde. Ale prawdziwe. Odpowiedzią no to zagadnienie może być zrobienie macierzy kompetencji i zdefiniowanie przez samych członków zespołu w którym kierunku chcą się rozwijać.
      Odnośnie punktu drugiego to faktycznie taka sytuacja może mieć miejsce. Oczywiście dość rzadko się zdarza, że biznes urośnie (ca 1 na 10 przypadków). Ale jeżeli tak się stanie, to możemy mieć jako zespół problem, ponieważ nasze rozwiązania/ archtektura nie są przystosowane do tak dużego ruchu.

  2. […] Co z wdrożeniami? Dodatkowo na slajdach dołączonych do webinara prowadzonego przez twórców Scruma została poruszona kwestia czy zespół może wdrażać tylko raz, na koniec sprintu? Nie. Twórcy Przewodnika po Scrumie opisali, że wdrożenie może odbyć się w każdym momencie wybranym przez Product Ownera, pod warunkiem, że jest to możliwe dla Zespołu. Dodatkowo opisano, że podejście Continuous Delivery jak najbardziej może być zastosowane w Scrumie. Podkreślono też ciekawą rzecz – nie należy obniżać jakości wymagań, aby wdrażać szybciej, bo Zespół zostanie przygnieciony przez dług technologiczny. […]

  3. Dawid Lewandowicz

    Techniczny czy technologiczny?
    Zastanawiałem się, szukałem źródeł i nie znalazłem. Jednak jak się wydaje, poprawne tłumaczenie zwrotu oryginalnego (ang. technical debt), to dług techniczny. Nie technologiczny.
    Przy okazji znalazłem również krótki filmik wyjaśniający metaforę „długu”, zaproponowaną przez twórcę pojęcia Ward’a Cunningham.

    https://www.youtube.com/watch?time_continue=44&v=pqeJFYwnkjE


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

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