Miks mulle meeldib Scrum? Vastab Scrum Master!
Lugedes LHV IT-juhi Rainer Tiki kirjutatud artiklit “Miks mulle ei meeldi Scrum”, ei saanud ma esialgu aru, kuidas on võimalik Scrumist nii kirjutada. Kuid järele mõeldes, võib leida rea põhjuseid, miks asjadest saadakse erinevalt aru. Ka Scrumist.
Eks kõik proovime leida keerukas maailmas toimetulemiseks erinevaid meetodeid. Probleemid, millega kokku puutume ei ole tihti selged ja ühemõõtmelised. Minule see iseenesest meeldib, sest see loob võimalusi ja väljakutseid. Ma arvan, et ei ole üldse halb, kui toetume millelegi, mis aitab leida tööelus tasakaalu, loogilisust ja kasutada tervet mõistust (e. common sense). Nagu seda pakub Scrum.
Scrum kui tööriistakast
Scrum on raamistik, mis oma olemuselt on väga lihtne, ilma suurte keerukusteta. Seda võib nimetada ka tööriistakastiks, kus olemas põhilised vahendid, kuidas oma tööd võimalikult hästi korraldada.
Tööriistakast aitab järgida agiilset mõtteviisi, väärtusi ja põhimõtteid. Kui nüüd meistrimees on sinna kasti ostnud juurde veel erinevaid vahendeid, mida ta ehk nii hästi kasutada ei oska, ei saa süüdlaseks pidada töövahendit ega ka tööriistakasti. Kõiki töövahendeid ei saa ilma õppimata kasutada. Võib, aga paraku olen praktikas palju kogenud, et sellega kaasnevad probleemid ja väärkastus.
Räägime sprintidest
Scrumis on kirjeldatud sprintimine kui võimalus keskenduda kokkulepitud ajaks ühise eesmärgi täitmisele. Sprindi lõpus peab valmima töötav ja tarnimiseks valmis tarkvara tükk. Scrum raamistikku kasutav arendustiim teab, et agiilse tarkvaraarenduse manifesti üks põhimõtetest on tarnida kvaliteetset tarkvara võimalikult sageli.
Scrum ei keela pidevat lakkamatut tarnet. See põhimõte ei ole kuidagi vastuolus Scrumiga. Samuti ei ole Scrumi järgi mingit nõuet tarneks üksnes sprindi lõpus.
Miks üldse sel juhul sprintida? Sprindiga saab tiim endale seada fookuse ja lühiajalise eesmärgi. Seda selleks, et me ei rööprähkleks ning oleks selge fookus ja ka töörahu. Olen tähele pannud, et arendustiimid soovivad sageli sprintida ka siis, kui keskkond on muutlik ja sprinti on teinekord raske planeerida.
Sprint annab teatava kindluse määramatus maailmas. See annab rütmi ja loob turvatunde. Ka katkematu ja pideva tarne tingimustes on tiimil sprindi lõpus võimalik tutvustada tulemusi ja teha kokkuvõtteid. Kui need ei ole saavutatud, saab teha järeldusi ja otsuseid, mida teha järgmisel korral teisiti.
Agiilne tiim väärtustab pidevat õppimist ja oma tööviiside täiustamist – iga järgmine sprint on tiim parem. Scrum on empiiriline, sest õpime kogemusest ja kohaneme.
Sprindil on ka see eelis, et kui arendustiimi ümber on palju erinevaid huvigruppe, siis stiilis „olge head ja tehke see asi ka kiirelt ära“ palved ei kuku automaatselt tiimi töölauale. Seal on justkui vahefilter, mis võib oskuslikul kasutamisel olla ülimalt tõhus. Eri tüüpi ülesannete vahele võtmine segab keskendumist ja võib ohustada eesmärgi saavutamist. Seetõttu soovib Scrum tiim selle jätta pigem erandiks kui reegliks.
Ennustamise kunst ehk planeerimine
Kui sprindime, siis peame ka planeerima – 1–2 nädalat ette. Võib väita et see on kasutu ennustamine ja läbikukkumine on mängu osa. Kas ikka on? Võib vaielda, et planeerimiseks kulub palju aega ja tegelikult võiks selle asemel juba koodi kirjutada. Kui tiimi tööjärg (backlog) on korras, siis sprindi planeerimine läheb lihtsalt ja kiirelt. Jah, planeerimise osana tuleb võtta ka sprinti planeeritavate tööde tiimiga läbiarutamist ja sageli ka hindamist. Aga hindamine ei ole vajalik mitte kellegi teise, kui vaid tiimi enda jaoks.
Sprindi planeerimise tarbeks tehtav hindamine ei ole ennustamine või suvaline hämamine. See on vajalik esmajoones selleks, et kõik tiimiliikmed saaksid aru, mis on järgmiste ülesannete sisu ja eesmärk.
Hindamisi saab kasutada töövahendina mitte eesmärgina omaette – kui tiim on otsustanud kasutada punktide abil hindamist, siis selle peamine väärtus on see, et hindamisel selgub, kas kõik tiimiliikmed on ülesandest samaväärselt aru saanud. Praktikas tuleb ka väga kogenud ja hästi töötavatel tiimidel ette suurel määral erinevusi, kui hinnatakse ülesande keerukust. Olukorra tekkides arutatakse ning leitakse optimaalne lahendus. Tiimina.
Kui Scrumi puhul hakata keskenduma ainult mõõtmistele ja numbritele, mis muuseas ei ole Scrum raamistikus üldse kirjeldatud (vt Scrum Guide), siis oleme sattunud valele teele. Scrum raamistik ei räägi midagi punktidest (story points), jõudlusest (velocity), graafikutest (burndown, cumulative flow) ega muust sellisest. Mainitud on vaid seda, et sprinti planeerides tuleb arvestada tiimi võimekusega (capacity).
Kuidas seda teha, on juba edasise meisterlikkuse küsimus.
Kõik erinevad mõõdikud ja näitajad, mille abil parandada planeerimist ja ennustatavust, on kasutusele võetud kui arendusprotsessis abistavad töövahendid Scrum tööriistakastis. Sinna võib neid lisada nii palju kui vaja – näiteks poolelioleva töö piiramise võtteid (WIP liimits), väljundi mõõdikuid (cycle time, lead time, throughput jne) jne. Neid kasutatakse, sest nad on abiks. Nende nimel ei tee õige agiilne tiim kunagi tööd. Praktiseerigu ta Scrumi või midagi muud.
Oma kogemustele tuginedes saan aga siiski väita, et tiimi jõudluse (velocity) andmete kasutamine lühiajaliste prognooside tegemisel võib osutuda päris edukaks. See muidugi ei välista, et ka muud meetodid töötavad hästi.
Lõpetuseks
Scrum tiimi eesmärk iga sprint peab olema alati väärtuse loomine kliendile, kasutajale. Õige agiilne tiim töötab selleks, et klient saaks kiiresti kätte selle tarkvara, mida tal on vaja. Kui me unustame Scrumi rakendades ära peamised Scrumi alused ja väärtused, siis ei saa rääkida Scrumi rakendamisest. Siis sarnaneb see ühe järjekordse kultusega, kus usk välistab kriitilise meele ja teeme asju pimesi. See aga ei ole Scrum. Igat head asja annab kuritarvitada, ka Scrumi.
Scrum tiim peab lugu agiilse tarkvaraarenduse manifestist ning teab Scrumi väärtuseid ja aluspõhimõtteid. Töö pideva enesetäiendamise ja väärtuse loomise rütmis tagab stabiilse ja turvalise keskkonna, mis soodustab loovust ja efektiivsust. Tiim teab, et mõõdikute eesmärk on muuta töötamine tõhusamaks ja töökeskkond paremaks, stressivabamaks. Ikka selleks, et teha head tööd – luua väga head tarkvara.
Scrumi juhend ütleb Scrumi kohta järgmist: Scrum on kerge, seda on lihtne mõista, aga keeruline käigus hoida.
Kristi Paas
Agile coach, Scrum Master & koolitaja
Lugu ilmus 20. juuni 2020 Agilemasters.ee blogis.
Faktid
Kristi Paas alustas koos Einar Koltšanovi (CSM) ja Andri Vanemaga (CSPO) koolitamist IT Koolituses. Koolituskalendris on kaks teemat: "Agiilse arenduse põhialused" ja "Tooteomanik - põhialuste koolitus".
Tutvu koolitusega - Agiilse arenduse põhialused
Tutvu koolitusega - Tooteomanik – põhialuste koolitus
