Scrum vadovas | 11. Statistika ir metrikos, kurias Scrum meistras turėtų stebėti

Kodėl Scrum Master’ui reikalinga statistika ir metrikos? Pirmiausia, kad patikrintų, ar jo darbo metodai, skirti rezultatų prognozavimui ir komandos efektyvumo gerinimui, yra veiksmingi. Taip pat, kad stebėtų, kaip jų veiksmai veikia Plėtros komandą. Tai yra, kaip jie formuoja darbuotojų vartotojo patirtį (UX). Taigi šiame straipsnyje pristatome statistiką ir metrikas, kurias Scrum Master’is turėtų stebėti.

Scrum Master’ui svarbi statistika ir metrikos – turinys:

1. Plėtros komandos darbo rezultatų matavimas
2. Darbuotojų vartotojo patirties stebėjimas
3. Santrauka

Plėtros komandos darbo rezultatų matavimas

Dažniausiai naudojama statistika ir metrikos, kurias Scrum Master’is turėtų stebėti, yra tos, kurios apibūdina užduočių vykdymo tempą ir srautą. Tai yra Burnup diagrama, Burndown diagrama ir Kumulatyvinio srauto diagrama. Šie matavimai vertina tiek produkto plėtrą, tiek komandos efektyvumą. Kiekvienas leidžia pažvelgti į šias problemas iš skirtingo kampo, todėl gerai juos parodyti kartu. Tai naudingi įrankiai, vertinantys pažangą skirtingais masteliais, tiek Sprint’o metu, tiek viso produkto plėtros proceso metu.

Burndown diagrama

Burndown diagrama rodo Scrum Master’iui ir Plėtros komandai, kiek darbo jau atlikta ir kiek dar liko padaryti. X ašis rodo laiką, likusį darbui užbaigti. Y ašis rodo likusį atlikti darbą, kuris buvo suplanuotas Sprint’o Backlog’e arba Produkto Backlog’e.

Ši diagrama taip pat padeda nustatyti Plėtros komandos greitį, kuriam taip pat skirsime atskirą straipsnį. Čia tik paminėsime, kad tai yra vidutinė darbo apimtis, atlikta per vieną Sprint’ą.

Šis paprastas įrankis leidžia Scrum Master’iui ne tik matyti kaip efektyviai komanda dirba. Jis taip pat padeda atsakyti į klausimus:

• Kokia dalis darbo jau buvo atlikta?
• Kiek užduočių liko užbaigti?
• Kiek laiko užtruks produkto plėtra?

Naudojant Burndown diagramą, Scrum Master’is turi atsiminti, kad tai nėra vienintelis įrankis statistiškai vertinti komandos pažangą. Ji geriausiai veikia projektuose, kur darbo apimtis yra fiksuota ir žinoma. Ji nepasiteisina kuriant labai novatoriškus sprendimus su nauju Klientu. Tada viso projekto atliktino darbo apimtis – tai yra Produkto Backlog’o turinys – gali žymiai keistis projekto metu, todėl sunku naudoti Burndown diagramą.

Burnup diagrama

Burnup diagrama yra priešingybė aukščiau aptartai Burndown diagramai. Čia taip pat Y ašis rodo likusį atlikti darbą. X ašis, kita vertus, rodo užbaigimo laiką, išreikštą arba Sprint’ų skaičiumi, arba datomis.

Tačiau Scrum Master’is naudoja Burnup diagramą šiek tiek kitam tikslui. Tai yra todėl, kad ji ne tik padeda matuoti produkto pažangą ir komandos pažangą. Ši metrika taip pat vertina, kaip darbo apimtis projekte keičiasi laikui bėgant. Todėl ji gerai veikia projektuose su kintama apimtimi.

Burnup diagrama taip pat yra planavimo įrankis, kuris laikui bėgant tampa vis efektyvesnis. Ji suteikia atsakymus į klausimą, kiek darbo Plėtros komanda planuoja atlikti kitame Sprint’e.

Kumulatyvinio srauto diagrama

Trečiasis diagramos tipas, kuris yra labai naudingas Scrum Master’io darbui su Plėtros komanda, yra Kumulatyvinio srauto diagrama. Ji apima kaip stabilus yra Plėtros komandos tempas ir produktyvumas. Jos ašių išdėstymas yra toks pats kaip Burnup diagramoje, todėl ji dažnai vadinama jos sudėtingesne versija.

Tačiau Kumulatyvinio srauto diagrama ne tik nustato užduočių, atliktų per tam tikrą laikotarpį, skaičių. Ji taip pat atsižvelgia į užduočių, laukiančių vykdymo, skaičių. Dėl to ji leidžia diagnozuoti vadinamuosius “sukibimus” – proceso momentus, kurie lėtina produkto kūrimą.

Ši labai diagnostinė funkcija daro ją viena naudingiausių metrikų Scrum Master’io rankose. Tai yra todėl, kad ji leidžia reorganizuoti darbą taip, kad būtų kitaip paskirstyta Plėtros komandos jėga ir išvengta prastovų.

Darbuotojų vartotojo patirties stebėjimas

Reguliarus ir kruopštus statistikos priežiūra ir analizė yra esminė efektyvaus Scrum Master’io darbo dalis. Tačiau jis / ji turi pirmiausia atsižvelgti į darbuotojų vartotojo patirtį, t.y., kaip jie suvokia darbą Scrum komandoje. Tačiau ne metrikos kokybė lemia, o tai, kaip Scrum Master’is jas naudoja.

Jei statistika laikoma pagal Scrum principus – ji yra skaidri, vieša ir suprantama įtrauktiems Plėtros darbuotojams – ji gali būti būdas motyvuoti komandą dirbti efektyviau arba apdovanoti juos už puikius rezultatus. Tačiau statistika gali veikti kaip įrankis, darantis spaudimą Plėtros komandai. Tada jų rodikliai tampa kaltinimų ir nuoskaudų generatoriumi. Jie gali prisidėti prie komandos moralės pablogėjimo ir komandinio darbo praktikų sugadinimo.

Antras svarbus darbuotojų patirties veiksnys, kurį Scrum Master’is, dirbantis su statistiniais įrankiais, turi prižiūrėti, yra laiko valdymo būdas. Tai yra todėl, kad Scrum Master’iu reikia turėti pakankamai laiko rūpintis Plėtros komanda. Dėl šios priežasties, didelio projekto atveju, verta apsvarstyti galimybę įtraukti papildomą asmenį į Scrum komandą. Jis / ji veiks kaip projekto vadovas ir rūpinsis metrikomis. Dėl to tai atlaisvins Scrum Master’į – ir iki tam tikros ribos Produkto savininką – nuo užduočių, kurios atitraukia jį nuo darbo su Plėtros komanda.

Statistika ir metrikos – santrauka

Scrum Master’is turėtų stebėti pagrindinę statistiką, apibūdinančią Plėtros komandos darbą. Jų įgudęs interpretavimas padidina galimybę greitai pastebėti problemas komandos darbe ir reaguoti į jas. Tačiau svarbiau nei laikyti diagramas yra tai, ką Scrum Master’is su jomis daro. Jie neturėtų vertinti metrikų kaip įrankio komandos vertinimui, o labiau kaip naudingą pagalbą motyvuojant komandą ir diagnozuojant jų pačių darbo būdą. Tai yra todėl, kad metrikos bus naudingos tik tuo atveju, jei jos padės palengvinti komandos ir produkto tobulinimo procesus.

Jei jums patinka mūsų turinys, prisijunkite prie mūsų užimtų bičių bendruomenės Facebook, Twitter, LinkedIn, Instagram, YouTube.