“If you carry this way of working on for months or years, you get a lot of technical debt …”, vagyis “ha hónapokon, vagy éveken át így dolgozol, rengeteg technikai adósságot halmozol fel …”, írja az agilis módszertanokról a sorozatunkban elemzett cikk. Nagy hiányossága az írásnak, hogy csak kijelent, de nem indokol; így vitába szállni sem lehet vele. Vita helyett tehát inkább elmondjuk, tapasztalataink szerint mi okozhatja a fenti helyzet kialakulását, és hogyan lehet kivédeni azt.

A technikai adósság keletkezésének gyökéroka, hogy a sebesség oltárán feláldozzuk a minőséget. Itt hívjuk fel a figyelmet arra, hogy ezek az okok nem csak agilis környezetben merülnek fel. Sok megjelenési formája van ennek, néhány példa:

• Kritikus hibát gyorsan kell javítani. Ilyen esetben a hackelés teljesen helytálló stratégia: ha éles rendszerhiba miatt mondjuk óránként egymillió dollárt veszít a cég, senkit nem érdekel és nem is szabad, hogy érdekeljen a megoldás eleganciája; a gyorsaság a kulcs. A probléma abból fakad, hogy miután a hibát elhárítottuk, más feladatok lesznek sürgősek és a rendrakás elmarad.
• Hasonló eset, ha kritikus fejlesztést kell gyorsan elvégezni. Ebben az esetben is új irányba állítjuk a fejlesztőcsapatot, amikor már működik az új funkció, és a rendrakás ismét elmarad.
• Előfordulhat az is, hogy egy, a korábbi követelményeknek tökéletesen megfelelő kóddal kapcsolatban olyan új igény merül fel, aminek a lefejlesztése a kód átstrukturálását igényelné. Ha nem vállaljuk fel, hogy az új igény fejlesztési költségének része a meglévő rendszer szükség szerint átalakítása, ismét nem lesz idő megfelelő minőségű munkát végezni.
• Megtörténhet; különösen, ha új technológiával kezd el dolgozni a csapat, hogy a korai megoldásokról kiderül: nem időtállóak. Ahogy egyre jobban megismerik az új technológiát, sorra fedezik fel, mit hogyan lehetett volna jobban megoldani. Természetesen nem kell minden felmerülő ötlet esetén rögtön átírni az egész kódbázist; de ha soha nem hajtjuk végre ezeket a módosításokat, egész biztosan csak halmozni fogjuk az adósságot.

Akárhogy is jutottunk el a technikai adósságig, minden esetben feszültséget szül az üzleti és a fejlesztési oldal között. Az üzlet frusztrált és nem érti, miért lassul folyamatosan a fejlesztés; a fejlesztés szintén frusztrált, mert az üzlet nem hagy időt a refaktorálásra és folyamatosan nő a nyomás.

Az agilis kiáltvány egyik alapelve így hangzik: “A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást” (A félreértések elkerülése végett, a “terv” szó itt a design, mint architektúra terv fordítása, nem pedig a plan, mint projekttervé). Talán túl megengedő a megfogalmazás; kimondhatnánk azt is, hogy a műszaki kiválóság szem előtt tartása nélkül nem lehet fenntarthatóan és agilisan dolgozni.

Muszáj tehát a refaktorálást a napi munka részévé tenni, és amennyiben ez nem elég, nagyobb szabású átalakításra van szükség, annak is teret kell adni a fejlesztés során.

Általános jelenség, hogy a fejlesztők, ha tehetnék, folyamatosan csinosítanák a kódot, az üzlet pedig mindig rohanna tovább előre. Eközött a két véglet között kell megtalálni az egyensúlyt. Két utat ajánlunk erre:

• A fejlesztési oldalnak “el kell tudnia adni” a technikai adósság csökkentését célzó feladatokat az üzlet számára.
  Nekünk leginkább az vált be, ha ilyen esetben nem azt keressük, miért fontos végrehajtani a szóban forgó refaktorálást, hanem azt, milyen következménye lesz annak, ha elmarad. Pl.: “a jelenlegi megoldással maximum 25 konkurens felhasználót tudunk kiszolgálni”, “3 MByte-nál nagyobb file-oknál nagyon belassul a feldolgozás, akár több percig is eltarthat”, “nem lehet automata tesztet illeszteni a kódhoz, így minden egyes release előtt kézzel kell végigtesztelni ezt a modult”, …
  A “mit veszítünk, ha nem csináljuk meg” gondolkodás segít üzleti nyelvre fordítani a refaktorálás technikai feladatát, és abban is segít, hogy kiszűrje azokat a módosításokat, amiket csak a személyes szépérzékünk kielégítése kedvéért szeretnénk elvégezni.
• Ha már felépült a megfelelő kommunikáció üzlet és csapat között a technikai adósságról, sok esetben létrejön egy megállapodás, miszerint a csapat a kapacitás x%-át ilyen jellegű feladatokra fordíthatja. Ez megkíméli a Product Ownert attól, hogy számára esetleg nem érthető backlogelemeket kelljen priorizálnia és a megfelelő szintre viszi a döntést: ahol a tudás és az információ rendelkezésre áll. Egyúttal - mivel véges budget-ből gazdálkodhat a csapat - ezzel a módszerrel is ki tudjuk védeni a valódi értéket nem adó technikai feladatokat: a csapat sajnálni fogja ezekre az időt.

A fentiek alapján nekünk az a személyes véleményünk, hogy jól működő agilis környezetben a technikai adósság problémája egy beismert és tudatosan kezelt kérdés, és sokkal nagyobb a valószínűsége annak, hogy ezek az adósságok tényleg “kifizetésre kerülnek”, mint egy hagyományos környezetben.