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 , ,

Agile Metodikos Didelėse Organizacijose

Augant Agile metodikų populiarumui, nenuostabu, jog jomis pradeda domėtis ir didelių įmonių atstovai. Jie taip pat nori būti lankstesni, geriau prisitaikyti prie kintančios rinkos ir pasinaudoti kitais Agile teikiamais privalumais. Tačiau dauguma susiduria su problemomis, mat metodikos yra pritaikytos kelių žmonių komandai, o ne dešimčių, šimtų ar tūkstančių darbuotojų organizacijoms. Tokiais atvejais tradiciniai Agile metodai nebėra tinkami, o vietoj jų naudojami kiti, specialiai pritaikyti. Vienas plačiau žinomų tarp jų – SAFe.

SAFe nėra naujas metodas, jis jau keletą metų sėkmingai naudojamas siekiant Agile metodiką pritaikyti didelių organizacijų veiklai. Šifruojamas kaip Scaled Agile Framework arba Praplėstas Agile Metodas, jis pristato naują požiūrį į darbuotojų santykių organizavimą ir taip pritaiko metodiką dideliam žmonių ratui. Vietoj darbuotojų sankirtų vertinimo per vadovavimo lygius, šis metodas padalina įmonę į keturias skirtinguose lygiuose veikiančias komandas – Darbų, Projekto, Vertės ir Portfelio.

Toks pokytis reikalauja nemenkų pertvarkų įmonės struktūroje – visi darbuotojai yra skirstomi į keturis komandų lygius ir dar į atskiras komandas kiekviename lygyje. Tad SAFe vertėtų rinktis tik žinant, jog įmonė pokyčius įveda ilgam, kad tai nėra tik vieno projekto ar trumpalaikė užgaida. Jei dar tik svarstote pradėti naudoti Agile metodiką, verčiau rinktis Scrum ar Kanban metodų pritaikymą kelių mažesnių komandų lygiu. Kita vertus, jei jau esate susipažinę su Agile ir norite praktikuoti visos įmonės mastu, SAFe bus puikus pasirinkimas.

SAFe veikia keturių didelių komandų principu.

Darbų Lygmuo

Pirmasis arba smulkiausias lygmuo sutinkamas šioje metodikoje yra darbų lygmuo. Čia komandomis yra atliekami smulkiausi darbai, leidžiantys įmonei judėti į priekį. Dauguma komandų dirba naudodamos Scrum ar Kanban metodikas pagal savo darbų specifiką ir kiekvienos iteracijos pabaigoje pateikia papildomą vertę galutiniam produktui.

Darbai – Smulkios konkrečios užduotys

Lygmens tikslas – Iteracijos pabaigoje pateikti papildomą vertę.

Komanda – Produkto Savininkas (Product Owner), Scrum Vadovas (Scrum Master) ir Komandos nariai

 

Projekto Lygmuo

Antrasis SAFe metodikoje sutinkamas Projekto arba Produkto lygmuo. Šio lygmens komandos taip pat dirba iteracijų principų, kurių pabaigoje siekia pateikti vertės prieaugį, tačiau jų užduočių specifika skiriasi nuo Darbų Lygmens komandų. Vietoj to, jog dirbtų ties užduotimis, šios komandos dirba ties Darbų lygmes komandų organizavimu siekiant užtikrinti vertės prieaugį produkto ar projekto lygmeniu. Koordinavimui yra naudojamas Agile Išleidimo Traukinys (Agile Release Train), kuris padeda užtikrinti, jog visos koordinuojamos komandos papildomą vertę sukurs vienu metu. Viena Projekto Lygmens iteracija yra lygi penkioms Darbų Lygmens iteracijoms.

Darbai – Darbų Lygmens komandų darbo organizavimas

Lygmens tikslas – Iteracijos pabaigoje pateikti papildomą projekto ar produkto funkcionalumą.

Komanda – Išleidimo Traukinio Inžinierius (Release Train Engineer) atsakingas už iteracijos koordinavimą, Produkto Vadovas (Product Manager) prižiūri ir prioretizuoja darbų sąrašą, Sistemos Architektas – Inžinierius (System Architect – Engineer) atsakingas už techninių sprendimų kryptį.

 

Vertės Lygmuo

Trečiasis – Vertės Lygmuo, atsakingas už Projekto Lygmens komandų koordinavimą ir užtikrinimą, jog visi projekto ar produkto patobulinimai atitinka vertės galutiniam tikslui reikalavimus. Tam pasiekti, šio lygmens komandos koordinuoja kelis ar visus įmonėje kuriamus Agile Išleidimo Traukinius ir koreguoja Projekto Lygmens komandų kryptį, jei to reikia.

Darbai – Projekto Lygmens komandų darbo organizavimas ir vertės kūrimo užtikrinimas

Lygmens tikslas – Iteracijos pabaigoje pateikti papildomą vertės prieaugį įmonei

Komanda – Vertės Srauto Inžinierius (Value Strem Engineer), Sprendimų Vadovas ir Sprendimų Architektas/Inžinierius (Solution Management and Solution Architect/Engineer) prižiūri vykstančius procesus ir užtikrina vertės prieaugį po kiekvienos iteracijos.

 

Portfelio Lygmuo

Paskutinis bei stambiausias – Portfelio Lygmuo. Geriausiu šio lygmens komandos apibūdinimu galėtu būti Įmonės vadovybė, tik SAFe metodikoje ji yra traktuojama, kaip komanda, ne vadovų rinkinys. Šios komandos tikslas – įmonės tikslų ir strategijos nustatymas, bei jų komunikavimas Vertės Lygmens komandoms. Ši komanda nustato bendrą įmonės veiklos kryptį, strategiją ir skiriamus tam įgyvendinti kaštus.

Darbai – Įmonės strategijos kūrimas ir komunikavimas Vertės Lygmeniui

Lygmens tikslas – Iteracijos pabaigoje pateikti aiškius įmonės strategijos tikslus ir tam skiriamus kaštus

Komanda – Programos Portfelio Vadovas (Program Portfolio Manager), Epų savininkas (Epic Owners), Įmonės Architektas (Enterprise Architect) prižiūri vykstančius procesus ir užtikrina vertės prieaugį po kiekvienos iteracijos.

 

SAFe 4.0 Pateikia kitokį, didelėms organizacijoms tinkamą, Agile suvokimą. Komandos pasiskirsto darbus pagal savo kompetencijų lygmenis, vietoj to, jog kiekviena komanda būtų atsakinga už Epo – Vertės – Funkcionalumo – Vartotojo istorijos grandinę. Įmonės vadovai patampa Protfelio Lygmens komanda ir yra atsakingi už Epus, vidutinio lygmens vadovai perima vertės kūrima ir tampa Vertės Lygmens komanda, žemiausiojo lygio vadovai sudaro Projekto Lygmens komandą ir yra atsakingi už funkcionalumus, o įmonės darbuotojai sudaro Darbų Lygmens komandas ir kuria vartotojų istorijų lygmenį.

Šio metodo pritaikymas reikalauja nemažai atsidavimo, bet kartu suteikia aiškų Agile pritaikymo būdą didelėse organizacijos. Daugiau apie SAFe galite sužinoti čia.

Tagged ,

Kaip Išsirinkti Geriausią Projektų Valdymo Įrankį?

1. Visual board

Projektų valdymo erdvėje dažnai sklando klausimai – kuris projektų valdymo įrankis yra geriausias, kaip rasti tinkamiausią sprendimą, kuris iš siūlomų įrankių tiks mano situacijoje. Ir nors kartais rekomendacija gali nukreipti prie to vienintelio teisingo pasirinkimo, dažniausiai ji nurodo įrankį, kuris yra geras, bet toli gražu ne idealus. Todėl svarbu suprasti, kad norint rasti įrankį tinkantį būtent jums, būtent jūs ir turite jo ieškoti.

Nors toks pareiškimas gali atrodyti gana gąsdinančiai, nusivilti nereikėtų – susirasti tinkamą įrankį yra visai nesudėtinga, tereikia žinoti kaip jo ieškoti. Tai padaryti padės šis paprastas procesas.

  1. Atsiminkite – tai ne populiarumo konkursas

Pradėję ieškoti naujo įrankio, neišvengiamai norėsite patikrinti informaciją internete, paklausti kolegų nuomonės ir ieškoti atsiliepimų. Nors tai visiškai natūrali paieškos dalis, ji neturėtų būti jūsų pirmas žingsnis naujo sprendimo link. Pradėję savo paieškas nuo kitų žmonių rekomendacijų, susidarysite išankstinę nuomonę apie įrankius net gerai nesuprasdami savo poreikių, kurie gali būti visiškai kitokie nei jūsų. Tad atsiliepimų skaitymą reikėtų atidėti šiek tiek vėlesniam laikui. Continue reading

Tagged , ,

Atraskite Agile metodikų skirtumus

agile_development_logo2Lietuvoje sparčiai augant agile metodikų populiarumui, vis daugiau komandų renkasi scrum, kanban ar scrumban pritaikymus savo našumui pagerinti. Tačiau didėjant vartotojų skaičiui, neišvengiamai didėja ir nesusipratimų, siekiant išsirinkti kiekvienai komandai tinkamiausią metodiką. Svarbu suprasti, jog renkantis geriausią darbo principą, reikia žinoti ne tik jų apibrėžimus, tačiau ir suprasti pagrindinius skirtumus. Būtent šie skirtumai padės atskleisti darbo principus ir komandai teikiamus privalumus.

Darbo metodikų skirtumus patogiausia vertinti pasitelkus konkrečius aptariamus kriterijus. Pirmiausia tai – iteracijos, darbų skirstymas ir darbų apimtis. Šios trys sritys tai vieni pirmųjų dalykų, su kuriais susidursite pradėję diegti naują metodiką komandoje ir nors scrum, kanban ir scrumban metodikos yra panašios, šiuo atveju jos turi ne vieną skirtumą. Continue reading

Tagged , ,

Eylean Board – lankstus projektų valdymo įrankis

Siekiant pagerinti projektų valdymą, daugumą įmonių pradeda naudoti įvairius projektų valdymo įrankius. Tačiau augant šių įrankių pasiūlai, išsirinkti tinkamiausią gali būti sunku. Todėl nauja šio tinklaraščio skiltis skirta tokių įrankių apžvalgai. Pirmasis po padidinamuoju stiklu – lietuviškas projektų valdymo įrankis Eylean Board.

lenta

Eylean komanda veiklą pradėjo prieš trejus metus, kuomet sukūrusi projektų valdymo įrankį savo reikmėms suprato, kad jis gali būti naudingas ir kitiems. Dabar tarp Eylean klientų tokios pasaulinio lygio įmonės, kaip Tesla Motors, British Petroleum, Sandvik ir daug kitų. Taigi, kuo Eylean sužavėjo pasaulio gigantus?

Paprastumu

Eylean Board naudotis paprasta – visos projekto užduotys vaizduojamos vienoje ar keliose projekto lentose, yra lengvai sukuriamos ir keičiamos. Prie užduočių ar darbų komanda gali palikti aprašus, komentarus, prisegti dokumentus ir kitas svarbias detales. Patogu tai, jog bendroje projekto lentoje vaizduojamos tik mažos užduočių kortelės ir svarbiausia su jomis susijusi informacija, tad galima greitai ir patogiai apžvelgti bendrą projekto būseną. Norint gauti daugiau detalių apie konkrečią užduotį, ši informacija yra pasiekiama atidarius konkrečios užduoties detales. Continue reading

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