Jul 23 2008
Puugid puuri!
Paljud lugejad mäletavad ehk 1990. aastate esimest poolt, kus iga endast lugupidav eestlane oma isikliku panga asutas. Mingil hetkel avastasid pankurid aga, et lihtsalt kilekottidega sularaha ühest kohast teise tarimisest ei piisa, ja algas buum Eesti IT-maastikul. Tarkvarafirma Joostes Marss oli tol vanal heal ajal loomisjärgus ning tegi suuremaid ja väiksemaid projekte Ahja Kommertspangale.
Tihti lõppesid Ahja Kommertspanga IT-juhi Ilmari ja Joostes Marsi projektijuhi Joosepi vahelised vestlused aga mõlemapoolse ärritusega. Tüüpiline telefonikõne oli näiteks järgmine:
Ilmar: Kas bugid on ära parandatud?
Joosep: Mis bugid?
Ilmar: Need, millest ma kuu aega tagasi telefonis rääkisin!!
Joosep programmeerija Priidule: On ära parandatud või?
Priit: Midagi ma vist parandasin jah…
Joosep Ilmarile: Jah, on küll parandatud.
Ilmar: Millal kätte saab?
Joosep: Homme saadame.
Mõned päevad hiljem:
Ilmar: No aga ikka ei ole ju kõik ära parandatud!?!
Joosep: Mis siis veel?
Ilmar kirjeldab.
Joosep Priidule: Mis värk sellega on?
Priit: Aa, selle ma unustasin.
Joosep Ilmarile: Teisipäevaks saadame uue!
Kolmapäeval:
Ilmar: Aga IKKA ei ole ju kõiki asju!!
Joosep: Aga see polegi bug, see on feature.
Ilmar hakkab karjuma, et tema on klient ja tema otsustab, mis on feature ja mis mitte.
Lõppkokkuvõttes võttis projekt kahe kuu asemel kaheksa, Priit logeles enamiku päevi niisama ja tegi vahele meeleheitlikke spurte, et probleeme kontrolli alla saada, kui Ilmarilt järjekordne kõne tuli. Ebaregulaarse rütmi tõttu läks ta tüdruksõbraga tülli ja kirjutas koodi sisse Ilmari aadressil ebatsensuurseid kommentaare.
Milles asi? Nagu ühes eelnevas, projektijuhtimisele pühendet jutus mainitud, on projekti õnnestumise tagamisel peamine osa korralikul kommunikatsioonil. Arvatavasti kõige olulisem asi, mida projekti käigus tuleb kirja panna ja millest kõik osalised peavad ülevaadet omama, on see, kui palju ja milliseid vigu (ehk buge või puuke) meil parajasti koodist on leitud.
Vigade andmebaasi pidamine on tegelikult väga lihtne asi, selleks on loodud suurel hulgal nii vabu kui kommertsprodukte, enamasti on puuduliku veahalduse põhjused suhtumises.
Vahel tuuakse vastuväiteks näiteks, et oh, me suudame niisama ka oma vigu meeles pidada. Absurdne. Ma pole veel näinud ühtki inimest, kes suudaks korraga meeles pidada rohkem kui kolme vea üksikasju. Võib ju ka öelda, et me parandame vead kohe nende ilmnemisel ära, aga seegi ei tööta, sest parandamine võtab vahel paratamatult kauem aega, kui meil hetkel käepärast on.
Tegelikult olen ma leidnud, et isegi väikeste projektide puhul, millega ma vahel ise oma lõbuks tegelen (ehk siis 1 inimene, 1000-25 000 rida koodi), on väga kasulik vead kohe avastamisel kirja panna (kui tegemist pole just asjaga, mis sama päeva jooksul valmis saab), sest hiljem on suur osa vajalikust kontekstuaalsest teadmisest kadunud.
Igas veakirjelduses peavad kindlasti olemas olema järgmised komponendid:
- Täielik info, kuidas viga reprodutseerida
- Soovitud tulemus programmi käivitamisel
- Tegelik tulemus
- Kellele viga on omistatud (mitte ei eelda kõik inimesed, et keegi teine asja korda teeb)
- Vea staatus (aktiivne, parandatud, kontrollitud/suletud)
Peale selle kasutavad erinevad organisatsioonid veel mitmeid väljasid, nagu
- Tõsidus (oluline vahe, kas programm crashib või on mõni ikoon pikseli võrra paigast ära)
- Prioriteet (erineb tõsidusest, vahel on avalehel oleva ikooni pikselid olulisemad kui kord 10 aasta jooksul juhtuv crash)
- Vea parandamiseks kuluv hinnanguline aeg
- Parandamise tähtaeg (kui meil on tegemist vahepealsete verstapostidega)
- jne.
Kui vigade andmebaasi 100% kasutatakse, siis nende andmete põhjal saab projektijuht teha juba väga võimsaid päringuid, kui palju tööd on veel jäänud, kas programmeerijad jaksavad testijatega sammu pidada, milline on produkti üldine kvaliteet (s.t kas leitakse tõsisemaid või vähemtõsisemaid probleeme) jne. Samas ei tohi lisaväljadega üle pingutada, sest siis ei viitsi keegi neid enam täita. Ülaltoodud 5 välja on aga esmase tähtsusega. Kui vigade registreerimine muutub nii vaevanõudvaks, et inimesed seda enam ei tee, tuleb meil oma protsess alati optimiseerida sellele, et 100% vigadest saaks kirja pandud.
Esineb ka psühholoogilist laadi vastuväiteid, näiteks võtavad mõned programmeerijad nende koodist vigade leidmist isiklikult ja peavad selle kirjapanemist veel eriti solvavaks. Ütle mulle lihtsalt, mis värk on, ja ma parandan asja ära, pole vaja midagi kirja panna, urisevad nad testijale. Siin saame teha kaks olulist tähelepanekut:
- Kas on parem, et vea leiab meie testija või klient? Testija peaks olema programmeerija parim sõber ja programmeerija peaks teda igal viisil julgustama, et ta rohkem vigu saaks leida, sest sel viisil päästab testija programmeerija piinlikkusest, mis leiab aset, kui hoopis klient või mõni muu tähtis tegelane vea avastab ja programmeerijal tulekahju kustutamiseks ületunde tuleb teha.
- Programmeerija produktiivsust ei tohi hinnata lihtsalt vigade arvu põhjal, sest see loob initsiatiivi mitmesuguseks sohitegemiseks ja lõpuks oleme lõhkise küna ees: vigade andmebaas valetab ja ka produktiivsust hindame ilmselt valesti.
Lisaks on vigade andmebaasil mitmeid sekundaarseid väärtusi, näiteks langeb ära vaidlus teemal, kas mingi asi on bug või feature, sest kõik on ilusasti kirja pandud ja kohe vea registreerimisel saab arutada, kas asjad peavad nii olema või ei.
Kokkuvõtteks võib öelda, et võrreldes projektiga, kus projektijuhtimisvahendid täielikult puuduvad, on vigade andmebaas ilmselt esimene asi, millest alustada, sest see annab lihtsa vaevaga kõige suuremat kasu. Lisalugemist muidu Joelilt.
