Ohjelmointi

3 ketterää paloraporttia ja miten niitä käytetään

Ketterät käytännöt tuntemattomille ja alitietoisille voivat joskus näkyä tapauskohtaisina ohjelmistokehitys- ja projektinhallintamenetelminä. Totuus on paljon erilainen.

Yksi ketterän ohjelmiston 12 periaatteesta sanoo: "Paras arkkitehtuuri, vaatimukset ja suunnittelu syntyvät itseorganisoituvista tiimeistä", mutta useimmat ketteriä käytäntöjä soveltavat organisaatiot, mukaan lukien scrum ja Kanban, panevat täytäntöön merkittäviä prosessin ankaria vaatimuksia ja rituaaleja. Esimerkiksi monet organisaatiot toteuttavat ketterän suunnittelun käytäntöjä, mukaan lukien tarinapisteiden arviointi, arkkitehtuuristandardit ja julkaisujen hallinnan tieteenalat parantaakseen sovellusjulkaisujen liiketoiminnan vaikutusta, laatua ja luotettavuutta.

Suurin osa joukkueista päättää käyttää ketterää työkalua, kuten Jira Software tai Azure DevOps, hallitsemaan kuormien, sprinttien ja ketterien joukkueiden välistä yhteistyötä. Näiden työkalujen ensisijainen tarkoitus on hallita keskitetysti vaatimuksia, sprintin tilaa, työnkulkua ja yhteistyötä ketterän tiimin jäsenten ja useiden ketterien joukkueiden välillä. Mitä tarkemmin organisaatiot panostavat näiden työkalujen käyttöön, sitä enemmän nämä työkalut voivat auttaa johtajia ja tiimejä tunnistamaan ongelmat, raportoimaan sidosryhmille asemasta ja parantamaan niiden toteuttamista.

Yksi yleisimmistä out-of-the-box-raporteista on polttoraportti. Koska ketterien käytäntöjen avulla tuotteiden omistajat voivat priorisoida myöhästymisen asiakkaiden palautteen perusteella, perinteisissä raporteissa, kuten Gantt-kaavioissa, ei oteta huomioon ketterän suorituksen sujuvuutta. Polttokaavion perustana on, että siinä otetaan huomioon valmistuneet työt, laajuuteen lisätty uusi työ ja muut laajuuden muutokset. Palotaulukko voi antaa nopean kuvan joukkueiden marssimisesta kohti tavoitteitaan.

Lukee sprintin palamisen kaavion

Palontakaavioilla on yleensä aikaa x-akselin poikki ja arviot y-akselilla. Monet joukkueet arvioivat tarinapisteinä, mutta monet ketterät työkalut voivat kartoittaa palovammat tarinoiden tai arvioiden lukumäärän perusteella tunneissa. Oletan, että tässä artikkelissa käytetään tarinapisteitä.

Sprintin palovammaraportti kuvaa tarinapisteiden määrän, jotka ovat voimassa aikavälillä. Kun tiimi viimeistelee tarinoita, kaavio osoittaa, kuinka ne "polttavat" tarinaluettelon ja muun tyyppiset työt (Jiran ongelmat, Azure DevOps -työkalutyypit), kunnes työ on valmis tai sprintti päättyy. Kun joukkueet suorittavat sprintille sitoutuneen työn, piirretty viiva leikkaa x-akselin, mikä osoittaa, että kaikki on tehty.

Sprintin palaminen on helpoin käsitteellistää. Sprintin ensimmäisenä päivänä joukkue sitoutuu joihinkin tarinoihin ja tarinapisteiden kokonaismäärään. Jos tarkastelet polttokaaviota sinä päivänä, y-akselilla pitäisi näkyä yksi piste, joka edustaa joukkueen sitoutuneiden pisteiden määrää sprintin nollapäivänä.

Kun tarinat merkitään valmiiksi, sprintin palaminen näyttää jäljellä olevan määrän pisteitä.

Kuinka sprintin palamista käytetään käytännössä? Terve palaminen osoittaa lineaarisen ja ihanteellisesti eksponentiaalisen käyrän nollaan. Jos käyrällä on tasainen kaltevuus sprintin alkupuolella, se voi osoittaa lohkoja tai paljon käynnissä olevaa työtä ja että sprintti voi olla vaarassa. Tasainen tai hitaasti viisto palaminen voi olla erittäin ongelmallista, jos koodin täydellisille tarinoille suoritetaan paljon testejä ja jos testityö voi alkaa vasta sprintin viimeisinä päivinä.

Nopeasti laskeutuva sprintin palaminen on yleensä hyvä asia, mutta se voi viitata siihen, että joukkue on sitoutumaton tai on päättänyt ottaa sprintissä vain pienempiä tarinoita.

Eeppiset palovammat seuraavat kehitystä liike- ja teknisten kuljettajien suhteen

Sprint-palot ovat erittäin hyödyllisiä lyhytaikaisen suorituksen seurannassa ja auttavat joukkueita täyttämään sprintin sitoumukset. Eeppisten ja vapautettujen palovammojen avulla voidaan seurata paremmin pitkän aikavälin tavoitteita ja saavuttaa tarvittava näkyvyys.

Eeppiset palovammat toimivat parhaiten, kun tiimit määrittelevät useita pitkäaikaisia ​​ponnisteluja, kuten suurten loppukäyttäjien ominaisuuksien, teknisten velkastrategioiden, suorituskyvyn parantamisen tai prosessin kehityksen toteuttamisen. Eeppisten palovammojen hyödyntämiseksi myöhässä tulisi olla:

  • Viisi ja 15 eeposta, jotka kestävät vähintään useita kuukausia ja kestävät vähintään kuusi pikajuoksua.
  • Ominaisuudet, tarinat ja tarinatankot, jotka rullaavat eepoksen alle ja edustavat korkean tason suunnitelmaa eepoksen toteuttamiseksi.
  • Korkean tason arviot, mieluiten tarinapisteissä jokaisesta tarinasta tai tarinan tupasta, joka rullaa eeposien alle.

Kun nämä ovat paikallaan, eeppinen palaminen kuvaa kaavion muutokset tähän suunnitelmaan. Sen x-akseli edustaa sprinttejä, ja y-akseli edustaa eepokselle osoitettujen tarinoiden ja tarinoiden kokonaisarviota. Jira Softwaren eeppisessä polttokaaviossa näet pylväskaavion, jossa on yksi väri, joka edustaa sprintissä suoritettuja tarinoita ja toinen, joka näyttää lisätyt tarinapisteet. Tarinapisteet kasvavat, kun eepokseen lisätään uusia tarinoita tai tarinoita tai kun arviot muuttuvat.

Eeppistä polttokaaviota on useita tapoja:

  • Se kuvaa ominaisuuksien ja tarinoiden suorittamisen nopeutta suunnitelmaa vastaan. Kun suunnitelmat ovat tarkkoja ja tiimin nopeus yhdenmukainen, se voi olla indikaattori eepoksen työn valmistumisesta.
  • Useimmat ketterät suunnitelmat eivät ole täydellisiä, ja joukkueet lisäävät, muuttavat ja poistavat tarinoita, jotka perustuvat loppukäyttäjien palautteeseen, teknisten monimutkaisuuksien löytämiseen ja matkan aikana käyttöön otetun teknisen velan korjaamiseen. Eeppinen palaminen osoittaa sitten, kuinka kaukana suunnitelmasta eepos perustuu siihen, kuinka paljon viivästys kasvaa verrattuna sprintin suorittamaan sprinttiin.
  • Eeppiset palovammat auttavat myös vertailemaan useiden sprinttien ponnisteluja ja mittaamaan, kuinka paljon suunnittelu- ja toimitustöitä tehdään yhdessä eepoksessa verrattuna muihin.

Julkaisupalot ilmoittavat joukkueille, osuvatko julkaisut päivämäärää ja laajuutta

Edistyneet tiimit, jotka automatisoivat toimitusputkistonsa täydellisesti jatkuvalla integroinnilla, jatkuvalla testauksella ja jatkuvalla toimituksella, eivät ehkä tarvitse julkaisupaloja. Usein käyttöön ottavien joukkueiden tulisi seurata, mitkä ominaisuudet ja tarinat on sidottu julkaisuun, mutta julkaisun palaminen ei ole kovin hyödyllistä, koska se seuraa usein edistymistä sprintin mukaan.

Muille tiimeille, jotka seuraavat julkaisunhallintakäytäntöjä ja standardoivat usean painoksen julkaisuja, julkaisun palaminen voi olla tuotteen omistajan ja tiimin tärkein työkalu.

Julkaisun palaminen on samanlainen kuin eeppinen palaminen, paitsi että eeppeen määritettyjen ominaisuuksien, tarinoiden ja tarinankappaleiden seurannan sijaan julkaisun palaminen osoittaa, mikä julkaisulle on määritetty. Akseli ja palkit ovat sitten identtisiä eeppisten palovammojen kanssa.

Joukkueet, jotka käyttävät julkaisupalautuksia, voivat siten seurata julkaisun laajuutta ja aikataulua. Raidalla olevat joukkueet näkevät palamisrampin alas x-akselille, jonka kaltevuus vastaa joukkueen nopeutta. Julkaisuilla, jotka saattavat siirtyä radalta, on joko pienempi kaltevuus tai ne kuvaavat enemmän lisättäviä tarinapisteitä (kun julkaisuun lisätään enemmän laajuutta) kuin mitä valmistutaan.

Jira Software auttaa sinua näissä ennusteissa. Olettaen, että joukkue on työskennellyt projektissa vähintään kolmen sprintin ajan, Jira Software laskee joukkueen keskimääräisen nopeuden ja ennustaa lopullisen sprintin julkaisulle tämän nopeuden perusteella.

Sprintin, eeppisen ja vapauttamisen palamat antavat joukkueille joitain helppokäyttöisiä työkaluja tavoitteiden saavuttamiseen. Kun joukkueilla on yhteinen käsitys soveltamisalasta, sovitaan prioriteeteista, suunnitellaan useita pikajuoksuja eteenpäin ja merkitään tarinoita myöhässä myöhässä, palovammat kertovat, onko suunnittelu ja toteutus linjassa tavoitteiden kanssa. Kun he eivät ole, ne ovat datapohjainen työkalu, joka voi herättää keskustelua siitä, mitä muutoksia tarvitaan.

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