Programavimas

3 judrios sudegimo ataskaitos ir kaip jas naudoti

Vykdanti praktika nežinantiems ir nepakankamai informuotiems žmonėms kartais gali pasirodyti kaip ad hoc programinės įrangos kūrimo ir projektų valdymo metodika. Tiesa yra gerokai kitokia.

Vienas iš 12 judrios programinės įrangos principų teigia: „Geriausios architektūros, reikalavimai ir dizainas atsiranda iš organizuojančių komandų“, tačiau dauguma organizacijų, kurios taiko judrią praktiką, įskaitant „scrum“ ir „Kanban“, vykdo kai kuriuos reikšmingus proceso griežtumus ir ritualus. Pavyzdžiui, daugelis organizacijų taiko judriojo planavimo praktiką, įskaitant istorijos taškų įvertinimą, architektūros standartus ir leidimų valdymo disciplinas, kad pagerintų verslo poveikį, kokybę ir patikimą programų leidimus.

Daugelis komandų nusprendžia naudoti judrų įrankį, pvz., „Jira Software“ ar „Azure DevOps“, kad valdytų atsilikimus, sprintus ir judrių komandų bendradarbiavimą. Pagrindinis šių įrankių tikslas yra centralizuotai valdyti reikalavimus, sprinto būseną, darbo eigą ir bendradarbiavimą tarp judrių komandos narių ir kelių judrių komandų. Tačiau kuo griežtesnės organizacijos naudojasi šiais įrankiais, tuo daugiau šios priemonės gali padėti lyderiams ir komandoms nustatyti problemas, pranešti suinteresuotosioms šalims apie būseną ir pagerinti jų vykdymą.

Viena iš dažniausiai pasitaikančių pranešimų yra sudegimo ataskaita. Kadangi vikri praktika leidžia produktų savininkams perkelti prioritetus, atsižvelgiant į klientų atsiliepimus, tradicinėse ataskaitose, tokiose kaip „Gantt“ diagramos, nepavyksta užfiksuoti sklandaus judraus vykdymo pobūdžio. Pagrindinė sudedamųjų dalių diagrama yra ta, kad joje atsižvelgiama į atliktus darbus, į sritį pridėtus naujus darbus ir kitus srities pakeitimus. Nudegimo diagrama gali suteikti greitą vaizdą apie tai, kaip komandos žengia link savo tikslų.

Skaityti pagrindinę sprinto sudegimo diagramą

Apdegimo diagramos paprastai turi laiką visoje x ašyje ir įvertina y ašį. Daugelis komandų vertina pasakojimus, tačiau daugybė judrių įrankių gali sudeginti duomenis pagal istorijų skaičių arba įvertinimus valandomis. Darau prielaidą, kad šiame straipsnyje naudojami istorijos taškai.

Sprinto sudegimo ataskaitoje pateikiamas istorijos taškų, kuriems taikoma laiko intervalas, skaičius. Komandai baigiant istorijas, diagramoje parodyta, kaip jos „sudega“ istorijų ir kitų rūšių darbų sąrašą („Jira“ problemos, „Azure DevOps“ darbo elementų tipai), kol darbas bus baigtas arba sprintas baigsis. Komandoms atlikus sprintui skirtą darbą, nubrėžta linija kerta x ašį, nurodydama, kad viskas padaryta.

Sprinto sudegimą yra lengviausia suvokti. Pirmąją sprinto dieną komanda įsipareigoja atsižvelgti į kai kurias istorijas ir bendrą pasakojimų taškų skaičių. Jei peržiūrėsite tos dienos sudegimo diagramą, y ašyje turėtumėte pamatyti vieną tašką, nurodantį taškų skaičių, kurį komanda paskyrė sprinto nulinę dieną.

Kai istorijos pažymimos kaip baigtos, sprinto sudeginimas rodo likusį užbaigtų taškų skaičių.

Kaip praktiškai naudojamas sprinto perdegimas? Sveikas perdegimas rodo tiesinę ir idealiu atveju eksponentinę kreivę iki nulio. Jei kreivė yra plokščio nuolydžio ankstyvojoje sprinto dalyje, tai gali reikšti blokus arba daugelį nebaigtų darbų ir kad sprintui gali kilti pavojus. Plokščias arba lėtai nuožulnus perdegimas gali būti labai problemiškas, jei atliekama daug kodų užbaigtų istorijų bandymų ir jei bandymo darbai negali prasidėti iki kelių paskutiniųjų sprinto dienų.

Greitai besileidžiantis sprinto perdegimas paprastai yra geras dalykas, tačiau tai gali reikšti, kad komanda yra nepakankamai įsipareigojusi arba pasirinko sprinte tik mažesnes istorijas.

Epas perdegimas stebi pažangą, palyginti su verslo ir techniniais veiksniais

Sprinto perdegimai yra labai naudingi stebint trumpalaikį vykdymą ir padeda komandoms sėkmingai vykdyti sprinto įsipareigojimus. Norint geriau sekti pažangą siekiant ilgalaikių tikslų, epinės ir išlaisvinimo versijos suteikia reikiamą matomumą.

Efektyvūs perdegimai geriausiai veikia, kai komandos apibrėžia keletą ilgalaikių pastangų, pavyzdžiui, įgyvendina pagrindines galutinio vartotojo galimybes, technines skolų strategijas, našumo patobulinimus ar procesų pokyčius. Norint pasinaudoti epinių perdegimų pranašumais, neužbaigtoje veikloje turėtų būti:

  • Tarp penkių ir 15 epų, kurios truks mažiausiai kelis mėnesius ir užtruks šešis ar daugiau sprintų.
  • Po epu susivynioję bruožai, istorijos ir pasakojimai, atspindintys aukšto lygio epo planą.
  • Aukšto lygio įverčiai, idealiu atveju - pasakojimai apie kiekvieną epopėjoje sukurtą istoriją ar pasakojimą.

Kai jie bus sukurti, epinė sudegimo schema rodo šio plano pakeitimus. Jo x ašis atspindi sprintus, o y ašis - bendrą epui priskirtų istorijų ir pasakų sąmatų įvertį. „Jira Software“ epinėje sudegimo diagramoje matote juostos diagramą, kurios viena spalva atspindi sprinto metu užbaigtas istorijas, o antroji rodo pridėtus istorijos taškus. Istorijos taškai padidėja, kai į epą įtraukiama naujų istorijų ar pasakojimų šaknų arba kai keičiasi įverčiai.

Yra keli būdai, kaip naudoti epinę sudegimo diagramą:

  • Tai iliustruoja funkcijų ir istorijų užbaigimo greitį pagal planą. Kai planai yra tikslūs ir pastovus komandos greitis, tai gali būti indikatorius, kai epo darbas bus baigtas.
  • Daugelis judrių planų nėra baigti, o komandos prideda, keičia ir pašalina istorijas, remdamosi galutinio vartotojo atsiliepimais, techninių sunkumų atradimu ir kelionės metu atsiradusių techninių skolų sprendimu. Tada epo sudegimas nurodo, kiek toli nuo epo yra planas, atsižvelgiant į tai, kiek auga atsilikimas, palyginti su sprinto užbaigimu.
  • Epas perdegimas taip pat padeda palyginti daugelio sprintų pastangas ir įvertinti, kiek planavimo ir pristatymo darbų atliekama per vieną epą, palyginti su kitais.

Išleidimo perdegimai informuoja komandas, ar leidimai pasieks datą ir apimtį

Pažangiosioms komandoms, kurios visiškai automatizuoja savo tiekimo vamzdynus, nuolat integruodamos, nuolat bandydamos ir teikdamos nuolatinį pristatymą, gali nebūti reikalingų perdegimų. Dažnai dislokuojančios komandos turėtų sekti, kokios funkcijos ir istorijos yra susietos su leidimu, tačiau leidimo perdegimas nėra labai naudingas, nes jis dažnai stebi progresą.

Kitoms komandoms, kurios laikosi leidimo valdymo praktikos ir standartizuoja daugiaspausdinius leidimus, leidimo perdegimas gali būti svarbiausias produkto savininko ir komandos įrankis.

Išleidimo perdegimas yra panašus į epinį sudegimą, išskyrus tai, kad vietoj epo priskirtų funkcijų, istorijų ir pasakojimų dalių, leidimo perdegimas rodo, kas priskirta leidimui. Ašis ir strypai yra identiški epinių sudegimų atveju.

Komandos, naudojančios leidimo perdegimus, gali stebėti leidimo mastą ir laiką. Važiuojančios komandos matys degimo nuolydį iki x ašies, kurios nuolydis atitinka komandos greitį. Leidinių, kurie gali nukrypti nuo bėgių, nuolydis yra mažesnis arba juose vaizduojama daugiau istorinių taškų (kai leidiniui pridedama daugiau apimties) nei baigiama.

„Jira“ programinė įranga padeda jums atlikti šias projekcijas. Darant prielaidą, kad komanda dirba bent tris kartus, „Jira Software“ apskaičiuos vidutinį komandos greitį ir pagal šį greitį prognozuos leidimo pabaigos sprintą.

Sprinto, epo ir paleidimo perdegimai suteikia komandoms keletą lengvai naudojamų įrankių, kad jie atitiktų tikslus. Kai komandos vienodai supranta taikymo sritį, susitaria dėl prioritetų, planuoja keletą sprinto į priekį ir tinkamai pažymi istorijas savo atsilikime, perdegimai pasakoja, ar planavimas ir vykdymas atitinka tikslus. Kai jų nėra, tai yra duomenimis pagrįstas įrankis, kuris gali paskatinti diskusijas apie tai, kokių koregavimų gali prireikti.

$config[zx-auto] not found$config[zx-overlay] not found