Category Archives: Projektų valdymas

4 pagrindiniai Kanban principai ir 5 žingsniai jiems pritaikyti


Kaip ir dauguma naujų dalykų, Kanban metodologijos pritaikymas iš pradžių gali pasirodyti sudėtingas ir painus. Norėdami padėti Kanban naudotojams sėkmingai pritaikyti šį metodą prie savo procesų bei poreikių, aptarsime 4 pagrindinius Kanban principus, kurie padės perprasti metodologijos esmę, bei 5 aiškius ir paprastus žingsnius, padėsiančius šio metodo principus pritaikyti praktikoje.

4 pagrindiniai Kanban principai

Siekiant lengvai perteikti Kanban metodo esmę, išskiriami keturi pagrindiniai Kanban principai:

  1. Vizualizacija. Tai – darbų ir jų atlikimo eigos vizualinio modelio sudarymas, leidžiantis stebėti visą darbų ir su jų atlikimu susijusių procesų eigą. Darbų atlikimo vizualizacija, kurioje išryškėja greičiausi bei lėčiausi procesai, trikdžiai ir kiti veiksniai, lemiantys darbų atlikimo eigą, padeda greičiau pastebėti bei efektyviau spręsti iškilusias problemas.
  2. Atliekamų darbų apribojimas. Remiantis Kanban praktika, reikėtų visuomet nustatyti atliekamų užduočių skaičiaus apribojimą. Toks apribojimas padeda darbuotojams išvengti kelių užduočių atlikimo vienu metu. Užtikrinimas, kad darbuotojas vienu metu galėtų atlikti tik vieną užduotį, leidžia panaikinti neefektyvų laiko panaudojimą, kurį sukelia bandymas vienu metu atlikti kelis darbus.
  3. Sklandi darbų eiga. Vienu metu atliekamų darbų apribojimas leidžia užtikrinti optimizuotą, tolygų ir sklandų atliekamų darbų srautą. Šis optimizavimas naudingas tuo, jog suteikia galimybę analizuoti darbų atlikimo eigą, įžvelgti esamas ir netgi galimas ateities problemas, trikdančias darbų atlikimo procesą, bei užkirsti joms kelią.
  4. Nuolatinis tobulėjimas. Įgyvendinus pirmuosius tris Kanban principus (sukūrus vizualizaciją, įvedus atliekamų darbų apribojimą ir užtikrinus sklandžią darbų eigą), galima pradėti analizuoti įmonėje vykstančius procesus. Darbams atlikti reikalingo laiko skaičiavimas, atliktų užduočių kokybės vertinimas bei kiti rodikliai padeda komandoms identifikuoti savo silpnąsias puses, problemas ir tobulėti jas sprendžiant.

 

5 pagrindiniai žingsniai, padedantys užtikrinti sėkmingą Kanban principų pritaikymą

Aptarus Kanban principus galima pereiti prie konkretaus jų pritaikymo, leidžiančio užtikrinti efektyvų šio metodo panaudojimą. Kanban principų pritaikymą galima suskirstyti į penkis pagrindinius, aiškius ir paprastus žingsnius:

  1. Įmonės procesų suvokimas. Prieš pradedant pritaikyti Kanban metodą, labai svarbu suvokti visus įmonės procesus – pradedant pirminiu užsakymu ir baigiant produkto ar paslaugos suteikimu galutiniam klientui. Reikia gerai išmanyti vykdomų užduočių tipus, visų darbų atlikimo procesų dalis (tokias kaip kūrimas, testavimas, pritaikymas ir t. t.), užduočių pasiskirstymą, atsakomybės pasidalinimą, jos perdavimą ir t. t. Kuo tiksliau žinosite, kas vyksta Jūsų įmonėje, tuo efektyviau galėsite pritaikyti Kanban metodologiją.
  2. Vizualaus darbalaukio sukūrimas. Įvykdžius pirmąjį žingsnį, galima pereiti prie Kanban darbalaukio kūrimo. Šis darbalaukis – užduočių lenta, kurioje įvairios užduotys yra talpinamos lapelių pavidalu. Gautos užduotys keliauja per įvarius lentos stulpelius iš kairės į dešinę tol, kol yra atliekamos. Kurdami savo pirmąjį darbalaukį pradėkite nuo paprasčiausios užduočių lentos, sudarytos iš trijų stulpelių – „Užduočių sąrašas“, „Atliekamos užduotys“ bei „Atliktos užduotys“. Atlikdami darbus ir fiksuodami jų eigą darbalaukyje greitai pamatysite kokių papildomų stulpelių Jums trūksta, o kokių stulpelių nebereikia. Taip pat atrasite Jums patogų būdą išskaidyti atliekamus projektus, užduotis bei jas atliekančius komandos narius. Koreguodami savo darbalaukį po kiek laiko turėsite optimalią, Jūsų poreikius atitinkančią užduočių lentą.
  3. Atliekamų darbų apribojimas. Kitas žingsnis, kuris padės Jums užtikrinti optimalią ir sklandžią darbų atlikimo eigą, yra atliekamų dabų skaičiaus apribojimas. Tokius apribojimus galite nustatyti kiekvienam savo darbalaukio stulpeliui. Derėtų pabrėžti, kad stulpeliui pasiekus maksimalų nustatytų užduočių skaičių, turėtumėte jo nebepildyti tol, kol nebus atlikta bent viena iš stulpelyje esančių užduočių. Kaip minėta Kanban principuose, toks apribojimas padeda užtikrinti darbuotojų produktyvumą ir efektyvų laiko panaudojimą.
  4. Susirinkimų planavimas. Susirinkimai – puikus būdas aptarti įmonės procesų optimizavimo ir tobulėjimo galimybes. Kasdieniai susirinkimai padės Jūsų komandai aptarti problemas, iškilusias atliekant užduotis ar stebint jų atlikimo eigą, bei jų sprendimo būdus. Norėdami aptarti jau atliktas užduotis, įgyvendintus projektus ir būdus, kuriais galėtumėte patobulinti darbų bei projektų atlikimo procesą ateityje, galite surengti retrospektyvinį susirinkimą. Panašiai planuojami ir būsimi projektai – jų aptarimui skirti planavimo susirinkimai.
  5. Ataskaitų sudarymas. Paskutinis žingsnis, užtikrinantis efektyvų Kanban metodologijos pritaikymą, yra įvairių ataskaitų sudarymas. Gamybos, tiekimo laiko ataskaitos, suminės darbų eigos diagramos ir kitos ataskaitos parodo kaip greitai yra atliekamos užduotys, leidžia stebėti atliekamų ir dar nepradėtų užduočių kiekio pokyčius, nustatyti greičiausius bei lėčiausius procesus, įvertinti kiekvieno komandos nario produktyvumą ir t. t. Šios ataskaitos, kartu su susirinkimų planavimu, padeda vertinti įmonėje vykstančių procesų kokybę ir galimybes juos patobulinti bei optimizuoti.

Štai tokie yra keturi pagrindiniai Kanban principai ir penki žingsniai, padedantys šią metodologiją sėkmingai pritaikyti  prie Jūsų įmonės procesų. Perpratus metodo esmę ir ją pritaikius praktikoje, belieka tęsti įmonėje vykstančius procesus, pagal juos atnaujinti savo darbalaukį, stebėti užduočių bei darbų atlikimo kokybę, organizuoti susirinkimus projektų ir problemų aptarimui bei siekti nuolatinio tobulėjimo.

 

 

Tagged ,

Sėkmingas projektų vadovas – koks jis?

Sėkmingą projekto įgyvendinimą lemia efektyvus darbas nuo tikslo išsikėlimo iki jo realizavimo. Idėjos konvertavimo į rezultatą kelyje komandą lydi Projektų Vadovai, siekiantys maksimaliai išpildyti verslo lūkesčius. Sėkmingi Projektų Vadovai yra orientuoti į tikslą ir geba dirbti su platų įgūdžių spektrą turinčiais žmonėmis.

Projektų Vadovų funkcijas galima išskaidyti į vidines ir išorines. Vidinėje organizacijos aplinkoje Projektų Vadovai sukuria planą, paskiria užduotis, stebi darbuotojų pažangą jas įgyvendinant ir pataria kaip spręsti iškilusias problemas, o išorinėje – bendrauja su suinteresuotomis šalimis, rėmėjais ir partneriais bei šalina barjerus, trukdančius sėkmingai projekto eigai.

Pamatinės vertybės, siekiant sukurti sėkmingą projektą yra disciplinuotas darbas, gebėjimas kruopščiai planuoti laiką ir finansus bei nuolatinis verslo aplinkos stebėjimas ir prisitaikymas prie jos kintančių poreikių.

Sėkmingi Projektų Vadovai, turi tokius techninius įgūdžius, kaip:

  • Vadovavimas – Projektų Vadovas turi gebėti sutelkti komandą ir išlaikyti jos narius motyvuotus viso projekto metu, spręsti konfliktus bei priimti atsakingus sprendimus.
  • Laiko valdymas – Projektų Vadovas vienu metu dirba su darbuotojais, klientais ir vadybininkais, todėl turi gebėti efektyviai skirstyti laiką ir prioritetizuoti darbus.
  • Biudžeto valdymas – Projektų Vadovas sprendžia, skirsto ir prižiūri projekto biudžetą, todėl turi būti užtikrintas dėl tinkamo savo matematinių įgūdžių panaudojimo planuojant ir vykdant pinigų operacijas.
  • Analizavimas – Projektų Vadovas dirba nuolat besikeičiančioje aplinkoje, todėl privalo gebėti greitai ir efektyviai spręsti susidariusius nesklandumus. Tai padaryti galima tik gerai išanalizavus turimus duomenis ir grėsmes, galinčias neigiamai paveikti tolesnius sprendimus.

Ne ką mažiau svarbi ir Projekto Vadovo asmenybė. Nuolat bendraudamas su įvairaus amžiaus, išsilavinimo ir būdo žmonėmis, Projektų Vadovas turi būti atviras, patikimas bei motyvuojantis. Siekiant, kad kolegos matytų projektų vadovą kaip lyderį ir tikėtų jo idėjomis, reikia turėti tokias asmenines savybes kaip:

  • Patikimumas – tam, kad visos suinteresuotos šalys imtų tikėti projekto sėkme, pirmiausia, jie turi pasitikėti Projektų Vadovu. Nepaisant to, ar projekto eiga sklandi ar ne, projektų vadovas turi būti nuoširdus ir sąžiningas. Tuomet žmonės jaučiasi užtikrinti, kad jie gauna visą reikiamą informaciją apie projektą, kad jais pasitikima ir jų bendradarbiavimas yra vertinamas.
  • Ekstravertiškumas – Projektų Vadovai nuolat apsupti žmonių, naudojančių skirtingą komunikaciją. Bendraujant tiek su projekto rėmėjais, tiek su suinteresuotomis šalimis ar komandos nariais, Projektų Vadovai turi gebėti efektyviai rinkti ir skleisti gautą informaciją. Intravertai taip pat gali būti sėkmingais Projektų Vadovais, tačiau jiems reiks įdėti daugiau darbo ir pastūmėti save išeiti iš komforto zonos.
  • Organizuotumas – gebėjimas planuoti savo veiklą yra lemiamas sėkmės veiksnys Projektų Vadovo darbe. Projektų Vadovas turi gebėti ne tik suplanuoti projektą, bet ir sekti jo įgyvendinamą bei visuomet turėti planą “B”, jei planas “A” neduoda norimų rezultatų. Atlikus pakeitimus, Projektų Vadovas turi informuoti visus su projektu susijusius žmones, supažindinti su nauja tvarka, papasakoti apie galimas grėsmes ir paskirstyti būsimas užduotis.

Teigiamos būdo savybės visuomet palengvina tarpusavio komunikaciją, tačiau kiekvienas žmogus turi tam tikrus dominuojančius asmenybės bruožus, lemiančius bendravimo pobūdį.

Žemiau pateikiame dažniausiai pasitaikančius projektų vadovų charakterių tipus ir aptariame jų naudą projektų vystymui:

  1. Valdingas – pasižymi geromis lyderiavimo savybėmis, kurios įkvepia komandą bendradarbiauti ir greičiau pasiekti norimų rezultatų. Toks Projektų Vadovas padeda komandai pasiekti daugiau, mažomis energijos sąnaudomis.
  2. Prisitaikantis – lengvai bendraujantis bei gerbiantis kitų nuomonę, net jei ši nesutampa su jo. Toks Projektų Vadovas kuria pasitikėjimą ir palaiko nuoširdumu paremtus santykius.
  3. Orientuotas į detales – kreipia dėmesį į kiekvieną projekto detalę. Toks Projektų Vadovas pastebi problemines projekto vietas dar prieš joms sukeliant nesklandumus.
  4. Deleguojantis – skirsto užduotis kiekvienam komandos nariui, sudarydamas griežtus laiko limitus, kada užduotis turi būti atlikta. Toks projektų vadovas užtikrina terminų laikymąsi ir efektyvų laiko skirstymą.
  5. Vizualizuojantis – prieš pradėdamas daryti darbus jau turi darbo rezultatų viziją savo galvoje. Toks Projektų Vadovas taupiai skirsto projekto kaštus, užtikrindamas jų pakankamumą.
  6. Kūrybiškas – vadovaujasi ne tik savo gebėjimais, bet ir intuicija. Toks Projektų Vadovas generuodamas naujas idėjas lemia inovacijų plėtrą.
  7. Sumanus – nebijo kliūčių ir niekada nepasiduoda. Nepaisant nesėkmių, toks Projektų Vadovas visada ieško tinkamo sprendimo, tol, kol išpildo savo sumanymus.

Nors Projektų Vadovai yra komandos vedliai ir gidai, tačiau dėl plačios projektų specifikacijos jie negali būti ekspertais visais klausimais. Tokiais atvejais gelbsti tinkamai orientuota komanda, turinti arba gebanti greitai surinkti visus reikalingus duomenis einamojo projekto tema ir suteikti juos Projekto Vadovui. Turėdamas šiuos duomenis, Projektų Vadovas gali priimti svarbius sprendimus dėl projekto eigos, terminų, apimties bei paskirstymo.

Projektų vadovas privalo būti nešališkas, remtis duomenimis, o ne emocijomis. Tik tuomet galima tikėtis objektyvių sprendimų, tenkinančių visų, su projektų susijusių, asmenų poreikius.

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.

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.

 

 

 

 

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