Dług techniczny - cichy morderca

2018-02-17 | Krzysztof Dębski

Niedawno miałem przyjemność współprowadzić wraz z AgileRebels meetup ScrumVival w Krakowie. Było to miejsce, w którym Scrum Masterzy, Product Owner-zy, Menedżerowie oraz Inżynierowie mieli okazję do całodziennej pracy nad tym czym jest dług techniczny. Ponadto poruszyliśmy wiele kwestii związanych ze sposobami walki z nim, a także z tym jak ulepszyć swoją pracę i podnieść produktywność. Jak to się dzieje, że dług się pojawia w procesie?

Pierwszą częścią warsztatów było ćwiczenie - gra, w której uczestnicy mieli możliwość na własnej skórze poczuć i zobaczyć, że dług pojawia się w procesie wytwarzania po cichu i praktycznie bez żadnej specjalnej pracy. W czasie gry, w miarę dokładania długu, praca zaczynała zajmować coraz więcej czasu a przyrost wartości był coraz mniejszy. Nie pomogły tu nawet pokrzykiwania menedżera. Jak tylko doszliśmy do momentu, że praca stała się naprawdę wolna, postanowiliśmy ulepszyć nasz proces i oprócz dodawania nowej wartości postanowiliśmy część wysiłków poświęcić na spłatę długu. Po jakimś czasie praca znacząco przyspieszyła i prawie osiągnęliśmy początkową sprawność.

Skoro dług się pojawia niezauważony, to skąd on się bierze?

Funkcjonalności czy użyteczności?

Kiedy budujemy nasze aplikacje zazwyczaj skupiamy się na dowiezieniu jak największej ilości funkcjonalności. Ponieważ pracujemy w środowisku, w którym mamy ograniczony czas i zasoby, musimy iść na kompromisy i coś poświęcić, aby uzyskać jak największą wartość biznesową.

Zazwyczaj ciężko jest zrezygnować z wymagań biznesowych, więc próbujemy odsunąć w czasie poprawę użyteczności aplikacji. Czasem objawia się to brakiem lub słabymi testami, w innych projektach budujemy SPOF-y (single points of failure). Czasem budujemy aplikacje, które bardzo trudno nam będzie później skalować. Żadna z tych użyteczności nie jest widoczna dla naszych użytkowników kiedy zaczynają używać naszej aplikacji. Na początku są oni skupieni na funkcjonalnościach , które im dostarczyliśmy. Jednak po jakimś czasie zaczynają zauważać, że aplikacja pracuje wolniej, muszą dłużej czekać na odpowiedzi i od czasu do czasu aplikacja zachowuje się zaskakująco dla użytkownika.

Dług zaczyna być widoczny i musimy pomyśleć o jego spłacie.

Dług techniczny czy technologiczny?

Na początku naszego warsztatu ScrumVivalowego rozmawialiśmy o doświadczeniach z długiem. Wielu uczestników mówiło, że chciałoby zacząć zwalczać dług technologiczny, w związku z czym chcieliby się czegoś więcej o nim dowiedzieć. Jedna z osób zadała jednak pytanie czym się różni dług techniczny od technologicznego, bo nie znając różnicy używa tych określeń zamiennie.

Znajomość różnicy między długiem technicznym a technologicznym jest jednym z wyników naszego warsztatu.

Kiedy mówimy o technice mamy na myśli:

  • zbiór praw naukowy,
  • specyficzną grupę zastosowań,
  • specyficzną grupę produktów,
  • specjalistyczną wiedzę, wyrażającą się m.in. w zbiorze używanych technologii,
  • doświadczenie praktyczne,
  • organizację, składającą się ze struktur i systemów.

Możemy to mapować na obszary, w których zaciągamy dług techniczny: * produkt * organizacja * procesy * architektura * technologia

Skąd wiemy, że dług techniczny pojawił się w naszym produkcie?

Wskaźniki długu

Podczas warsztatów przeprowadziliśmy jeszcze jedno ćwiczenie. Po podziale uczestników na grupy, każda z nich miała za zadanie znalezienie jak największej ilości wskaźników długu w danym obszarze. W ramach ćwiczenia pojawiła się ważna uwaga. Wskaźniki długu nie mówią nam nic o przyczynach zaciągnięcia długu, ani o tym czy dług jest dobry czy zły. Jednak duża ilość wskaźników w danym obszarze to bardzo wyraźny sygnał, że w danym obszarze konieczna jest głębsza analiza.

Przykłady wskaźników długu są wymienione poniżej.

Produkt

  • aplikacja restartuje się
  • stroma ścieżka nauki

Organizacja

  • niska motywacja
  • defetyzm

Procesy

  • duża ilość procesów
  • procesy bez wyznaczonych właścicieli
  • brak procesów CI/CD

Architektura

  • brak środowisk dev/test
  • przeskalowana architektura
  • skomplikowane zależności

Technologia

  • duża ilość wykorzystanych technologii
  • wiele wykorzystywanych frameworków
  • własny framework
  • duże pliki

Co można zrobić z taką listą?

Zwalczanie długu technicznego

Po zdefiniowaniu wskaźników długu technicznego wiemy co chcemy zlikwidować. Należy jednak walczyć z prostymi rozwiązaniami, które służą tylko usunięciu wskaźników. Kiedy widzimy wskaźnik “brak testów” oczywistym rozwiązaniem wydaje się rozwiązanie “zacząć pisać testy”. Innym wskaźnikiem może być “brak wizji architektury” na który prostą odpowiedzią jest “zatrudnić architekta”.

Niestety nie możemy do tego podejść tak łatwo. Zazwyczaj wskaźnik to tylko szczyt góry lodowej, pod którym czai się duża ilość pracy do wykonania. Na przykład to, że nie piszemy testów może oznaczać, że mamy spaghetti w kodzie i że powinniśmy się skupić na podniesieniu umiejętności developerskich w zespołach. To z kolei może też oznaczać, że nie używamy odpowiednich narzędzi lub że mamy zbyt mało doświadczonych pracowników. Co z kolei może nas zaprowadzić do błędów w architekturze systemu.

Ważne jest, aby walka z długiem technicznym nie była w rękach IT, ale żeby była wysiłkiem całej organizacji. Z długiem musimy walczyć w sposób skoordynowany.

Czy możliwe jest wygranie z długiem technicznym?

Ostatnią częścią warsztatów było case study projektu Rubicon przeprowadzonego w Allegro. Dług techniczny, który rósł od lat spowodował spowolnienie prac developerskich w monolitycznej aplikacji. Przez to zdecydowaliśmy się walczyć z długiem we wszystkich obszarach. Zmiana architektury, technologii, procesów, a w końcu organizacji przyniosła do Allegro mikrousługi i metodyki zwinne. To doskonały przykład na to, że w długim terminie spłata długu technicznego może przynieść duże zyski.

Liczę, że mając dobry przykład i narzędzia do walki z długiem technicznym wyniesione z warsztatu każdy z uczestników wprowadzi w swojej organizacji działania mające na celu walkę z długiem technicznym.

Krzysztof Dębski Technical Advisor Inżynier oprogramowania, architekt oraz techniczny właściciel produktów. Posiada eksperckie doświadczenie w budowaniu wysokowydajnych, rozproszonych aplikacji a także transformacjach technologicznych monolitycznych aplikacji w duchu Domain Driven Design.

Bądźmy w kontakcie

If you have a problem who'd gonna call? Tech Rebels ;)



Jeżeli chcesz zapoznać się bliżej z naszymi usługami lub chcesz z nami rozpocząć współpracę skorzystaj z formularza.

Pozdrawiamy i do usłyszenia,

TechRebels Team.

Napisz do nas