Päevariim:

Tulemas on reliis,
järjekordne kriis.

Arutasime kolleegidega lõunalauas järgmise reliisi teemadel, mille käigus kerkis üles küsimus – millal oli viimane reliis, mis polnud järjekordne kriis? Peale mõningast meenutamist pidime tunnistama fakti, et keegi meist ei ole midagi sellist kunagi kogenud.

Edukas reliis – on see võimalik? Optimistlikumad arvasid, et see on võimalik. Pessimistlikumad jäid seisukohale, et see on müüt.

Olgugi, et võimalikkuse osas jäime eriarvamusele, jõudsime siiski ka ühe kokkuleppeni. Tulevikus *hakkame reliisiharusid nimetama RELEASE_1, RELEASE_2 jne. asemel CRISIS_1, CRISIS_2.

* Kui protsessid, protsessi- ja reliisijuhid vahele ei sekku.

On ammuteada tõde, et programmeerija tööülesannete hulka kuulub pidev ennustamine ja kõikvõimalike olematute probleemidega arvestamine või nende lahendamine.

Alljärgnev on eluline näide ühest sellisest hetkest tarkvaraarendaja igapäevatöös.

13:17 <n> kas sa saaksid mulle mõned kasutuslood saata?
13:17 <n> proovin siis analüüsida
13:17 <n> ja sinu vajadusi ette aimata
13:18 <n> mul on üks selline task ühes projektis, ette näha võimalus, et kunagi peab integreerima ühe teise süsteemiga
13:18 <n> seda süsteemi veel pole, keegi ei tea milline see tuleb, aga võimaluse peaks ette nägema
13:27 <w> sellised ülesanded on lahedad
13:27 <n> see task võttis pmõtselt 1 sekund aega
13:27 <w> ignore lihtsalt?
13:27 <n> mhmh
13:28 <n> ma nägin ette, et kunagi on vaja midagi teha

Tavaliselt nii hästi ei lähe, et ettenägemiste peale kulub vaid sekund. Enamasti kulub selliste asjade peale kuid, kui mitte aastaidki. Ma usun, et meie ettevõttes oleks kulutatud suur osa projekti ajast liideste loomisele, mille abil ehk kunagi tulevikus tehtav teine süsteem võib-olla kuidagi siduda. Ja projekt aina venib ja venib …

Kohtumine ülitähtsa kliendiga. Projektijuht rõhutas korduvalt just selle kliendi tähtsust meie ettevõttele. Ja seekord kutsuti sellele kohtumisele ka mind – tavalist programmeerijat! Tundus ülimalt veider, sest selliseid asju ei juhtu iga päev, mil tarkvaraarendajaid kliendiga kohtuma lubatakse kutsutakse.

Koosolekule olid lisaks minule, analüütikule ja meie projektijuhile kohale tulnud ka kliendipoolne projektijuht, nende IT juht või midagi sarnast.

Pole vist väga suureks üllatuseks, kui ma ütlen nüüd, et selle kokku saamise eesmärgiks oli lubatud tähtaja ületamine. Vestlus kulges alljärgnevalt.

Kliendi projektijuht: “Kokkulepitud tähtajast on möödunud 8 nädalat ning tulemust ei ole veel kusagil?!”
Mina (mõttes): “Ah? 8 nädalat? Mis asja?”
Meie projektijuht: “Jah, me mõistame täielikult Teie pahameelt, aga me anname endast parima, et järgmise nädala lõpuks asjad valmis saaks”
Mina (mõttes, seekord veel valjumalt): “???”
Kliendi IT juht: “Meile tundus isegi 4 nädalat väga pika tähtajana tööle, mida on võimalik ära teha 1 nädalaga!”

Siis jooksis minu juhe kokku. Millisest ühe nädalasest projektist nad räägivad? See millega tuleb veel vähemalt 8 nädalat tööd teha? Või on mind kogemata vale projekti kohtumisele kutsutud? Kohtumine jätkub.

Meie projektijuht (mulle otsa vaadates): “Ole hea ja seleta Jürile, mis takistused meil selle projektiga, et sellega nii kaua veninud on?!”

Vaatan talle kõigepealt suure hämminguga otsa ja peas kõmiseb “… nii kaua veninud on?“. End veidi kogununa üritan midagi seletada, et miks minu hinnangul 4-5 kuuline projekt (selle jätan igaksjuhuks välja ütlemata) ei saanud ei nelja ja veel vähem ühe nädalaga valmis.

Peale koosolekut projektijuhilt küsides, et kuidas oli minu pakutud 4-5 kuust saanud neli nädalat, sain äärmiselt lakoonilise vastuse: “Me pidime selle kliendi omale saama ja muidu poleks nad nõus olnud!”

Ma ei mõista miks ta üldse vaevus mu käest hinnangut küsima, kui lõpuks nagunii lubati välja mingi suvaline kliendile sobilik tähtaeg, mida pole võimalikki täita?

Tuttav: “Me oleme tööl 100% agile!”

Mina: “Ah??!!”

Tuttav: “Noh, täna hommikul saime kätte projekti, mille deadline on kolme päeva pärast, kuigi tööd on vähemalt 3-4 nädalaks. Me peame olema tõeliselt väledad, et õigeks ajaks valmis jõuda!”

—-

Lahkasin sama teemat oma kolleegidega ja töötasime välja väga huvitava särgi kavandi. Kõhu osale kirjutaks markeriga “100% AGILE“, seljale joonistaks leegid ning õlgadele kleebiks kiiruse rõhutamiseks turbulentsirõngad.

Ära kukkunud projekti asemel (palgapäev saab olema üllatus, sest siiani ei ole ma teada saanud mis palgast saab) anti mulle täna uus, millele tahaks väikese nurga siin blogis pühendada.

Projektidokumentatsioon, nagu alati, oli üsna mahukas ja kasutu, aga selle järgi ei tundunudki asi väga hull. Põnevamaks läks siis, kui sain kätte koodi kuhu see uus projekt lisada tuli. Arvake ära milline see oli olemasoleva projekti struktuur?

/
  img/
    *.jpg|gif
  script/
     *.js
  index.php

Ja see ainus php fail (index.php) oli 14 829 rida pikk! Täis arusaamatut ning täiesti struktureerimata koodi.

Kusagilt algab php kood, kusagil echotakse html, kusagil lõpetatakse ära php tag ja kirjutatakse lihtsalt htmli. if/for/while blokid on aegajalt 14-15 korda teineteise sisse nestitud (keegi teab head vastet eesti keeles?). Kõik kohad on täis mingeid muutujaid, mis hoiavad endas olekut. Mõistlikest muutujate ja funktsioonide nimedest ei maksa rääkidagi – $x, $asd, $lol, $lehmakook … Mõnes kohas on näha, et eelmised progejad on kuulnud objekt orienteeritud programmeerimisest ja teinud mõned klassid staatiliste funktsioonide grupeerimiseks.

Oma töös olen varemgi kokku puutunud sarnase OFP (one file programming) lähenemisega, mis ei ole PHP maailmas üldse mitte haruldane nähtus. Aga seekordne on ikka uskumatu leid. Üritasin täna sellesse süveneda, aga see osutus lootusetuks, sest täiesti võimatu oli sellest koodist aru saada ja ka sellest kuidas selline asi üldse töötada saab.

Ma näen juba oma järgmist ebaõnnestunud projekti. Loomulikult anti ka väga “mõistlik” tähtaeg sellele, mida minuga ei vaenunud keegi kooskõlastama – aitäh!

PS. OFP on ise välja mõeldud termin ja seda ei pruugi leida teaduslikus kirjanduses.