User:Hrus07

Technický dluh je dnes neodmyslitelnou součástí softwarového vývoje. Vzniká v důsledku různých důvodu (tlak na rychlost dodání, neoptimální řešení, používání zkratek a zanedbání architektury). Tento dluh se časem akumuluje a projevuje se v podobě nárůstu úsilí nutného k úpravám, údržbě ale ovlivňuje i další vývoj. Čím větší dluh, tím větší dopad na produktivitu týmu. Projekt se zpomaluje a dále zvyšuje celkové náklady.

Definice problému

Aplikace, o kterou se starám vznikla jako demovací nástroj. S průběhem času se vyvinula do plnohodnotného projektu a její rozšiřování naráží na technologický dluh. Začínáme tedy s již existencí defektů, ke kterému se přidává backlog nových funkcionalit. Stavu nepomáhá omezená velikost týmu, zdrojů a talk od vedení.

Metoda

Pro simulaci byla zvolena metoda systémové dynamiky, která je vhodná pro modelování zpětných vazeb a kumulativních efektů v časově proměnných systémech. Model byl vytvořen v nástroji Vensim.

Model

Model reprezentuje reálný případ z praxe. Kde dochází k interakci mezi backlogem, technickým dluhem, produktivitou a strategiemi řízení dluhu.

Míra využití zkratek se pohybuje kolem 4 z 10 případů. Backlog v tomto momentu má přes 80 hodin na jednotlivých požadavcích. A taky v tomto momentu už máme vedle backlogu kolem 30 hodin přirazených na refaktoring z důvodu neoptimálních řešení. Projekt je koncipován pro 2 aktivní developery s možností rozšíření na 6 lidí. Míra nově příchozích požadavcích je simulována normálovým rozdělením, tasky chodí pravidelně na týdenní bázi no pro jednoduchost jsme upravili logiku a denně se generuje v průměru 6 hodin práce. V tomto modelu jsme zanedbali svátků a jiných nepracovních dnů. Jelikož na projektu pracují převážně studenti, uvažujeme produktivitu 50 %.

Pro CLD jsme si identifikovali tři důležité kauzální slučky:

R1 – Růst dluhu: Tlak na rychlé dodání zvyšuje míru zkratek, což vede k rychlejší akumulaci technického dluhu, ten snižuje produktivitu, což vede k pomalejšímu dodání a opětovnému nárůstu tlaku.

R2 – Ztráta morálky: Nárůstem dluhu se zvyšuje frustrace a ztráta morálky týmu, což má negativní dopad na produktivitu a znovu zvyšuje backlog a dluh.

B1 – Refaktoring: Pokud dochází k refaktoringu, může dojít k redukci technického dluhu a obnovení části ztracené produktivity.

SFD model obsahuje následující: Proměnné v modelu: • Počáteční backlog (hodinově) • Počáteční dłuh • Velikost týmu (počet developerů) • Základní produktivita • Míra zkratek (neboli nátlak vedení, protože alibisticky počítáme s poctivostí developera) • Podíl času na refaktoring • Efektivita refaktoringu • Dopad dluhu na produktivitu • Nové požadavky (generovány s malou stochastickou variabilitou)

Výsledky

Prvotní simulace se spoléhali na konstantní alokaci času na refaktoring kterou je zákazník ochoten zaplatit kolem 10 %. Tato míra pomáhá udržet duh pod kontrolou, ale dlohodobě nedokáže dluh zastavit. Reaktivní strategie (refaktoring, když duh dosáhne určité úrovně) se ukazuje jako efektivnější v rovnováze mezi krátkodobou produktivitou a dlouhodobou udržitelností vývoje. Proto dále uvažujme jen výsledky s dynamickou mírou alokovaného času pro refaktoring.

Simulace jednoho roku projektu z počátečního stavu by nebyla zvládnutelná a by bylo odpracováno méně než 8 hodin. 1 student by na konci roku efektivně zvládl odpracovat 2 hodiny na projektu a 1.5 hodiny na refaktoringu.

Optimalizací počtu developerů jsme zjistili, že 3 studenti jsou optimální počet pro udržení 8 hodin práce na projektu a 3 hodin na refaktoringu, přičemž dodání práce nekolísá a dluh se zmenšuje. Přičemž studenti můžou být pohodlně nahrazeni 2 zaměstnanci na plný úvazek.

Dle předpokladu, vyšší optimalizace získáme jen za předpokladu snížení tlaku a tedy míry zkratek které zaměstnanci použijí. Optimální řešení je 20 % využití zkratek s 2 zaměstnanci na plný úvazek. Při kterém získáme 12.4 hodin práce na projektu místo 8 s nulovou mírou využívání zkratek.

Závěr

Model potvrzuje, že řízení technického dluhu je klíčové pro udržitelný vývoj software. Projektoví manažeři a stakeholdeři mohou pomocí simulace pochopit důsledky různých rozhodnutí a lépe prioritizovat mezi rychlostí dodání a kvalitou kódu. Zkratky dokážou přinést bonus k produktivitě no musí být správně ošetřeny a zkratky nesmí překročit hranici, v našem konkrétním případu 20 %. Refaktoring není luxus, ale nezbytný nástroj k zabránění kolapsu produktivity.

Data

Po konzultaci s vedením jsem dosal povolení pro využití produkčních dat na méně důležitém projektu a kombinoval je s informacemi z odborní literatury.

• GUPTA, Kartik, 2025. Measuring the Impact of Technical Debt on Development Effort in Software Projects. arXiv [online]. [cit. 2025-05-12]. Dostupné z: https://arxiv.org/abs/2502.16277

• YLI-HUUMO, Jesse, Andrey MAGLYAS a Kari SMOLANDER, 2016. How do software development teams manage technical debt? – An empirical study. Dostupné z: doi:https://doi.org/10.1016/j.jss.2016.05.018

• TOM, Edith, Aybüke AURUM a Richard VIDGEN, 2013. An exploration of technical debt. Journal of Systems and Software. 86(6), 1498–1516. Dostupné z: doi:https://doi.org/10.1016/j.jss.2012.12.052

• HOLVITIE, Johannes, Sherlock A. LICORISH, Rodrigo O. SPÍNOLA, Sami HYRYNSALMI, Stephen G. MACDONELL, Thiago S. MENDES, Jim BUCHAN a Ville LEPPÄNEN, 2018. Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology. 96, 141–160. Dostupné z: doi:https://doi.org/10.1016/j.infsof.2017.11.015

• Wierzchanowski G. and Jackiewicz M. Web Article: The complete guide to technical debt management: best practices for future proofing your new apps. Dostupné z: https://www.rst.software/blog/technical-debt-management

Jiné pomocné materiály Feedback loops: System Dynamics: Exploring System Dynamics in Feedback Loops [1]

Technical debt quantification financial analysis: [2]

Kód

File:Hrus07.mdl

(01) Akumulace dluhu=Míra zkratek * Dodana prace

   Units: Hour

(02) Backlog= INTEG (MAX(Nové požadavky - Dodana prace, 0), Počáteční backlog)

   Units: Hour

(03) Čas na Refaktoring=Produktivita * Podil refaktoru

   Units: Hour

(04) Developeři=1 + INTEGER ((Backlog + Dluh) / 160)

   Units: Dmnl [1,20,1]

(05) Dluh= INTEG (Akumulace dluhu-Refaktoring, Počáteční dluh)

   Units: Hour

(06) Dodana prace=Produktivita * ( 1 - Podil refaktoru)

   Units: Hour

(07) Dopad Dluhu=1 / (1 + EXP((Dluh - 50) / 10))

   Units: Dmnl

(08) Efektivita Refaktoringu=0.6

   Units: Dmnl [0,1,0.01]

(09) FINAL TIME = 365

   Units: Day
   The final time for the simulation.

(10) INITIAL TIME = 0

   Units: Day
   The initial time for the simulation.

(11) Míra zkratek=0.4

   Units: Dmnl [0,1,0.01]

(12) Nové požadavky=RANDOM NORMAL(4, 10, 6, 2, 12345)

   Units: Hour

(13) Počáteční backlog=80

   Units: Hour [0,500,8]

(14) Počáteční dluh=30

   Units: Hour [0,500,8]

(15) Podil refaktoru=MIN(1, Dluh / 150 + 0.2 * (Backlog / 200))

   Units: Hour

(16) Produktivita=Developeři * 8 * Základní produktivita * (1 + 0.35 * Míra zkratek) * Dopad Dluhu

   Units: Hour

(17) Refaktoring=Čas na Refaktoring * Efektivita Refaktoringu

   Units: Hour

(18) SAVEPER =

      TIME STEP 
   Units: Day [0,?]
   The frequency with which output is stored.

(19) TIME STEP = 1

   Units: Day [0,?]
   The time step for the simulation.

(20) Základní produktivita=0.5

   Units: Dmnl [0,1,0.01]