Amikor egy agilis csapat műszaki adóssága kezd halmozódni, biztos jele annak, hogy a termékfejlesztés veszélyben van.
De mi is az a műszaki adósság? Minden olyan a termékbe beépített már létező vagy potenciális műszaki probléma, amely a jelenben (az éppen fejlesztés, feldolgozás alatt álló sztorik megvalósítása során) vagy a jövőben (a későbbiekben kialakítandó termékbővítmények elkészítésekor) rontja a termék minőségét, illetve a termékfejlesztési folyamat hatékonyságát, és ezáltal veszteséget okoz. Sok minden lehet a műszaki adósság: megannyi más dolog mellett az, hogy valamilyen “quick-and-dirty” megoldás a termékben marad, a kód minősége nem kielégítő, esetleg egy már régen szükséges refaktorálás elmaradása.
A műszaki adósság pontosan olyan nehézségeket jelent egy csapat számára, mint a pénzügyi adósság egy cég vagy magánszemély számára.
Amíg tudjuk, hogy miért veszünk fel hitelt, hogyan, mennyi idő alatt fogjuk törleszteni, milyen kockázatokkal jár a részletek törlesztésének elmaradása, valószínűleg kézben tudjuk tartani azt. Azonban amikor már újabb hiteleket veszünk fel csak azért, hogy a korábban felvetteket törlesszük, érezhetjük, hogy baj van. Ha sokáig nem fizetjük az részleteket, biztosak lehetünk, hogy egyszercsak kopogtat a bank, és az nekünk valószínűleg csak további nehézségeket, extra anyagi terheket fog jelenteni.
A műszaki adósságot is mindaddig könnyebben kezelhetjük, amíg
- pontosan tisztában vagyunk azzal, hogy mekkora adósságról is beszélünk;
- van arról elképzelésünk, hogyan akadályozzuk meg a halmozódását;
- megfelelő időben törlesztjük a részleteket, vagyis folyamatosan felszámoljuk a meglévő adósságokat.
Ezt persze könnyű kimondani, de sokkal nehezebb egy fejlesztési projekten biztosítani. Ha viszont ezt nem tesszük, nincs semmi, ami megakadályozza azt, hogy a műszaki adósság csődbe vigye a projektet.
#1: Új termékképességek favorizálása a műszaki adósság ledolgozásával szemben
Az egyik legutóbbi ügyfelem projektjét néhány hét alatt súlyos veszteséggel terhelte meg az a tény, hogy észlelte, de figyelmen kívül hagyta a minőséghez kapcsolódó problémákat.
A fejlesztőcsapat észrevette, hogy a megvalósításhoz használt architektúra feleslegesen “nehéz” elemeket tartalmaz, amelyek nem szükségesek a termék funkcionális és minőségi követelményeinek megvalósításához. A csapat a product ownerrel megvitatta ezt a tényt, és létrehozta a refaktoráláshoz szükséges backlog elemet. A product owner ezt folyamatosan mélyebbre tette a backlogban, előnyben részesítve újabb funkcionális termékképességek fejlesztését. A csapat már a harmadik újabb sprintet valósította meg anélkül, hogy a korábban feljegyzett refaktorálás a látókörébe került volna, mert minden alkalommal az új termékképességek fejlesztése kapott prioritást.
Így ment ez még további két sprinten keresztül. Végre a látótérbe került a várt refaktorálás, és a csapat hozzáláthatott annak tervezéséhez. Ekkor jött a feketeleves: az időközben beépített új termékképességek miatt a refaktorálás eredetileg becsül ráfordításai közel megtízszereződtek, és akkorára nőttek, hogy a csapatnak egyetlen sprintjébe már nem fértek volna bele. Az eredeti backlog bejegyzést 14 kisebb (a termékképességekhez kapcsolódó) bejegyzésre vágták szét, és négy sprint alatt dolgozták le, hogy eközben ne álljon meg az élet, és újabb értéknövelő termékképességek megvalósítására is jusson idő.
A történet abból a szempontból pozitív eredménnyel zárult, hogy a csapat és a product owner egyaránt tanult belőle. A csapat tagjai azt tanulták meg, hogy fel kellhívni a product owner figyelmét arra, hogy a refaktorálás halogatása ilyen extra költségekkel járhat, a product owner pedig megértette saját döntéseinek jelentősségét.
#2: Elfelejtett adósságok
Apró figyelmetlenségek, lustaságok és halogatások masszív adóssághalmazzá állhatnak össze.
Egy csapat, amelyet már hetek óta segítettem, az önállósodás útjára lépett, és saját lábukon biztosan állva sok-sok sprinten keresztül fejlesztettek. Néhány hónap után azzal fordultak hozzám, hogy jelentősen visszaesett a hatékonyságuk. Megkértek, hogy segítsenek kideriteni ennek a jelenségnek az okát.
Hamar kiderült, a probléma oka az (ezt ők is sejtették), hogy jelentősen megnőtt műszaki adósságuk. Ezt ők is látták: időnként átléptek egy-egy olyan problémán, amiről tudták, hogy az műszaki adósságot jelent, de “éppen nem volt rá idejük foglalkozni”, és napok, hetek múlva tértek vissza azok ledolgozására. A problémákat ugyan ledolgozták (úgy vélték), de mégis mindig jobban nőtt a problémahegy, mint amilyen sebességgel azt kezelni tudták. Figyelmeztető jel volt az, hogy brainstorming segítségével próbálták összeszedni a számukra fontos műszaki adósságok listáját.
Kiderült, hogy a műszaki adósságok nemcsak a backlogba nem kerültek be, de még csak más egyéb listát sem vezettek azokról. Amikor megfelelő kapacitásuk maradt arra, hogy egy-egy új termékinkrementum kapcsán egy kódrészhez hozzányúljanak, és annak minőségét javítsák, emlékezetből próbálták meg a változtatásokat elvégezni.
Két fontos intézkedéssel sikerült a helyzetet rendbetenni:
- Utólag elkészítettük a műszaki adósságok listáját, és az a backlog részévé válva segítette a csapat további munkáját.
- Egyeztettük, hogy a megtalált műszaki adósságok folyamatosan a csapat backlogjába kerülnek, és azokat lehetőleg az adott sprinten, de legkésőbb a következő sprint során igyekeznek ledolgozzi.
A csapat megszenvedte a hatalmas adósságlista ledolgozásának első két sprintjét. A sebességük egy ideig még nem nőtt jelentősen, azonban a hangulatuk javult, ugyanis napról-napra látták, hogyan fogy a lista, és ez bizakodással töltötte el őket.
A halogatásnak ára van
Egy jó csapat igyekszik elkerülni azt, hogy a sztorik megvalósítása során műszaki adósságot képezzen. Ezt nem mindig egyszerű megtenni, hiszen nagyon gyakran egy adott termékképességhez tartozó szoftverrész kifejlesztésekor nem mindig ismerjük fel, hogy ilyen műszaki adósság keletkezik. Gyakran ez a felismerés csak később, egy kapcsolódó újabb képesség kialakításakor történik meg.
Ha a fenti két csapdahelyzetet el akarod kerülni, érdemes az alábbiakat szem előtt tartanod:
- A csapatod lehetőleg azonnal igazítsa ki azokat a minőségi problémákat, amelyeket potenciális műszaki adósságnak lát! Olyan hasznos technikák mint a páros programozás, a folyamatos kódvizsgálat, statikus kódanalízis (és még sok más) segíthet a megbúvó problémák feltárásában, elkerülésében.
- Jegyezzetek fel minden olyan potenciális problémát (már az észlelés során), amely műszaki adósság lehet, és vitassátok meg azt! Legalább azokat az egyszerű tevékenységeket végezzétek el, amelyek megakadályozzák, hogy egy potenciális probléma (nehezen kezelhető) műszaki adóssággá nője ki magát!
- A már beazonosított műszaki adósságokat lehetőleg azonnal oldjátok fel, ha ez valamiért nem lehetséges, akkor mindenképpen készítsetek hozzá egy backlog bejegyzést!
- Ne toljátok el a műszaki adósságok ledolgozását egy bizonytalan jövőbeli sprintre!
A csapat addig tudja önállóan kezelni a műszaki adósságokat, amíg azokról backlog bejegyzés nem születik. Ezután már csak a product ownerrel együttműködve kezelheti azt. A legtöbb product owner hajlamos az új képességek fejlesztésének jelentősen nagyobb prioritást adni, mint a műszaki adósságok ledoglozásának. A csapat feladata és jól felfogott érdeke, hogy az adósságok potenciális következményeiről tájékoztassa a product ownert.