Burndown diagrama turi daug privalumų. Tai yra viena iš pagrindinių metrikos priemonių Scrum, dėl kelių priežasčių. Ji yra lengva sukurti, pritaikyti ir skaityti. Tačiau ji taip pat turi trūkumų, dėl kurių ji nėra universali priemonė. Šiandienos straipsnyje aptarsime Burndown diagramos privalumus ir trūkumus.
Mes rašėme apie tai, kas tai yra, kaip sukurti ir interpretuoti Burndown diagramą ankstesniuose straipsniuose. Šiandien mes sutelksime dėmesį į Burndown diagramos privalumus ir trūkumus. Tačiau dauguma jų nėra paslėpti pačioje paprastoje diagramoje. Vietoj to, jie yra susiję su Burndown diagramos naudojimo būdais, kad motyvuotų plėtros komandą, nes jie apibūdina savo darbo rezultatus ir stiprina saviorganizaciją.
Burndown diagrama leidžia vizualizuoti jūsų projekto pažangą. Jos skaitomumas ir paprastumas daro ją labai populiarią. Todėl gerai, kad Burndown diagrama būtų ne tik nuolat atnaujinama metrika, paslėpta skaitmeninėje projektų valdymo priemonėje. Jei tik įmanoma, verta ją padaryti referenciniu tašku plėtros komandai, matomu fizinėje darbo vietoje. Nesvarbu, ar tai būtų ekrane matoma vizualizacija, ar ranka piešta eskizas.
Burndown diagramos skaidrumas gali padaryti ją priemone, motyvuojančia plėtros komandą dirbti efektyviai. Pasiekti “nulinį” tašką kiekviename Sprint’e gali tapti ambicingu komandos tikslu, už kurį suteikiamos premijos – pagal verslo žaidimų principus.
Atnaujintos ir įdomiai prižiūrimos Burndown diagramos matomumas taip pat gali sustiprinti bendradarbiavimo ir saviorganizacijos dvasią. Galų gale, metrika yra komandinio darbo matas. Ji neparodo tiksliai, kas atliko – ar ne – suplanuotus uždavinius, tik pasiektus rezultatus.
Plėtros komanda nusprendžia, kiek užduočių jie atliks tam tikrame Sprint’e. Kuo labiau patyrusi komanda, tuo tiksliau jie turėtų prognozuoti savo veiksmus. Ir burndown diagrama atspindi tikrąją Sprint’o pažangą.
Taigi, Burndown diagramos privalumas nėra tiek matuoti objektyvų atlikto darbo kiekį, bet planuotų ir atliktų užduočių santykį. Taigi, plėtros komanda pamažu išmoksta, kaip jas planuoti, ir gali vis tiksliau įvertinti savo galimybes bei pašalinti pasikartojančias klaidas.
Vienas iš reikšmingų Burndown diagramos privalumų yra jos universalumas derinant su kitomis priemonėmis. Šios priemonės gali būti taikomos:
Pavyzdžiui, pastaruoju atveju, naudojant projekto skalės Burndown diagramą, galima palyginti suplanuotą ir tikrąjį biudžetą visam projektui.
Nepaisant visų aukščiau išdėstytų Burndown diagramos privalumų, ji gali tapti painiavos šaltiniu plėtros komandai. Tačiau tai, ką dažnai vadiname Burndown diagramos “trūkumais”, nėra dėl pačios priemonės trūkumų. Žemiau išdėstyti problemos susijusios su Burndown diagramos įgyvendinimo būdu, o ne jos dizainu. Žemiau pateikiami trūkumai, kurie gali trukdyti vaizduoti plėtros komandos pažangą šiuo būdu.
Diagramas negalima laikyti absoliučiu komandos pažangos matu. Jos yra tik priemonės, kurias galima taikyti įvairiais, labiau ar mažiau įgudusiais būdais. Galime tai laikyti trūkumu (arba privalumu) ne tik Burndown diagramai, bet ir kitoms komandos veiklos matavimo priemonėms.
Norint sukurti Burndown diagramą, reikia kitų žmonių įvesti duomenis. Kitaip tariant, plėtros komanda užrašo užduočių atlikimo laiką diagramoje. Jie galėjo šiek tiek pailginti arba sutrumpinti jį – arba dėl neatidumo, arba norėdami pagerinti situaciją komandai. Plėtros komanda taip pat kartais pamiršta užregistruoti savo laiką. Arba palieka laikmatį įjungtą. Tai sukelia darbo laiką, kuris prailgėja iki kelių valandų. Ir po klaidos atradimo sunku atkurti tikrąjį jos eigą.
Sprint Backlog’as neturėtų būti keičiamas po Sprint’o pradžios. Tačiau praktikoje tokie pokyčiai įvyksta gana dažnai. Jie kyla dėl besikeičiančių suinteresuotųjų šalių reikalavimų. Arba dėl nenumatytų problemų, su kuriomis susiduria plėtros komanda.
Tai sukelia Burndown diagramos skalę. Tai yra todėl, kad užduočių atlikimui skirtas laikas išlieka tas pats. Tačiau likusių užduočių skalė didėja. Tai gali sukelti klaidingą įspūdį, kad plėtros komanda neteisingai suplanuoja darbą, kurį reikia atlikti tam tikrame Sprint’e. Arba kad ji dirba per lėtai.
Pokyčiai Sprint Backlog’e taip pat gali kilti dėl užduočių, kurios buvo numatytos atlikti per greitai. Tokiu atveju plėtros komanda paprastai nusprendžia padidinti užduočių skaičių. Tai savo ruožtu gali lemti, kad jų nebus galima atlikti laiku. Taip pat gali kilti konfliktų dėl likusių užduočių iš ankstesnio Sprint’o, kurios sutampa su naujomis užduotimis, kurias numatė suinteresuotosios šalys ir produkto savininkai.
Dideli pokyčiai produkto Backlog’e gali sutrikdyti Burndown diagramos formą. Ir taip stipriai iškreipti darbo pažangos ir komandos efektyvumo vaizdą. Tai įvyksta, kai atsiranda naujos vartotojų istorijos. O tos, kurios yra arti įgyvendinimo etapo, dažnai yra padalijamos į mažesnes dalis. Taip pat nutinka, kad klientas atsisako kai kurių produkto funkcionalumų.
Todėl, interpretuojant Burndown diagramą, reikia vadovautis žiniomis ir patirtimi vertinant komandos veiklą. Taip pat reikia atsižvelgti į Backlog’o kintamumą. Jei diagrama nėra vienintelė metrika, naudojama veiklai vertinti, kitos diagramos leis pamatyti išsamesnį darbo pažangos vaizdą.
Burndown diagrama gali reikšmingai prisidėti prie plėtros komandos motyvacijos. Tai yra todėl, kad ji suteikia tikrą atlikto darbo matą pagal planą. Be to, jos derinimas su kitomis metrikos priemonėmis gali būti vertingos žinios apie komandos darbą ir produkto planavimą.
Atidžiai taikydami Scrum principus, galite išvengti galimų problemų su Burndown diagrama. Svarbiausia yra pritaikyti diagramos laikymo priemones, atsižvelgiant į tikrąją Scrum komandos veiklą, taip pat minimalizuoti pokyčius Sprint ir produkto Backlog’e, apie kuriuos daugiau rašome šiame straipsnyje.
Jei jums patinka mūsų turinys, prisijunkite prie mūsų užimtų bičių bendruomenės Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
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.
Ar kada nors jaučiate, kad diena per trumpa viskam, ką planavote, padaryti? Visi mes tai…
Kas yra programinė įranga? Kokie yra jos tipai ir platinimo metodai? Kalbėdami apie skaitmeninius produktus,…
Pateikti ir perduoti tyrimų rezultatus greičiausiai yra viena iš svarbiausių (ir reikalaujančių daug pastangų) UX…
Ar žinote, kaip sukurti el. knygą? Ar žinote visus esminius el. knygos gamybos proceso aspektus?…
Tvarus marketingas nebe yra tik viena iš marketingo strategijų, kurias galite taikyti savo įmonėje, bet…
Neseniai darbo rinkoje pasirodė du reiškiniai, susiję su šiuolaikinių darbuotojų ir vadovų požiūriu – tylus…