Kuidas kaob tarkvara kvaliteet?

Enne kui hakata rääkima kuidas tarkvara kvaliteet kaob, tuleks vaadata, mis see on ja kuidas see projektijuhtimise kolmnurgaga seotud on.

Mis on tarkvara kvaliteet?

Tarkvara kvaliteet jaguneb kaheks: toote ja struktuuriline kvaliteet. Esimese puhul võetakse vaatluse alla vastavus nõuetele, terviklikkus, kasutatavus, dokumenteeritus ja veatus. Teisel puhul võetakse vaatluse alla arhitektuuri paindlikus, lähtekoodi loetavus, haldamise kergus, ressursside kasutus ja laiendatavus [Wiki].

Lähtekood on toode – suures osas määrab kood kvaliteedi ja arengujõulisuse.

Toote kvaliteet on oluline kasutajatele ja ärilisele poole, seevastu struktuuriline kvaliteet mängib suurt rolli edasiarenduses, süsteemi haldamises ja üleval hoidmises, mis peaks olema ärilisele poolele küllaltki oluline.

Projektijuhtimise kolmnurk

See on üks projektijuhtimise põhitalasid. Kolmnurk sümboliseerib seoseid aja (ajagraafik, projektiplaan), ressursi (maksumus, eelarve, inimesed) ja skoobi (funktsionaalsus) vahel. Sellega arvestavad projektijuhid, kuid paljudele jääb nägemata üks punkt – kvaliteet. See on neljas punkt ning kolmnurgast saab kas tetraeeder või nelinurk (või nagu kujund pildil).

Tänu sellele, et neljandat punkti ei nähta, siis on see suurim kannataja projektides. Kui fikseerime aja, ressursi ja skoobi, siis saame mängida ainult kvaliteediga. See tähendab, et tehtav süsteem ei ole väga kasutatav või edasiarendatav.

Üheks peamiseks kvaliteedi vastaseks on kiirustamine. Tihtipeale tuleb mõni projektijuht jutuga, et selle funktsionaalsuse tegemiseks on aega vähe ja see tuleb kindlalt ära teha. Sellega hakkame vastavust nõuetele nö mõõdikut suurendama. Kuna aega on vähe, siis arendajad tihtipeale testivad vähem (näiteks ei kirjuta komponenditeste) ning seda peavad nad enesestmõistetavaks. Seepärast projektijuht ega klient ei tea, et struktuurne kvaliteet võib kahjustuda tõsiselt ja sama võib ka juhtuda toote kvaliteediga (dokumentatsiooni ei kirjutata, vigu tekkib juurde, kasutatavus ei ole kõige parem vms.)

Kõrgem kvaliteet soodustab kiiremat edasiminekut pikemas perspektiivis, mistõttu peaksime siiski endale kindlaks jääma ja tagama selle olemasuolu.

Siinpuhul võib tulla mõtte, et ületundidega hoiame kvaliteeti ja ajagraafikut ohjes. Siiski ei aita ka see – inimesed on väsinumad ning toodavad ka rohkem vigu eriti pikema aja jooksul. Teine mõte,, mis võib rünnata on see, et hiljem teeme selle korda, kuid tõenäoliselt seda ei juhtu ja see ei tule odavam. Seetõttu poleks mõistlik ennast petta, sest kvaliteeti ei anna hiljem juurde lisada nagu ketšupit oma toidule. Pikemalt sellest võib lugeda Derick Bailey kandest.

Teised lähenemised projekti kolmnurgale

Donald Belcham ja Kyle Baley vestlesid projekti kolmnurgast ning jõudsid järgnevale analoogiale: kui vastavad atribuudid lisada kaalule, kus vasakul on ressurss ja aeg ning paremal on skoop ja kvaliteet, siis peaks jääma see tasakaalu. Sellisel puhul võib öelda, et projekt peaks sujuma kenasti. Väiksed näited ka kaalu kasutamisest:

Kui suurendada skoopi, siis tuleks suurendada ka aega või ressurssi või mõlemat. Halb variant on vähendada kvaliteeti, kuigi see on võimalik suund. Kui reageerimata jätta, siis võib tulla scope creep [Wiki], mis ei ole ühelegi osapoolele kasulik – tellija saab küll odavamalt, kuid olematu kvaliteediga toote, mille ta peab ehitada laskma ja teostaja peab tegema palju tasuta tööd.

Kui vähendada aega, siis tuleks vähendada skoopi või kvaliteeti. Siinkohalgi tundub kasulik suund skoobi vähendamine. Võiksime ka suurendada ressursse, kuid projekti käigus inimeste juurde lisamine ei pruugi efektiivne olla (neil tuleb kohaneda süsteemiga ja uurida nõudeid jne, mis kõik võtab teiste tegelejate aega).

Mis saab kui kvaliteedile rõhku ei panda?

Vahel on vajatakse mõnda funktsionaalsust ärilistel põhjustel kiiresti. Siinkohal tuleb arvesse võtta, et kvaliteedi vähendades tekkib tehnilist praaki (technical debt), mida tuleb hiljem korrastada, kui soovitakse pikemas perspektiivis arengujõulised olla. Lisaks ei tohi tehnilise praagi osakaal liiga suur olla, sest siis võib olla juba liiga hilja seda korrastada. Tegemist on siis kaosega: uut funktsionaalsus lisatakse kaua; vigade arv suureneb jne. Järgmine jutt, mida kuulda võib, et see projekt tuleb uuesti teha ja siis tehakse see tunduvalt paremini – siiski ebaefektiivne lahendus.

Võimalusi kvaliteedi parandamiseks

Toote kvaliteedi parandamiseks on hea pidevalt tellijale näidata süsteemi, et saaks tagasidet võimalikult varakult. See peaks olema ka tellija enda huvides, sest igasugused ümbertegemised lähevad hiljem kallimaks kui algul. Struktuurilist kvaliteeti aitab parandada peamiselt head arenduse praktikad: automaatsed testid, pidev integratsioon, koodi standardid ja ka tehnilised teadmised.

Ärge unustage kvaliteeti! Kui teate häid praktikaid, kuidas kvaliteeti ohjes hoida, siis andke kommentaarides kindlasti märku.