Archive for the 'Joostes Marss' Category

Aug 02 2011

Kaubakultus tarkvaraprojektides

Published by Targo under Joostes Marss, Projektijuhtimine

Tarkvarafirmasse Joostes Marss tuli tööle uus ja uljas projektijuht Jaana. Jaanal polnud küll formaalset tarkvaraprojektide juhtimise alast haridust (mitte et kuigi paljudel projektijuhtidel seda oleks), aga ta oli seltskondlik ning omas palju tuttavaid. Muuhulgas oli tal sõber Jim, kellega Jaana oli kohtunud ühel JCI üritusel. Jim oli hiljuti tööle asunud IBMis ja rääkis Jaanale oma kogemustest. Meil vaadatakse kõik töötulemused ja dokumendid ühiselt üle ja kõik asjad on dokumenteeritud! Ja iga päev on koosolek, kus arutame päevaplaani, nii et kõik teavad, mis toimub! Niiviisi on kord majas ja tulemus kvaliteetne! Kuna Joostes Marsis taheti pahatihti parimat, aga välja kukkus nagu alati, avaldas see jutt Jaanale sügavat muljet ja ta tahtis samuti vastavat lähenemist juurutada. Me peaksime ka igapäevaseid koosolekuid korraldama ja rohkem dokumente kirjutama!

Vanem olija, projektijuht Joosep, laitis selle idee maha. Mis bürokraatiat sa tahad siin tekitada? Tõelised programmeerijad kirjutavad programme, mitte dokumentatsiooni, oli tema kindel seisukoht. Tuleb lihtsalt kõvasti tööle pihta anda ja asjad ära teha, küll siis kõik laabub. Just ütlesin progeja Priidule ka, et praegu on kiire aeg ja tuleb ohtralt tunde teha! Ja üleüldse, vaata näiteks Google’it, seal tehakse palju ületunde ja vaata kui edukad nad on! Kui me sunnime programmeerijaid koosolekutel käima ja oma tegevust dokumenteerima, ei jää neil päris töö jaoks piisavalt aega.

Tänane jutt on inspireeritud Steve McConnelli samateemalisest suurepärasest artiklist, aga ülaltoodud diskussioone toimub kogu aeg – vaieldakse viimse veretilgani selle üle, kas progejad peaksid ületunde tegema või ei, kas dokumente kirjutada on vaja või ei, kas nad peaksid koosolekutel osalema või mitte jne.

Perfektse illustreeriva näite leiame aga 70 aasta vanusest minevikust. II Maailmasõja ajal ehitas alguses Jaapani ja siis USA sõjavägi mitmetele Vaikse ookeani väikestele saartele lennuvälju ja muid rajatisi. Kohalikele elanikele tõi see kaasa enneolematu buumi, kuna sõdurid tõid kaasa imelisi riideid, tööriistu, toiduaineid ja muud kraami, millest ka pärismaalased natuke osa said. Aga siis sai sõda läbi ja lennukid lendasid ära. Kohalikud ootasid ja ootasid, aga ei midagi. Lõpuks ehitasid nad puust lennurajad ja juhtimistornid ning sooritasid oma lennuväljal rituaalseid toiminguid, mida olid näinud võõramaalasi tegemas, lootuses sel viisil lennukeid tagasi meelitada, nähtus, mida nimetatakse kaubakultuseks (cargo cult).

Sarnaselt püüavad paljud ettevõtted matkida edukamate firmade tegevuse väliseid jooni, lootuses saavutada samasugust edu. Nad panevad tähele, et mõnes kohas korraldatakse palju koosolekuid ja kirjutatakse palju dokumente, ning teevad ise siis sedasama. Need koosolekud on aga igavad ning ebapraktilised ning kellelegi ei meeldi seal kohal käia, sest neil pole tegelikult selgelt defineeritud eesmärki. Heas ettevõttes on igal koosolekul konkreetne eesmärk, mis aitab kaasa tarkvara efektiivsemale valmimisele, aga seda defineerida ning ohjata on palju raskem kui lihtsalt koosolekut kokku kutsuda.

Ka tehakse Google’is või Microsoftis tõesti palju ületunde, aga seda ei tehta mitte ülemuste nõudmisel, vaid seetõttu, et sinna on kokku kutsutud inimesed, kes armastavad tarkvarategemist, ning neile seejärel  võimalikult head tingimused loodud, mille tagajärjel kulutavad töötajad vabatahtlikult tööl rohkem aega.

Teistes ettevõtetes püütakse abi leida käesoleva hooaja imerohtudest, olgu need siis seotud lahendustega (nt SOA) või metoodikatega (nt Scrum). Iga paari aasta tagant kuulutatakse välja uhke initsiatiiv, kuidas kõik hakkab nüüd teisiti olema, puhutakse pasunaid, võtmeisikud käivad konverentsidel jne. Samas on põgusagi vaatluse järel selge, et nende tegelik probleem on hoopis selles, et nad ei tunne piisavalt hästi ei seda ärivaldkonda, milles nad tegutsevad, ega tehnoloogiaid, mida nad kasutavad. Uue buzzwordi kasutuselevõtt aitab neid sama palju kui istekohtade vahetus Krõlovi valmist tuttavas loomade orkestris.

Jaana ja Joosepi vaidlus on seega sama mõttetu kui pärismaalaste vaidlus, kas puust lennurada ehitada põhjast lõunasse või idast läände. Kui me ei mõista, miks edukas ettevõttes mingid asjad juhtuvad, ei saa me välise matkimise abil ka edu saavutada. Tegelik vaidlus peaks käima mitte “protsess” vs “heroism” või “dokumentatsioon” vs “väledus” teemal, vaid kompetentsus vs ebakompetentsus teemal.

Sellegipoolest on paljudes ettevõtetes puust lennurada juba valmis ja inimesed kirjutavad nt mingeid dokumente, mida mitte keegi kunagi ei loe. Hea test on siin neilt küsida, miks nad üht või teist dokumenti kirjutavad? Tihti on vastuseks midagi ebamäärast, et “meil näevad reeglid nii ette” või “alati on nõnda tehtud” (tuletan ka meelde lugu seitsmest ahvist). Sellise vastuse puhul on praktiliselt garanteeritud, et lennuk on puust.

11 responses so far

Jul 15 2010

Mida parem, seda halvem

Tarkvarafirma Joostes Marss oli Hulkuvate Kasside Riiklikule Inspektsioonile tarninud juba õige mitu versiooni nende andmeregistrist. Kuigi projektides esines teinekord konarusi, harjusid kõik osalised vähehaaval üksteisega ning asjad sujusid. Andmeregistrile kasvatati järjest uusi kombitsaid, kelli ja vilesid ning ametnikud olid rahul.

Siis leidis loomakaupluste kett Krants, Kõuts & Kirjak, et aitab paberi ja pliiatsiga asjaajamisest ning kutsus Eesti erinevate tarkvarategijate esindajaid oma lahendusi pakkuma. Joostes Marsi direktor Tõnis hõõrus käsi: keegi ei tea kassidest rohkem kui meie! Ja projektijuht Joosep saadeti KK&K peakorterisse esitlust tegema.

Joosep näitas hulgaliselt ägedaid vorme, graafikuid ning raporteid ja kiitis süsteemi rikkalikke võimalusi. “Kasutajad saavad ise töövooge disainida näiteks!”, vedas ta uhkelt ekraanil kastikesi. Võit tundus käes olevat.

Ent kui tulemused välja kuulutati, osutus võitjaks hoopis AS Pärlike, keda Joostes Marss polnud enne just kuigi tõsiseks konkurendiks pidanud. Aga… aga töövood! protesteeris Joosep. Nojah, see on tore küll, nõustus KK&K IT-juht Iko. Aga meil on siin lihtsad inimesed, nad ei kasutaks niikuinii kõiki neid võimalusi. Pärlikese lahendus on palju mugavam. Ja pealegi ma kuulen, et teil on Inspektsioonis vahel stabiilsuse probleemid. Stabiilsuse probleemid muidugi olid, seda ei saanud Joosep salata, aga see oli erinevate lisavõimaluste hind ning eelmine klient oli nende eest täiesti valmis olnud väikest ohvrit tooma.

AS Pärlike töötas projekti kallal mõned aastad, elu sujus, tehti jätkuarendusi jne. Ühel päeval aga tuli Iko Pärlikesse ja teatas, et nende IT-kulud on liiga suured ja nad peavad plaani anda oma arendus pigem OÜ Ülo&Aivari kätesse, kuna nonde tunnihind on mitu korda madalam. Pärlikese boss oli endast väljas: Aga… aga meie progejad on ju palju paremad! Ülo ja Aivar on ju täitsa metsast, mida nemad ka teavad? Nojah, võib-olla, arvas Iko. Aga meil pole midagi väga keerulist niikuinii vaja, küll me hakkama saame.

Mis siis tegelikult juhtus? Ilmselt on paljud meist olnud ühes või mitmes ülalkirjeldatud rollidest ja vastavalt oma vaatenurgale kas rõõmustanud võidu üle või kirunud, kuidas klient on ikka taipamatu ega saa meie väärtusest aru.

Tegelikult on majandusteaduses kindlaks tehtud, et enamik konkureerivate ettevõtetega turge käivad läbi neli konkreetset faasi:

  1. Võistlus funktsionaalsuse baasil, kus hinnatakse seda, kelle tootel on rohkem võimalusi.
  2. Võistlus töökindluse baasil, kus kõigil on piisav funktsionaalsus on olemas, aga oluliseks saab, et süsteemile võib kindel olla.
  3. Võistlus kasutajamugavuse baasil, et toode saaks uutele kasutajatele võimalikult kerge vaevaga kättesaadavaks.
  4. Võistlus hinna põhjal. Kui kõige muu osas tundub kliendile, et vahet pole, saab ainsaks määravaks teguriks hind.

Need faasid kehtivad igal pool ekskavaatoritest mikroprotsessoriteni ning nende osas rakenduvad järgmised reeglid:

  • Igas järgmises faasis kahaneb kasumimarginaal.

Kui puhtalt funktsionaalsuse juurdetreimisega tegelevatel firmadel on marginaalid tihti 30-40% kandis, siis ainult hinnapõhises konkurentsis tuleb rahulduda paari protsendiga.

  • Ettevõtetele on ühest kategooriast teise liikumine äärmiselt raske ning see saab neile tihti saatuslikuks.

Minu Microsoftis töötatud aja keskele jäi ka Trustworthy Computingu initsiatiivi väljakuulutamine. Kui varem oli hiigelsuure ettevõtte igal tasemel ja üksuses olnud edu valemiks konkurentide löömine suurema hulga funktsionaalsusega, siis nüüd kerkis (kasvõi Linuxi jt uute tulijate survel) fookusesse turvalisus ja töökindlus ning ümber orienteerumine nõudis väga raskeid pingutusi. Siiski sai Microsoft ülesandega enamvähem mõistlikult hakkama (NB! oluline pole mitte ideaalne õnnestumine, vaid see, et olla klientide jaoks piisavalt hea) ning Linuxi poolt enam otsene häving Microsofti ei ähvarda. Uueks ohuks on saanud hoopis Google ja Apple, turg on liikunud kasutajamugavusele keskendumise faasi. Mis siin lõpuks saab, näitab aeg. Analoogselt on ka mitmed varasemad väga edukad ettevõtted areenilt kadunud.

  • Uutesse faasidesse jõutakse vähemnõudlike klientide kaudu.

Ülaltoodud loos esindas Krants, Kõuts & Kirjak vähemnõudlikku klienti, kellele oli olulisem uue süsteemi kiire omandamine ja hind. Hulkuvate Kasside Riiklik Inspektsioon nõuaks ilmselt veel mõnda aega uusi kelli ja vilesid, kuid millalgi saab ka neil isu täis ja rõhk liigub töökindlusele ning kasutajamugavusele. See on aga kuldne võimalus AS Pärlikesele, kes on harjunud nendele aspektidele rõhuma, et Joostes Marsi käest magus klient ära rabada. Samamoodi õõnestab Ülo&Aivar pidevalt Pärlikese turgu jne.

  • Mida paremat tööd me teeme, seda kiiremini jõuab kätte faasivahetus.

See on ärijuhtidele kõige valusam reegel. Kui teha kõike, mida peetakse eduka äri aluseks: kuulata oma klienti, uurida nende vajadusi, investeerida uutesse tehnoloogiatesse jne, siis tähendab see, et mõnda aega teenitakse head kasumit, kuid seda kiiremini saabub aeg, kus klient küllastub meie poolt pakutavast, tal pole enam rohkem funktsionaalsust (või töökindlust või mugavust) vaja, meie poolt välja töötatud lahenduste loomine muutub odavamaks ning altpoolt tulijal ja järgmisele faasile keskendujal tekib kuldne võimalus hoopis oma väärtust pakkuda.

Ehk siis, mida paremini me töötame, seda kiiremini endale ise auku kaevame.

4 responses so far

Jan 05 2009

Peresõbralike ajagraafikute koostamine

Hulkuvate Kasside Riiklik Inspektsioon tellis tarkvarafirmalt Joostes Marss täiendusi oma andmeregistrile. Ülesandepüstitus oli küllaltki selge ja põhjalik ning projektijuht Joosep küsis programmeerija Priidult, kui kaua asjaga läheb. Neli nädalat, vastas Priit, Joosep pani igaks juhuks puhvri mõttes veel nädala otsa ning teatas klient Kustavile, et viie nädala pärast saab asja kätte.

Priit hakkas asjaga hoolega pihta, Joosep käis regulaarselt pärimas, kuidas läheb, ja üldiselt asi sujus. Nagu programmeerimise puhul ikka ette tuleb, tekkis ka siin ootamatuid viivitusi, kuid viienda nädala lõpuks teatas Priit siiski, et kood on valmis.

Joosep helistas Kustavile, et asjad on korras, aga arvas seejärel, et vaatab ise ka siiski funktsionaalsust. Tulemused tõstsid tal ihukarvad püsti – enamvähem iga viie kliki järel rakendus crashis ja praktiliselt ühtki kasutusjuhtu polnud võimalik algusest lõpuni läbi käia.

Joosep tormas kõva kisaga Priidu juurde, et mis toimub. Aset leidis järgmine kahekõne.

Joosep: Mis bl*#¤% selle koodiga toimub??
Priit: Kood sai just valmis ja kogu funktsionaalsus on teostatud.
Joosep: No aga miks see crashib siis, jo*#¤ma*#¤% ?!?
Priit: No aga keegi pole ju seda testinud, loomulik ju, et koodis pole kõik asjad kohe päris õiged.
Joosep: Kas sa ise ei testinud siis oma asja?
Priit: Testimiseks polnud aega ette nähtud, ise küsisid, et kui kaua teostamisega läheb, mitte testimisega. Ja üldse oled ise üks hu*”%¤% !!

Oops.

Asi lõppes sellega, et Joosep istus ise järgmise paari nädala hilisõhtud töö juures ja testis erinevaid stsenaariume ning käis ka Priidul piitsaga kannul. Mõlemad olid stressis ja magamata, Kustav õiendas iga päev, et mis ikkagi toimub, pidi ju valmis olema, ning kui projekt lõpuks üle anti, tekkis seal ikkagi probleeme, sest testimine polnud nii põhjalik, kui vaja oleks olnud.

Lisaks süüdistasid Joosep ja Priit pidevalt ka teineteist asja nässukeeramise eest, Joosep leidis, et Priidu tulemus ei oleks tohtinud selline olla, Priit omakorda, et kõik on Joosepi süü selle pärast, et projektigraafikusse ei arvestatud testimise ja vigade parandamise aega.

Milles siis tegelikult asi? Minu isiklikus kogemuses ei hävi projektigraafikud mitte niivõrd sellepärast, et hinnangud oleksid ebatäpsed, kui sellepärast, et mingid tegevused unustatakse lihtsalt graafikusse lisamata.

Iidseks vaidluste allikaks on siin, et kes peaks tegelikult hoolt kandma, et kõik tegevused oleks arvesse võetud? Programmeerijad sõimavad enamasti projektijuhte, samas õppis Joosep Audentese koolis rahvusvahelist ärijuhtimist ja kuigi ta saab hästi hakkama kliendisuhtluse ja raha lugemisega, on temalt mõneti utoopiline loota, et ta täpselt teaks, mida kõike üks tarkvaraarendaja peab tegema, et asi valmis saaks. Seda enam, et “valmis” võib tegelikult erinevate inimeste jaoks tähendada väga erinevaid asju, näiteks:

  • Funktsionaalsus on koodiridadena olemas
  • Keegi on rakenduse peamised kasutajajuhud läbi käinud
  • Programmeerija on rakendusele kirjutanud unit testid ja need töötavad
  • Testija on mingi testimisplaani alusel kontrollinud, et funktsionaalsus töötab
  • Tellija on formaalse kava alusel kontrollinud mitmesuguste nõuete täidetust

Jutu peamine moraal kõigile tarkvaraprojektides osalejaile on:

  • Täpsustada, mida nimetatakse valmis olekuks, kuna see on olenevalt inimese taustast ja ametist väga suuresti vaataja silmades
  • Teha vahet lubaduste (commitmentide), ligikaudsete esmärkide ja tõenäosuslike ajahinnangute vahel ning iga mainitava kuupäeva puhul täpsustada, millega on tegemist.

Konkreetselt programmeerijad on mitmel korral mulle kurtnud, et nende ajagraafikud on ebarealistlikud, sest ei võta kõiki tegevusi arvesse. Peamine nõu, mida ma neile olen andnud, on:

  • Tavaliselt on ebarealistlik oodata, et projektijuht ise kõiki tehnilisi tegevusi meeles jõuab pidada ja nende kohta eraldi ajahinnanguid küsida. Seega peaks programmeerija tõusma oma positsioonilt natuke kõrgemale ja ise järele mõtlema, mis on tegelikult projekti õnnestumiseks vaja teha.
  • Selle asemel, et keskenduda oma ajahinnangute kitsale definitsioonile ja anda ainult koodikirjutamiseks kuluv aeg, eelda, et niikuinii tuleb sul teha hulk muid asju nagu unit testide kirjutamine, komponenditestimine, süsteemitestimine, vigade parandamine jne. Kui on teada, et keegi teine mingi osa nendest tegevustest enda kanda võtab, on väga hea, aga üldiselt seda ei juhtu ja vaikimisi on parem need kohe hinnangutena kirja panna. Mõte siis selles, et lõpuks tuleb need tegevused niikuinii ära teha, iseasi, kas ületundidena või mingil mõistlikul ajal.
  • Kuus kuud hiljem ei mäleta üldjuhul keegi, kui kaua see asi tegelikult aega võttis, küll aga mäletavad inimesed hästi, kas 1) tähtajad pidasid 2) kui hästi tulemus toimis. Töötasin kord koos ühe arendajaga, kelle ajahinnangud alati väga kõrged tundusid. Kui teda aga lähemalt üle kuulata, tuli välja, et tegelikult oli ta graafikusse lisanud ka väga täpsed ja detailsed ajahinnangud sellele, kui palju teste ta ise tahab kirjutada, kui palju võtab aega funktsionaalsuse testijale üleandmine ja tutvustamine, potentsiaalsete vigade parandamine jne. Ja tulemuseks oli, et kuigi ta lõpetas oma lõigu nominaalselt teistest hiljem, oli ta projekti testimis- ja stabiliseerimisfaasi lõpuks teistest ees ning tema kood töötas palju paremini kui kellelgi teisel. NB! See ei tähenda, et kõik võiks lihtsalt oma ajahinnanguid hakata kahega korrutama, vaid seda, et inimesel tuleb tõesti hoolikalt järele mõelda, kui palju nendele ekstra tegevustele kulub ja neid detailselt hinnata!
  • Vahel väidavad ülemused või kliendid, et testimine pole oluline, või et selle eest niikuinii ei maksta. Ma arvan, et selline seisukoht on tihti tingitud valdkonna puudulikust tundmisest. Kui keegi tõesti ütleb, et ärme neid lisategevusi graafikusse pane, siis ma soovitan nad enda jaoks sellegipoolest kirja panna ning lihtsalt “koodikirjutamisele” juurde liita. Elu on näidanud, et lõpuks tuleb sellised tegevused nii või teisiti ära teha ja kuna shit flows downhill, näidatakse pärast ikka näpuga progeja peale, et tema tegi halvasti.

5 responses so far

Jul 23 2008

Puugid puuri!

bug.jpg

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.

phone_rage.jpg

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.

 bugjail.jpg

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.

informationoverload.jpg

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.

 insult.gif

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.

No responses yet

May 22 2008

Assumption is the mother of all f*ck ups

iceberg.jpg

Tarkvarafirma Joostes Marss ostis hiljuti AS HüperKonsultantidelt uue HüperGeneraatori(tm) versiooni. HüperGeneraator on kirjade järgi vahend, mis kirjutab programmeerija eest 97,4% koodist ise valmis, joonistad ainult diagrammi ette, vajutad nuppu ja voilà, rakendus ongi olemas.

Järgmises projektis otsustatigi HüperGeneraator täie hooga tegevusse rakendada. Nagu ikka, tehti pärast esialgset analüüsi valmis projekti graafik. Programmeerijad Priit ja Peeter vaatasid eeldatava mahu üle, lugesid vormid-päringud-moodulid kokku ja leidsid, et kuus kuud tööd tuleb kindlasti ära. Projektijuht Joosep polnud nõus: aga HüperKonsultantide demost oli ju näha, et need vormid, mis varem võtsid päeva, võtavad nüüd ainult pool tundi! Üle kahe kuu ei tohiks kindlasti minna! Priit ja Peeter ei osanud ka suurt midagi vastu kosta, Joosepil on uhkem ametinimetus, eks tema teab paremini.

Tippjuht Tõnis vaatas graafiku üle, imestas küll, et kas tõesti saab nii ruttu, aga eeldas, et küllap projektiga lähemalt seotud inimesed teavad paremini. Samamoodi imestas klient Kustav, aga lõpuks löödi siiski käed.

generator.jpg

Tegelikkuses selgus muidugi näiteks, et

  • HüperGeneraator genereerib koodi ainult positiivse stsenaariumi jaoks, igasuguste vigade käsitlemine tuleb hiljem juurde pookida.
  • Vormide asetusest on HüperGeneraatoril küllaltki fikseeritud arusaam ja kui Kustav leidis, et tema töötajad kõiki vajalikke andmeid korraga ei näe, tuli need ringi teha.
  • Sama päringute kohta.
  • Kui midagi oli juba valmis genereeritud ja sinna seejärel muudatusi tehtud, aga äkitselt oli vaja andmemudelit kohendada, siis uuesti genereerimine hävitas muidugi olemasolevad muutused.
  • jne. jne.

Asi lõppes muidugi sellega, et Priit ja Peeter tegid kõvasti ületunde, Joosep kutsuti mitu korda Tõnise juurde vaibale, Kustav sai omakorda ministeeriumi ülemuste käest pähe jne.

Küsimus, kas koodi genereerimine on üldse mõistlik idee, on eraldi teema (sellest millalgi tulevikus), aga praegu on huvitav tähele panna, millistele eeldustele kõik osalised oma tegevuse rajasid. Igas olukorras jaguneb otsuste alusmaterjal kaheks: info, mis tegelikult teada on, ja asjad, mida me eeldame. Olukorras, kus on tegemist millegi tundmatuga (olgu see siis tehnoloogia, teostaja, partner või klient), on teadaolev info suures vähemuses, jäämäe veealuse osa moodustavad eeldused.

Antud juhul:

  • Kõik osalised eeldasid, et HüperGeneraator on antud projekt jaoks sobiv vahend.
  • Priit ja Peeter eeldasid, et Joosepil on eelnev kogemus taoliste vahenditega.
  • Joosep eeldas, et kui programmeerijad juba uue ajagraafikuga nõus on, siis saavad nad sellega ka kindlasti hakkama.
  • Tõnis eeldas, et projektirühm on kava korralikult läbi mõelnud.
  • Kustav eeldas, et Joostes Marsil on tekkinud uued võimalused projekte senisest kiiremini täide viia.

Üks eeldus viis teiseni ja kui projekt lõpuks kümne kuu pärast (sest liiga agressiivselt planeeritud projektid võtavad vahepealse ümbertegemise tõttu veel rohkem aega) valmis sai, ei jõudnud keegi ära imestada, kuidas asjad küll nii hulluks said minna.

Joostes Marss pole teab mis hiigelfirma, aga isegi seal oli halbadel eeldustel katastroofiline tagajärg. Suurtes, paljude inimestega organisatsioonides on eeldustel kriitiline roll. Töötan praegu Microsofti Office’i divisjonis, mis koosneb kümnetest väiksematest produktidest, igaühel omakorda kümned arendajad. Kõik need produktid on omavahel tihedalt integreeritud, kui näiteks SharePoint lisab uue andmetüübi, peavad inimesed Outlooki, InfoPathi, Accessi, ECMi, Searchi ja mitmetes teistes gruppides, mis SharePointist andmeid oskavad lugeda, mõtlema, kuidas seda kõige paremini toetada. Muidugi katsutakse sama ülesande mitmekordset lahendamist vältida, aga see põhjustab enamasti situatsiooni, kus mitmed tiimid ootavad kellegi järel, et need selle ühise lahenduse valmis teeksid, teised tiimid ootavad jällegi esimeste järel jne. Sellises ahelas on rohkesti võimalusi halbadel eeldustel põhinevate otsuste tegemiseks, olgu siis tegemist tehnoloogia, ajagraafiku, inimeste võimekuse või millegi muu valesti hindamisega. Sellepärast tuleb ka panna suurt rõhku uurimisele, mis meie edu jaoks kriitilistes lõikudes tegelikult toimub ja kuidas asjad töötavad. Olulisel kohal on siinkohal näiteks täpsusküsimise ja täpsusvastamise rakendamine.

Eeldused võib jagada mitmesse kategooriasse, millest igaühe kohta saab enamasti küsida häid, täpseid küsimusi. Vaatleme näiteks HüperKonsultantide reklaamlauset:

HüperGeneraator 5.0 on parim projektide läbiviimiseks! HüperGeneraator suurendab teie koodikirjutamiskiirust sada korda!!!

Juba ainuüksi seda lauset lugedes, ilma tehnilistesse detailidesse süüvimata, peaksime mõtlema järgmistele eeldustele, mis selles reklaamis peituvad:

1. Väärtuse eeldus: koodi kiiresti valmimine on hea. Küsimus: kas koodi kiire valmimine on meie projekti juures tegelikult kõige olulisem?

2. Mõõtmise eeldus: koodi hulka ja valmimiskiirust on võimalik mingi ühe mõõdupuu järgi mõõta. Küsimus: kas me saame koodi kirjutamise kiirust mõõta? Kuidas?

3. Võimalikkuse eeldus: koodi genereerimine on alati võimalik. Küsimus: kas koodi genereerimine on alati võimalik?

4. Sihtgrupi eeldus: HüperGeneraator suurendab konkreetselt meie koodikirjutamiskiirust. Küsimus: kas meie oleme toote õigeks sihtgrupiks? Või on tegemist raamatupidajatele, kes tegelikult programmeerida ei oska, mõeldud abivahendiga?

5. Eksistentsi eeldus: meie probleemiks on, et kood ei saa piisavalt kiiresti valmis. Küsimus: kas koodi kirjutamise kiirus on probleemiks? Või võtab mõni muu tegevus hoopis rohkem aega?

6. Kategooria eeldus: Kõik projektid on sarnased ja HüperGeneraatoriga lahendatavad. Küsimus: kas erinevad projektid on võrreldavad? 

7. Samalaadsuse eeldus: meie projektid on samasugused kui teised. Küsimus: kas meie projekt on samasugune kui teised HüperGeneraatoriga lahendatud projektid?

8. Unikaalsuse eeldus: HüperGeneraator on parim vahend koodivalmimiskiiruse suurendamiseks. Küsimus: kas HüperGeneraator on ainus vahend, mida me kasutada saaksime?

9. Ajalise kestvuse eeldus: ka meie tulevased projektid on HüperGeneraatori abil lahendatavad. Küsimus (juhul kui praegune projekt on tõesti HüperGeneraatori jaoks sobilik):  aga meie järgmine ja ülejärgmine projekt?

Sarnaseid eeldusi võib leida igasugustest situatsioonidest. Tulevad näiteks misjonärid ukse taha ja küsivad: “Kas te usute, et Jumal soovib teile head ja armastab teid kogu südamest?”. Selle kohta võiks kohe mitukümmend eeldust leida, aga jäägu see heale lugejale mõtlemiseks :)

No responses yet

May 09 2008

Programmeerija kolm voorust: laiskus, kannatamatus ja edevus

virtue.jpg 

We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” – Larry Wall

Klassikalised kristlikud voorused on: mõistlikkus, mõõdukus, meelekindlus, õiglus, usk, lootus ja armastus. Samas, nii palju kui ma ka ei püüaks klassikalist vooruslikku elu elada, on vähemalt minu naise arvates mind märgatavalt paremini varustatud laiskuse, kannatamatuse ja edevusega. Kuna aga vähemalt professionaalses elus on viimased kolm mind kõvasti rohkem edasi aidanud kui esimesed seitse, siis tuleb ilmselt olukorrast võtta, mis võtta annab :) Siin ei tule asja muidugi nii mõista, et me neid kolme omadust kogu aeg ja igas situatsioonis peaksime kasutama, küll aga on nad meile suureks abiks oma igapäevase koodi kirjutamisel.

 laziness.jpg

Esimene voorus: laiskus

Tarkvarafirmal Joostes Marss tuleb teha Hulkuvate Kasside Riiklikule Inspektsioonile statistiliste aruannete moodul, toomaks eraldi välja, kui palju erinevate ajaperioodide lõikes koeri ja kasse kaotatakse ja leitakse. Jagatakse siis ära: pooled aruanded Priidule ja pooled Pärtlile. Priit hakkab asjaga kohe hoolega pihta, kirjutab ühe lehekülje keerulist andmebaasikoodi teise järel. Ajaperioodide arvestamisel on teatavasti palju erijuhtumeid, teha päringut näiteks juuni viimasest pühapäevast 5. septembrini pole triviaalne ja Priidu kood koosneb lõpuks suurest hulgast if-then-else klauslitest, igaühe sees omakorda keeruline arvutus. Priit muudkui kirjutab, möödub päev ja teine, projektijuht Joosep küsib, kuidas läheb, Priit näitab suurt hulka koodi ja seletab pikalt, kui keerulise ülesandega ikka tegemist on, ja kuidas tal veel kolm korda nii palju koodi tuleb kirjutada, enne kui asi valmis. Kuna koodihulgast on ilmselgelt näha, et asjad edenevad, siis Joosep rahuneb natuke.

Pärtel ei tee samal ajal pealtnäha suurt midagi, nokitseb asja kallal, sirgeldab ühtteist paberile, lõpuks teeb siiski kompilaatori ka lahti. Joosep on mures ja küsib Pärtli käest, et näe, Priidul juba nii palju koodi valmis, mida sina teed? Pärtel vastu, et pole hullu, küll saab. Ja teatab õhtul, et temal on kõik valmis. Joosep ei usu, sest koodi pole pealtnäha nagu ollagi, aga näeb siis, et tõepoolest, kõik töötab, kiiresti ja korralikult. Pärtel ei viitsinud palju koodi kirjutada ja tekitas lihtsalt denormaliseeritud vahetabeli, kuhu enne aruannete koostamist andmed kopeeritakse, ja mille pealt päringute tegemine on selge, lihtne ja lühike.

Tegelikult on laiskus arvutitega lahutamatult seotud. Kuna arvuti on loodud selleks, et inimese eest töö ära teha, poleks virk inimene kunagi sellise leiutise peale tulnud. Hea programmeerija püüab teha kõik, et omaenda vaeva võimalikult vähendada. Las arvuti töötab, tema on rauast. Ma ise pean konkreetset kooditoksimist küllaltki tüütuks ega viitsi sellega palju vaeva näha, selle asemel püüan nuputada, kuidas võimalikult vähese arvu ridadega hakkama saada või üleüldse mõnd olemasolevat komponenti kohandada. Selline nuputamine on palju huvitavam ja inimesele kohasem ning rahuldust pakkuvam tegevus, rääkimata sellest, et tähtajad saavad kiiremini valmis ja ka tulemus on enamasti kvaliteetsem (vigade hulk kipub kasvama koos koodi hulgaga).

Laiskus soodustab veel mitmeid häid harjumusi nagu

  • korduvate tegevuste jaoks spetsiaalsete utiliitide kirjutamine
  • koodi hoolikam testimine ja debugimine (sest tarkvara põhiteoreemi järgi kulub meil testimata ja debugimata koodi peale rohkem aega)
  • selge ja lihtsa koodi kirjutamine, selle kommenteerimine ja dokumenteerimine (et hoida kokku aega, mis muidu kuluks teiste inimeste aitamisele ja rumalatele küsimustele vastamisele)
  • taaskasutatavusele optimiseerimine, et me ei peaks sama koodi mitu korda kirjutama
  • jne

 impatience.jpg

Teine voorus: kannatamatus

Ma arvan, et inimeste kannatamatus on asjaolu, mis on otseselt põhjustanud Moore’i seaduse ja palju muud lahedat.

Kannatamatusega saab mõõta näiteks selliseid asju:

  • Mitu korda ma pean sama koodi uuesti kirjutama, enne kui ma selle jaoks uuestikasutatava mooduli teen?
  • Mitu korda ma viitsin oma programmi testides samu liigutusi teha kuni ma sagedasemate operatsioonide jaoks lühema ja intuitiivsema meetodi välja mõtlen?
  • Kui kaua ma jaksan mingi olemasoleva tarkvara järel oodata enne kui ma parema ja kiirema lahenduse välja mõtlen ja sellega palju raha teenin?
  • Kui kaua ma mõne inimese või teenuse järel ootan, enne kui ma asja ise kiiremini ja efektiivsemalt ära teen või veel parem, automaatse lahenduse leiutan?
  • Kas ma kannatan olukorda, kus inimesed minu tiimis kirjutavad tuhat rida koodi, kui hakkama saaks ka viiesajaga? Või korraldan ma neile koolituse, et nad parematest metoodikatest aimu saaksid?

 pimp.jpg

Kolmas voorus: edevus

Kui Pärtel oli oma aruanded ennetähtaegselt valmis saanud, ei jäänud ta siiski rahule sellega, et juba enne olemas olnud, valmis koodis käisid paljud aruanded liiga aeglaselt. Päringud olid kirjutatud täpselt kliendi tellimuse kohaselt, imiteerides protsesse, mida klient Kustavi alluvuses töötavad kontorirotid enne kas siis Exceli või ka paberi ja pliiatsi abil sooritasid. Selle tõttu kopeeriti ka andmeid liigselt ühest kohast teise, päringud käisid üle seitsmeteistkümne erineva tabeli korraga jne. Pärtel uuris veel natuke asja, kombineeris mõned tabelid kokku, lisas paar indeksit, kirjutas mõne stored procedure’id lihtsalt päringusse lahti jne. Järgmisel päeval ehmus Joosep, et kas kõik testandmed on ära kustutatud või milles asi, et aruanded järsku mitukümmend korda kiiremini toimivad. Pärtlile ei läinudki eriti korda, kas kliendi jaoks on oluline vahe, kas aruanne käib kümme sekundit või kümnendik sekundit, kuid tal oli võimalus näidata, kes on ettevõttes alfaprogrammeerija.

Hubris ei tähenda küll päris täpselt edevust, aga mulle meeldib “edevus” tähendusväljana isegi rohkem. Tegemist on jõuga, mis paneb programmeerijat seatud ärilisi eesmärke ja tehnilisi nõudeid ületama, mis sunnib neid kirjutama eriti elegantset koodi, mis vastab headele tavadele ja standarditele, kuid teeb asju siiski efektiivsel ja isikupärasel moel. Tihti ei pane lõppkasutaja selliseid töövõite otseselt tähelegi, aga edevale programmeerijale on tähtis eelkõige kolleegide imetlus. Seetõttu katsub ta kirjutada koodi, mille kohta kellegil midagi norida ei oleks, mis on tarkvara kvaliteedi seisukohalt muidugi väga hea.

Lisaks koodi efektiivsusele avaldub edevus muidugi ka muudes asjaoludes:

  • Kes saab oma töölõigu esimesena valmis?
  • Kelle koodis on kõige vähem vigu?
  • Kelle tehtud kasutajaliides on kõige uhkem?

Kui edevat programmeerijat selliste asjade eest piisavalt tunnustada, kasvab produktiivsus mühinal, piitsa ja präänikut ei lähe üldse vajagi.

2 responses so far

Mar 19 2008

Täpsusküsitlemine

 informationoverload.jpg

Esimene juhtum. 

Tarkvarafirma Joostes Marss sai hiljuti valmis Hulkuvate Kasside Riikliku Inspektsiooni infosüsteemi uue versiooniga. Pärast paigaldamist selgus aga, et vähemalt klient Kustavi arvates ei kõlba süsteem kassi saba allagi. Parandati-täiendati ja paigaldati uuesti, aga ikka ei kõlba. Veel üks kord ja ikka sama lugu. Lõpuks saadeti Kustavi juurde analüütik Anton, kes viimaks selgeks tegi, mida Kustav tegelikult tahab, aga vahepeal oli möödunud mitu kuud asjatut ajakulu.

Teine juhtum.

Projektijuht Joosep küsib programmeerija Peetrilt, kas töö on valmis. Peeter vastab, et üldiselt on valmis, aga natuke tuleb veel refaktoreerida ja seletab pool tundi, kuidas on väga halb, kui IFoo sõltub IBarist. Järgmisel päeval sama küsimuse peale vastab Peeter, et veel on vaja natuke debugida ning täidab taas Joosepi kõrvad tehnilise žargooniga, kuni viimane ehmunult põgeneb. Nädal hiljem räägib Peeter, et kuna Priidu komponendis on vaja mälulekkeid parandada, ei saa ta ka enda asju üle anda. Joosep on vahepeal Kustavile lubanud, et töö antakse kohe üle ja mõlgutab nüüd musti muremõtteid.

Kolmas juhtum.

Tippjuht Tõnis tahab teada, kas panustada AS HüperKonsultantide pakutavasse uude supermodernsesse tootmismetoodikasse. Analüütikud kiidavad, programmeerijad laidavad, müügimehed näitavad värvilisi slaide, kõik on väga emotsionaalsed ning Tõnise peas valitseb kaos. Lõpuks otsustab Tõnis pakkumise vastu võtta, sest tema naine käib HüperKonsultantide bossi naisega koos spaas.

Neljas juhtum.

Joostes Marss teeb Kustavile vägeva demo ja Kustav kirjutabki alla uue sajamiljonilise lepingu. Hiljem selgub aga, et valminud süsteem ei toeta üldse nii paljusid kasutajaid, kui palju Kustavi asutuses töökohti on, samuti ka mitte nõutavaid andmemahtusid. Teha pole aga midagi, sest vastavaid sätteid pole lepingusse üles tähendatud.

questioning_mind.jpg

Põhimõtteliselt saab kõiki neid situatsioone lahendada, rakendades õigel hetkel kriitilist mõtlemist ja küsides suure hulga väga konkreetseid ja täpseid küsimusi. Täpsusküsitlemine(Precision Questioning) on üks metoodikaid, mis õpetab selliseid küsimusi süsteemselt esitama, kuigi ma ei tea, kas Eestis keegi selle levitamisega on tegelenud. NB! PQ ei asenda kindlasti tavalist suhtlemist, vaid on lihtsalt üks vahendeid, mida teatud situatsioonides kasutada!

PQ põhineb formaadil üks lühike küsimus/üks lühike vastus, mille põhjal küsitakse järjest uusi küsimusi. Rohkete küsimuste esitamine soodustab kriitilist mõtlemist ning lühike formaat samm-sammulist lähenemist, mis aitab hoida teemat laiali valgumast ja laseb küsitlejal oma peas asjadest selge ülevaate saada.

Tavaelu PQ näited on näiteks ristküsitlemine kohtus, suuline eksam ülikoolis või presentatsioon riskikapitalistidele. Tarkvaraga seotud situatsioonid on mitmesuguste spetsifikatsioonide inspekteerimine, kliendi vajaduste kaardistamine, kriitilises seisus projekti olukorrast ülevaate saamine ja muidugi kõik rahakulutamisega seotud juhtumid.

Ühisteks joonteks on siin:

  • Olukord, kus kogu info ei pruugi tingimata tõene olla
  • Vigade tegemisel on tõsine hind
  • Materjali loomus võimaldab samm-sammulist lähenemist

Näide (Edit: see näide on natuke utreeritud, tegelikkuses on täitematerjali muidugi natuke rohkem, aga infoedastuse seisukohalt jääb mõte samaks):
Küsimus: Kas teine moodul saab neljapäevaks valmis?
Vastus: Jah, tegelikult isegi kolmapäevaks.
K: Ja prototüüp saadetakse Kustavile reedel?
V: Ei, sellega läheb järgmise teisipäevani.
K: Millest see viivitus?
V: Kaks põhjust, Priidul läheb töö ülevaatamisega kauem aega ja kujundajatel pole ikoonid veel valmis.
K: Kas Priidu viivitust oleks saanud ette näha?
V: Ei, tal oli vaja projekt Dünamo jaoks mõned kriitilised vead ära parandada.
K: Kas see võib põhjustada täiendavaid viivitusi?
V: Hetkel ei tea, küsin Priidu käest.
K: Miks ikoonid veel valmis pole?
V: Rudolf libises vannitoas seebi otsas, vigastas kätt ega saanud paar päeva tööle tulla.
K: Mida see viivitus meie jaoks tähendab?
V: Pikas perspektiivis on kõik korras, lühiajaliselt peame paar päeva ületunde tegema.
K: Kas lõpptähtajaks saab kõik valmis?
V: Praeguse arvestuse järgi jah.
K: Kas miski võib selles osas muutuda?
V: Ma olen mõelnud, mis saab, kui Dünamoga muid probleeme tekib.
K: On see tõenäoline?
V: Ei tea, räägin nendega homme ja küsin.
K: Mis on halvim võimalik stsenaarium?
V: Nad jäävad hiljaks ja põhjustavad meile lisaviivitusi.
K: On meil võimalik Dünamo asemel midagi muud kasutada?
V: Probleem pole otseselt nende viivituses, vaid selles, et testijad on siis kõik Dünamo peal ega saa meie projektiga tegeleda.

Ilmselt on selge, et tegemist pole tavalise jutuajamisega, vaid üks pool juhib vestlust väga konkreetse infokogumise eesmärgiga ning teine aitab talle kaasa, vastates konkreetselt ainult sellele, mida talt küsitakse, ilma et tekiks infoüleujutust. Mõistagi on vajalik, et pooled mängivad samade reeglite järgi ning igapäevases tavasuhtluses ei tule selline formaat kõne alla, kuid teatud situatsioonides on täpsusküsitlemine väga vajalik oskus.

Milliseid küsimusi küsida, sellest tuleb juttu järgmistel kordadel, luban vekslina, et suvalise keskmiselt informatiivse lause kohta on võimalik küsida 70 erinevat küsimust :)

No responses yet

Feb 17 2008

Tarkvaratootmise põhiteoreem I

Published by Targo under Joostes Marss, Põhialused

bug_cost.jpg

Tarkvaratootmise põhiteoreem on ambitsioonikas pealkiri, aga tegemist on niivõrd fundamentaalse asjaoluga, et väiksemat nimetust pole ka mõtet kasutada. Pealegi, kui pokkeril võib oma põhiteoreem olla, olgu siis ka tarkvaral.
Sõnastus siis:

Vea parandamise hind kasvab aja möödudes.

Lihtne ja elementaarne, eks? Samas on praktiliselt kõik ebaõnnestunud tarkvaraprojektid võimalik taandada põhiteoreemi mingis vormis eiramisele ja enamik tarkvarametodoloogiaid tegelevad põhiteoreemi tagajärgede pehmendamisega.
Enamik tarkvaraga tegelejaid mõistab seaduspärasuse olemust intuitiivselt, kuid ei pruugi taibata selle täit ulatust. Näiteks programmeerija ei pruugi mõista, et juba analüüs ja disain, millel tema kood põhineb, on vigased ja nende parandamiseks tuleb suur osa koodist ümber kirjutada. Projektijuht ei taipa jällegi, et väga tähtis on värskelt kirjutatud koodile kohe ka mõned testid kirjutada, et vead saaksid parandatud, kui programmeerija peas kõik veel värskelt meeles on. Kasutajapoolsest mittetaipamisest saab juba eraldi artikli kirjutada :)

Sõna “maksumuse” definitsioonist: Tarkvara maksumuse all pean ma üldjuhul silmas inimtundide arvu, mis sellesse on pandud, olgu siis analüüsi, kodeerimise, parandamise, testimise või muuna. Efektiivne projektihaldamine minimiseerib seda tegelikku maksumust ja püüab ülesande lahendada minimaalse energiakuluga. See kehtib nii vaba kui ka kommertstarkvara puhul. Hind, mida tegelikult kliendilt küsitakse, on juba teine teema.

Kõige hullemad näited tarkvaratootmise põhiteoreemi eiramisest on enamasti seotud tellija vajaduste puuduliku tundmaõppimisega.

  • Näide 1: Kurikuulsamaid näiteid ebaõnnestunud tarkvaraprojektidest oli FBI Virtual Case File süsteem. Projektiga tegelejad rajasid süsteemi lähtudes tavaliste kontoritöötajate kogemustest, inimestel on tööjaam, kohtvõrk, andmed jooksevad kõik andmebaasist jne. Ainult et FBI agendid ei ole tavalised kontoritöötajad, nad liiguvad “objektidel” ringi ja neil on vaja andmeid kaasa võtta ning ka offline’is sisestada. Ja keegi ei tulnud ka selle peale enne, kui süsteemi juurutama hakati. Kui palju võtab aega olemasolevale süsteemile turvaliste offline-võimaluste juurdepookimine, võib igaüks ise nuputada, kuid antud projekt katkestati (selle ja paljude, paljude muude probleemide tõttu) pärast 170 miljoni dollari maksumaksja raha kulutamist. Kui vajadused oleks tuvastatud õigeaegselt, oleks kogu süsteemi loodud hoopis teistel alustel ning tohutu hulk aega oleks jäänud raiskamata.
  • Näide 2, natuke lähemalt: analüütik Albert (nimed ja muud konkreetsed faktid siin ja edaspidi muudetud, kuid põhinevad sellegipoolest tõestisündinud seikadel) Eesti tuntud tarkvarafirmast Joostes Marss vestles klient Kustaviga Hulkuvate Kasside Riiklikust Inspektsioonist, et luua infosüsteem kasside nummerdamiseks. Kustav oli igati asjalik ja pädev, rääkis, et on vaja seda ja seda, joonistas isegi tahvlile skeeme jne, aga Albert ei pannud mitte kõike juttu kirja, vaid eeldas, et oh, see on kõik lihtne, teeme ära. Projektijuht Joosep oli äsja lõpetanud majanduskooli ega tulnud selle peale, et Alberti tööd üle vaadata. Programmeerija Peeter aga, ilma konkreetse spetsifikatsioonita peale selle, et “see on kõik lihtne, tee ära”, oli aga teisel arvamusel lihtsusest ja loodu sarnases kliendi joonisega nagu raudteejaam lennujaamaga, pealtvaadates nagu sarnane, aga olemuselt midagi hoopis muud. Eesti riik on õnneks leplik ja asi tehti suurema pahanduseta ringi (ringitegemise kulu siis ka sarnane raudteejaama lennujaamaks ümber ehitamise kuluga). Parandamise hind oleks võinud olla mitu suurusjärku väiksem, kui analüütiku viga oleks korraliku projektijuhtimise poolt kinni püütud ja Albert kliendi juurde tagasi saadetud korralikke märkmeid tegema enne, kui Peeter ridagi koodi oleks jõudnud kirjutada.
  • Metoodiline lahendus mõlema näite puhul: spetsifikatsioonide ülevaatamine, milles osalevad nii kliendi- kui ka tööettevõtjapoolsed projektijuhid, lõppkasutaja ja tehniliste teostajate esindajad.

Muidugi pole analüütikud ainsad, kes vigu teevad, programmeerijate elus võib pisikesi näiteid põhiteoreemi rakendamisest leida igal sammul:

  • Näide 3: Peeter kirjutas just uue protseduuri ja vajutas nuppu Compile. Samal ajal küsis teine programmeerija, Priit, temalt, mis vahe on SendMessage‘il ja PostMessage‘il. Seletuse lõpetanud, leidis Peeter, et kompilaator oli leidnud tema koodist kolm viga, kuid kuna värskelt kirjutatud kood oli Peetri lühiajalisest mälust välja uhutud, kulus tal lisaks veel kümme minutit, et meelde tuletada, mida ta ennist oli tegemas ja vead parandada. Näide on eelmistega võrreldes mikroskoopiline, aga kui selliseid väikesi segajaid, mis takistavad programmeerijal vigade kohest parandamist, tuleb päevas ette palju, kahaneb tema produktiivsus mitukümmend protsenti.
  • Metoodiline lahendus: töökeskkond, kus programmeerijal on võimalik vaikselt keskenduda, ja töökultuur, kus inimestel on kombeks lihtsatele küsimustele ise kiirelt MSDNist vastuseid leida.

mad-dog.gif persiankitty.jpg

  • Näide 4: Priit leiab, et tema kirjutatav uus hulkuvate kasside andmebaasipäring teeb enamvähem sedasama, mis hulkuvate koerte päring, ja teeb kiire copy/paste. Päring on aga keeruline ja ühes kohas jääb “koer” kogemata “kassiga” asendamata, tekitades olukorra, kus varjupaigas pannakse marutaudis rotveiler Raudhamba asemel magama hoopis pärsia kass Viktooria, kellele omanik järgmisel päeval järele pidi tulema. Lisaks tarkvaraparandusega seotud kulule oleme jõudnud kahjudeni muudes valdkondades.
  • Metoodiline lahendus: iga rida koodi vaadatakse kellegi teise poolt üle. Tihti juhtub, et kui inimene vaatab omaenda kirjutatud teksti, libiseb ta detailidest alateadlikult üle, aga teisele inimesele torkab kohe silma, kuhu koer on maetud. Koodiülevaatusele kulunud aeg: 30 minutit, vea parandamisele kulunud aeg: 3 minutit. Vea parandusele ja kliendi juures paigaldamisele kulunud aeg, kui ülevaatust ei toimunud: mitu inimpäeva, halvemal juhul veel palju rohkemgi, pluss kohtukulud. (Loomulikult on ka vahepealsed võimalused, kus viga tuleb testimises välja, aga ka siis on testimise+vea raporteerimise+diagnoosimise+parandamise kulu kõvasti suurem kui esialgne 33 minutit.)

(järgneb)

One response so far