|
|
| Line 1: |
Line 1: |
| − | 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.
| |
| − |
| |
| − | [[File:Hrus07_01.png]]
| |
| − |
| |
| − | '''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)
| |
| − |
| |
| − |
| |
| − | [[File:Hrus07_02.png]]
| |
| − |
| |
| − | =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 [https://www.fastercapital.com/content/Feedback-loops--System-Dynamics--Exploring-System-Dynamics-in-Feedback-Loops.html]
| |
| − |
| |
| − | Technical debt quantification financial analysis: [https://fullscale.io/blog/technical-debt-quantification-financial-analysis/]
| |
| − |
| |
| − |
| |
| − | =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]
| |
