# Czym jest dług techniczny i jak go spłacić – przykłady > Dług techniczny może być cichym zabójcą projektów oprogramowania. Dowiedz się, jak identyfikować, priorytetyzować i rozwiązywać problemy związane z długiem technicznym, aby utrzymać zdrową bazę kodu. Source: https://asana.com/resources/technical-debt ## Czym jest dług techniczny? Jak go spłacić (z przykładami) #### Podsumowanie Dług techniczny to koszt dodatkowej pracy spowodowanej wyborem najszybszego, a nie najskuteczniejszego rozwiązania. Chociaż są sytuacje, w których dług techniczny jest tego wart, ważne jest, aby Twój zespół rozumiał pozytywne i negatywne strony szybkich decyzji oraz wiedział, jak efektywnie zarządzać poprawkami. Menedżerowie produktu, programiści i inni interesariusze powinni dokładnie rozważyć związane z tym kompromisy. W tym artykule wyjaśniamy, czym jest dług techniczny, dzielimy się technikami jego unikania i przyglądamy się, jak odróżnić decyzje wartościowe od bezwartościowych.Praca nad produktem często wymaga szybkiego podejmowania decyzji dotyczących funkcji oprogramowania. Jeśli zdarzyło Ci się pracować w zespole DevOps, wiesz, jak wiele decyzji jest potrzebnych, aby wprowadzić funkcje na rynek. Te wybory mogą mieć wpływ na kod źródłowy, doświadczenie użytkownika, czas wprowadzenia produktu na rynek i inne aspekty. Dług techniczny to termin używany do opisania wyniku [podejmowania decyzji](https://asana.com/resources/decision-making-process) w oparciu o szybkość. Te szybkie decyzje podejmowane w czasie rzeczywistym mogą sprawić, że aktualizacja oprogramowania zakończy się sukcesem lub porażką. Powinna jednak istnieć równowaga między dobrymi decyzjami a szybkimi decyzjami. Poniesienie długu technicznego może przynieść negatywne skutki lub być tego warte, w zależności od decyzji podjętych przez Ciebie i Twój zespół. Nie zawsze jest to zła rzecz, ale zbyt duży dług techniczny zmniejsza łatwość utrzymania i jakość kodu. W tym artykule omówimy definicję długu technicznego, sposób efektywnego zarządzania szybkimi decyzjami w procesie tworzenia oprogramowania oraz podzielimy się przykładami, które pomogą Ci uniknąć problemów w przyszłości. Omówimy takie tematy, jak refaktoryzacja, automatyzacja, wskaźniki, przeglądy kodu i dostosowanie do potrzeb biznesowych. ## Czym jest dług techniczny? Dług techniczny to cena dodatkowej pracy wynikającej z wyboru najszybszego, a nie najbardziej efektywnego rozwiązania. Programista Ward Cunningham po raz pierwszy użył tego wyrażenia w 1992 roku, ale od tego czasu jego znaczenie ewoluowało. Obecnie dług techniczny, znany również jako dług technologiczny i dług kodowy, zwykle pojawia się, gdy zespoły programistyczne decydują się na szybkie pisanie kodu podczas tworzenia nowych funkcji produktu. Szybkie dostarczanie kodu może pomóc zespołowi dotrzymać terminów, a nagromadzony dług _może_ być tego wart, choć może również prowadzić do negatywnych skutków, jeśli będzie niewłaściwie zarządzany. Tych negatywnych skutków nie zawsze można uniknąć po podjęciu decyzji o zaciągnięciu długu technicznego.  Niezależnie od tego, czy doświadczasz dobrych, czy złych skutków, omówimy ważne fakty dotyczące długu technicznego, abyś był(a) przygotowany(a) na podejmowanie właściwych decyzji w danej chwili. #### Koniec z silosami: optymalizacja struktury organizacyjnej w celu wzmocnienia współpracy między zespołami Z tego e-booka dowiesz się, jak ustrukturyzować swoją organizację, aby zapobiegać izolacji w silosach, działać szybciej i być na bieżąco w obliczu zmian. - [Pobierz pełny raport](/resources/organizational-structure-ebook) - [Pobierz pełny raport](/resources/organizational-structure-ebook) ### Czy dług techniczny jest zły? Podobnie jak dług finansowy, dług techniczny może być wykorzystywany zarówno w dobry, jak i zły sposób. W niektórych przypadkach dług techniczny jest wynikiem przemyślanego posunięcia, które ma na celu zarówno dotrzymanie terminów związanych z oprogramowaniem, jak i dostarczenie wysokiej jakości kodu w ramach sprintów. W innych przypadkach dług techniczny jest wynikiem nieuniknionego błędu popełnionego podczas wydawania aktualizacji oprogramowania. - [[Przeczytaj] 5 filarów skutecznego zarządzania wydaniami](/resources/release-management) ## Co powoduje powstawanie długu technicznego? Istnieją cztery różne przyczyny powstawania długu technicznego, określane jako kwadranty długu technicznego. Cztery kwadranty długu technicznego, które wymyślił Martin Fowler, to lekkomyślny, rozważny, celowy i nieumyślny. Kwadranty te pomagają członkom zespołu i interesariuszom zrozumieć różne rodzaje długów, które mogą narastać w kodzie źródłowym. Przypisanie długu technicznego do tych czterech kwadrantów pomaga ocenić intencje i kontekst problemów z kodem. Podczas gdy niektóre długi techniczne mogą być celowe i sklasyfikowane jako _dobre_, inne, takie jak szybkie poprawki i zły kod, mogą być nieumyślne i sklasyfikowane jako _złe_. - **Rozważny i celowy:**decyzja o szybkim wydaniu produktu i zajęciu się konsekwencjami później powoduje powstanie długu rozważnego i celowego. Ten rodzaj długu jest najczęściej stosowany, gdy stawka w projekcie oprogramowania jest stosunkowo niska, a korzyści z szybkiego wydania przeważają nad ryzykiem. Jest to świadomy kompromis, który pozwala skrócić czas wprowadzenia produktu na rynek. - **Nieprzemyślany i celowy:**gdy wiadomo, jak stworzyć najlepszy kod, ale priorytetem jest szybkie dostarczenie, powstaje nieprzemyślany i celowy dług. Często prowadzi to do powstania starszego kodu, który jest trudniejszy w utrzymaniu.  - **Rozważny i niezamierzony:**ten rodzaj długu pojawia się, gdy istnieje chęć stworzenia najlepszego kodu, ale po wdrożeniu znajduje się lepsze rozwiązanie. Automatyczne testowanie i inne metodologie mogą pomóc w wcześniejszym wykryciu tego problemu. - **Nieprzemyślany i niezamierzony:**nieprzemyślany i niezamierzony dług pojawia się, gdy zespół próbuje stworzyć najlepszy kod bez niezbędnej wiedzy. Często zespół nie zdaje sobie sprawy z popełnianych błędów. Może to prowadzić do powstania luk w zabezpieczeniach i problemów z utrzymaniem. Zespoły decydują się na celowe zadłużenie techniczne, aby przyspieszyć dostawę, podczas gdy zadłużenie nieumyślne jest przypadkowe – pojawia się po wdrożeniu. Różnicę tę najlepiej opisuje Steve McConnell, inżynier oprogramowania, który wyróżnia dwa ogólne rodzaje długu technicznego. Zrozumienie tych kwadrantów jest kluczem do zarządzania długiem w różnych cyklach rozwoju. Przyjrzyjmy się każdemu z nich, aby lepiej zrozumieć ten temat.   ## Rodzaje długu technicznego Steve McConnell, główny inżynier oprogramowania w Construx Software, zasugerował, że istnieją [dwa rodzaje długu technicznego](http://www.construx.com/uploadedfiles/resources/whitepapers/Managing%20Technical%20Debt.pdf): celowy i niezamierzony. ### 1. Celowy dług techniczny Celowy dług techniczny powstaje, gdy organizacja podejmuje świadomą decyzję o optymalizacji pod kątem teraźniejszości, a nie przyszłości. Często przyczyną takiego stanu rzeczy są potrzeby biznesowe i presja ze strony interesariuszy, takich jak menedżerowie produktu i dyrektorzy ds. informacji, aby szybko dostarczać funkcje. Istnieją zarówno krótkoterminowe, jak i długoterminowe warianty celowego zadłużenia. Na przykład celowy dług narosły w celu spłaty wcześniejszego długu projektowego jest długiem krótkoterminowym, podczas gdy celowy dług narosły w celu zapobieżenia większemu przyszłemu długowi dokumentacyjnemu byłby długiem długoterminowym.  - **Dług krótkoterminowy**: dług krótkoterminowy jest zaciągany w sposób reaktywny, z powodów taktycznych, takich jak wykorzystanie istniejących zasobów. Ponadto dług krótkoterminowy może być ukierunkowany lub nieukierunkowany. Członkowie zespołu mogą zaciągać dług krótkoterminowy, aby szybko dostarczać poprawki błędów lub inne ulepszenia w zakresie komfortu użytkownika. - **Ukierunkowane zadłużenie krótkoterminowe:**obejmuje indywidualnie identyfikowalne skróty.  - **Nieskoncentrowane zadłużenie krótkoterminowe:** obejmuje liczne drobne skróty. Z biegiem czasu może to znacznie spowolnić cykle rozwoju. - **Dług długoterminowy**: dług długoterminowy jest zaciągany proaktywnie, ze względów strategicznych, takich jak dotrzymanie terminu. Do tej kategorii często zalicza się automatyzacja i refaktoryzacja. Jak widać, rodzaj narosłego długu decyduje o tym, jak długo potrwa jego spłata. ### 2. Nieumyślny dług techniczny Z drugiej strony, niezamierzony dług techniczny powstaje z powodu braku zrozumienia, przypadkowych błędów lub – w niektórych przypadkach – źle napisanego kodu. Przykładem niezamierzonego długu technicznego może być podejście do projektowania, które okazuje się podatne na błędy. Regularne przeglądy kodu mogą pomóc w wcześniejszym wykryciu takich problemów. Można założyć, że niezamierzony dług techniczny jest przypadkowy, ponieważ zespół nie zaciągnął go celowo. Najczęściej zdajemy sobie sprawę z błędu dopiero po wdrożeniu aktualizacji oprogramowania lub ukończonym projekcie.  - [Przeczytaj: 27 wskaźników sukcesu w biznesie, które warto śledzić](/resources/success-metrics-examples) ## Jak mierzyć dług techniczny Pomiar długu technicznego jest niezbędny, aby zespoły programistyczne mogły zrozumieć zakres swojego długu kodowego i podejmować świadome decyzje dotyczące zarządzania nim. Określając ilościowo dług techniczny, zespoły mogą nadać priorytet nakładowi pracy związanemu z refaktoryzacją i zapewnić, że ich kod źródłowy będzie łatwy do utrzymania i skalowalny w dłuższej perspektywie. ### Wskaźniki i narzędzia Do oceny wielkości długu technicznego w projekcie oprogramowania można wykorzystać różne wskaźniki. Należą do nich złożoność kodu, duplikacja, pokrycie testami i wskaźniki łatwości utrzymania. Narzędzia takie jak SonarQube, CAST i Kiuwan mogą zautomatyzować proces pomiaru, dostarczając cennych statystyk dotyczących kondycji bazy kodu. ### Najlepsze praktyki w zakresie oceny Oceniając dług techniczny, należy zaangażować wszystkie zainteresowane strony, w tym programistów, menedżerów produktu i liderów biznesowych. Regularne przeglądy kodu i dyskusje na temat metafor dotyczących długu mogą pomóc w zwiększeniu świadomości i wspólnym zrozumieniu wpływu długu technicznego. Priorytetyzacja zadłużenia na podstawie jego zdolności do utrudniania cykli rozwoju, funkcjonalności i doświadczenia użytkownika jest kluczem do skutecznej oceny. ## Jak spłacać dług techniczny Chociaż możesz świadomie zaciągać pewne długi techniczne, wiele zespołów produktowych ma trudności z ich śledzeniem i [komunikowaniem](https://asana.com/resources/effective-communication-workplace). Może to skutkować większą ilością pracy niż oczekiwano przy próbie rozwiązania luk w kodzie oprogramowania.  Ten przewodnik krok po kroku pomoże Ci spłacić dług techniczny i stworzyć większą [przejrzystość w miejscu pracy](https://asana.com/resources/workplace-transparency) w odniesieniu do obciążenia zadłużeniem.  ### Krok 1: zidentyfikuj i ustal priorytety zadłużenia technicznego Pierwszym krokiem do spłaty długu technicznego jest zidentyfikowanie i priorytetyzacja obszarów kodu, które wymagają uwagi. Obejmuje to analizę wskaźników, przegląd kodu i zbieranie informacji od członków zespołu. Ustal priorytet zadłużenia na podstawie jego wpływu na funkcjonalność, łatwość utrzymania i potrzeby biznesowe. - Prowadź listę zadłużeń w systemie śledzenia. Za każdym razem, gdy zaciągasz dług, wprowadź do systemu śledzenia zadania wymagane do jego spłaty, a także szacowany nakład pracy i harmonogram. Użyj backlogu zadłużenia, aby śledzić postępy w spłacaniu długu technicznego. Każdy nierozliczony dług starszy niż 90 dni należy traktować jako krytyczny. - Jeśli korzystasz ze Scruma, prowadź listę zadłużeń jako część backlogu produktu Scruma, traktując każde zadłużenie jako „historię” Scruma i szacując nakład pracy oraz harmonogram spłaty każdego zadłużenia – w taki sam sposób, w jaki szacujesz inne historie w Scrumie. ### Krok 2: Refaktoryzacja i optymalizacja kodu Po zidentyfikowaniu zadłużenia technicznego o wysokim priorytecie nadszedł czas, aby rozpocząć refaktoryzację i optymalizację kodu. Może to obejmować rozbijanie złożonych funkcji, eliminowanie duplikacji, poprawianie konwencji nazewnictwa i aktualizowanie przestarzałych struktur. Unikaj skrótów i szybkich poprawek, ponieważ w dłuższej perspektywie mogą one prowadzić do jeszcze większego zadłużenia. ### Krok 3: Ustal standardy kodowania i najlepsze praktyki Aby zapobiec kumulowaniu się nowego długu technicznego, ustal jasne standardy kodowania i najlepsze praktyki dla swojego zespołu programistycznego. Obejmuje to wytyczne dotyczące struktury kodu, komentowania, testowania i dokumentacji. Zachęcaj członków zespołu do konsekwentnego przestrzegania tych standardów oraz zapewniaj im szkolenia i wsparcie w razie potrzeby. ### Krok 4: Monitoruj i rozwiązuj problemy związane z nowym długiem na bieżąco Dług techniczny to problem, który nie znika. Dlatego ważne jest, aby stale monitorować i rozwiązywać problemy związane z nowym długiem, gdy tylko się pojawią. Regularnie oceniaj bazę kodu za pomocą wskaźników i narzędzi oraz włącz zarządzanie długiem do procesu tworzenia oprogramowania. Rozważ wdrożenie metodologii takich jak Scrum lub DevOps, aby wspierać ciągłe doskonalenie i redukcję zadłużenia.  - [Przeczytaj: Wydajność a skuteczność w biznesie: dlaczego Twój zespół potrzebuje obu z nich](/resources/efficiency-vs-effectiveness-whats-the-difference) ## Przykłady zadłużenia technicznego i rozwiązania Teraz, gdy wiesz już, jak zarządzać długiem technicznym i znasz niektóre przyczyny powstawania długu niezamierzonego i zamierzonego, przyjrzyjmy się kilku przykładom z życia wziętym.  ### Przykład 1: celowy dług techniczny - **Opis:** zespół wybiera strukturę, która jest szybka w budowie, ma znane problemy z wydajnością i oferuje minimalne możliwości funkcjonalne. - **Rozwiązanie:**zespół korzysta z dodatkowych aplikacji do wdrażania oprogramowania, które zawierają brakujące funkcje struktury. - **Dług:**mimo dotrzymania terminu, zespół będzie musiał przerobić funkcje po premierze produktu i będzie potrzebował dodatkowych środków.   ### Przykład 2: nieumyślny dług techniczny - **Opis:** zespół składa się z wielu młodszych programistów, którzy pomagają uruchomić nową funkcję oprogramowania w krótkim terminie, a liczba starszych programistów nie jest wystarczająca, aby przejrzeć każdy fragment kodu.  - **Rozwiązanie:**zespół zatrudnia tymczasowo dodatkowych doświadczonych programistów, aby przejrzeli kod i sprawdzili, czy wszystko działa prawidłowo.  - **Dług:**zespół wykrył większość problemów, ale z powodu nieporozumień między pracownikami etatowymi a tymczasowym wsparciem przeoczono kilka błędów w kodzie. Oznacza to, że zespół będzie musiał debugować te problemy po premierze.  Jak widać, zarówno celowy, jak i niecelowy dług będą musiały zostać spłacone w miarę upływu czasu. [Przeprowadzając burzę mózgów na temat rozwiązania](https://asana.com/resources/brainstorming-techniques) problemu długu technicznego, możesz zadbać o to, aby aktualizacje oprogramowania były wprowadzane na czas przy niewielkim długu narosłym.  ## Zarządzaj długiem technicznym w przejrzysty sposób Podczas pracy nad premierą oprogramowania nie zawsze można uniknąć zadłużenia. Zespoły [Agile](https://asana.com/resources/agile-methodology) wiedzą, jak wielkość narosłego długu technicznego może wpłynąć na aktualizacje oprogramowania, od trudnych decyzji po błędy w kodzie.  Kluczem do spłaty długu jest utrzymanie i śledzenie płatności przyrostowych. Chociaż rodzaj spłaty zadłużenia jest inny w każdym scenariuszu, przejrzystość i komunikacja w zespole mogą pomóc w szybszym spłacaniu zadłużenia. Wynika to z faktu, że większa przejrzystość w projektach Agile może wymusić zbiorowe rozwiązanie danego problemu. ## Często zadawane pytania: dług techniczny **Czym jest dług techniczny w Scrumie?** W Scrumie dług techniczny odnosi się do nagromadzenia pracy, którą należy wykonać, aby utrzymać i poprawić jakość oprogramowania. Powstaje, gdy zespół programistów podejmuje świadome decyzje o priorytetowym traktowaniu szybkości nad jakością lub gdy nieświadomie zaciąga dług z powodu braku doświadczenia lub wiedzy. W Scrumie dług techniczny jest często reprezentowany jako elementy backlogu, które należy uwzględnić w przyszłych sprintach. **Czy dług techniczny jest dobry, czy zły?** Dług techniczny nie jest z natury dobry ani zły. Wszystko zależy od tego, jak się nim zarządza. W niektórych przypadkach zaciągnięcie długu technicznego może być decyzją strategiczną, która pozwoli zespołowi szybciej dostarczyć wartość. Jednakże, jeśli nie jest kontrolowany, dług techniczny może prowadzić do zwiększonych kosztów utrzymania, zmniejszonej produktywności, a nawet niepowodzenia projektu. Dlatego kluczowe jest zachowanie równowagi między zaciąganiem a spłacaniem długu technicznego. **Jakie są najczęstsze przyczyny powstawania długu technicznego?** Typowe przyczyny powstawania długu technicznego obejmują napięte terminy, które zmuszają zespół do stosowania rozwiązań na skróty, brak standardów kodowania i najlepszych praktyk, niewystarczające testowanie i dokumentację oraz korzystanie z przestarzałych lub niekompatybilnych technologii. Inne czynniki, takie jak rotacja zespołu i brak komunikacji, również mogą przyczyniać się do narastania długu technicznego. **Jak dług techniczny może wpłynąć na projekt?** Dług techniczny może mieć znaczący wpływ na powodzenie projektu. Wraz ze wzrostem zadłużenia technicznego baza kodu staje się coraz bardziej złożona i trudna w utrzymaniu, co prowadzi do wydłużenia cykli rozwoju i zwiększenia liczby poprawek błędów. To z kolei może opóźnić wprowadzenie nowych funkcji i negatywnie wpłynąć na komfort użytkowania. W skrajnych przypadkach dług techniczny może sprawić, że projekt stanie się niewykonalny i będzie wymagał całkowitego przepisania kodu źródłowego. **Jak zapobiegać długowi technicznemu?** Zapobieganie długowi technicznemu wymaga proaktywnego podejścia obejmującego cały zespół programistów. Obejmuje to ustanowienie i przestrzeganie standardów kodowania i najlepszych praktyk, przeprowadzanie regularnych przeglądów kodu oraz priorytetyzację testów i dokumentacji. Metodologie Agile, takie jak Scrum, mogą również pomóc w zapobieganiu długowi technicznemu, zachęcając do częstego przekazywania informacji zwrotnych i ciągłego doskonalenia. Ponadto przeznaczanie czasu w każdym sprincie na rozwiązanie problemu długu technicznego może pomóc w utrzymaniu go pod kontrolą. - [Zarządzanie projektami](/resources/project-management) - [Sprint planning template](https://asana.com/templates/sprint-planning) Agile Planowanie projektu - [Product backlog template](https://asana.com/templates/product-backlog) Agile - [Product roadmap template](https://asana.com/templates/product-roadmap) Planowanie projektu inżynieria Agile - [Product development template](https://asana.com/templates/product-development) Agile Strategia biznesowa Zarządzanie projektami Planowanie projektu inżynieria - [What is technical debt and how to pay it off (with examples)](/pl/resources/technical-debt) Agile Zarządzanie projektami - [Autor treści](/author/team-asana) Praca nad produktem często wymaga szybkiego podejmowania decyzji dotyczących funkcji oprogramowania. Jeśli zdarzyło Ci się pracować w zespole DevOps, wiesz, jak wiele decyzji jest ...