Tehnički dug u agilnom razvoju: kada brzina isporuke postaje dugoročni poslovni problem

Ključne teze – šta je najbitnije u ovom tekstu

• Tehnički dug nije isto što i loš kod, niti je svaki kompromis u razvoju automatski pogrešan.

• Ponekad je potpuno racionalno svesno izabrati jednostavnije ili privremeno rešenje kako bi se proverila poslovna hipoteza, brže izašlo na tržište ili izbeglo preuranjeno ulaganje u glomaznu arhitekturu.

• Problem nastaje kada privremeno rešenje postane trajno, dug ostane nevidljiv u planiranju, a kompanija nastavi da meri isključivo površinsku brzinu novih isporuka.

• Martin Fowler je odavno definisao kvadrant tehničkog duga (Technical Debt Quadrant), razlikujući promišljen od nepromišljenog, te nameran od nenamernog duga. Razlika je u tome da li uzimate kontrolisani kredit za razvoj ili nepromišljeno gomilate dugove na kreditnoj kartici.

• Najbolja metrika tehničkog duga nije estetika koda, već cena promene i brzina kojom sistem može bezbedno da evoluira.

Tehnički dug nije problem programera već odloženi poslovni trošak

Izraz tehnički dug menadžmentu često zvuči kao interna tehnička tema inženjerskog tima. Kada inženjeri kažu: „Moramo da refaktorišemo ovaj modul“, rukovodstvo često čuje: „Želimo da potrošimo tri nedelje na nešto što klijent uopšte neće primetiti“.

To je verovatno najveći komunikacioni nesporazum u savremenom razvoju softvera. Korisnik zaista ne vidi refaktorisanje dok se ono dešava, ali itekako vidi posledice njegovog izostanka:

• Usporenu isporuku novih mogućnosti;

• Češće greške i neočekivane prekide u radu aplikacije;

• Pad performansi i nestabilnost servisa.

Sa poslovne strane, to se direktno prevodi u skuplji razvoj, probijanje rokova, veće troškove podrške, bezbednosne rizike i opasnu zavisnost od svega nekolicine ključnih ljudi koji jedini znaju kako sistem zapravo radi. Tehnički dug zato nije apstraktan problem lošeg koda, već odloženi poslovni trošak svake naredne promene.

Najbolja metafora nije sam dug, već kamata

Jedna inženjerska prečica retko kada donosi propast. Problem je ono što se dešava nakon nje.

Uzmimo jednostavan primer: danas uštedimo dva radna dana tako što ćemo konfiguraciju uneti direktno u kod (hardcoding), preskočiti pisanje automatskog testa i dodati još jednu komplikovanu logičku granu u već preopterećen modul. Funkcionalnost izlazi na vreme i sa tržišnog aspekta to može biti sjajna taktička odluka.

Međutim, kada sledeći put isti taj modul zatreba nadogradnju, developer mora da utroši dva sata samo da bi razumeo prethodnu prečicu. Kod sledeće promene gubi se četiri sata, a posle deset iteracija nepovratno se gube celi radni dani. To je kamata.

Martin Fowler tehnički dug opisuje kroz pojam naslaga (cruft): kada unutrašnji kvalitet koda padne ispod kritičnog nivoa, stalno forsiranje kratkoročnih prečica počinje da usporava tim. Nove mogućnosti tada stižu sporije nego što bi stizale da je kod redovno održavan. Posle određene tačke, kvalitet više nije suprotnost brzini – on postaje njen osnovni preduslov.

Agile nije stvorio tehnički dug, ali ume savršeno da ga sakrije

Agilne metodologije osmišljene su da obezbede kraće cikluse povratnih informacija, brže učenje i češću isporuku vrednosti. To je u potpunosti kompatibilno sa inženjerskom izuzetnošću.

Problem nastaje kada organizacija agilnost svede na jednostranu parolu: „Svake dve nedelje moramo prikazati nešto novo na ekranu“.

U takvom okruženju pregled sprinta (Sprint Review) postaje izložba vizuelnih noviteta, lista zahteva (Product Backlog) puni se isključivo funkcionalnostima za korisnike, a refaktorisanje, automatski testovi, bezbednost i dokumentacija gube prioritet jer nemaju neposrednu tržišnu vidljivost. Tim ubrzo usvaja nepisano pravilo da se vrednuje samo nov ekran, a ne stabilnost i održivost sistema.

Atlassian upravo zato ističe preporuku da tehnički dug mora biti tretiran kao ravnopravna stavka u listi zadataka (First-class Backlog Item), sa jasnim kriterijumima prihvatanja. Testiranje, pregled koda (Code Review) i tehnička dokumentacija moraju biti sastavni deo stvarne definicije završenog posla (Definition of Done), a ne zadaci koji se stalno ostavljaju za neka mirnija vremena.

Ako priču završite bez testa, niste je zapravo ni završili

Pravilo deluje strogo, ali počiva na jasnoj inženjerskoj logici. Zamislimo situaciju u kojoj funkcionalnost radi, ali nema automatizovane testove. Tim odlučuje: „Dodaćemo testove tokom sledećeg sprinta“.

Šta se zapravo dogodilo? Funkcionalnost je unovčena danas, dok je trošak očuvanja njenog kvaliteta prebačen na buduće budžete. Kada se ovakva praksa ponovi na desetinama zadataka, stvara se nevidljiva lavina zaostalog posla koju tim vremenom više ne može da kontroliše. Test nije opcioni dodatak funkcionalnosti – on je sastavni deo cene njenog dugoročnog postojanja u produkciji.

Ni potpuno čist kod nije racionalan poslovni cilj

Naravno, postoji i suprotna krajnost. Kada inženjerski tim odbija da isporuči bilo šta dok arhitektura ne bude akademski besprekorna, rizikuje se pojava preteranog inženjeringa (overengineering). Šest meseci kasnije sistem ima idealne apstrakcije i savršen domen model, ali je tržišna prilika u međuvremenu propala.

Tehnički dug je potpuno opravdan onda kada kupuje stratešku poslovnu prednost:

• Lansiranje minimalno održivog proizvoda (MVP) pred ključnu industrijsku konferenciju;

• Brza validacija ideje za koju još nije sigurno da li uopšte ima publiku;

• Svesni izbor jednostavnije infrastrukture umesto rešenja za milione korisnika koje još nemate.

Ključ je u tome da se odluka dokumentuje, da se razumeju njena tehnička ograničenja i da se unapred definiše tačka aktivacije promene: kada broj korisnika pređe određeni prag ili modul postane centralni deo poslovanja, pristupa se planskom refaktorisanju. To je primer zdravog, kontrolisanog tehničkog duga.

Najopasniji dug je onaj za koji kompanija više ne zna ni zašto postoji

U sistemima sa dugim stažom često se nailazi na situaciju gde programer gleda nelogično parče koda i pita: „Zašto je ovo uopšte ovako rešeno?“

Niko u timu ne zna odgovor. Možda je to bila privremena zakrpa u tri ujutru tokom nekog incidenta. Originalni autor je odavno napustio kompaniju, dokumentacija ne postoji, a privremeno rešenje se sada tretira kao nepromenjiva arhitektonska činjenica. To je faza zaboravljenog duga. U tom trenutku više ne plaćate samo cenu lošeg koda, već i vreme utrošeno na mukotrpno odgonetanje njegovog porekla.

Tehnički dug je mnogo više od samog koda

Kada se pomene ovaj termin, većina pomisli na loše napisane funkcije i dupliranu logiku. Međutim, tehnički dug zahvata mnogo dublje slojeve:

• Arhitektonski dug (Architecture Debt): Struktura sistema više ne podržava način na koji proizvod raste;

• Testni dug (Test Debt): Nedostatak automatizovanih testova ili postojanje nepouzdanih testova kojima niko u timu više ne veruje;

• Infrastrukturni dug (Infrastructure Debt): Zastareli serveri, ručni koraci pri puštanju u rad i nesinhronizovana konfiguracija okruženja;

• Dug zavisnosti (Dependency Debt): Zastarele biblioteke i razvojni okviri koji godinama nisu ažurirani;

• Bezbednosni dug (Security Debt): Poznate ranjivosti čije se rešavanje uporno odlaže zarad novih funkcionalnosti;

• Dokumentacioni dug (Documentation Debt): Ključne arhitektonske odluke i integracije nisu nigde zabeležene;

• Podatkovni dug (Data Debt): Neusaglašeni modeli baze, gomilanje duplikata i nejasno vlasništvo nad podacima;

• Dug znanja (Knowledge Debt): Znanje o radu kritičnih delova sistema koncentrisano je u glavi samo jedne osobe.

„Samo Milan zna kako to radi“ jeste ozbiljan tehnički dug

Ako organizacija zavisi od jednog čoveka za isporuku koda, rešavanje produkcionih incidenata ili razumevanje integracija, stvoren je pojedinačni faktor rizika (Single Point of Failure). Samo što u ovom slučaju to nije server koji može da otkaže, već čovek koji može da promeni posao ili ode na odmor.

Tehnički dug se ovde direktno pretvara u organizacioni rizik. Na ITNetwork-u smo u tekstu „Zašto Agile transformacije propadaju: organizacioni, tehnološki i ljudski faktori“ već detaljno analizirali ovaj problem: možete formalno imati sve agilne ceremonije i sastanke, ali ako su arhitektura, zavisnosti i procesi isporuke loše postavljeni, brzina tima ne može pobediti zakone inženjerske fizike.

Kako prepoznati da kamata na dug ubrzano raste?

Nisu vam uvek potrebne komplikovane metrike – dovoljno je pažljivo poslušati svakodnevne razgovore unutar tima:

• „Taj fajl radije ne diraj.“

• „Ako promenimo ovu funkciju, ko zna šta će sve pasti u produkciji.“

• „Testovi ponovo nasumično padaju, samo pokreni build još jednom.“

• „Moraćemo prvo da ažuriramo osnovni radni okvir, a za to nemamo vremena.“

• „Ova promena deluje jednostavno, ali naš sistem to trenutno ne podržava lako.“

Kada bezazleni poslovni zahtevi redovno nailaze na ovaj poslednji odgovor, tehnički dug je već postao dominantna poslovna prepreka.

Brzina tima može izgledati odlično dok sistem tiho propada

Fokusiranje isključivo na brzinu prelaska zadataka kroz sprint (velocity) može biti varljivo. Tim može mesecima da održava privid visoke produktivnosti tako što postepeno smanjuje obim posla po zadatku, zaobilazi čišćenje koda, dodaje brze zakrpe i stalno povećava procene težine posla.

Grafikon u menadžerskom izveštaju ostaje zelen, ali vreme od ideje do stabilne isporuke (lead time) neprekidno raste. Broj prijavljenih grešaka se uvećava, pregledi koda traju duže, a uvođenje novih članova u tim postaje presporo. Zato pitanje „koliko smo poena zatvorili u sprintu“ vredi znatno manje od pitanja: da li nas ista vrsta promene danas košta više vremena nego pre godinu dana?

Najbolja metrika tehničkog duga jeste cena promene

Umesto da se gubite u pojedinačnim inženjerskim merenjima, posmatrajte praktične indikatore:

1. Vreme ciklusa (Cycle Time) i vreme realizacije (Lead Time): Koliko dana prolazi od prve linije koda do stabilnog rada u produkciji?

2. Učestalost neuspelih izmena (Change Failure Rate): Koliki procenat novih isporuka dovodi do grešaka?

3. Učestalost i težina incidenata: Koliko se često javljaju prekidi servisa?

4. Vreme sklapanja i testiranja aplikacije (Build Time): Da li provera promena traje minutima ili satima?

5. Vreme prilagođavanja novih inženjera: Koliko nedelja je potrebno novom članu tima da samostalno i bezbedno izmeni modul?

Tehnički dug postaje strateški problem onog trenutka kada počne direktno da guši agilnost kompanije.

Nije svaki nasleđeni sistem automatski tehnički dug

Stari kod nije po definiciji loš kod. Stabilna interna aplikacija napisana pre deset godina, koja pouzdano obavlja svoju funkciju, retko zahteva promene i zadovoljava potrebe posla, ne mora se prepisivati samo zato što je u međuvremenu izašao noviji tehnološki okvir.

Dug postoji onda kada tehničko rešenje stvara stvarni budući trošak, rizik ili usko grlo. Pokretanje prepisivanja stabilnog sistema samo radi prelaska na moderniju tehnologiju često je najskuplji način da stvorite potpuno novi tehnički dug.

Pisanje sistema ispočetka često je najskuplje bežanje od problema

Ideja da se postojeći sistem jednostavno „baci i napiše ispočetka“ zvuči primamljivo, ali krije ogromne zamke. Stari sistem u sebi nosi godine rešavanja specifičnih graničnih slučajeva, skrivena poslovna pravila i integracije koje niko nije detaljno popisao.

U praksi se često dešava da novi projekat traje godinama, dok stari sistem i dalje mora da se održava paralelno. Rezultat je dvostruki trošak i dvostruki tehnički dug. Mnogo zreliji pristup jeste postepena modernizacija – kroz razbijanje na manje module i primenu proverenih obrazaca poput Strangler pristupa, gde novi servisi postepeno preuzimaju delove starog sistema.

Refaktorisanje nije jednokratni projekat već svakodnevna higijena

Pokušaj da se petogodišnje gomilanje prečica reši tako što će se proglasiti šestomesečni „projekat čišćenja tehničkog duga“ tokom koga se ne isporučuje ništa novo za klijente, gotovo uvek doživljava neuspeh. Menadžment brzo gubi strpljenje, projekat se prekida na pola, a sistem ostaje u još gorem međustanju.

Refaktorisanje funkcioniše onda kada je sastavni deo svakodnevnog rada: svaki put kada inženjer menja modul, dužan je da ga ostavi u malo boljem stanju nego što ga je zatekao – da doda nedostajući test, ukloni zastareli kod i poboljša jasnoću funkcija. Kontinuirana otplata je jedini održiv model.

Pravilo od 20% sprinta za tehnički dug zvuči lepo, ali nije univerzalno

Savet da se ravno petina svakog sprinta posveti tehničkom dugu jeste dobra polazna osnova, ali ne može biti kruto pravilo.

Ako je produkcija nestabilna i incidenti se ređaju svakodnevno, možda je neophodno privremeno usmeriti i 60% kapaciteta na sanaciju temelja. Sa druge strane, u ranoj fazi testiranja novog koncepta koji možda neće preživeti sledeći mesec, taj procenat može biti minimalan. Od fiksnih brojeva važnije je da tehnički dug bude jasno vidljiv u istom razvojnom planu sa novim funkcionalnostima, kako bi inženjerski i poslovni deo tima zajednički donosili odluke o prioritetima.

Product Owner mora razumeti cenu neplaćanja duga

Razgovor o tehničkom dugu ne sme se voditi na nivou apstraktnih inženjerskih želja:

• Loša komunikacija: „Treba nam ceo sprint za refaktorisanje jer nam se ne dopada arhitektura ovog modula.“

• Dobra komunikacija: „Ovaj servis učestvuje u 40% svih novih izmena. Prosečno vreme za isporuku zadatka u njemu poraslo je sa dva na pet dana, a u poslednja tri meseca izazvao je četiri zastoja u produkciji. Ako uložimo pet dana u razdvajanje odgovornosti i testove, sledećih šest planiranih funkcionalnosti isporučićemo duplo brže i bezbednije.“

Tada tema više nije inženjerska estetika naspram poslovnih želja, već kratkoročno ulaganje zarad dugoročne operativne brzine celog tima.

Tehnički dug mora imati vlasnika, razlog i rok

Kada svesno donosite odluku o tehničkom kompromisu, zabeležite je kroz jednostavan arhitektonski zapis (Architecture Decision Record – ADR):

• Odluka: Koristimo jednostavnu sinhronu obradu podataka;

• Razlog: MVP faza i mali očekivani početni saobraćaj;

• Rizik: Moguće zagušenje baze pri većem opterećenju;

• Okidač za promenu: Saobraćaj prelazi 5.000 zahteva u minuti;

• Plan sanacije: Prelazak na asinhronu obradu preko reda poruka.

Na ovaj način dugom aktivno upravljate, umesto da se prepuštate stihiji. Lista tehničkog duga koju niko mesecima ne otvara nije upravljanje resursima, već groblje zaboravljenih kompromisa.

Retrospektiva mora obuhvatiti i zdravlje koda, a ne samo procese

Retrospektive agilnih timova često se svedu na analizu međuljudske komunikacije i efikasnosti sastanaka. Iako su to važne teme, tim periodično mora postaviti i tehnička pitanja:

• Šta nam je tokom ovog sprinta bilo nepotrebno komplikovano za izmenu?

• Gde smo morali da pravimo zaobilazna rešenja da ne bismo polomili postojeći kod?

• Koji delovi sistema nas najviše usporavaju?

• Koji testovi nam ulivaju sumnju umesto sigurnosti?

Retrospektiva je mehanizam za pregled celokupnog inženjerskog ekosistema, a ne samo procesnih tabli.

Definicija završenog posla kao prva linija odbrane

Ako pojam „završenog posla“ (Done) u timu znači samo to da kod radi na računaru programera koji ga je napisao, tehnički dug je praktično ugrađen u sam proces rada.

Kada definicija završenog podrazumeva da je kod prošao stručni pregled kolega, da su automatski testovi napisani i uspešno izvršeni, bezbednosne provere zadovoljene, a dokumentacija ažurirana, prostor za tiho taloženje duga svodi se na minimum. U kombinaciji sa kontinuiranom integracijom (CI), gde se svaka promena automatski proverava više puta dnevno, problemi se otkrivaju dok su još mali i izuzetno jeftini za rešavanje.

Arhitektura je najskuplji oblik tehničkog duga

Loše napisanu funkciju lako je prepraviti. Loše postavljenu granicu između deset servisa znatno je teže i skuplje ispraviti.

Arhitektonski dug diktira koliko timova mora međusobno da koordinira pre svake izmene, koliko se servisa mora puštati u rad istovremeno i ko sme šta da menja. Kada kompanija želi autonomne timove, a arhitektura sistema zahteva strogu centralnu kontrolu svake izmene, problem se ne može rešiti uvođenjem agilnih ceremonija. Arhitektura koda mora pratiti organizacionu strukturu.

Kada tehnički dug postane paravan za puke želje developera

Potrebno je biti objektivan: inženjerski timovi ponekad koriste izraz tehnički dug kao izgovor za prelazak na tehnologije koje su im lično zanimljivije za učenje:

• „Moramo preći na mikroservise jer je monolit zastareo.“

• „Zašto?“

• „Zato što je to savremeniji pristup.“

To nije poslovno opravdanje. Ako monolitna aplikacija radi stabilno i brzo, prelazak na mikroservise bez realne potrebe može samo uneti dodatnu mrežnu kompleksnost, komplikovane distribuirane transakcije i znatno veće troškove održavanja. Prioritet sanacije duga uvek se mora voditi frekvencijom poslovnih promena i stvarnim rizikom: loš kod u delu aplikacije koji niko ne dira nije prioritet; umereno problematičan kod u modulu koji se menja svake nedelje mora biti saniran odmah.

Veštačka inteligencija dodatno zaoštrava problem duga

Do skora je postojala prirodna fizička kočnica gomilanju koda: čovek je morao ručno da napiše svaki red. Pojava savremenih AI alata za generisanje koda tu kočnicu je u potpunosti uklonila.

Danas jedan programer uz pomoć AI asistenata može izbaciti višestruko više linija koda, konfiguracionih fajlova i skripti. Međutim, veća količina napisanog koda više ne znači i bolje razumevanje sistema.

Na ITNetwork-u smo u analizi posvećenoj konceptu „Vibe Coding i Agile: nova paradigma razvoja ili novi izvor tehničkog duga?“ detaljno obradili pojavu duga razumevanja (Comprehension Debt): sistem spolja radi i prolazi osnovne provere, ali inženjeri više nemaju duboko razumevanje zašto je arhitektura postavljena na određeni način niti kakve skrivene zavisnosti postoje u generisanom kodu.

Kada se tome doda rizik kognitivnog izmeštanja – o čemu smo pisali u tekstu o primeni agentskih AI sistema i agilnog pristupa – organizacija može postati potpuno zavisna od softvera koji njeni sopstveni inženjeri više nisu u stanju samostalno da održe i modifikuju.

AI kao alat za otplatu duga – pod uslovom da se koristi promišljeno

Sa druge strane, veštačka inteligencija donosi izuzetne mogućnosti kada se koristi sa jasnim ciljem:

• Brzo analiziranje i dokumentovanje nasleđenog koda;

• Pronalaženje dupliranih segmenata u velikim bazama koda;

• Pisanje osnovnih jedinica testova za module koji ih nikada nisu imali;

• Pomoć pri rutinskom refaktorisku i migracijama verzija.

Ipak, test koji je generisala mašina nije sam po sebi dokaz ispravnosti. Ako model pogrešno razume poslovni zahtev, napiše pogrešan kod i zatim napravi test koji samo potvrđuje tu istu grešku, dobijate lažni osećaj sigurnosti. Automatizacija nikada ne može biti zamena za profesionalno inženjersko prosuđivanje.

Primer veb sistema: ista ekonomija na nivou portala i aplikacija

Isti principi važe i na nivou veb portala i platformi za upravljanje sadržajem. Često se odlaže ažuriranje osnovnog sistema, radno okruženje ostaje na zastarelim verzijama, a svaki problem sa brzinom privremeno se „krpi“ instaliranjem još jednog dodatnog plugina.

Sve deluje mirno dok jedna bezbednosna zakrpa ili prinudna nadogradnja ne izazove lančani pad funkcionalnosti. Joombooz upravo kod usluge redovnog održavanja sajtova naglašava kontinuiranu bezbednost, redovna ažuriranja i prevenciju kao osnovni posao, jer se svako odlaganje održavanja pre ili kasnije pretvara u znatno skuplji krizni projekat. To je klasičan primer upravljanja tehničkim dugom u praksi.

Kada treba povući ručnu i privremeno zaustaviti nove funkcionalnosti?

Ne postoji matematička formula, ali postoje jasni signali kada je sanacija temelja postala neodložna:

1. Kada uobičajene i male izmene postanu nepredvidivo skupe i spore;

2. Kada procenat neuspelih isporuka naglo raste i incidenti u produkciji postanu redovna pojava;

3. Kada razvojni okviri ili zavisnosti izgube bezbednosnu podršku proizvođača;

4. Kada ključno znanje o funkcionisanju sistema drži samo jedna osoba;

5. Kada sledeći strateški cilj kompanije fizički ne može da se izgradi na postojećim temeljima.

U tim situacijama pitanje više nije koliko košta sanacija, već koliko kompaniju košta ako ništa ne preduzme. Ako neulaganje u arhitekturu znači da će narednih deset poslovnih funkcionalnosti koštati 30% više i kasniti mesecima, svako dalje odlaganje predstavlja direktan poslovni gubitak.

Prava brzina je maraton, a ne sprint u jednom dahu

Najbolje tehnološke kompanije ne teže nultom dugu, jer je takav cilj u realnom poslovanju nerealan i često kontraproduktivan. Cilj je imati kontrolisan i svesno vođen dug, baš kao što uspešna preduzeća koriste finansijske kredite za strateški rast.

Prava agilnost ne meri se time koliko ste brzo izbacili prvu verziju na tržište, već koliko dugo i stabilno možete da nastavite da isporučujete vrednost iz meseca u mesec. Tim koji danas napravi novu funkciju za tri dana, a za godinu dana mu za sličnu sitnicu trebaju tri naporne nedelje, nije bio brz – samo je pozajmio prividnu brzinu od sopstvene budućnosti.

Često postavljana pitanja o tehničkom dugu u agilnom razvoju

Šta je tehnički dug?

Tehnički dug predstavlja budući trošak, rizik ili tehničko ograničenje koje nastaje usled svesnih inženjerskih prečica radi brže isporuke, ili usled postepenog opadanja kvaliteta sistema tokom vremena.

Da li je svaki tehnički dug loš?

Ne. Svesno i kontrolisano preuzimanje duga može biti potpuno opravdana poslovna odluka kada omogućava bržu proveru tržišne hipoteze ili raniji izlazak proizvoda na tržište.

Ko je tvorac termina Technical Debt?

Pojam je početkom devedesetih godina uveo Ward Cunningham, dok su ga autori poput Martina Fowlera kasnije razvili u precizne modele za analizu softverskog razvoja.

Šta predstavlja Fowlerov kvadrant tehničkog duga?

To je model koji tehnički dug posmatra kroz dve ose: nameran naspram nenamernog, te promišljen naspram nepromišljenog duga.

Da li loš kod automatski znači tehnički dug?

Ne nužno. Loš kod u delu sistema koji je stabilan i nikada se više ne menja ima minimalan stvarni poslovni uticaj, dok osrednji kod u modulu koji se menja svakodnevno generiše visoke troškove.

Zašto agilni timovi često nagomilavaju tehnički dug?

Najčešći uzroci su preterani pritisak na rokove, jednostran fokus na korisnički interfejs, labava definicija završenog posla i stalno odlaganje inženjerske higijene.

Da li Scrum zahteva posebne sprintove posvećene dugu?

Ne. Tehnički dug treba da se rešava kontinuirano kao sastavni deo redovnog razvojnog plana, a ne kroz sporadične i vanredne projekte.

Koliko vremena treba odvojiti za vraćanje tehničkog duga?

Ne postoji univerzalno pravilo. Potreban kapacitet zavisi od stabilnosti produkcije, starosti sistema i planiranih poslovnih koraka.

Kako se tehnički dug meri u praksi?

Najbolje kroz operativne pokazatelje kao što su vreme realizacije izmene (Lead Time), vreme ciklusa (Cycle Time), učestalost produkcionih grešaka i vreme potrebno za uvođenje novih programera u rad.

Šta je arhitektonski dug?

To je stanje u kome sama struktura softverskih servisa više ne podržava efikasno skaliranje niti organizacioni model timova, pa svaka promena traži složenu koordinaciju.

Šta je dug razumevanja (Comprehension Debt)?

To je situacija u kojoj sistem funkcioniše, ali tim usled prevelikog oslanjanja na generisani kod više nema suštinsko razumevanje kako rešenje radi i gde leže skrivene zavisnosti.

Da li je nasleđeni sistem (Legacy) isto što i tehnički dug?

Nije. Stari softver koji godinama radi stabilno, ne kvari se i ne koči poslovne procese ne predstavlja nužno tehnički dug.

Ko treba da odlučuje o prioritetu rešavanja duga?

Inženjerski tim predočava rizike i tehničke posledice, dok nosioci proizvoda (Product Owners) i menadžment učestvuju u rangiranju prioriteta, jer ulaganje inženjerskog vremena uvek predstavlja stratešku poslovnu odluku.