Burndown diagrama yra palyginti lengva sukurti. Yra daug įrankių, kurie leidžia ją generuoti iš darbo, kurį užfiksavo Vystymo komandos nariai. Nepaisant savo paprastumo, jos interpretacija gali suteikti vertingos informacijos visai Scrum komandai. Perskaitykite šį straipsnį, kad sužinotumėte, kaip sukurti ir interpretuoti Burndown diagramą.
Kaip sukurti ir interpretuoti Burndown diagramą? – turinys:
- Kaip sukurti Burndown diagramą?
- Kas atsakingas už Burndown diagramą?
- Kaip interpretuoti Burndown diagramą?
- Reali ir ideali Burndown diagrama
- Matuoklio pasirinkimas
- Santrauka
Kaip sukurti Burndown diagramą?
Vystymo komanda turėtų stebėti savo kasdienį darbą. Tai yra pagrindas ne tik vertinant jos efektyvumą, bet ir jį gerinant. O vienas iš paprasčiausių ir patikrintų įrankių šiam tikslui yra Burndown diagrama.
Ją galite sukurti rankiniu būdu, piešdami koordinačių sistemą ant popieriaus lapo. Y ašyje turite pavaizduoti darbo kiekį, išreikštą pasirinkta vienete, pavyzdžiui, istorijos taškais. X ašyje nupieškite skalę, nurodančią nuoseklias Sprinto dienas. Nupieškite idealaus sprinto liniją, tada pažymėkite realiai užbaigtų užduočių skaičių kiekvienai dienai. Nors šis sprendimas yra žavus ir įtraukia komandą, jis nėra labai praktiškas. Taip pat jis nebūtinai tinka nuotolinėms komandoms.
Todėl skaitmeniniai Burndown diagramų kūrimo būdai yra daug dažnesni. Daugelis užduočių darbo registravimo įrankių, paskirstytų komandos nariams, turi galimybę automatiškai sukurti Burndown diagramą. Tada viskas, ką turi padaryti programuotojas, tai pažymėti darbo pradžią ir pabaigą konkrečiai produkto funkcijai, o jų indėlis atsispindi Burndown diagramoje.
Naudojant tinkamus įrankius, taip pat galima laisvai keisti diagramos mastelį. Tai suteikia įžvalgų ne tik apie konkretų Sprintą, bet ir apie ketvirtį ar visą projektą.
Pasirenkant įrankį Burndown diagramai kurti, svarbus veiksnys yra prieinamumas visiems Scrum komandos nariams. Burndown diagramos matomumas visai Vystymo komandai yra pagrindinis motyvacinis veiksnys. Taip pat svarbu kasdien stebėti liniją, rodančią likusį darbą. Kalbant apie degimą per Kasdienį Scrum,, tai skatina programuotojus galvoti apie savo darbo būdus ir dabartinę produkto būklę.
Kas atsakingas už Burndown diagramą?
Klausimas dėl Burndown diagramos nuosavybės yra šiek tiek prieštaringas. Viena vertus, ji turėtų priklausyti Scrum Master, nes tai yra įrankis, užtikrinantis, kad komanda dirba efektyviai ir pagal planą. Kita vertus, ji turėtų likti Produkto savininko rankose, nes ji atspindi pažangą link produkto tikslo, kuris yra perduodamas klientui. Be to, trečioji šalis, pretenduojanti į nuosavybę, yra Vystymo komanda, nes diagrama veikia kaip jos vidinis įrankis.
Burndown diagrama yra esminis rodiklis vertinant Vystymo komandos efektyvumą ir tampa priimta visų Scrum komandos narių. Todėl skaidrumas ir prieinamumas yra labai svarbūs. Tačiau jos tikslas yra tarnauti komandai. Ji turėtų stiprinti jos saviorganizaciją, gerinti motyvaciją ir suteikti tikrą vaizdą apie užduočių, priskirtų jai, darbo būklę. Todėl teoriškai kiekvienas Vystymo komandos narys gali atnaujinti Burndown diagramą.
Tačiau praktikoje Burndown diagramos atnaujinimo užduotis paprastai tenka Scrum Master. Tai ypač vyksta jo darbo pradžioje su nauja Vystymo komanda, kai komandos greitis vis dar kinta ir sunkiai įvertinamas. Vis dėlto rekomenduojama šią užduotį deleguoti vienam iš programuotojų. Galų gale, diagrama turėtų būti sąžiningas ir vidinis darbo pažangos matavimas, kaip jį vertina patys programuotojai.
Kaip interpretuoti Burndown diagramą?
Mes išsamiai aprašėme Burndown diagramos išvaizdą ankstesniame straipsnyje. Čia tik priminsime, kad X ašis rodo laiką, likusį užduočiai užbaigti. Kita vertus, Y ašis rodo likusį darbą, kurį reikia atlikti.
Reali ir ideali Burndown diagrama
Norint interpretuoti Burndown diagramą, svarbus veiksnys yra ne tik reguliarus tikro “degimo” žymėjimas, t.y. užduočių vykdymas Vystymo komandos. Lygiai taip pat svarbu yra palyginti su idealaus degimo linijos kritimu (gaires).
Palyginus idealią degimo liniją su realiu darbo sumažėjimu, pažymėtu Burndown diagramoje, galima įvertinti du labai svarbius parametrus. Pirmiausia, ar darbas tęsiasi dabartiniu tempu, Vystymo komanda pasieks Sprinto tikslą ar produkto tikslą laiku. Antra, gauti idėją, kada darbas bus užbaigtas, išlaikant dabartinį tempą. Kitaip tariant, Burndown diagrama rodo tikrą užduočių tempą, o ideali linija rodo, kokiu tempu komanda turėtų dirbti, kad užbaigtų užduotis.
Burndown diagrama taip pat leidžia nustatyti vertę, vadinamą Vystymo komandos greičiu ilgalaikėje perspektyvoje. Tam skirsime atskirą straipsnį. Čia tik paminėsime, kad tai yra vertė, nustatyta pagal atlikto darbo kiekį per vieną Sprintą.
Dėl to, kad Burndown diagrama iliustruoja idealaus degimo linijos palyginimą su realiu užduočių sumažėjimu, ji leidžia įvertinti darbo tempą. Ir taip numatyti projekto vėlavimo riziką.
Matuoklio pasirinkimas
Komandos greitis paprastai matuojamas vienetais, vadinamais istorijos taškais. Tai apibrėžia realizuotų vartotojų istorijų skaičių. Šios gali reikalauti labai skirtingo darbo kiekio.
Štai kodėl daugelis Scrum komandų naudoja laiko pagrindu paremtą matą. Priklausomai nuo mastelio, tai yra dienos arba žmogaus valandos. Kiekvienas programuotojas įvertina ir tada registruoja laiką, praleistą savo užduotims.
Kita galimybė yra priimti užduotis kaip matavimo vienetą. Tai šiek tiek didesni vienetai, kuriems, savo ruožtu, priskiriama vertė, išreikšta istorijos taškais, arba dienomis ar žmogaus valandomis. Tai yra vienetas, leidžiantis klientui aiškiau pateikti darbo pažangą produkto atžvilgiu.
Nepriklausomai nuo matavimo vieneto, verta prisiminti Vystymo komandos greičio skaičiavimo principą. Tam tikrą dieną ar Sprintą skaičiuojamos tik užduotys, kurios buvo iš tikrųjų užbaigtos. Tai reiškia, kad pradėtos užduotys bus skaičiuojamos kitai dienai ar Sprintui, net jei trūksta tik galutinio testavimo.
Santrauka
Naudojant komandos stebėjimo įrankius, Burndown diagramos kūrimas tampa lengva užduotimi. Svarbiausias klausimas yra užtikrinti jos nuoseklumą, aiškumą ir prieinamumą visiems Scrum komandos nariams.
Jei jums patinka mūsų turinys, prisijunkite prie mūsų užimtų bičių bendruomenės Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Kaip projekto vadovė, Karolina yra ekspertė, ieškanti naujų metodų, kaip sukurti geriausius darbo srautus ir optimizuoti procesus. Jos organizaciniai įgūdžiai ir gebėjimas dirbti spaudimo sąlygomis daro ją geriausia asmenybe, galinčia sudėtingus projektus paversti realybe.
Scrum Guide:
- Pagrindinių terminų, vaidmenų ir sąvokų žodynas
- Kas yra Scrum?
- Scrum vertybės
- Kaip įgyvendinti Scrum savo įmonėje?
- Scrum komanda - kas tai yra ir kaip ji veikia?
- Kas yra produkto savininkas?
- Dažniausios Produktų Savininko klaidos
- Kas yra Scrum meistras?
- Dažniausios Scrum Master klaidos
- Kokias statistiką ir metrikas turėtų stebėti Scrum meistras?
- Plėtros komanda Scrum sistemoje
- Dažniausios programuotojų klaidos
- Scrum artefaktai
- Mastelio didinimas Scrum
- Sprinto ataskaita
- Kas yra produkto atsargų sąrašas?
- Kas yra vartotojo istorijos?
- Geriausios vartotojo istorijos kūrimas su INVEST
- Dažniausios vartotojo istorijų klaidos
- Vartotojo istorijos priėmimo kriterijai
- Įvertinimas ir istorijos taškai Scrum metodikoje
- Planavimo pokeris
- Komandos vertinimo žaidimas
- Inkremento apibrėžimas
- Scrum renginiai
- Kas yra degimo diagrama?
- Burndown diagramos privalumai ir trūkumai
- Kanban lentos Scrum ir Scrumban sistemose
- Greitis Scrum - Vystymo komandos greitis
- Kasdienis Scrum
- Sprinto planavimas
- Sprinto apžvalga
- Kas yra Sprinto retrospektyva?
- Bendros klaidos per Sprint retrospektyvą
- Produkto backlog'o puoselėjimas
- Kaip sukurti ir interpretuoti degimo grafiką?