Technológiai adósság: minden, amit tudni érdemes
A technológiai adósság megfelelő kezelése jelentheti a különbséget a sikeres és a sikertelen szoftverprojekt között. Figyelmen kívül hagyása vagy fel nem ismerése magasabb fejlesztési költségekhez és alacsony pénzügyi megtérüléshez vezethet. De mit is takar pontosan a technológiai adósság? Hogyan keletkezik és milyen fajtái vannak? Cikkünkben most ezeket mutatjuk be részletesen.
Mi az a technológiai adósság?
A szoftveriparban a technológiai adósság egy mindennapos kifejezésnek számít, amit olykor szoktak technikai adósságnak, tervezési adósságnak vagy kódadósságnak is nevezni. Egy gyűjtőfogalomról van szó, amely a hibáktól kezdve az örökölt kódon át a hiányzó dokumentációig mindent lefed.
A technológiai adósság minőségi hiányosságot jelent, amely minden fejlesztésnél keletkezik és a fenntarthatóságot nehezíti. Hosszú távon növeli a karbantartási, üzemeltetési és módosítási költségeket. Fenntartható termékek fejlesztése esetén ezért fontos explicit időt szánni a technológiai adósság kezelésére.
Honnan származik a technológiai adósság kifejezés?
A technológiai adósság terminológiát egy szoftverfejlesztő, Ward Cunningham alkotta meg, aki amellett, hogy az Agilis Kiáltvány 17 szerzőjének egyike, a wiki feltalálójának is tulajdonítják. Ő használta először ezt a metaforát, hogy a WyCash-nél a nem műszaki érdekelteknek elmagyarázza, miért szükséges a költségvetésbe erőforrásokat betervezni a refaktorálásra.
Ezzel egyúttal egy új divatos frázist alkotott a szoftveres közösségben, ami később számtalan tanulmány, vita és panelbeszélgetés tárgya lett.
A technológiai adósság különböző értelmezései
A technológiai adósság definícióját az évek során különbözőképpen fogalmazták meg. Nézzünk most meg néhányat ezek közül!
A technológiai adósság egy eszköz
Hasonlóan ahhoz, ahogyan valaki hitelt vesz fel egy ingatlanra, hogy a fellendülő ingatlanpiacra bejusson, a technológiai adósságot is gyakran használják eszközként az előrejutáshoz.
Trey Huffine, a Gitconnected alapítója például egy startup szemszögéből magyarázza el a szerepét. Úgy fogalmaz, hogy a technológiai adósság minden olyan kód, amelyet most adunk hozzá a gyors nyereség elérése céljából, és amelynek kijavítása később több munkát igényel.
A technológiai adósságnak következményei vannak
Shaun McCormick definíciója a technológiai adósságról inkább a hosszú távú következményekre összpontosít. A technológiai adósságot olyan kódnak tekinti, amely csökkenti az agilitást a projekt előrehaladása során. Ugyanakkor nem használja a rossz vagy törött kód kifejezést.
Azt javasolja, hogy a valódi technológiai adósság mindig legyen szándékosés sose véletlenszerű.
Mint mondja, a technológiai adósság akkor jön létre, amikor a fejlesztők rövidítéseket alkalmaznak, hogy gyorsabban elérjék a célt, mindez azonban egy nehezebben karbantartható kód árán történik.
Gaminer megfogalmazása szerint a technológiai adósság olyan, mintha kölcsönt vennénk fel. Tehát segítségével többet érhetünk el, mint normális esetben, hosszú távon azonban magasabb költségeket kell megfizetnünk.
A technológiai adósság fajtái
Ahogy a technológiai adósságnak számos definíciója létezik, ugyanígy különböző szakemberek más-más kategóriákat határoznak meg ezen belül.
- 2007-ben Steve McConnell a technológiai adósság 2 típusáról beszélt:
I. Szándékos – Olyan adósság, amelyet valaki tudatosan, stratégiai eszközként vállal.
II. Nem szándékos – Ez a rossz munka és nem a stratégia eredménye.
- Martin Fowler továbbgondolta McConnell koncepcióját és 4 kategóriát alkotott:
1.Szándékos és meggondolatlan – Leggyakoribb oka, hogy stratégiailag a gyors átadást helyezik előtérbe a jól megtervezett fejlesztési folyamattal szemben.
PÉLDA: A csapat úgy dönt, hogy nincs elég ideje, és szándékosan csökkenti a termék jellemzőit. Nem is tervezi a pótlásukat, és a sebességet a minőség elé helyezi. Vagy a projekt során leredukálják a kódolásra fordított időt azáltal, hogy kevesebb időt adnak a fejlesztőknek, ami nem megfelelő kódolást eredményez.
2. Szándékos és körültekintő – Ebben az esetben a csapat tisztában van a technológiai adósság generálásával, ennek ellenére továbbhalad. A csapat a kezdetektől fogva pontosan látja a következményeket, tudja, hogy szükség lesz a legjobb gyakorlatok újbóli áttekintésére és alkalmazására, ha egyszer lesz rá idő.
3.Nem szándékos és meggondolatlan – Ez a technológiai adósságok legkárosabb típusa. Akkor fordul elő, amikor a szoftverfejlesztő csapat nem alkalmazza a legjobb gyakorlatokat, és nem tudja, hogy technológiai adósság halmozódik fel. Ez lehetetlenné teszi a megoldások megtervezését vagy az adósság negatív hatásának mérését.
PÉLDA: Előfordul, hogy bizonyos csapattagok nem rendelkeznek a szoftver kódjának megírásához szükséges készségekkel. Ennek ellenére felhatalmazást kapnak arra hogy dolgozzanak rajta. Miközben kódolnak, technológiai adósságot generálnak és halmoznak fel. A fejlesztők a készségek hiánya miatt nincsenek is tisztában azzal, hogy milyen kárt okoznak a projektnek, így nem tudnak körültekintően eljárni.
4. Nem szándékos és körültekintő – A csapat ilyenkor egy szoftverfejlesztési ütemterv minden lépésénél alkalmazza a legjobb gyakorlatokat, de valamilyen okból mégis technológiai adósság generálódik, amit a szakemberek képesek kezelni.
PÉLDA: Ebben az esetben egy hozzáértő csapat dolgozik a szoftver kódján, ugyanakkor a technológiai adósság egy nem látható kódolási hiba miatt keletkezik. Képességeiknek köszönhetően a szakemberek képesek ezt azonosítani és megfizetni.
- 2014-ben egy akadémikusokból álló csoport megállapította, hogy a technológiai adósság kategorizálására szolgáló meglévő keretek nem foglalkoznak közvetlenül az adósság konkrét természetével.
Egyúttal elutasították a McConnell és Fowler által felvázolt kategóriákat, és azt javasolták, hogy a technológiai adósságot a jellege alapján osztályozzák, és ne aszerint, hogy azok stratégiai vagy nem stratégiai jellegűek.
Az ennek eredményeként született dokumentum szerint, amelyet a Software Engineering Institute “Towards an Ontology of Terms on Technical Debt” (A technológiai adósság fogalmainak ontológiája felé) címmel tettek közzé, a technológiai adósság 13 különböző típusáról beszélnek. Ezek mindegyikéhez kulcsfontosságú mutatókat határoznak meg:
- Építészeti adósság
- Építési adósság
- Kódadósság
- Hibaadósság
- Tervezési adósság
- Dokumentációs adósság
- Infrastruktúra adósság
- Emberi adósság
- Folyamat adósság
- Követelmény adósság
- Szolgáltatás adósság
- Tesztautomatizálási adósság
- Tesztadósság
Mi lehet a technológiai adósság oka?
Egy projekt során sokféleképpen halmozódhat fel technológiai adósság, nézzünk most meg ezek közül néhányat!
#1. ok: A tervezés hiánya
Amennyiben időmegtakarítás céljából a projekttervezés befejezése előtt kezdődik a fejlesztés, akkor nagy valószínűséggel később vissza kell térni egyes elemekhez és át kell dolgozni azokat.
#2. ok: Külső erők
Ilyen lehet például az üzleti nyomás. Gyakran fordul elő, hogy a piac vagy az üzleti vezetők azt várják el, hogy a termék minél hamarabb közönség elé kerüljön, még abban az esetben is, ha nem készült el az összes szükséges változtatás. Ez meglehetősen gyakori a termékmenedzsment területén.
#3. ok: Tudatlanság
Ha a projektmenedzser és a projektcsapat nem ismeri a technológiai adósságot, akkor szinte biztosan szembe találják vele magukat. Ha olyan folyamatot követnek, amely nem veszi figyelembe ennek következményeit, akkor a projektet érintő eredendő kockázatok ismerete nélkül haladnak előre.
#4. ok: A rugalmasság hiánya
A rugalmasságra és a változtatásra való képtelenség szintén technológiai adóssághoz vezet. A vezetők esetében elengedhetetlen a flexibilitás.
#5. ok: Nem megfelelő dokumentáció
Amennyiben nem készül el a megfelelő dokumentáció a projekt folyamán, az olyan technológiai adósságot eredményez, amelyet később meg kell majd fizetni.
#6. ok: Az együttműködés hiánya
A projekt csapaton belüli tudásmegosztás hiánya befolyásolja a hatékonyságot, ami technológiai adósságot teremt. Az online kollaborációs eszközök használata segíthet a kulcsfontosságú információk cseréjének javításában.
#7. ok: Párhuzamos projektek
A párhuzamos fejlesztések szintén adósságot okozhatnak, mivel a változtatások egyetlen forrásba történő egyesítéséhez szükséges munka többlet energiát kíván.
#8. ok: A követelmények módosítása
Ha egy projekt követelményei megváltoznak, az szintén technológiai adósságot okoz.
#9. ok: Az iparági szabványok elhanyagolása
Ezek figyelmen kívül hagyása szintén jó példája a technológiai adósság halmozásának, amire a későbbiekben biztosan figyelmet kell fordítani a projekt során.
#10. ok: Gyenge vezetés
A felelősségvállalás hiányától kezdve a rossz vezetésen át az utolsó pillanatban végrehajtott változtatásokig, minden oka lehet az adósság generálásnak.
A technológiai adósság minden esetben rossz?
Ha egyszerűen szeretnénk válaszolni erre a kérdésre, akkor a technológiai adósság nem jó, és nem rossz. De adósság.
A legtöbb szoftvercéget manapság a piaci verseny arra kényszeríti, hogy rövid idő alatt fejlesszen és szállítson. A startupok különösen érzik annak súlyát, hogy minél gyorsabban képesek legyenek előállni a termékkel. Ez a nyomás pedig sok termék- és szoftverfejlesztő csapatot arra ösztönöz, hogy kompromisszumot kössön a technológiai adósság bevállalása kapcsán.
Agilis projektmenedzsment vs. vízesés modell
Az agilis csapatok vélekedése szerint a technológiai adósság nem eleve rossz. Valójában a legtöbb – ha nem minden szoftvertermékben van – valamilyen mértékű technológiai adósság.
Ha figyelembe vesszük, hogy a csapatok mennyi kódot szállítanak naponta – különösen agilis környezetben, ahol a működő szoftver a haladás elsődleges mércéje -, ez nem meglepő állítás.
Ugyanakkor a vízeséses módszertan és más dokumentáció vezérelt keretrendszerek szerint dolgozó szoftverfejlesztő csapatok nem osztják ezt a szemléletet.
A technológiai adóssággal kapcsolatos hozzáállás nem csak a vállalati filozófiától, hanem az egyes részlegektől és szerepköröktől függően is nagymértékben eltérhet.
Hogyan előzhetjük meg a technológiai adósság generálását?
Mint ahogy már említettük, a technológiai adósság nem feltétlenül rossz dolog, mivel a versenytársaknál gyorsabban juthatnak el termékeink a piacra. Ahogy visszajelzéseket kapunk, a hibákat javítani lehet, és a termék fejlődik, miközben bevételt hoz a szervezet számára.
A megtermelt pénzből ki lehet fizetni a felhalmozott technológiai adósságot. Fontos azonban azzal is tisztában lenni, hogy ez az adósság váratlanul is jelentkezhet az irreális idő- vagy erőforrás korlátok miatt.
Vannak módszerek, amelyekkel a projektmenedzser elkerülheti a technológiai adósságot:
1. Beszéljünk a technológiai adósságról
Ez kulcsfontosságú. Ha a csapattagok tisztában vannak vele, akkor nagyobb valószínűséggel azonosítják azokat az utakat, amelyek azt eredményezik. Érdemes figyelmet szentelni rá, például olyan kérdéseket, feltenni, hogy: “Ha a rövidítés a helyes választás, mit nyerhetünk vele? Mik a kihívások és a jövőbeli következmények?”
2. Legyen idő a kezelésre
Mindig gondoskodni kell arról, hogy az ütemtervben legyen idő a technológiai adósságok mielőbbi kezelésére, hogy a sebezhetőségek és gyengeségek csökkentése mellett haladhasson előre a projekt.
3. KPI-ok használata a projekt elvárásainak nyomon követésére
Azzal, hogy KPI-okkal rendelkezünk a projekt teljesítményéről vagy a fejlesztésről, jobban priorizálhatjuk a technológiai adósságot kezelő munkát.
4. A technológiai adósságok folyamatos monitorozása
Fontos, hogy a csapat a technológiai adósságot a feladatok elvégzése közben rendszeresen nyomon kövesse és más feladatokkal együtt kerüljön rangsorolásra.
5. Legyenek reális céljaink
A technológiai adósság felhalmozásának biztos módja, ha túl hamar, túl sok feladatot kap a csapat. Mindig igyekezzünk reális határidőket és célokat kitűzni, amelyeket teljesíteni tudunk anélkül, hogy spórolni kellene, és esetleg technológiai adósságot halmoznánk.
Az agilis irányzatok egyre nagyobb teret hódítanak projektek során és a szervezetek életében. Fejlessze Ön is gyakorlati eszköztárát és szerezzen nemzetközi képesítéseket! Mélyítse el tudását agilis képzéseinken!
Designabc