Inovatyvus Projektų Valdymas

Kuomet organizacija veikia Scrum metodo principu, įprasta darbo diena prasideda kasdieniu Scrum narių susitikimu. Idealiu atveju, susitikimai visada vyksta toje pačioje vietoje, tuo pačiu laiku, griežtai limituojant posėdžio trukmę – vieno susitikimo laikas neturi viršyti penkiolikos minučių.

Posėdyje dalyvauja visi Scrum nariai: Produkto Šeimininkas, Scrum Meistras ir Komanda. Visi kiti su projektu susiję asmenys, tačiau nepriklausantys Scrum (pvz.: pardavimų vadybininkai), taip pat gali dalyvauti susitikime, su sąlyga, kad jie užims tik klausytojų pozicijas. Ši sąlyga susitikimus daro kryptingai orientuotus į sklandų Scrum narių tarpusavio bendradarbiavimą ir apsaugo nuo išorinių trikdžių.

Kadangi, posėdžio laikas yra labai ribotas, jo metu nesprendžiami nesklandumai ir neaptariami iškilę klausimai. Komandos narys, susidūręs su problema gali konsultuotis individualiai su Scrum Meistru iš karto po susitikimo ar kitu patogiu laiku. Tai padeda išvengti nereikalingų diskusijų tarp nesuinteresuotų asmenų ir sutaupyti laiko.

Kasdienio susirinkimo metu, Komandos nariai orientuojasi tik į tris klausimus:

1. Ką nuveikiau vakar?
2. Ką nuveiksiu šiandien?
3. Kaip man sekasi tvarkytis su užduotimis?

Sutelkdami dėmesį į ką tik atliktus ir ketinamus atlikti darbus, Komandos nariai vieni su kitais dalinasi savo kuriama verte bei išlaiko atvirus darbinius santykius, reikalingus tvariam bendradarbiavimui ir vieningam tikslo siekimui. Nepaisant to, kad susitikimuose dalyvauja Produkto Šeimininkas ir Scrum Meistras, tai nėra standartiniai posėdžiai, kurių tikslas – priversti darbuotojus atsiskaityti už atliktus darbus. Atvirkščiai, tai yra susirinkimas, kuriame Komandos nariai prisiima įsipareigojimus vienas kitam ir dalinasi pasiekimais. Pavyzdžiui, jei programuotojas sako, kad šiandien baigs duomenų saugojimo modulį, tuomet kiti Komandos nariai žino, kad ši užduotis rytoj bus padaryta ir programuotojas galės pereiti prie naujos.

Nuoseklus darbo eigos stebėjimas padeda Komandai pamatuoti savo atliekamo darbo vertę, suvokti savo vykdomų atsakomybių svarbą ir nebijoti prisiimti naujų įsipareigojimų.

Dauguma organizacijų, propaguojančių Scrum, atlieka kasdienį Scrum susitikimą standartiškai, kiekvienam Komandos nariui atsakant į tris klausimus. Tačiau galima alternatyva – aptarti kiekvieną užduočių sąrašo punktą iš eilės. Tokiu būdu, visi Komandos nariai gauna progą pasisakyti apie kiekvieną punktą atskirai.

Tam, kad nereiktų mokytis iš savų klaidų, pateikiame penkias dažniausiai daromas klaidas, kurios gadina kasdienių Scrum susitikimų kokybę ir primygtinai siūlome jų nekartoti.

5 kasdienių Scrum susitikimų klaidos:

1. Informacijos kolekcionavimas – neverta rinkti ir užsirašinėti kasdienių susitikimų metu girdimos informacijos. Sisteminti gautą informaciją ir daryti išvadas yra Scrum Meistro darbas, o Komandos nariai turėtų koncentruotis į užduotis ir būdus, kaip jas atlikti geriausiai.
2. Nuostata, kad kasdieniai susitikimai reikalingi tik Scrum Meistrui – jei, vienas Komandos narys kalba Scrum Meistrui, o kiti landžioja mobiliuosiuose telefonuose, tada, tai nėra bendradarbiavimu grindžiama aplinka ir Scrum Meistro pareiga tai ištaisyti. Kasdienių susitikimų paskirtis – komunikavimo ir bendro darbo principu eiti vieno tikslo link, todėl kolegos turi būti suinteresuoti išklausyti vienas kitą.
3. Kasdienis susitikimas nėra tas pats, kas planavimo susitikimas – jei Scrum Meistras pradeda kasdienį susitikimą pranešdamas Komandai apie naujus reikalavimus ir klausdamas ar šie sugebės juos pritaikyti savo darbe, tuomet prasideda diskusija ir kasdienis posėdis virsta planavimo susitikimu. Esant neatidėliotinai būtinybei aptarti šiuos reikalavimus, siūloma tai padaryti po kasdienio susitikimo, skiriant kelias papildomas minutes, nemaišant visko į vieną.
4. Kasdienis susitikimas neturi pavirsti į technines diskusijas – kai kurios Komandos pasakodamos apie savo atliekamas užduotis išsiplečia iki detalių. Nariai kalba apie techninę užduoties atlikimo pusę, o tai iššaukia nereikalingus kolegų klausimus, kurie sunaudoja daug laiko ir duoda mažai naudos.
5. Scrum lentos lokalizavimas vienoje patalpoje, o kasdienių susitikimų vykdymas – kitoje – lentos naudojimas suteikia galimybę perteikti reikiamą informaciją vizualiai ir padeda nepasimesti susitikimo eigoje. Kuomet lentos nėra toje pačioje patalpoje, kur vyksta susitikimas, Scrum Meistrai naudoja elektroninius laiškus, o tai nėra nei patogu, nei protinga, nes atima daug laiko ir išskaido Komandos dėmesį.

Siekiant maksimaliai tenkinančių rezultatų ir didžiausio produktyvumo, kasdienių susitikimų metu Scrum nariai turi koncentruotis į esminius tris klausimus, nekalbėti apie kliūtis bei rizikas ir nesiūlyti būdų kaip jas išspręsti, nes tai padarys Scrum Meistras, tam skirtu laiku. Pagrindinis komandos tikslas turėtų būti – pristatyti savo atliekamas užduotis, išklausyti kolegų ir pasiruošti naujai produktyviai dienai. 

Nepaisant to, kad internete gausu straipsnių Scrum metodikos taikymo organizacijose tematika, pradedantys vartotojai ne visada randa aiškius atsakymus į jiems rūpimus klausimus. Tam, kad Scrum diegimas organizacijoje būtų sklandus, parengėme trumpus ir aiškius atsakymus į dažniausiai sutinkamus klausimus.    

Ar Scrum yra Agile?

Scrum yra Agile šeimos narys. Scrum metodika vadovaujasi visomis Agile vertybėmis ir principais, kurių laikantis, kuriami maksimalios vertės produktai ar paslaugos. Scrum metodikos paskirtis – padidinti darbo našumą ir sumažinti laiko sąnaudas. Scrum procesai padeda organizacijoms prisitaikyti prie greitai besikeičiančios aplinkos ir pagaminti maksimalios vertės produktus.

Kada verta rinktis Scrum?

Scrum naudojimas organizacijoje yra naudingas, jei:

• Projekto pradžioje nėra aiškios visos detalės;
• Egzistuoja pakeitimų rizika;
• Yra poreikis nuolat stebėti atlikto darbo vertę;
• Produkto kūrimui pasitelkiamas kūrybiškumas.

Scrum privalumai:

• Ankstyva vertės realizacija;
• Mažesnė vėlavimo rizika;
• Mažesnė produkto kūrimo kaina;
• Didesnė motyvacija darbuotojams;
• Propaguojamas bendradarbiavimas;
• Kokybiškesnis galutinis produktas ir didesnis klientų pasitenkinimas;
• Suderinamumas tarp IT ir verslo padalinių.

Kokio dydžio turėtų būti Scrum komanda?

Vieningo atsakymo į šį klausimą nėra. Viena vertus, kuo didesnė Komanda, tuo daugiau darbo ji gali atlikti, tačiau, kita vertus, didelės Komandos valdymas sąlygoja daugiau komplikacijų, dėl sudėtingesnio užduočių planavimo ir koordinavimo. Optimaliu Komandos dydžiu laikomas narių skaičius – nuo trijų, iki devynių, neskaičiuojant Produkto Šeimininko ir Scrum Meistro.

Kodėl Produkto Šeimininkas tuo pačiu negali atlikti ir Scrum Meistro rolės?

Produkto Šeimininko paskirtis yra atstovauti verslo interesus komandai, o Scrum Meistro paskirtis – atstovauti komandos interesus verslui. Kai vienas asmuo atstovauja abiem interesų grupėms, jis natūraliai linksta į vieną arba į kitą pusę, o tai yra neteisinga kažkurios iš jų atžvilgiu.

Kaip ir kuo remiantis Komandos nariai skirstosi užduotis?

Teoriškai, Scrum Komanda pati organizuoja savo darbą, bendradarbiavimo principu. Tol, kol Komandos nariai geba įsiklausyti vienas į kitą, bendrai priimti sprendimus bei planuoti darbą, pavienių užduočių skirstymasis nėra būtinas. Praktiškai, daugumos Komandų nariai specializuojasi skirtingose veiklos srityse, todėl užduočių skirstymas gali būti naudingas. Tai leidžia Komandai tiksliai identifikuoti užduotis ir sklandžiai atlikti savo funkcijas. Skirstymas turėtų būti preliminarus, lankstus ir lengvai prisitaikantis prie galimų pokyčių.

Kas yra produkto užduočių sąrašas (Backlog)?

Produkto užduočių sąrašas yra prioretizuotas darbų planas, apibrėžiantis kokios užduotys turi būti atliktos vienos iteracijos metu. Sąrašas sudaromas trumpų istorijų pagrindu, kurių tikslas –  kuo tiksliau atspindėti produkto funkcionalumo reikalavimus.

Kaip turi būti tvarkomas produkto užduočių sąrašas?

Produkto užduočių sąrašas turi būti tvarkomas tokiu būdu, kad didžiausios vertės, kruopščiai detalizuotos istorijos būtų patalpintos produkto užduočių sąrašo viršuje, o mažiau detalių turinčios – apačioje. Produkto Šeimininko atsakomybė yra paruošti tokį užduočių sąrašą, kuris kurtų didžiausią vertę verslui. Svarbu atkreipti dėmesį, kad šiuolaikinėje rinkoje vyrauja staigių ir nenuspėjamų pokyčių tikimybė, kuri reikalauja lankstumo. Atsižvelgiant į pokyčius istorijos gali būti koreguojamos bei keičiama jų prioretizavimo tvarka.

Kas yra iteracijos planavimo susitikimas ir kam jis skirtas?

Iteracijos planavimo susitikimas skirtas savarankiškai dirbančios Komandos bendradarbiavimo su Produkto Šeimininku užtikrinimui. Susitikimo tikslas – aptarti artėjančios iteracijos planus ir preliminariai nuspręsti kokie darbai turi būti padaryti.

Susitikimas skaidomas į dvi dalis:

1. Teorinė dalis, kurios metu sprendžiama KĄ reikia padaryti. Komanda aptaria savo gebėjimus ir galimybes bei analizuoja naujų galimybių prieinamumą. Komanda peržiūri Produkto Šeimininko parengtą užduočių sąrašą ir išsikelia būsimos iteracijos darbų tikslus.
2. Praktinė dalis, kurios metu sprendžiama KAIP tuos tikslus įgyvendinti. Aptariama kas atliks kurias užduotis, kaip jos paveiks projektą, kaip sumažinti galimas rizikas ir kaip bendru darbu pasiekti maksimalią vertę.

Kas yra istorijų taškai (story points) ir kiek jų reikia surinkti per vieną iteraciją (sprintą)?

Istorijų taškai yra preliminari matavimo priemonė, apibrėžianti kiek pastangų reikės įdėti vienos istorijos įgyvendinimui. Paprastai tariant, tai yra numeris, kuris leidžia Komandai numatyti ar bus sunku realizuoti istoriją ar ne. Dažniausiai naudojama istorijos taškų skalė yra nuo 1 iki 100. Jei viena istorija verta 20 taškų, o kita 40, tuomet galima numatyti, kad antrosios įgyvendinimui prireiks dvigubai daugiau laiko. Tam, kad vertinant būtų pasiektas maksimalus tikslumas, vertinimo procese turi dalyvauti visi Komandos nariai. Kiek taškų reikia surinkti vienos iteracijos metu, priklauso nuo kiekvienos Komandos poreikių, projekto apimties ir galimybių individualiai, todėl svarbu išsikelti bendrą tikslą ir siekti jo kolektyviai.

Kam skirtas greičio (velocity) matavimas ir kaip jis veikia?

Greičio metrika yra pagrindinė darbo vertės matavimo priemonė Scrum. Ji nusako kokį darbo kiekį Komanda gali atlikti vienos iteracijos metu parodo jos produktyvumą. Greitis apskaičiuojamas iteracijos pabaigoje susumavus visus atliktų vartotojo istorijų taškus.

Kada Scrum nėra tinkamiausias pasirinkimas?

Scrum metodas geriausiai veikia nedidelėse Komandose, kurių nariai siekia bendro tikslo dirbdami kartu. Scrum taikymas gali būti komplikuotas, jei Komandos narių skaičius viršija dešimties žmonių ribą ir, jei kiekvienas iš jų atlieka labai skirtingas, tarpusavyje nesusijusias funkcijas. Vis tiek esant poreikiui taikyti Scrum, rekomenduojama skirstyti Komandą į mažesnius pogrupius ir ugdyti bendradarbiavimo dvasią juose.

Scrum – projektų valdymui ir produktų kūrimui naudojama sistema. Pirminė Scrum paskirtis buvo palengvinti programinės įrangos kūrimo procesus, tačiau šiuo metu, sistema plačiai naudojama ir kitose srityse. Iš pirmo žvilgsnio, gali pasirodyti, kad Scrum pritaikymas kitų veiklų sritims kelia nemažai problemų, tačiau, iš tiesų, Scrum naudojimas gana paprastas. Didžiausiu iššūkiu tampa ne eksploatacija, o įdiegimas, kuomet tradicinį projektų valdymą propagavusi įmonė pradeda dirbti naujų metodų principu.

Ar įmonės perėjimas prie Scrum metodo taikymo savo darbe bus sėkmingas, didžiąją dalimi priklauso nuo to, kokia yra įmonės struktūra. Mažą bendruomenę, kurioje vyrauja tvarūs tarpusavio santykiai, suvaldyti bus gana lengva, kai tuo tarpu, daugybę filialų turinčią milžinę – pakankamai didelis iššūkis.

Kol komanda įpras organizuoti savo darbą pagal Scrum metodiką, rekomenduojama veikti koncentruotai, vienoje grupėje, be papildomų pogrupių. Tai neleis komandai blaškytis ir padės koncentruotis ties atliekamu darbu visu pajėgumu. Pradžioje gali iškilti nemažai nesklandumų, todėl vertėtų rinktis mažos rizikos projektus.

Scrum metodikos diegimas įmonėje pareikalaus tam tikrų pertvarkymų, tokių kaip pareigybių bei darbo pobūdžio pakeitimai, naujų atsakomybių prisiėmimas ir senųjų pamiršimas. Siekiant sklandaus Scrum technikos įgyvendinimo, svarbu neskubėti ir stengtis suprasti Scrum taisykles. Tai padaryti padės septyni žingsniai sėkmingo Scrum naudojimo link.

Pirmas žingsnis – išsiaiškinti detales apie būsimą projektą ir išnagrinėti kliento poreikius. Šį darbą Scrum metodikoje atlieka Produkto Šeimininkas, kuriuo dažniausiai tampa žmogus,   gebantis prisiimti atsakomybę ir stropiai ją vykdyti. Produkto šeimininkas yra vienintelis asmuo, atsakingas už produkto užduočių sąrašą – ką, kada ir kam reikia padaryti, todėl jis turi pasirūpinti, kad produkto užduočių sąrašas visada būtų paruoštas, patalpintas matomoje vietoje ir visiems prieinamas.

Antras žingsnis – išsirinkti Scrum Meistrą. Tai daryti reiktų labai atsakingai, nes šis žmogus lydės komandą kiekviename žingsnyje, mokys teisingai taikyti Scrum metodiką ir padės spręsti nesklandumus. Scrum Meistro tikslas – užtikrinti komandos darbo našumą, pakreipiant komandą reikiama linkme ir padedant teisingai pasiskirstyti darbo krūvį. Scrum Meistrą galima traktuoti kaip laivo kapitoną, sujungiantį komandą, kurios kiekvieno nario užduotis yra nepriekaištingai atlikti savo darbą, kai, tuo tarpu, Scrum Meistro – fokusuotis ties projekto visuma.

Trečias žingsnis – paruošti užduočių sąrašą. Šį darbą padaro Produkto Šeimininkas, kuris paskirsto užduotis prioritetų tvarka, tam, kad komanda pirmiausia atliktų svarbiausius darbus ir tik tada pereitų prie mažiau svarbių. Užduočių sąrašas Scrum metodikoje yra pateikiamas istorijų pagrindu – trumpais aprašymais, papasakotais per kliento perspektyvą. Tarkim “aš noriu, kad mygtukai A ir B atliktų funkciją C”. Tuomet programuotojai – komandos nariai – atliekantys užduotis, imasi šio noro įgyvendinimo.

Ketvirtas žingsnis – suplanuoti įvykį (sprintą) ir jį įgyvendinti. Scrum metodikoje, projektas skaidomas į įvykius, leidžiančius atlikti darbus dalimis. Projekto planavimui skirto susitikimo metu, Produkto Šeimininkas pristato užduotis ir kartu su komandos nariais aptaria pirmojo įvykio eigą. Scrum metodikoje susitikimai yra kasdienis reiškinys, padedantis išlaikyti tvarų komandinį darbą ir efektyviai valdyti projektą. Kasdienių susitikimų metu aptariama kas buvo nuveikta iki šiol, identifikuojami ateinančios dienos darbai bei pristatomi iškilę nesklandumai ir ieškomi būdai jiems išspręsti.

Penktas žingsnis – peržiūrėti įgyvendintą įvykį (sprintą). Šiame etape dalyvauja ne tik Produkto Šeimininkas, Scrum Meistras ir komanda, bet ir klientai. Peržiūros metu pristatomi nuveikti darbai, aptariami pasiekimai ir įvertinama pažanga. Čia svarbiausia – kliento poreikių įgyvendinimas.

Šeštas žingsnis – testuoti bandomąją projekto versiją. Kadangi dalis darbų jau baigti ir projektas įgavęs pagreitį, laikas praktiniam patikrinimui. Šiame žingsnyje akivaizdžiai matomas progresas ir galima objektyviai įvertinti darbo rezultatus.

Septintas žingsnis – įvykių retrospektyva. Paskutinis projekto vystymo etapas, kurio metu, Produkto Šeimininkas, Scrum Meistras ir komanda aptaria kaip galėtų pagerinti savo darbą. Tai padaryti padeda “pradėti – baigti – tęsti” metodas. Kiekvienas Scrum komandos narys pasidalina savo įžvalgomis ką naujo būtų galima įnešti, kad darbas vyktų sklandžiau, ką reiktų baigti daryti, kad būtų išvengta nesklandumų ir kokios technikos vertos tęstinio naudojimo naujuose projektuose.

Scrum sistemos paskirtis – užtikrinti, kad darbo procesas veiktų sklandžiai, kad darbo laikas būtų išnaudojamas efektyviai ir, kad kliento poreikiai būtų išpildyti maksimaliai kaip tik įmanoma. Taigi, kodėl įmonėms verta taikyti Scrum savo kasdienybėje? Todėl, kad šis metodas padeda pamatyti, patikrinti bei pritaikyti geriausius sprendimus, ugdo komandinę dvasią ir skatina nuolat peržiūrėti savo veiklos rezultatus, mokytis iš klaidų ir tobulėti.