Author Archives: inovatyvuspv

Kam reikalingi kasdieniai susitikimai Scrum?

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. 

Dažniausiai užduodami klausimai apie Scrum

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.

Kaip įdiegti Scrum savo įmonėje?

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.

Kuo Scrum Meistras skiriasi nuo Projektų Vadovo?

Kaip įprastai veikiančiai organizacijai nepasimesti Scrum metodo rolėse ir teisingai perorganizuoti savo darbuotojų atsakomybės? Svarbu įsisąmoninti, kad Scrum metodo veikla, paremta darnia trijų rolių komunikacija. Čia egzistuoja Produkto Šeimininkas, Scrum Meistras ir Darbų Vykdymo komanda. Šios rolės išskaidė įprastas Projektų Vadovo funkcijas ir griežtai suskirstė atsakomybes. Kiekviena rolė turi savo nuosavą aiškiai apibrėžtų darbų rinkinį, kurių vykdymas užtikrina projekto sėkmę.

Produkto Šeimininko, Scrum Meistro ir Darbų Vykdymo Komandos paskirtis

Produkto Šeimininkas iš esmės yra atsakingas už projektą. Pagrindinė jo funkcija – užtikrinti, kad darbų sąrašas sutaptų su verslo reikalavimais ir kliento poreikiais. Darbų Vykdymo Komanda atlieka visas užduotis, reikalingas kokybiškam projekto vystymui, o Scrum Meistras, bendradarbiaudamas su Darbų Vykdymo Komanda ir Produkto Šeimininku, kuria palankią aplinką efektyviam produkto vystymui.

Scrum Meistras iš arčiau

Scrum Meistro paskirtis – užtikrinti, kad Darbų Vykdymo Komandos nariai laikosi Scrum metodikos taisyklių ir principų. Atsiradus nesklandumams, Scrum Meistras motyvuoja komandą bei pataria jai kaip susitvarkyti su nesėkme ir grįžti prie darbų, išnaudojant mažiausiai resursų. Jis nuolat stebi kaip veikia Scrum procesai ir dalinasi idėjomis kaip jų veikimą padaryti sklandesniu, moko komandą saviorganizacijos bei padeda jai tikslingai planuoti savo laiką. Scrum meistras skatina betarpišką komandos narių bendradarbiavimą, ugdo jų pasitikėjimą vienas kitu ir atsako už individualaus darbo transformavimą į kolektyvinį rezultatą.

Projektų Vadovas iš arčiau

Projektų Vadovo pozicija apima labai platų atsakomybių spektrą. Pradedant planavimu bei  organizavimu ir baigiant vadovavimu bei kontroliavimu. Planavimo procesas, dėl dinamiškos aplinkos, dažniausiai trunka visą projekto laiką ir atsako į klausimus “kas turi būti padaryta?” “kada turi būti padaryta?” bei “kas tai padarys?”. Projektų Vadovas susiduria su tokiais uždaviniais, kaip projekto plano vystymas, tvarkaraščio sudarymas ir procedūrų, skirtų remti projekto tikslus, vykdymas. Organizuodamas projektą, Projektų Vadovas turi apsibrėžti kompanijos struktūrą – identifikuoti darbuotojų roles ir pozicijas, nustatyti išorės įmonių paslaugų poreikį ir apsibrėžti reikalavimus personalui. Vadovavimas projektui remiasi projekto plano įgyvendinimu, siekiant užsibrėžtų tikslų. Šiame etape Projekto Vadovo sėkmę lemia plano stiprumas ir asmeniniai įgūdžiai, tokie kaip gebėjimas aiškiai komunikuoti, motyvuoti komandos narius bei spręsti konfliktus. Projektui įgavus pagreitį, Projektų Vadovas negali prarasti kontrolės. Galutinė projekto sėkmė priklauso nuo projekto matavimo (pažangos tikrinimo), įvertinimo (nukrypimo nuo plano priežasčių nustatymo) ir taisymo (nukrypimo padarinių sprendimo).

Kada Projektų Vadovas, o kada Scrum Meistras?

Pereidamos prie Scrum metodikos taikymo, įmonės dažnai susiduria su problema, kuomet yra painiojama Projekto Vadovo ir Scrum Meistro rolė. Projektų vadovų funkcijos apibrėžtos labai plačiai. Jie patys valdo darbo procesus, skirstosi užduotis, sprendžia problemas bei dėliojasi prioritetus. Projektų Vadovai laikomi komandos lyderiais, sprendimų priėmėjais ir planuotojais. Jie atsakingi už sklandžią produkto vystymo eigą, efektyvų komandos darbą ir numatytų tikslų įgyvendinimą. Paprastai tariant, Projekto Vadovas atsako už visą projekto eigą, nuo jo pradžios, iki galo.

Tuo tarpu, Scrum Meistro rolė pastebimai siauresnė, orientuota į pagalbą komandai, taikant Scrum metodiką kasdieniame darbe. Vietoj tiesioginio vadovavimo komandai, Scrum Meistras atlieka “trenerio” funkciją. Jis padeda kiekvienam komandos nariui efektyviai organizuoti savo darbą, laikantis Scrum metodikos taisyklių bei prižiūri sklandų Scrum procesų įgyvendinimą.

Taigi, pagrindinis skirtumas, skiriantis Scrum Meistrą nuo Projektų Vadovo yra tas, kad Scrum Meistras, kitaip nei Projektų Vadovas, praktiškai nevykdo produkto vystymo projekto, o tik teoriškai padeda Darbų Vykdymo Komandai efektyviai dirbti. 

Scrum Meistras – kas jis ir ką jis daro?

Scrum Meistras – Scrum Komandos pagalbininkas, lyderis. Bendrai kalbant, Scrum Meistro pareiga yra suteikti Kūrimo Komandai žinias apie Scrum metodą bei jo taikymą, prižiūrėti kaip Komanda laikosi Scrum teorijos, praktikos ir taisyklių, o iškilus sunkumams, padėti juos išspręsti.

Pagrindinis Scrum Meistro tikslas – užtikrinti komandos darbo našumą, kuriant maksimalios vertės produktus.

Scrum meistro atsakomybės kūrimo komandai:

  • Mokyti komandą savitvarkos ir organizuotumo;
  • Teikti pagalbą produkto kūrimo metu ir šalinant iškilusias kliūtis;
  • Prižiūrėti Scrum įvykių eigą.

Scrum Meistro rolė atlieka svarbų vaidmenį visame produkto kūrimo procese, palaikant glaudžius ryšius ne tik su Kūrimo komanda, bet ir su Produkto Šeimininku.

Scrum Meistro atsakomybės Produkto Šeimininkui:

  • Ieškoti ir taikyti efektyvius metodus darbui su produktų sąrašu;
  • Suvokti ir gebėti naudoti produktų planavimo metodus bei dalintis visa informacija, reikalinga vertės kūrimui.

Renkantis Scrum Meistrą, svarbu atsižvelgti į jo asmenybę ir kaip jį priima Komanda. Dažniausia problema, su kuria susiduria organizacijos yra Scrum Meistro rolės suteikimas Projektų Vadovui. Tokiais atvejais komanda jau būna pripratusi iš jo gauti konkrečias instrukcijas ir prireikia nemažai laiko, kol pavyksta pereiti prie saviorganizacijos.

Taigi, suteikti Scrum Meistro pareigas kvalifikuotam asmeniui yra sveikintina, tačiau ne ką mažiau svarbu ir atsižvelgti į jo asmenines savybes bei santykį su komanda. Geriausi Scrum Meistrai paprastai būna tie, kurie mėgaujasi padėdami ir geba džiaugtis kitų sėkme lyg sava.

Iš pirmo žvilgsnio gali pasirodyti, kad Scrum Meistras vadovauja Komandai, tačiau, iš tiesų, komanda pati organizuoja savo darbą bei skirstosi užduotis. Scrum meistras tik pakreipia ją tinkama linkme ir padeda teisingai pasiskirstyti darbo krūvį. Taigi, Scrum Meistras nėra nei koordinatorius, nei vadovas, todėl jis turi gebėti įsiklausyti ir priimti Komandos bei Scrum Šeimininko tempą, norus ar nuomonę, tuo pat metu, prižiūrėdamas ir užtikrindamas darbo efektyvumą.

Komandoms dažnai tenka susidurti su išoriniais trikdžiais, tokiais kaip įvairios užklausos ir prašymai programuotojams iš kaimyninių skyrių, kurie trukdo darbą ir mažina veiklos našumą. Tokiu atveju, Scrum Meistro pareiga yra sureguliuoti šiuos nesklandumus, nukreipiant adresantus tinkama linkme ir padedant jiems gauti reikiamą informaciją, tuo pat metu, maksimaliai išvengiant Komandos narių sutrukdymo.

Scrum Meistras turi išmokyti organizacijos narius Scrum metodikos ir paaiškinti kokią naudą teikia jos paisymas. Tai garantuos organizacijos savivokos apie Scrum svarbą formavimąsi ir savanorišką taisyklių laikymąsi.

Taigi, Scrum Meistras yra tarsi sporto treneris, kuris skatina siekti geriausių rezultatų ir padeda rasti tinkamiausius būdus tai padaryti. Kaip bebūtų, procesas, siekiant išsikeltų tikslų, nėra Scrum Meistro atsakomybė. Jo misija ne nurodyti kaip atlikti darbą, o padėti nepasiklysti taikant Scrum metodą savo darbe.

Kas yra Kanban ir kuo jis skiriasi nuo Scrum?

Šiomis dienomis, įmonės, vystančios naujus produktus, gali rinktis iš plataus Agile produktų kūrimo metodų asortimento, tačiau populiariausiųjų viršūnėse karaliauja Scrum ir Kanban.

Pastarasis metodas sukurtas Japonijoje, tarptautinės korporacijos Toyota, dėka. Kanban naudoja vizualinius įrankius, nurodančius ką gaminti, kiek gaminti ir kada gaminti. Sistema veikia skaitmeninės lentos pagrindu, kurioje naudojamos užduočių kortelės keliauja nuo pradinės stadijos iki užduoties įvykdymo. Paprasta ir patogi lentos vizualizacija leidžia nepasimesti informacijos sraute ir lengvai bendradarbiauti su kolegomis.

Kanban metodas vadovaujasi komandos nusistatytais laiko limitais, skirtais sklandžiam užduočių vykdymui. Siekiant užtikrinti nuoseklumą, sistema riboja vienu metu atliekamų užduočių skaičių, o tai leidžia komandai susikoncentruoti ties esamais darbais ir tik pilnai juos pabaigus, pereiti prie naujų. Tokiu būdu yra  garantuojamas užduočių atlikimas prioritetų tvarka.

Kanban privalumai:

  • Atsakingas požiūris į pokyčius
  • Efektyvus veiklos, neturinčios pridėtinės vertės, šalinimas
  • Nuolatinė ir nenutrūkstama komunikacija su klientu
  • Aukštas koncentracijos ties dabartinėmis užduotimis lygis
  • Paprastas naudojimas bei patogus laiko planavimas pagal individualius poreikius ir galimybes

Tiek Kanban, tiek Scrum vadovaujasi panašiais principais. Abu metodai grįsti bendradarbiavimu ir saviorganizacija bei siekia efektyvaus darbo proceso, tačiau, turi ir šiek tiek skirtumų.

Kiekviena darbo komanda yra unikali, turinti individualius poreikius bei vykdanti skirtingos specifikos projektus, todėl, renkantis metodą, patartina atsižvelgti į asmeninius komandos pageidavimus, vidinę politiką ir vykdomų projektų charakteristiką.

Kaip susikurti Scrum lentą Eylean

Scrum lentos paskirtis – pakeisti paprastą baltą lentą su lipniais lapeliais modernia, lankstaus profilio skaitmenine lenta, padedančia komandai taupyti laiką ir efektyviai planuoti darbą.

Scrum projekto planas pradedamas paspaudus “kurti naują darbalaukį”, šablonų kategorijoje pasirinkus Scrum lentą ir įvedus darbalaukio pavadinimą.

Visa darbalaukio informacija koreguojama įrankyje “nustatymai”. Čia pagal individualius poreikius tvarkoma lenta – jei reikia, pakeičiami stulpelių pavadinimai, pasirenkamas jų plotis.

 

 

 

 

 

 

 

 

 

 

 

 

Porą kartų spustelėjus bet kurioje lentos vietoje, sukuriama užduoties kortelė. Kortelei būtinai suteikiamas pavadinimas ir, esant reikalui, pridedama kita svarbi informacija.

 

 

 

 

 

 

 

 

 

 

 

Tam, kad užduotys būtų aiškiai atskirtos viena nuo kitos, galima jas priskirti tam tikram komandos nariui bei paryškinti pasirinkta spalva.

Užduotys gali būti skaidomos į sub-užduotis. Skaidymas leidžia detalizuoti bei konkretizuoti pagrindinę užduotį, kad būtų pasiektas išbaigtumas.

 

 

 

 

 

 

 

 

 

 

Kiekvienai užduočiai gali būti priskirtas pradžios ir pabaigos laikas, nurodantis kiek ilgai komandos narys gali užtrukti ties jos sprendimu. Užduočių vykdymo laikas yra sekamas, o susidūrus su nenumatytomis problemomis, turi būti stabdomas, naudojant komandą “blokuoti”. Užduoties lango apačioje atsiranda raudona juosta, įspėjanti kitus komandos narius, kad įvyko susidūrimas su problema, dėl kurios darbas negali būti tęsiamas ir yra reikalingas sprendimo būdas. Užbaigus užduotį, ji yra perkeliama į sekantį stulpelį, pavyzdžiui, iš kategorijos “daroma”, į kategoriją “padaryta”.

 

 

 

 

 

 

 

 

 

 

Scrum lentoje galima pridėti tiek vartotojų, kiek yra Jūsų komandoje. Tai atliekama kelių mygtukų paspaudimu: “nustatymai” – “serveris” – “vartotojai” ir suvedant trumpą informaciją apie naują komandos narį.  Nuo tos akimirkos, jis gali matyti lentos veiklą ir joje dalyvauti.

 

 

 

 

 

 

 

Vykstant kasdieniams susirinkimams, Eylean lenta gali būti peržiūrima naudojant projektorių arba išmanią lentą. Tai padeda komandai operatyviai apžvelgti tam tikro laikotarpio darbus, jų eigą, problemas, įvertinti savo veiklos našumą ir aptarti ateities perspektyvas.

 

 

 

 

 

 

 

 

 

 

 

Eylean lentą patogu ir paprasta naudoti, ji puikiai tinka dinamiškai aplinkai – lanksčiai vykdomi pakeitimai bet kurioje užduoties vystymo stadijoje. Lenta pritaikyta planuojantiems darbą tam tikrais laiko intervalais, atidžiai sekantiems veiklos procesą bei patraukli vertinantiems modernų dizainą.

Kas Yra Scrum?

Paprastai tariant, Scrum yra produktų kūrimo sistema, kurioje taikomi įvairūs procesai ir technikos. Tai vienas iš populiariausių Agile projektų valdymo metodų, aprašančių konkrečias roles ir taisykles, kuriomis vadovaujantis vykdomi projektai.

Scrum remiasi empirizmo teorija, teigiančia, kad priimant sprendimus, yra pasikliaujama žiniomis, o žinios ateina iš patirties.

Scrum procesai valdomi skaidriai – visi veiklos aspektai yra atviri ir matomi, tikrinamas darbo progresas, jei reikia, atliekamos korekcijos.

Scrum komandą sudaro:

  • Profesionalai, atliekantys darbą;
  • Produkto šeimininkas (product owner), atsakingas už maksimalią komandos atliekamo darbo vertę;
  • Scrum meistras (Scrum master) – komandos pagalbininkas, prižiūrintis Scrum teorijos, praktikos ir taisyklių laikymąsi.

Rekomenduojamas komandos dydis – iki dešimties žmonių, kad būtų užtikrintas tvarus ir patogus bendradarbiavimas.

Siekiant reguliarumo ir mažinant neapibrėžtų veiksmų vyravimą, Scrum darbas organizuojamas ribotos trukmės įvykiais – sprintais, padedančiais efektyviau atlikti numatytus darbus.

Sprinto eiga:

  • Naujo sprinto pradžioje, produkto šeimininkas paskiria užduotis, iš kurių kolektyvas pasirenka svarbiausias ir nusistato preliminarią jų trukmę. Laiko planavimas leidžia įvertinti savo galimybes ir efektyviai atlikti darbus. Tam, kad kolektyvas suprastų procesą ir jo laikytųsi, Scrum meistras prižiūri darbo eigą.
  • Prasidėjus sprintui, vykdomi kasdieniai susirinkimai, kuriuose komandos nariai pristato atliktus darbus bei iškilusias problemas. Tai padeda palengvinti ir paspartinti jų sprendimą, neišklystant iš nusistatytų laiko rėmų.
  • Sprintui einant į pabaigą, atlikti darbai pristatomi klientui. Pristatymas vyksta apžvalgos susirinkimo metu, dalyvaujant keliems komandos nariams bei produkto savininkui. Šio susirinkimo tikslas – ne tik parodyti progresą, bet ir gauti kliento atsiliepimus bei įvertinimus, į kuriuos atsižvelgdama komanda gali koreguoti savo darbų planą, prisitaikyti prie pakitusių rinkos poreikių.
  • Kiekvienas sprintas uždaromas apžvalgos susirinkimo metu, skirtu aptarti nuveiktą komandos darbą ir galimus patobulinimus ateityje.

Scrum projektai tęsiasi pasikartojančių sprintų principu tol, kol yra patenkinami visi kliento poreikiai (user stories) arba, esant ribotam laikui, tol, kol sukuriamas pakankamą vertę klientui teikiantis produktas.

Svarbiausi Scrum aspektai, suteikiantys naudą vartotojui:

  • Lankstumas – projekto skaidymas į dalinius projektus (sprintus), leidžiantis reaguoti į rinkos pasikeitimus bei naujas idėjas;
  • Kolektyvinės dvasios palaikymas – dirbant nedidelėje grupėje lengviau diskutuoti ir spręsti problemas;
  • Skaidrumas – visi projekto dalyviai turi prieigą prie darbų sąrašų, diagramų bei vertinimų.
  • Reguliarumas – pastoviai gaunami ir tikrinami tarpiniai rezultatai.

 

 

 

 

5 Sklandaus Perėjimo prie Agile žingsniai

Simple-kanban-board-

Susidomėjote ar nusprendėte pradėti taikyti Agile metodikas, tačiau bijote, jog tai nepasiteisins? Jūs ne vieni ir nuogąstaujate ne veltui. Pokyčiai nėra lengvas procesas – jie reikalauja pastangų, kantrybės ir gali neatnešti jokios naudos, tačiau kita vertus gali jos atnešti ir su kaupu. Tad ką daryti, kad užtikrinti kaip įmanomą sklandesnį ir efektyvesnį perėjimą prie Agile? Siūlome 5 paprastus žingsnius į kuriuos vertėtų atkreipti dėmesį.

  • Perpraskite

Ruošiantis bet kokiam įmonės ar asmeninio gyvenimo pokyčiui reikia gerai suprasti, kas jūsų laukia. Pereinant prie kito projektų valdymo metodo neužtenka tik išsirinkti jums labiausiai tinkantį, bet reikia taip pat išsiaiškinti, kaip jis veikia, ir kaip tai įtakos jūsų komandą bei procesus. Tik gerai suvokiant, kokie procesų, bei komandos sandaros pasikeitimai laukia galėsite tinkamai vesti komandą jų link, bei tikėtis sėkmės.

  • Pasiruoškite

Supratus, kas jūsų laukia, reikės tam tinkamai pasiruošti. Pirmiausia informuokite komandą apie naują metodiką, bei kodėl pasirinkote būtent ją. Taip užtikrinsite, jog motyvai yra bendrai suprantami ir priimtini. Apie pokyčius pranešus komandai, taip pat informuokite ir kitas su įmone susijusias interesų grupes, galbūt ši informacija bus svarbi tiekėjams, klientams ar tretiesiems asmenims, nes tai tiesiogiai palies ir juos. Galiausiai pasirūpinkite visais įrankiais pokyčiams įgyvendinti – paruoškite erdves kasdieniams susitikimams, fizines ar elektronines užduočių lentas ir kitus įrankius. Iš gausaus pasirinkimo reikėtų atsirinkti tuos, kurie labiausiai atitinka būtent jūsų komandos poreikius.

  • Bendraukite

Didelė dalis mūsų nesėkmių kyla iš bendravimo stokos ir Agile metodikų pritaikymas ne išimtis. Siekdami sklandžiai pakeisti įmonėje naudojamą metodą, nepamirškite, jog didelė jo sėkmės dalis priklausys nuo efektyvaus ir rezultatyvaus bendravimo tarp jūsų ir jūsų komandos. Bendravimas turėtų būti ištisinis nuo proceso pradžios iki pabaigos, taip užtikrinant, jog pokyčiai yra sėkmingai priimami ir suprantami visų komandos narių.

  • Pritaikykite

Diegiant Agile taip pat labai svarbu suvokti, jog tai nėra baigtinis metodas. Tad jei kažkuris metodo aspektas jūsų komandai netinka ar nėra priimtinas, jį galite keisti pagal savo poreikius. Nors iš pradžių toks procesas gali atrodyti per daug painus ir sudėtingas, pradėjus nuo mažų pokyčių ilgainiui taps paprastu ir labai naudingu. Tad nebijokite eksperimentuoti ir susikurkite sau tinkamiausią Agile versiją.

  • Neskubėkite

Galiausiai, kaip ir su bet kuriais kitais pokyčiais, jums prireiks kantrybės. Nesitikėkite, jog Agile suveiks pernakt. Taip atsitikti gali, bet dažniau tokie atvejai yra išimtis, o ne taisyklė. Tad bendraukite su komandos nariais, tikrinkite, kurie metodai veikia, o kurie ne, keiskite juos pagal savo poreikius ir laukite. Anksčiau ar vėliau Agile iš naujovės taps jūsų įpročiu, kuris pagerins ne tik jūsų, komandos, bet ir įmonės rezultatus.

Turite patarimų, kaip prisijaukinti Agile? Pasidalinkite!

Tagged , ,

LeSS: Scrum Metodika Didelėse Organizacijose

Praėjusią savaitę pristatėme SAFe metodą, skirtą Agile metodikų pritaikymui didelėse organizacijose, tačiau svarbu paminėti, jog tokių metodų yra ne vienas. Tarp geriau žinomų taip pat sutinkame SoS, DAD ir LeSS, tad šią savaitę būtent apie paskutinįjį. LeSS, priešingai nei SAFe, gali būti naudojamas ne su bet kuria, o tik su Scrum metodika. Tad puikiai tiks ją mėgstančioms ar norinčioms praktikuoti įmonėms.

Kaip tai veikia? Pažiūrėkim!

Kalbėdami apie LeSS, negalime nepaminėti jo kūrėjų – Craig Larman ir Bas Vodde. Kitaip, nei daugelio kitų metodų kūrėjai, taikydami Scrum panaudojimui didelėse komandose jie susitelkė į esminių metodo vertybių ir ritualų išsaugojimą. Tokiu būdu jie siekė užtikrinti, jog Scrum panaudojimas mažame ir dideliame žmonių rate ne tik kuo mažiau skirtųsi, bet ir būtų taip pat naudingas. Taigi LeSS metodas nėra Scrum perdirbinys, bet greičiau natūrali metodo evoliucija iš mažos pradedančios komandos į didelę ir sėkmingą įmonę.

less

Panašumai

Šis tikslas pasiektas gana paprastu metodu –užtikrinant kad LeSS išlaikytų daugelį tradicinių Scrum elementų. Kaip ir mažoje komandoje, visa kompanija naudojasi vienu darbų sąrašu (Backlog). Vietoj skirstymo pagal komandas, dėmesys fokusuojamas į galutinį bendrą tikslą – produktą. Pabaigto darbo apibrėžimas (Definition of Done) visoms komandoms taip pat yra vienodas, siekiant suartinti jų atliekamus darbus. Galiausiai, kiekvieno Sprinto pabaigoje yra sukuriamas vienas veikiantis galutinio produkto pagerinimas, kurį prižiūri ir kontroliuoja vienas Produkto Savininkas (Product owner). Tokiu būdu didelėje organizacinėje struktūroje yra išlaikomas vienos komandos ir vieno tikslo jausmas būdingas mažoms įmonėms.

Skirtumai

Žinoma,  toks vienos komandos principas nėra naudojamas visur, nes tiesiog nebūtų efektyvus. Sprinto planavimas (Sprint Planning), Sprinto peržiūra (Sprint Review) ir aptarimai (Retrospektive) yra organizuojami kiek kitaip. Jie taip pat rengiami visoms komandos tuo pačiu metu, tačiau ne visi komandos nariai dalyvauja visuose susirinkimuose.

Kiekvieno Sprinto planavimas yra padalinamas į dvi dalis – pirmojoje dalyvauja po du kiekvienos komandos atstovus ir produkto savininkas, o antroji dalis yra vykdoma atskirai kiekvienoje komandoje. Tokiu būdu komanda gali ne tik susiplanuoti savo darbų progresą, bet ir yra informuota apie bendrą planą bei tikslą. Tai pat yra rengiami ir dabų sąrašo išgryninimo (Backlog Refinement) susirinkimai, kur pirmoji dalis yra skirta užduočių skaidymui, lengvai analizei ir įvertinimui, o antroji dalis yra sutelkta į jų pasidalinimą komandos lygmenyje.

Kasdieniai susirinkimai (Daily Scrum) LeSS metodikoje kiekvienai komandai yra rengiami atskirai, tačiau visuomet yra atviri kitų komandų nariams, kurie netgi gali būti paskirti prižiūrėti kitos komandos susirinkimo kokybę. Visų komandų atstovų susirinkimai (Scrum of Scrums) dažniausiai rengiami porą kartų per savaitę. Jais siekiama trumpai apžvelgti kiekvienos komandos progresą ir užtikrinti, jog visos komandos juda teisinga linkme.

Sprinto peržiūroje (Sprint Review) taip pat dalyvauja po du kiekvienos komandos atstovus, produkto savininkas, bei klientai. Taip sumažinant dalyvių skaičių iki reikalingo informacijai pristatyti. O Sprinto aptarime dalyvauja Scrum vadovai (Scrum Masters) ir po vieną kiekvienos komandos atstovą, sukuriant efektyvią diskusijų apie galimybes ir tolesnį progresą erdvę.

LeSS yra puikus pavyzdys, kaip Scrum metodika gali būti pritaikyta didelėms organizacijoms. Vietoj to, jog metodika ir įrankiai būtų pergalvoti iš naujo, originalūs metodai yra pritaikomi didelėms komandoms. Tai leidžia išlaikyti ne tik metodo dvasią, bet ir komandos vienybę siekiant bendro tikslo.

Tagged , ,
Popo.lt tinklaraščiai. Hosting powered by   serverių hostingas - Hostex
Eiti prie įrankių juostos