Jan 05 2009

Peresõbralike ajagraafikute koostamine

Published by Targo at 5:05 pm under Joostes Marss, Programmeerijad, Projektijuhtimine

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

5 Responses to “Peresõbralike ajagraafikute koostamine”

  1. e:ron 05 Jan 2009 at 5:30 pm

    Ülalmainitu on IMO arendajakeskne lähenemine.. nö common sense mõttes hea nõuanne kahtlemata.

    Mis mind nörritab on see, et olukord, kus tarkvaralahendusi tarniva ettevõtte projektijuht tarkvaraprojektide olemusest väga sügavat arusaama ei oma, on võrdlemisi tavaline.

    Funktsionaalsed nõuded (kasutuslood) on reeglina äris orienteeruvale inimesele väga hästi arusaadavad, aga tehnilise platvormi ja metoodika valik, mittefunktsionaalsed nõuded, testimine, juurutamine jne võivad tunduda teisejärguliste teemade või arendaja targutamisena.

    Ma julgen väita, et projektijuht pole sellisel juhul talle pandud ülesannete kõrgusel.

    Hea müügioskusega – kliendi äri alase teadmisega, kuid IT-mõistmiseta inimese rolliks sobiks hästi “müügimees”, võib-olla suuremas ettevõttes “tootejuht”. Või kui see inimene tõesti IT projektijuhiks satub, tuleks osapooltel omavahel tavalisest hulga põhjalikumalt ja ettevaatlikumalt suhelda ja kokku leppida ning meeles pidada, et

  2. Juhanon 05 Jan 2009 at 5:46 pm

    Õige point minu arust, viimaselt Devoxx konverentsilt jäi ka just kõrvu ühe tähtsama poindina: “arendajad kipuvad andma täpseid ajahinnanguid … kui nad võtavad arvesse kõik aspektid”. Seepärast on väga oluline, et arendaja saaks ajahinnagu andmiseks aega ja et hea projektijuht küsiks üle – kas sa seda ja seda arvestasid, kui ajahinnangu andsid. St tasub lasta asi arendajal endal ka pulkadeks võtta või vähemalt üle kontrollida, et arendaja selle pulkadeks võttis, mitte ei andnud mingit numbrit puhtalt kõhutunde järgi.

  3. Targoon 05 Jan 2009 at 5:56 pm

    e:r, kurb tõsiasi on see, et enamikus organisatsioonides (mulle tundub, et Eestis kehtib see eriti, kuna siin on suurem puudus inimestest) pole valdav enamik töötajaist (programmeerijast tippjuhini) oma ülesannete maksimumdefinitsiooni kõrgusel (Peteri printsiip – http://en.wikipedia.org/wiki/Peter_principle).
    “Projektijuht” on amet, kelle kaela aetakse pea kõik probleemid, mis ette võivad tulla, aga nii perfektseid projektijuhte, kes selle kõigega ka ideaalselt hakkama saaks, on terve Eesti peale ehk kümmekond tükki.
    Seega ideaalis olen nõus, praktikas on uppuja päästmine enamasti uppuja enda asi.

  4. Tarmoon 06 Jan 2009 at 2:00 pm

    Julgeks veel väita, et eksiteerib peaprogrammeerija/vastutav arendaja jmv. roll(id), kus olev arendaja peaks tegelema teiste arendajate juhendamise ning kontrolliga. Kontrollida võiks ka teiste arendajate ajahinnanguid ning nende puudustele (ajahinnagud testimise, bugfixi jmv kohta) viidata ja vajadusel täiendada. Eriti kehtib see nooremarendajate poolt antud ajahinnagute kohta.

    : Kusjuures just eile oli väike vestlus kaasarendajaga teemal “Miks klient ega projektijuht ei taha testimisest eraldi miskit kuulda” ehk siis klient ei taha maksta ja projektijuht ei taha testimise tunde anda (õige progeja kirjutab kvaliteetset koodi ja bugisid polegi).

    Nokk lahti, saba kinni…

  5. Margoon 14 Jan 2009 at 11:43 am

    Ma soovitaks lugeda Scrum arenduse meetoodikat. See annab arendajal võimaluse ise hinnata oma töid ja kuluvat aega. Scrumis on kõik tulemusele orienteeritud ning kõik asjaosaliseld suhtlevad ja vahetavad informatsiooni ja taolised probleemid peaksid suhteliselt kiiresti välja tulema.

    http://en.wikipedia.org/wiki/Scrum_(development)

    Edu!

Trackback URI | Comments RSS

Leave a Reply