Kas ta Scrum metodika ir kodėl visi apie ją kalba
Jei dirbate IT srityje, tikriausiai jau ne kartą girdėjote apie Scrum. Galbūt net dalyvavote daily stand-up’uose, nors ne visai supratote, kodėl reikia kas rytą stovėti ir pasakoti, ką vakar veikėte. O gal jūsų komanda jau seniai naudoja Scrum, bet kažkaip viskas vyksta chaotiškai ir niekas nežino, ar tai tikrai Scrum, ar tiesiog savotiškas chaosas su fancy pavadinimais?
Scrum – tai agile projektų valdymo metodika, kuri IT komandose tapo beveik religija. Ir ne be reikalo. Gerai įdiegta Scrum sistema gali iš tikrųjų transformuoti komandos darbą, padidinti produktyvumą ir, kas svarbiausia, padaryti darbo procesą skaidresnį ir malonesnį. Bet štai problema – dauguma komandų daro Scrum neteisingai. Jie ima atskirus elementus, sumaišo juos su senosiomis praktikomis ir stebiisi, kodėl rezultatai ne tokie, kokių tikėjosi.
Scrum sukūrė Jeff Sutherland ir Ken Schwaber 1990-ųjų pradžioje, kai programinės įrangos kūrimas buvo tikras košmaras. Projektai užtrukdavo metus ar net ilgiau, o rezultatas dažnai neatitikdavo poreikių, nes per tą laiką reikalavimai jau būdavo pasikeitę. Scrum pasiūlė radikaliai kitokį požiūrį – trumpus darbo ciklus (sprintus), nuolatinį grįžtamąjį ryšį ir lankstumą.
Scrum komandos anatomija: kas už ką atsakingas
Viena didžiausių klaidų, kurias mačiau įmonėse, – tai neteisingas vaidmenų supratimas. Žmonės mano, kad Scrum Master yra tiesiog naujas projekto vadovo pavadinimas, o Product Owner – tai kažkas, kas sėdi kažkur viršuje ir kartais atsiunčia el. laiškus su reikalavimais. Realybė visiškai kitokia.
Product Owner yra tas žmogus, kuris atstovauja produkto vizijai. Jis priima sprendimus, kas bus daroma ir kokia tvarka. Jis tvarko Product Backlog – užduočių sąrašą, kuris nuolat keičiasi pagal prioritetus. Geras Product Owner yra prieinamas komandai, supranta verslo poreikius ir gali greitai priimti sprendimus. Blogas Product Owner – tas, kuris išnyksta savaitėms, o paskui grįžta su visiškai naujais reikalavimais ir stebiasi, kodėl komanda nepatenkinta.
Scrum Master nėra vadovas tradicine prasme. Jis neduoda užduočių ir nesako, kaip jas atlikti. Jis yra tarsi komandos treneris ir kliūčių šalintojas. Kai kažkas trukdo komandai dirbti efektyviai – ar tai būtų biurokratija, techninės problemos ar konfliktai – Scrum Master stengiasi tai išspręsti. Jis taip pat padeda komandai laikytis Scrum principų ir nuolat tobulėti.
Development Team – tai patys kūrėjai. Scrum filosofijoje komanda turėtų būti savivaldi ir kryžminių kompetencijų. Tai reiškia, kad komanda pati sprendžia, kaip atlikti užduotis, ir gali susidoroti su visais darbo aspektais – nuo dizaino iki testavimo. Ideali komandos dydis – 5-9 žmonės. Mažiau – per mažai įvairovės, daugiau – komunikacija tampa sudėtinga.
Sprintai: kaip suskaidyti darbą į valdomus gabalus
Sprintas – tai Scrum širdis. Tai fiksuotos trukmės laikotarpis (paprastai 2-4 savaitės), per kurį komanda įsipareigoja sukurti konkrečias funkcijas ar produkto dalis. Pabaigoje turėtumėte turėti kažką veikiančio, ką galima parodyti ar net paleisti į produkciją.
Daugelis komandų klysta pasirinkdamos per ilgus ar per trumpus sprintus. Dviejų savaičių sprintai dažniausiai yra auksinis viduriukas. Jie pakankamai trumpi, kad išlaikytų fokusą ir greitai gautumėte grįžtamąjį ryšį, bet pakankamai ilgi, kad galėtumėte sukurti kažką vertingo. Vienos savaitės sprintai dažnai tampa per intensyvūs – per daug susirinkimų proporcingai darbo laikui. Keturių savaičių sprintai – per ilgi, nes per tą laiką gali pasikeisti prioritetai.
Svarbiausia taisyklė – sprintas yra fiksuotas. Jei sprintas trunka dvi savaites, jis visada trunka dvi savaites. Jokių „šį kartą padarysime trijų savaičių sprintą, nes turime daugiau darbo”. Tokia disciplina padeda komandai išmokti geriau planuoti ir įvertinti savo pajėgumus.
Sprint Goal – tai trumpas sakinys, kuris apibūdina, ko norite pasiekti per sprintą. Ne tiesiog „padaryti 15 užduočių iš backlog”, o kažkas konkretesnio, pvz., „įgyvendinti naują mokėjimo sistemą” ar „pagerinti puslapio įkėlimo greitį 50%”. Turėdami aiškų tikslą, komanda gali geriau priimti sprendimus sprintu metu.
Ceremonijos, kurios neturėtų būti tik formalumas
Scrum turi keturias pagrindines ceremonijas (arba „events”, jei jums labiau patinka šis terminas). Problema ta, kad daugelyje komandų jos tampa nuobodžiais ritualais, kurie tik eikvoja laiką. Tačiau teisingai atliekamos, jos yra neįkainojamos.
Sprint Planning vyksta kiekvieno sprinto pradžioje. Čia komanda susitinka ir nusprendžia, ką darys per ateinantį sprintą. Product Owner pristato prioritetines užduotis iš backlog, komanda klausia klausimų, diskutuoja ir įvertina, kiek darbo gali įsipareigoti padaryti. Geras Sprint Planning trunka apie 2-4 valandas dviejų savaičių sprintui.
Dažniausia klaida – Product Owner tiesiog „priskiria” užduotis komandai. Scrum filosofijoje komanda pati pasirenka, už ką įsipareigoja. Tai ne smulkmena – kai žmonės patys pasirenka savo įsipareigojimus, jie jaučia didesnę atsakomybę ir motyvaciją.
Daily Scrum (arba daily stand-up) – tai trumpas 15 minučių susitikimas kiekvieną dieną. Kiekvienas komandos narys atsako į tris klausimus: ką padariau vakar, ką darysiu šiandien, ar yra kažkas, kas man trukdo. Tai ne statusas vadovui – tai komandos sinchronizacija. Jei kas nors užstrigo, kiti gali pasiūlyti pagalbą. Jei kažkas dirba ties kažkuo, kas priklauso nuo kito žmogaus darbo, jie gali koordinuotis.
Praktinis patarimas: tikrai stovėkite. Skamba kvailai, bet tai veikia – susirinkimai būna trumpesni. Ir nediskutuokite problemų sprendimų daily metu – tiesiog identifikuokite jas ir susitarkite, kas po susitikimo pasigilins.
Sprint Review vyksta sprinto pabaigoje. Komanda demonstruoja, ką sukūrė per sprintą. Tai ne formali prezentacija – tai darbo sesija, kur kviečiami stakeholderiai, gaunamas grįžtamasis ryšys ir diskutuojama, kas toliau. Turėtų trukti apie 1-2 valandas.
Sprint Retrospective – mano asmeniškai mėgstamiausia ceremonija. Po Review komanda susėda ir aptaria, kas gerai vyko per sprintą, kas ne, ir ką galėtų pagerinti. Tai ne kaltinimų sesija – tai saugi erdvė eksperimentuoti ir tobulėti. Gera retrospektyva baigiasi konkrečiais veiksmais, kuriuos komanda įsipareigoja išbandyti kitame sprinte.
Backlog valdymas: menas išlaikyti tvarką chaose
Product Backlog – tai prioritizuotas sąrašas visko, kas gali būti reikalinga produkte. Jis niekada nėra baigtinis – nuolat atsiranda naujų idėjų, klaidų, patobulinimų. Ir čia prasideda tikras iššūkis.
Geras backlog yra tarsi gyvas organizmas. Viršuje yra aiškiai suformuluotos, detalios užduotys, kurios paruoštos imti į artimiausiuosius sprintus. Žemiau – mažiau detalios idėjos, kurios gali būti aktualios ateityje. O dar žemiau – miglotos koncepcijos, kurios galbūt niekada nebus realizuotos.
User stories – tai populiariausias būdas aprašyti backlog užduotis. Formatas paprastas: „Kaip [vartotojo tipas], aš noriu [funkcionalumo], kad galėčiau [pasiekti tikslą]”. Pavyzdžiui: „Kaip registruotas vartotojas, aš noriu galėti išsaugoti savo mėgstamiausius produktus, kad galėčiau greitai juos rasti vėliau”.
Kodėl toks formatas? Nes jis verčia mąstyti apie vertę vartotojui, o ne tik apie techninius sprendimus. Bet realybėje ne viskas gali būti user story – kartais turite techninius darbus, refaktoringą, infrastruktūros patobulinimus. Ir tai visiškai normalu.
Backlog refinement (arba grooming) – tai nuolatinis procesas, kai Product Owner kartu su komanda peržiūri ir patikslina būsimas užduotis. Paprastai tam skiriama apie 10% sprinto laiko. Tai padeda užtikrinti, kad Sprint Planning nevirstų maratonu, nes užduotys jau yra pakankamai aiškios.
Įvertinimai ir velocity: kaip matuoti, neužmušant motyvacijos
Viena kontroversiškiausių Scrum dalių – užduočių įvertinimas. Daugelis komandų naudoja story points – santykinį sudėtingumo matą. Idėja ta, kad vietoj to, kad spėliotumėte, kiek valandų užtruks užduotis (o visi žinome, kaip blogai mes tai darome), įvertinate santykinį sudėtingumą.
Populiarus metodas – Planning Poker. Kiekvienas komandos narys turi korteles su skaičiais (dažniausiai Fibonacci seka: 1, 2, 3, 5, 8, 13, 21). Kai aptariama užduotis, visi vienu metu parodo savo įvertinimą. Jei įvertinimai labai skiriasi, tie, kurie davė didžiausią ir mažiausią įvertinimą, paaiškina savo samprotavimus. Po diskusijos balsuojama iš naujo, kol pasiekiamas konsenusas.
Velocity – tai kiek story points komanda vidutiniškai atlieka per sprintą. Po kelių sprintų matote tendenciją ir galite geriau planuoti. Bet čia slypi pavojus – kai vadovai pradeda velocity naudoti kaip našumo metriką ir spausti komandas „padidinti velocity”. Tai visiškai prieštarauja Scrum filosofijai ir veda į tai, kad komandos dirbtinai išpučia įvertinimus.
Praktinis patarimas: velocity yra tik komandos planavimo įrankis, ne našumo rodiklis. Niekada nelyginkite skirtingų komandų velocity – kiekviena komanda turi savo skalę. 20 story points vienoje komandoje gali būti ekvivalentas 50 kitoje.
Dažniausios klaidos ir kaip jų išvengti
Per metus konsultuodamas įvairias IT komandas, mačiau tas pačias klaidas kartojantis vėl ir vėl. Štai TOP sąrašas.
Scrum Master kaip projekto vadovas. Jei jūsų Scrum Master priskiria užduotis, kontroliuoja, kas kiek laiko dirba, ir raportuoja vadovybei apie progresą – tai ne Scrum Master. Scrum Master turėtų būti komandos tarnas, ne viršininkas. Jis padeda komandai būti efektyviai, šalina kliūtis, treniruoja.
Užduočių pridėjimas į sprintą jo metu. „Tai tik maža užduotėlė, tikrai suspėsite!” – girdėjote tokį sakinį? Sprintas turėtų būti apsaugotas nuo tokių įsikišimų. Jei kas nors tikrai skubu, galite nutraukti sprintą (nors tai turėtų būti kraštutinė priemonė) arba tiesiog palaukti kito sprinto. Nuolatinis sprintų trikdymas daro juos bevertėmis.
Retrospektyvų ignoravimas. Kai komanda užimta, retrospektyva dažnai pirmoji aukojama. „Praleiskim šį kartą, turime daug darbo.” Bet retrospektyva – tai kaip raumenų atsistatymas po treniruotės. Be jos komanda nesimoko iš klaidų ir nestobulėja.
Per didelės komandos. Jei jūsų daily stand-up trunka 45 minutes, nes komandoje 15 žmonių, turite problemą. Scrum komandos turėtų būti mažos ir judrios. Jei projektas didelis, geriau turėti kelias Scrum komandas su koordinacijos mechanizmais tarp jų.
Product Owner, kurio niekada nėra. Jei komanda turi klausimų, bet Product Owner atsako tik po kelių dienų, Scrum neveiks. Product Owner turi būti prieinamas – ne būtinai 24/7, bet pakankamai, kad komanda neužstrigtų laukdama sprendimų.
Įrankiai, kurie palengvina gyvenimą
Nors Scrum gali veikti ir su lipniais lapeliais ant sienos (ir kai kurios komandos vis dar taip dirba), dauguma naudoja skaitmenines priemones, ypač jei komanda dirba nuotoliniu būdu ar hibridiškai.
Jira – tai beveik industrijos standartas. Galinga, lanksti, bet kartais pernelyg sudėtinga. Gali konfigūruoti beveik bet ką, bet dėl to gali praleisti savaites nustatant visus workflow ir laukus. Jei jūsų organizacija jau naudoja Jira, tikriausiai ir jūs turėsite ją naudoti.
Azure DevOps – gera alternatyva, ypač jei jau naudojate kitus Microsoft įrankius. Integruojasi su kodu, CI/CD pipeline’ais. Mažiau populiarus nei Jira, bet daugeliui komandų visiškai pakankamas.
Trello – paprastas, vizualus, intuityvus. Puikiai tinka mažoms komandoms ar projektams. Trūkumas – mažiau funkcionalumo sudėtingesniems poreikiams. Bet jei tik pradedate su Scrum, Trello gali būti puikus pasirinkimas, nes neapsunkina proceso.
Monday.com, ClickUp, Asana – visi šie įrankiai gali būti pritaikyti Scrum procesui. Kiekvienas turi savo privalumų ir trūkumų. Patarimas – nepraleisite mėnesių ieškodami „tobulo” įrankio. Pasirinkite vieną, išbandykite kelias savaites, ir jei veikia – puiku. Įrankis neišspręs proceso problemų.
Svarbiau už įrankį yra tai, kaip jį naudojate. Mačiau komandas, kurios su paprastu Trello dirbo efektyviau nei kitos su visiškai sukonfigūruota Jira. Įrankis turėtų palengvinti procesą, ne tapti dar viena našta.
Kai Scrum nebėra tik Scrum: hibridiniai modeliai ir evoliucija
Realybė tokia, kad labai nedaug komandų praktikuoja „gryną” Scrum pagal vadovėlį. Ir tai visiškai normalu. Scrum yra framework’as, ne religija. Jis turėtų būti pritaikytas jūsų kontekstui.
Kai kurios komandos derina Scrum su Kanban elementais – pavyzdžiui, naudoja WIP (work in progress) limitus arba nuolatinį flow vietoj fiksuotų sprintų. Tai vadinama Scrumban ir gali būti labai efektyvu palaikymo komandoms ar situacijose, kur darbas ateina neprognozuojamomis bangomis.
Kitos komandos prideda elementų iš Extreme Programming (XP) – pair programming, test-driven development, continuous integration. Scrum iš tikrųjų nelabai kalba apie technines praktikas, todėl XP papildo jį puikiai.
Svarbu suprasti Scrum principus ir dvasią, o ne tik mechaniškai sekti taisykles. Jei kažkas neveikia jūsų kontekste, eksperimentuokite. Bet darykite tai sąmoningai – retrospektyvose aptarkite, kodėl norite kažką pakeisti, išbandykite, įvertinkite rezultatus.
Pavyzdžiui, jei jūsų komanda dirba ties produktu, kuris reikalauja ilgų tyrimų fazių, galbūt tradiciniai dviejų savaičių sprintai neoptimalūs. Galbūt reikia ilgesnių sprintų arba hibridinio modelio, kur tyrimai vyksta lygiagrečiai su kūrimu.
Arba jei jūsų komanda labai maža (3-4 žmonės), galbūt nereikia viso ceremonijų rinkinio. Galbūt pakanka trumpesnių, labiau neformaliųjų susitikimų. Bet ir vėl – darykite tai sąmoningai, ne tiesiog dėl to, kad „susitikimai nuobodūs”.
Kaip pradėti: pirmieji žingsniai link Scrum
Jei jūsų komanda dar nenaudoja Scrum ir norite pradėti, štai praktinis planas.
Pirma, išsimokysite pagrindus. Perskaitykite oficialų Scrum Guide (jis nemokamas ir tik 13 puslapių). Pažiūrėkite keletą video, paskaitykite straipsnių. Bet nesistenkite tapti ekspertais prieš pradėdami – mokysitės darydami.
Antra, gaukite organizacijos palaikymą. Scrum reikalauja tam tikrų dalykų – komandos autonomijos, Product Owner prieinamumo, laiko ceremonijoms. Jei vadovybė nesupras ir nepalaikys, susidursite su kliūtimis.
Trečia, pradėkite nuo pilot projekto. Neverskite visos organizacijos iš karto pereiti prie Scrum. Pasirinkite vieną komandą ir projektą, išbandykite, išmokite iš klaidų. Kai pamatysite rezultatus, kitos komandos norės prisijungti.
Ketvirta, apsvarstykite treniruotę ar konsultantą bent pradžiai. Taip, galite išmokti patys, bet patyrę Scrum Master ar coach gali padėti išvengti dažniausių klaidų ir greičiau pasiekti rezultatų. Nebūtinai samdyti ilgam – net kelios sesijos gali būti labai naudingos.
Penkta, būkite kantrus. Pirmieji keli sprintai tikriausiai bus chaotiški. Komanda mokysis planuoti, įvertinėti, bendradarbiauti naujais būdais. Tai normalu. Scrum Guide sako, kad komandai reikia maždaug 3-5 sprintų, kol ji pradeda jaustis komfortabiliai.
Šešta, naudokite retrospektyvas tobulėti. Po kiekvieno sprinto sąžiningai aptarkite, kas veikė ir kas ne. Eksperimentuokite su mažais pakeitimais. Scrum stiprybė – nuolatinis tobulinimas.
Ir paskutinis, bet svarbiausias patarimas – nepamirškite, kodėl tai darote. Scrum nėra tikslas savaime. Tikslas – kurti geresnį produktą, turėti laimingesnę komandą, greičiau reaguoti į pokyčius. Jei Scrum tam nepadeda, kažką darote ne taip arba galbūt jums reikia kito požiūrio.
Kodėl verta investuoti į teisingą procesą
Gali pasirodyti, kad Scrum – tai daug ceremonijų, susitikimų, planavimo. Ar verta? Ar ne geriau tiesiog duoti žmonėms užduotis ir leisti jiems dirbti?
Patirtis rodo, kad struktūra iš tikrųjų padidina laisvę. Kai visi žino, ko tikėtis, kada vyksta susitikimai, kaip priimami sprendimai, atsiranda aiškumas. Komandos nariai gali planuoti savo darbą, žino, kada bus trukdomi, o kada gali giliai sutelkti dėmesį.
Scrum taip pat padeda valdyti lūkesčius. Stakeholderiai žino, kad naujos funkcijos atsiras kito sprinto metu, ne atsitiktinai. Jie dalyvauja Review, mato progresą, gali duoti grįžtamąjį ryšį. Tai sumažina frustraciją iš abiejų pusių.
Be to, Scrum skatina komandos savivaldą ir atsakomybę. Kai komanda pati pasirenka įsipareigojimus, planuoja darbą, sprendžia problemas – žmonės jaučiasi labiau įsitraukę. Tai ne tik produktyvumo klausimas, bet ir pasitenkinimo darbu.
Ir galiausiai, Scrum padeda organizacijoms būti lanksčioms. Rinkos keičiasi, konkurentai išleidžia naujus produktus, vartotojų poreikiai evoliucionuoja. Su tradiciniais metodais, kur planuojate metams į priekį, rizikuojate sukurti kažką, kas jau nebeaktualus. Su Scrum galite keisti kursą kas dvi savaites.
Žinoma, Scrum nėra magiškas sprendimas. Jis neišspręs blogos komandos dinamikos, techninio įsiskolinimo ar neaiškios produkto vizijos. Bet jis suteikia struktūrą, kurioje šias problemas galima identifikuoti ir spręsti.
Taigi, ar Scrum tinka jūsų komandai? Tikriausiai taip, jei dirbate prie sudėtingų produktų, kur reikalavimai keičiasi, ir norite didesnio lankstumo. Galbūt ne, jei jūsų darbas labai prognozuojamas ir pasikartojantis. Bet net ir tada kai kurie Scrum elementai – retrospektyvos, vizualizacija, nuolatinis tobulinimas – gali būti naudingi.
Svarbiausia – nebijokite eksperimentuoti, mokytis iš klaidų ir pritaikyti procesą savo poreikiams. Scrum nėra dogma, o įrankis. Ir kaip su bet kuriuo įrankiu, reikia laiko išmokti jį naudoti efektyviai.
