11. Scrumi rakendamine tarkvaraprojektis
Scrumi rakendamine tarkvaraprojektis
Väikestes avalikes tarkvaraprojektides kasutatakse üha enam Scrumi metoodikat, et hoida arendus organiseerituna ja suutlikuna kiirelt väärtust tarnida. Järgnevalt vaatleme, kuidas Scrum on praktikas rakendatud ühes sellises projektis – kuidas toimub sprintide planeerimine ja läbiviimine, milline on rollijaotus tiimis, kuidas käsitletakse sprindiloge ja tagasivaateid ning milliseid tööriistu kasutatakse. Samuti analüüsime, millise ärimudeliga projekt end üleval peab – kas freemium, annetused või avatud lähtekoodiga kommertsteenus. Näidetena käsitleme Ghost blogiplatvormi.
Scrum väikese projekti arenduses: rollid ja rituaalid
Väikese arendustiimi puhul tuleb Scrumi põhimõtted kohandada tiimi suurusele. Olulised rollid on siiski olemas: Product Owner (tooteomanik), kes haldab toote nägemust ja backlog’i (tegevuste järjekorda) ning tagab, et tiim teeks kõige olulisemat tööd. Scrum Master tegeleb protsessi sujuvusega – korraldab sprindi alguse koosolekud (sprint kick-off), igapäevased lühikoosolekud (stand-up’id) ning sprindi lõpus toimuvad ülevaatus- ja tagasivaatekoosolekud. Arendustiim ise fokusseerib funktsionaalsuse teostamisele, andes Product Ownerile pidevalt tagasisidet ja hinnanguid töömahu kohta.
Sprintide planeerimine toimub tavaliselt eelneva sprindi lõpus või vahetult uue alguses. Näiteks on ühe avatud projekti praktikas juurutatud “tulevase sprindi eestvedajad”, kes juba eelmise sprindi jooksul rühmitavad backlog’is olevad teemad loogilisteks epikuteks ja pakettideks järgmise sprindi tarbeks. Enne uue sprindi starti vaadatakse need ettevalmistatud lood (user stories) ja ülesanded ühiselt üle, hinnatakse need ning kinnitatakse sprindi sisu. Hinnangud tehakse sageli story point meetodil (nt Fibonacci jada kasutades) ning arvestatakse iga tiimiliikme mahtuvust – väikestes tiimides planeeritakse tihti, et arendaja suudab umbes 3-4 story point’i nädalas tarnida. Oluline on hoida sprint lühikese ja teravdatuna: eelistatud sprindi pikkus on 1–3 nädalat, et tagasiside oleks kiire Väikestes tiimides võib juhtuda, et mitte kõik liikmed osalevad igas sprindis; kriitiline on vältida “täitetöö” lisamist lihtsalt inimeste hõivatuna hoidmiseks fookus peab olema prioriteedil.
Sprindi läbiviimise käigus peetakse igal päeval lühike daily stand-up, kus iga tiimi liige raportib, mida ta tegi, mida plaanib teha ja kas miski takistab tööd. Scrum Master juhib neid stand-up’e ning jälgib, et kui keegi on blokeeritud, siis otsitakse kiirelt lahendus. Väikese projekti puhul toimub palju suhtlust ka reaalajas vestluskanalite kaudu (nt Slack, Discord) või asünkroonselt GitHubi kommentaarides. Oluline on läbipaistvus – kuna projekt on avalik, siis sageli on ka tööülesanded ja koodimuudatused avalikult jälgitavad backlog’is või issue tracker’is.
Sprindi tulemuste ülevaatus (sprint review) ja tagasivaade (retrospective) on iga iteratsiooni lõpus tähtsad rituaalid ka väikestes tiimides. Ülevaatuskoosolekul demonstreeritakse valminud funktsionaalsust; Product Owner juhib arutelu, et saada tagasisidet ning veenduda, et toode liigub õiges suunas. Seejärel viiakse läbi retrospektiiv, mida juhib Scrum Master – tiim arutab, mis läks hästi, mis vajab parandamist, ja lepib kokku konkreetsetes parendusettepanekutes järgmisteks sprintideks. Tihtipeale pannakse need kokkulepitud tegevuspunkte kirja ja jälgitakse nende täitmist järgmiste sprintide jooksul. Isegi väikeses projektis aitab regulaarne tagasivaade protsessi järjepidevalt täiustada ning tiimi õppimiskõverat kiirendada.
Ghost – Scrum startup-stiilis ja ärimudeliks open-source SaaS teenusena
Ghost on 2013. aastal Kickstarterist alguse saanud avatud lähtekoodiga blogiplatvorm, mille ümber on tänaseks kasvanud välja väike rahvusvaheline tiim. Ghosti arendus on hea näide sellest, kuidas väike startup kasutab Scrumi, et fokusseeritult toodet arendada, samas olles kogukonnale avatud. Ghosti tiimis on selgelt defineeritud rollid: ettevõtte asutaja John O’Nolan täidab sisuliselt Product Owneri rolli, seades prioriteedid (millised funktsioonid on järgmiseks väljaandes vajalikud) ning hoides visiooni kirgas. Scrum Masteri roll võib väikestes tiimides olla kas eraldi inimene või jaotatud – Ghostis on see pigem de facto roll, mida täidab projektijuht või kogenum arendaja, kes hoolitseb, et sprindid algaksid ja lõpeksid korrektselt ning takistused saaks eemaldatud. Arendustiim (umbes paarikümne liikmeline meeskond üle maailma) töötab kahe-nädalastes sprintides, tarnides iga iteratsiooniga mõne uue funktsionaalsuse või täiustuse platvormile.
Ghosti tiim planeerib sprinte kasutades kombinatsiooni GitHubi issue’itest ja oma toodet/teenust. Kuna kogu Ghosti koodibaas on avalikult GitHubis saadaval, hallatakse seal ka veaparanduste ja ettepanekute järjekorda. Stratēegilisem tooteplaan (roadmap) oli varasemalt avalik Trello-tahvel, kuid hiljem on kolitud GitHub Projectsile, kus saab backlog’i ja sprinte hallata. Iga sprindi alguses valib Product Owner koos tiimiga GitHubi backlog’ist välja kõrgeima väärtusega üksused – olgu see siis uus feature nagu integratsioon mõne kolmanda osapoole teenusega või oluline veaparandus – ning need märked lisatakse aktiivse sprindi milestoni alla. Tiim hindab need ülesanded enne sprindi starti (Sageli teevad Ghosti arendajad ligikaudsed hinnangud päevades või story point’ides Slacki arutelude käigus). Seejärel lukustatakse sprindi sisu.
Sprindi jooksul kasutab Ghosti meeskond igapäevaselt Slacki kiireks infovahetuseks ja GitHubi töövoogu koodimuudatuste üle vaatamiseks. Iga arendaja töötab oma ülesannete kallal, tehes pull request’e Ghosti GitHubi reposse. Daily stand-up meetingud toimuvad videokõnena, arvestades meeskonna hajutatust erinevates ajavööndites – see võib tähendada, et osad stand-up’id on asünkroonselt kirjalikud (nt kirja teel postitades eelmisel päeval tehtu ja täna plaanitu). Scrum Master hoiab silma peal, et keegi liialt kõrvale ei kalduks sprindi eesmärgist ning et takistused (näiteks mõni blokeeriv bugi või viivitus kood ülevaatusel) saaks lahendatud. Ghosti tiim kasutab ka automaatseid teste ja pidevat integreerimist (CI) – need on osa Definition of Done’ist, mis on Scrumile omane kvaliteedi tagamise võte.
Sprindi lõppedes teeb tiim väikese demo või ülevaate. Kuna Ghost on ka kommertstoode (neil on maksvad kliendid Ghost(Pro) teenuse näol), on sprindi ülevaatus sisuliselt miniversioon toote release’ist: tiim vaatab üle, mis sai valmis ja kas see on releasitav. Sageli toimub iga paari sprindi tagant ka suurem versiooniväljalase, mida kommunikeeritakse Ghosti ajaveebis kasutajatele. Tagasivaate raames arutatakse tiimis, kuidas sprint läks – Ghost on tuntud kui täielikult kaugtöö ettevõte, seega pööratakse tähelepanu ka meeskonnatunde hoidmisele ja kommunikatsiooni sujuvusele. Näiteks võib retrospektiivis ilmneda, et “pull request’ide ülevaatused kuhjusid sprindi keskel” või “ülesannete hinnangud olid liiga optimistlikud” – Scrum Master märkib need probleemikohad üles. Järgmiseks sprintideks võetakse vastu parendusotsused (nt lepitakse kokku, et iga arendaja peab vähemalt kord päevas vaatama üle ka teiste koodi, et PR-id ei jääks toppama). Selline pidev protsessi täiustamine on Scrumi tuum, mida ka Ghostis rakendatakse, kuigi sellest avalikult palju ei räägita. (Sisemiselt peab Ghosti tiim Confluence’i või Google Docsi kujul tõenäoliselt sprindilogi, kuhu need õppetunnid kirja lähevad – see on tüüpiline praktika.)
Ärimudeli poolest esindab Ghost avatud lähtekoodiga kommertsteenuse lähenemist. Ghosti tarkvara on kõigile tasuta kättesaadav (MIT-litsentsiga) ja igaüks võib selle ise oma serverisse püsti panna. Samas pakub Ghosti arendustiimi haldav mittetulundusühing (Ghost Foundation) ka tasulist hostimisteenust Ghost(Pro) neile, kes eelistavad mugavust – kuutasu eest saab kasutaja Ghosti veebilehe, automaatsed uuendused ja tehnilise toe. Kogu teenusest teenitud tulu reinvesteeritakse Ghosti arendusse ja infrastruktuuri. Sisuliselt toimib Ghost freemium-ideoloogial: platvorm ise on vaba, aga mugav teenus on tasuline. See mudel on võimaldanud Ghostil kasvada majanduslikult jätkusuutlikuks – näiteks viie aasta järel teenis Ghost(Pro) piisavalt, et katta ~25 liikmega tiimi kulud. Ghosti näide illustreerib, kuidas avatud lähtekood ja Scrum võivad käia käsikäes kommertseesmärgiga: regulaarsed sprintid tagavad, et maksvatele klientidele jõuavad pidevalt uued funktsioonid ja parandused, samal ajal kui avatud koodibaas kaasab ka vabatahtlikke panustajaid (kes tihti raporteerivad vigu või isegi kirjutavad mõne paranduse).
Kommentaarid
Postita kommentaar