Autor: Rainer Tikk • 9. aprill 2020

LHV IT-arenduse juht: miks mulle ei meeldi Scrum

Kuigi Scrum on saavutanud tarkvaraarenduse meetodina "ainuõige" kultuse, on seal kasutatavatel tehnikatel olulisi vajakajäämisi, mistõttu mina seda ei soovita.

Järgneb LHV panga IT-arenduse juhi Rainer Tiku kommentaar:

Uuringute järgi läheb üle aja või ebaõnnestub täielikult 75% IT-projektidest.
Foto: Pixabay

Tarkvara arendust ja selle protsesse võib teha ja üles ehitada väga paljudel erinevatel viisidel, kasutades erinevaid metoodikaid, printsiipe ja tehnikaid. Tavaliselt võetakse aluseks midagi populaarset ja kui teadmisi rohkem, hakatakse seda enda vajaduste järgi paremaks tuunima.

Kõige tuntum neist ja ilmselt kõige lihtsam viis alustamiseks on Scrum. Teadupärast on Scrum väga spetsiifiline metoodika, mis surub tiimi kohe alguses väga konkreetsetesse raamidesse. See võib alguses tunduda hea ja lihtne, aga hiljem võib raamidest välja tulemine ja oma protsesside arendamine olla isegi keerukam. Siis tekibki küsimus, kas Scrum on ikkagi parim valik.

Pean tunnistama, et mulle pole Scrum kunagi väga meeldinud ning nendest põhjustest ka räägin. Esiteks häirib mind see, kuidas Scrumi müüakse (mitme tuhande eurosed koolitused ja sertifitseerimised) ja kuidas ta on saavutanud "ainuõige" kultuse ja kogunud enda taha jüngrid, kes pimesi justkui "valguse poole" tormavad. Väga sarnane Apple´i kultusele.

Aga see pole kindlasti põhjus, miks ma Scrumi ei kasuta (v.a mõningad Scrumi nüansid). See on pigem andnud ajendi vaadata mujale ja otsida alternatiive. Seda olen ma teinud umbes viimased kümme aastat ja hea meelega jagan mõtteid.

Scrumi puudujäägid

Kui tänapäevaseid tehnoloogiaid kasutada ja mõelda näiteks reliisimisprotsessile (CI/CD), kus toodangusse on võimalik panna iga arenduspilet eraldi või lausa iga commit - seega reliisida igal ajal ja ükskõik kui tihedalt -, siis olgem ausad, kahenädalane tsükkel selle kõrval ei tundu väga agiilne.

Tänane tehnoloogia võimaldab protsessi mõttes keskenduda flow´le, kus reliisimine on no-brainer ja igasugune suurem kuhjamine (batches) on jäänud ajalukku. Samuti ei saa ma väga aru mõnest tseremooniast nagu näiteks sprint planning. Istume terve tiimiga tunde ümber laua ja hindame ning "tükeldame" arendust? Ja mis siis saab, kui tuleb arendus, mille sisendiks on väline 1000-leheküljeline spetsifikatsioon? Leani mõistes on selline tegevus raiskamine.

Selles kirjatükis tahan keskenduda kahele asjale - hinnangud ja sellega seotud Scrumi story points ning mõõdikud, mida kasutatakse progressi hindamiseks. Mulle tundub, et Scrumi tehnikatel on nii olulisi vajakajäämisi, et enne nende kasutusele võtmist tasuks neile kriitilisemalt mõelda.

Miks hinnangud ei tööta

Igasugune hinnangute andmine on Lean´i mõistes raiskamine - see on tegevus, mis tegelikult ei loo väärtust. Üks asi on sinna alla pandud aeg, teine on tulemus. Kas me tegelikult saame sellest midagi muud peale kellegi arvamuse ajakulu kohta? Ning tihtipeale on see hinnang hoopis teine, mis tegelik ajakulu.

Uuringute järgi läheb üle aja või ebaõnnestub täielikult 75% projektidest. Selle kohta on ka mitmeid humoorikaid seadusi sõnastatud, näiteks Hofstadteri seadus või Parkinsoni seadus. Põhjuseid, miks me tulevikku ennustada ei suuda, on palju - tellija ei tea, mida ta tegelikult tahab; nõuded ei ole kunagi täielikud ega lõplikud; kontekstid (äri, ühiskond, kliendi vajadus jne) muutuvad, scope creep jne. Kindlasti teate ütlust, et "kurat peitub detailides". Ja lõpuks pole keegi meist ilmselt selgeltnägija, kes näeb tulevikku ja teab juba ette, mida kliendid tahavad.

Vähe sellest, hinnangud ei ole tihti ainult asjatud raiskamised, vaid võivad olla ka kahjulikud. Hinnanguid võetakse lubadustena (ja aeg hakkab tavaliselt kohe tiksuma). Hinnangute juures ei saada ka enamasti aru, kas need käivad mahu või aja kohta, mis on aga väga erinevad asjad.

Samuti on võimalik, et tiimi enda antud hinnangud mingil põhjusel "ei sobi" ja kõrgemalt sõidetakse neist üle või survestatakse tiimi neid muutma, rääkides sealjuures suuremast efektiivsusest või pühendumisest (commitment).

Nimekirja võib jätkata. Kõik see tekitab aga pingeid ja stressi, mis pikemas perspektiivis ei ole jätkusuutlik ega anna kuidagi paremaid tulemusi.

Kui hinnangust saab väärtus

Hinnangute andmise juures on veel üks oluline negatiivne nüanss. Kogu see hinnangute andmise mentaliteet on tulnud projektipõhisest arendusest (aeg, raha, skoop). Tavapärane projektijuhtimise stiilis lähenemine seab hinnangu pjedestaalile ja olulisemaks tegelikust prioriteedist.

Väärtus, mida luuakse, pole enam nii oluline ja hinnangust ise saabki justkui see "väärtus". Siis on juba lihtne teha "odavamaid"/"kiiremaid" asju enne ja algab garanteeritud allakäik keskpärase toote arendamise suunas. Ning samas liigutakse ka kaugemale igasugusest agiilsusest.

Kui niigi kaheldavale tegevusele panna veel juurde story points keerukus ja hägusus, siis läheb asi veelgi segasemaks. Üks Agile Manifesto väärtusi on kliendikommunikatsioon (customer collaboration). Hea kliendisuhtlus tähendab, et räägime kliendiga temale arusaadavas keeles. Story points´idest kliendile rääkima minemine ei ole nende keeles rääkimine. Või kui keegi on enesehävituslike kalduvustega, siis võib proovida minna CEO-le selgitama, mis asi on story point.

Eksitavad mõõdikud

Scrumi mõõdikutega - velocity ja burndown graafik - on sama probleem. Esiteks ei saa klient sellest aru, teiseks ei anna need vajalikku nähtavust, et vastata küsimustele, mis klienti ka tegelikult huvitab. Näiteks, millal valmis saab?

Isegi kui ajaloolist velocy´tit kasutada tuleviku prognoosimiseks, on see väär, sest Backlog kasvab ja me ei tea selle tuleviku mahtu ning story points jätab ikkagi valemisse hinnangu sisse. Kui vaadata päriselu burndown-graafikuid, siis ega ma ei saa aru, mis küsimusele need üldse vastama peaks.

Need mõõdikud ei anna soovitusi ning nende pealt ole ka võimalik teha otsuseid, mida teha siis, kui asjad hapuks lähevad. "Tööta rohkem ja kiiremini", "hinda paremini", "planeeri paremini" ei ole jätkusuutlikud lahendused.

Velocity kasutamise alternatiivid

Scrumil on ilmselgelt puudujääke, kuid mis võiksid siis olla mõistlikud alternatiivid ja paremad lahendused? Siin peaks kõigepealt mõtlema sellele, miks neid asju üldse tehakse. Ilmselt me sellest ei pääse, et klient/tellija tahab ikkagi teada, millal tema arendus valmis saab ja kui palju maksma läheb. Vähemalt ligikaudselt. Ütleme, et need on ratsionaalsed põhjused.

Kindlasti on ka emotsionaalseid põhjuseid - et sa saaks kliendile midagi öelda ja ta ei helistaks vahetpidamata; et keegi saaks rahulikumalt magada; et ülemused saaks aru, et sa oled võimeline projekte juhtima jne. Üldiselt tahetakse aru saada, mis toimub (nähtavus) ja milline on progress.

Samas, küsimuse, et millal valmis saab, asemel on ka paremaid küsimusi. Näiteks: arvestades tänast progressi ja järele jäänud tööd, millal arendus lõpeb? Või: arvestades tänast progressi, kui palju saab kuupäevaks X arendusest tehtud?

Siin tulevad mängu mõisted #NoEstimates ja Actionable Metrics. #NoEstimates hõlmab endas mitmeid väga häid praktikaid, mida võiks järgida, sh pakub #NoEstimates, et hinnangute andmise asemel võiks kasutada prognoosimist. Actionable Metrics jällegi räägib detailsemalt mõõdikutest ja graafikutest, mille abil saab vastuseid põletavatele küsimustele ning juhtnööre, kuidas oma arendusprotsess (flow) kontrolli all hoida.

Prognoosimine - viis hinnangute eemaldamiseks

Alustada tulekski ehk sellest, et hinnang ja prognoos on tegelikult väga erinevad asjad. Lihtsustatult, hinnang on kellegi arvamus mahu, hinna, väärtuse vms kohta. Prognoos on seevastu mingi analüüsi tulemus, mis baseerub reaalsel olemasoleval andmestikul. Olemasoleva andmestiku põhjal prognoosimine vs pelgalt kogemuse pealt millegi arvamine on nende kahe lähenemise fundamentaalne erinevus.

#NoEstimates läheneb prognoosimisele üsna lihtsalt. Tuleb hakata mõõtma tehtud töid ajaühikus. Mis täpselt on töö - arenduspilet, story vms ei oma erilist tähtsust. Tükeldamine on selle juures küll oluline, aga see ei ole selle artikli teema. Samuti võib ise valida ajaühiku, olgu see siis päev, nädal, kuu või sprint.

Kui teame, kui palju töid jõuab teha ühes ajaühikus ja teades, kui palju töid on veel teha, saame me hakata prognoosima vastuseid nendele samadele ülaltoodud põletavatele küsimustele.

Toon näite. Tiim on toimetanud neli nädalat ja ära teinud selle aja jooksul 20 tööd, mis teeb viis tööd nädalas. Teades, et 50 tööd on veel teha, saame me vastuse küsimusele - kaua läheb, et kõik tööd ära teha? 50/5=10 nädalat. Samuti saame me näiteks prognoosida, kui palju saab tehtud järgmise viie nädalaga? 5*5=25 tööd.

Positiivne on siin see, et prognoos põhineb päris elul - see arvestab igapäevast "mitte-kasulikku" aega, teisi sisse jooksvaid teemasid, koosolekuid, haigusi jms. Aga mitte ühtegi arvamust ega kõhutunnet.

Teine positiivne nüanss on see, et nende tööde suurus ei ole suures pildis oluline, sest töö suurus keskmistub ajas ära. Sama kehtib ka story points´ide kohta, st et kas see töö on üks, kaks või kolm punkti, ei oma tähtsust.

Lisaks võib nendele prognoosidele muidugi lisada erinevaid marginaale jms, mis annavad prognoosidele vahemikud. Marginaalid baseeruvad samuti andmestikul, näiteks analüüsitava andmestiku standardhälve.

Viimane pigem oluline asi prognoosi ja hinnangu vahel on see, et kui prognoosi saab teha olemasoleva andmestiku põhjal, siis hinnangute andmiseks tuleb meeskonnaliikmete tavapärane töö katkestada ja kutsuda nad üsna igavale koosolekule, et saada neilt hinnangud uute tööde kohta. Korduvad koosolekud hinnangute andmiseks, mis ei tõsta prognoositavust ega nähtavust, võivad ka meeskonna motivatsiooni negatiivselt mõjutada.

Rakendatavad mõõdikud

Iga mõõdiku mõõtmine ja rakendamine on samuti investeering (raha, aeg). Seda investeeringut oleks mõistlik teha mõõdikutesse, mis annavad vastuseid ja aitavad teha otsuseid. Actionable Metrics keskendub protsessi (flow) mõõdikutele ja selle protsessi kontrolli all hoidmisele. Samuti pakub ta graafikuid, mis annavad väga hea pildi sellest, mis toimub ja kus midagi valesti võib olla.

Kogu seda asja implementeerida pole enam nii lihtne ja rakenduvad printsiibid, millest kinni pidamine nõuab päris korralikku distsipliini. Siiski on ka siin paar lihtsat võtet, mida kohe saaks rakendada.

Actionable (Agile) Metrics defineerib kolm põhilist mõõdikut:

Work In Progress (WIP) - tööde arv, millega tiim hetkel tegeleb;

Cycle Time - kui kaua võtab aega, et üks töö läbiks kogu protsessi;

Throughput - kui palju töid jõutakse ühes ajaühikus (päev, nädal, kuu) ära teha.

Pane tähele, et Throughputist me juba eelmises peatükis rääkisime (näite põhjal Throughput = viis tööd nädalas). Selguse huvides olgu ka märgitud, et Velocity (story points ja hinnangud) ja Throughput (reaalne elu) ei ole samad asjad.

Kui neid mõõdikuid jälgida, siis saab juba mõnele põletavale küsimusele vastuse. Cycle Time vastab küsimusele, et kui kiiresti saab tehtud ühe töö, kui meeskond on selle tegemisse võtnud. Throughput vastab küsimusele, et kui mitu asja saab teatud ajaks tehtud.

Nende mõõdikute vahel on väga lihtne seos, mida nimetatakse Little's Law:Cycle Time=WIP/Throughput. See ütleb meile ühe väga olulise protsessi põhitõe - mida rohkem on tiimil asju töös, seda rohkem võtab aega, et need asjad ära teha.

Ehk kui tiim tahab asju kiiremini tehtud saada, tuleb tegeleda vähemate asjadega korraga. Tundub jube lihtne ja loogiline, aga praktika pigem näitab vastupidist. Seega, keskendu WIPile ja elu läheb juba palju paremaks.

Actionable Metrics räägib ka graafikutest nagu Cumulative Flow Diagram ja Cycle Time Scatterplot. Need on tugevalt seotud eelmainitud mõõdikutega ja annavad palju infot möödaniku kohta ning aitavad küsida õigeid küsimus, kuidas protsessi parendada. Selleks aga, et need graafikud näitaks matemaatiliselt õigeid numbreid, tuleb järgida mitmeid printsiipe ja nagu mainisin, siis nende järgmine nõuab distsipliini.

Samuti on nende joonistamiseks vaja juba tarkvara ja tavaline Excel pigem ei päde. Olgu ka siin tõe huvides öeldud, et antud graafikud ei ole mõeldud tuleviku prognoosimiseks, vaid minevikku vaatamiseks.

Siit tuleneb jälle huvitav nüanss. Kui teil on mõni uhke projektide haldustarkvara, mis rõõmsalt pritsib samu või sarnaseid graafikuid (näiteks Control Chart) ja te ei tea midagi protsessi printsiipidest, siis võite kindlad olla, et need numbrid näitavad aiateibaid.

Viimase asjana toob Actionable Metrics lauale samuti prognoosimise. Seda küll hard-core-stiilis - läbi Monte Carlo simulatsioonide. Antud simulatsioonid annavad lisaks eelpool räägitule ka juba tõenäosused jms (näiteks, et x tööd saab y kuupäevaks 80% tõenäosusega tehtud), aga nende simulatsioonide jaoks on vaja tarkvara ja kõike eelpool räägitut ehk kvaliteetset andmestikku.

Teha saab erinevat moodi

Minu eesmärk ei ole siin olnud Scrumi või hinnangute andmist materdada. Eks igaüks teeb nii, nagu talle sobib ja see on täiesti OK. Teeme me ju erinevad asju, erinevates keskkondades ja erinevate inimestega. Ka fookus võib olla erinev - kiirus, kvaliteet, väärtuse loomine, nähtavus, paindlikkus või hoopis aeg-raha-skoop. Kõike korraga ilmselt ei saa ning igaüks peab leidma oma tee.

Minu eesmärk on olnud pigem panna teid mõtlema alternatiividele ja leidma omale parimaid lahendusi. Mõned räägitud asjad on nii lihtsad kasutusele võtta, et seda võiks teha juba homme. Mõned vajavad rohkem aega ja on keerulisemad. Algus on alati raske, samas kui juba pihta hakatakse, siis tuleb ka motivatsioon edasi liikuda. Vähemalt sinna maani, et ise rahul oleks.

Liitu ITuudiste uudiskirjaga!
Liitumisega nõustud, et Äripäev AS kasutab sinu e-posti aadressi sulle uudiskirja saatmiseks. Saad nõusoleku tagasi võtta uudiskirjas oleva lingi kaudu. Loe oma õiguste kohta lähemalt privaatsustingimustest
Indrek KaldITuudised.ee toimetajaTel: 511 1112
Anne WellsReklaami projektijuhtTel: 5880 7755