ketterät ohjelmistokehityksen Mittarit ja KPI: t, jotka auttavat optimoimaan tuotteen toimituksen

lukuaika: 13 minuuttia

ketterä lähestymistapa ohjelmistokehitykseen on ollut jo pitkään yleinen käytäntö. HP online-kyselyn mukaan IT-alan ammattilaisista 16 prosenttia valitsee puhtaan ketterän, 51 prosenttia nojaa siihen ja 24 prosenttia omaksuu ketterän hybridiajattelun. Nykyään Putouksen kehitys mainitaan useimmiten ketteränä erottelijana, mitä ketterä ei ole. Olemme laajasti keskustelleet whitepaperin tärkeimmistä eroista ketterässä projektinhallintamenetelmässä.

ketterän johtamisen sopeutuvuudesta ja joustavuudesta ja nopeasta reagoinnista muutoksiin huolimatta työnkulku voi pysyä keskitettynä ja kontrolloituna. Ketterät suorituskykymittarit (key performance Indicators) ohjaavat strategista suunnittelua, arviointia ja toimintaprosessien parantamista.

perinteisissä arvonhallintajärjestelmissä keskitytään yleensä tehtävien suorittamiseen kategorisen aikataulun ja kustannusten puitteissa. Agilessa asiakkaat ja tiimin jäsenet näkevät kuitenkin välittömiä tuloksia ja muokkaavat aikatauluja ja pyrkivät toimittamaan tuotteen, joka vastaa aikatauluvaatimuksia. Mitä välineitä ja tekniikoita tällainen tieto vaatii? Tässä on katsauksemme ketterän kehityksen mittareiden suorituskyvyn arviointiin.

Agile software development KPI

tässä artikkelissa emme aio tutkia kaikkia mahdollisia ketterän kehityksen mittareita ja KPI: Itä. Sen päälle voi keksiä omia, projektiin parhaiten sopivia. Kuvaamme kuitenkin yleisimmät KPI: t, joita käytetään useilla ohjelmistokehityksen osa-alueilla:

• nopeus
• Sprint burndown
• Release burndown
• syklin aika
• kumulatiivinen virtaus
• Virtaustehokkuus
• Code coverage by automated tests
• Test automation against manual testing
• McCabe cyclomatic complexity (MCC)
• Code churn

keskeneräisen työn mittaaminen

nopeus

nopeus mittaa sprintissä suoritetun työn määrää (useita ominaisuuksia). Vaikka se ei ole ennuste-tai vertailutyökalu, velocity tarjoaa tiimeille käsityksen siitä, kuinka paljon työtä voidaan tehdä seuraavassa sprintissä.

Velocity index on yksilöllinen jokaiselle joukkueelle ja se tulisi asettaa arvioimaan, kuinka realistinen sitoutuminen on. Esimerkiksi, jos projektin backlog on 200 story pistettä ja keskimäärin joukkue täydentää 10 story pistettä per sprintti, se tarkoittaa, että joukkue tarvitsee noin 20 sprints loppuun projektin.

mitä pitempään nopeutta seuraa, sitä suurempi on velvoitteiden ja kustannusten vastaavuuden tarkkuus

sillä tiimillä, joka on juuri omaksunut ketterän menetelmän tai jopa aloittanut uuden tuotteen, ensimmäisten sprinttien nopeusarviot ovat todennäköisesti arvaamattomia. Mutta kun joukkueet saavat kokemusta, nopeus on huipussaan ja sitten saavuttaa tasanko ennustettavissa virtaus ja suorituskyvyn odote. Tasaisen virtauksen väheneminen kertoo kehityksen ongelmista ja kertoo muutoksen tarpeesta.

vinkkejä nopeusmittarin käyttöön

Torjuntahäviö 3-5 pyrähdyksen jälkeen. Jos nopeus pysyy epäjohdonmukaisena pitkän ajan kuluttua, harkitse sekä ulkoisten että sisäisten tekijöiden arviointia, joka estää selkeän estimoinnin.

muuta joukkue-ja tehtävämuutoksia seuraavaa nopeusseurantaa. Kun tiimin jäsen poistuu projektista tai lisää jäseniä/tehtäviä lisätään, laske nopeus uudelleen tai käynnistä laskenta kokonaan uudelleen.

kolme sprinttiä riittää varhaisiin ennusteisiin. Tulevaisuuden suorituskyvyn ennustamiseen käytetään kolmen edellisen sprintin keskiarvoa.

Sprintin burndown kaavio

sprintin burndown-kaavio kertoo, kuinka paljon työtä on jäljellä ennen sprintin päättymistä. Työkalu on erityisen arvokas, koska se näyttää edistymistä kohti tavoitetta sen sijaan, että lueteltaisiin valmiita kohteita. Siitä on hyötyä myös suunnitteluvirheiden paljastamisessa, joita joukkue teki sprintin alussa.

alla olevassa kaaviossa musta viiva esittää ennustetun (ideaalisen trendin) viivan, joka osoittaa, millä tahdilla joukkueen on poltettava tarinapisteitä, jotta sprintti saadaan päätökseen ajoissa. Sininen viiva kertoo koko Pyrinnön työmäärästä ja sen etenemisestä. Voi nähdä, että viiden ja kuuden päivän aikana yksi joukkue ei onnistunut saavuttamaan ennustettua edistystä. Seitsemäntenä päivänä asiaa kuitenkin käsiteltiin ja työ pääsi taas vauhtiin. Tällaiset jatkuvat päivitykset antavat tiimeille mahdollisuuden käsitellä ilmeneviä ongelmia päivittäisissä stand up-kokouksissa.

itse työsuorituksen lisäksi burndown-kaaviot voivat paljastaa suunnitteluongelmia

vinkkejä sprint burndownin lähestymiseen

Story Pointsin tulisi olla tasaväkinen. Jos työnkulku ei ole johdonmukainen, jotkut tehtävät on voitu jakaa epätasaisiin osiin. Ideaalisen suuntauksen ja todellisuuden välisen poikkeaman laajuus korostaa selvästi tätä ongelmaa.

kerro suunnittelemattomista tehtävistä. Burndown-kaavio on hyödyllinen piilotettujen ja jäljittämättömien tehtävien laajuuden ymmärtämisessä. Jos työmäärä kasvaa eikä vähene, hankkeessa on paljon arvioimattomia tai suunnittelemattomia tehtäviä, joihin pitäisi puuttua.

käytä burndown-kaaviota joukkueen itseluottamuksen arviointiin. Kun otetaan huomioon nykyiset hinnat, Kysy tiimiltäsi, kuinka varmoja he ovat sprintin suorittamisesta ajoissa. Mitä pidempään tätä mittaria soveltaa, sitä tarkemmat sprinttiarviot ovat.

julkaisun estimointi burndown-kaaviolla

release burndown-kaaviolla ilmaisee työn määrän, joka on saatava valmiiksi ennen julkaisua. Kaavio havainnollistaa edistymistä yleiskatsauksen ja voit toteuttaa muutoksia varmistaa ajoissa toimitus.

kaavion perinteinen versio on samanlainen kuin sprint burndown-kaavio, mutta antaa yleiskuvan koko projektista, jossa y-akseli on sprinttejä ja x-akseli on jäljellä olevan työn (päivät, tunnit tai tarinapisteet) mitta. Mutta, entä jos enemmän työtä lisätään projektiin tai arvioitu työ ei vastaa odotuksia?

alla olevassa kaaviossa joukkue suunnitteli vievänsä projektin loppuun neljässä sprintissä ja sai aluksi 45 kerrospistettä. Ensimmäisellä ja toisella Sprintillä eteneminen sujui suunnitellusti, mutta kolmannella Sprintillä arvioitu työ kasvoi, mikä näkyy Y-akselilla negatiivisina arvoina. Kolmannen sprintin aikana ilmestyi 5 uutta tarinapistettä. Ne eivät valmistuneet ja neljäs sprint lisätty toinen 5 tarina pistettä. Siksi etenemistä ja julkaisuaikaa jouduttiin säätämään.

release burndown chart on erittäin tehokas tilanteissa, joissa on paljon muuttuvia vaatimuksia ja mahdollistaa tiimin pysymisen raiteillaan jokaisen sprintin aikana

miten release burndown chart voi auttaa?

reaaliaikainen julkaisuennuste. Kun projektisi käy läpi muutoksia, jotka tapahtuvat joka kerta iteratiivisesti kehittämällä tuotteita, sinun täytyy nähdä, miten nämä muutokset vaikuttavat julkaisupäivään. Release burndown-kaavio mahdollistaa julkaisupäivän ennustamisen reaaliaikaisesti tehtäväkentän päivitysten mukaan.

Deadline-ennusteet. Voit arvioida, saako tiimi tuotejulkistuksen valmiiksi ajoissa tai ennakoida, että määräajan pitäisi edetä lisätehtävien harkinnassa.

sprinttien lukumäärän arvioiminen. Sen arvioiminen, kuinka monta sprinttiä tarvitaan viimeistelyyn, on myös tärkeä tekijä release burndown-kaavion kanssa.

Prosessiterveyden arviointi ja pullonkaulojen löytäminen

Jaksoaika

jaksotusmittari kuvaa, kuinka paljon aikaa johonkin tehtävään käytettiin, mukaan lukien joka kerta, kun työ oli avattava uudelleen ja saatettava päätökseen uudelleen. Syklin ajan laskeminen antaa tietoa kokonaissuorituksesta ja mahdollistaa tulevien tehtävien suorittamisen arvioimisen. Vaikka lyhyempi syklin aika kuvaa parempaa suorituskykyä, tiimit, jotka tarjoavat sisällä johdonmukainen sykli arvostetaan eniten.

alla olevan kaavion avulla voit määrittää, kuinka kauan keskimäärin kuluu tehtävän suorittamiseen, piirtää mediaani-tai kontrollirajan, jota ei pitäisi ylittää, ja huomata, minkä tehtävien suorittaminen kesti epätavallisen kauan.

keskihajonta piirtää viivan tehtävän suorittamiseen tarvittavan normaalin ja ei-suositellun päivien määrän välille

voit myös pinota kaikki jaksot tietylle ajanjaksolle ja saada tietoa vertaamalla sitä muihin tietoihin. Tekemällä jatkotutkimuksen voit tehdä johtopäätöksiä työn laadusta.

tästä näkee, että maaliskuusta kesäkuuhun suoritettujen tehtävien määrä on kasvanut samoin kuin vikojen määrä

kuinka jaksoaikaa

etsitään yhtäläisyyksiä. Hyvä käytäntö on löytää vastaavanlaisia kohteita, joiden valmistuminen kestää arvaamattomia sykliaikoja ja jotka paljastavat toistuvia ongelmia joko teknisessä tai johtamisessa.

piirtää ennusteita. Voit tehdä datalähtöisiä päätöksiä ennustamalla ajan uusien tehtävien suorittamiseen aiempien samankaltaisten perusteella.

seuraa tahtia. Kaavio kuvaa, miten pysyt samassa työtahdissa ja määrittelet, onko sisäisiä asioita, jotka hidastavat työtahtia.

kumulatiivinen vuokaavio (CFC)

kumulatiivista virtausmittaria kuvaa karttapinta-ala, joka osoittaa erityyppisten tehtävien määrän projektin jokaisessa vaiheessa, X-akseli ilmoittaa päivämäärät ja y-akseli kertoo tarinapisteiden määrän. Sen päätavoitteena on tarjota helppo visualisointi siitä, miten tehtävät jaetaan eri vaiheissa. Kaavion rivien pitäisi pysyä enemmän tai vähemmän tasaisina, kun taas ”done” – tehtävien bändin pitäisi kasvaa jatkuvasti.

kaavio esittää paljon kriittistä tietoa, kuten äkillisiä pullonkauloja tai nousuja millä tahansa kaistalla

CFC: stä on paljon hyötyä Kanbanin tiimeille yksinkertaisena visualisointina tiimin työstä. Kaavio vastaa myös Kanbanin kolmivaiheista työnkulkua. Tässä kartoitat myös kolme päätehtäväluokkaa: to-do, in progress, and completed.

lisäksi kaavio auttaa tunnistamaan, milloin keskeneräisen työn (WIP) raja-arvot ylittyvät. WIP limits on yksi ketterän kehityksen arvokkaimmista työkaluista, ja sen tarkoituksena on kehittää Viimeistelytyön kulttuuria ja poistaa moniajo asettamalla kullekin projektitilanteelle mahdollisimman suuri työmäärä.

mitä asioita CFC korostaa?

• ruuhkien kasvu viittaa ratkaisemattomiin tehtäviin, jotka ovat joko liian kiireellisiä hoidettaviksi tällä hetkellä tai ovat vanhentuneita
• epäjohdonmukaiset virtaukset ja äkilliset pullonkaulat osoittavat, mitkä alueet olisi tasoitettava myöhemmissä vaiheissa
• kunkin kaistan leveys osoittaa keskimääräisen jaksoajan
• keskeneräisen alueen merkittävä laajeneminen voi tarkoittaa sitä, että tiimi ei pysty saamaan koko projektia valmiiksi. on time

flow efficiency

flow efficiency on erittäin hyödyllinen mittari kanbanin kehityksessä, jota kehitys ei yleensä huomioi joukkue. Samalla kun virtaustehokkuus täydentää kumulatiivista virtausta, se antaa tietoa jakaumasta varsinaisen työn ja odotusaikojen välillä. Se on harvinainen tapaus, kun rakennuttaja työstää yhtä asiaa kerrallaan odottamatta. Todellisuus on yleensä monimutkaisempi. Ja ”keskeneräinen työ” on nimi, joka ei aina vastaa statusta.

esimerkiksi koodilla voi olla monia riippuvuuksia, etkä voi alkaa työstää jotain ominaisuutta ennen kuin toinen on valmis, prioriteettisi muuttuvat tai odotat sidosryhmien hyväksyntää. Työn odotusajan mittaaminen voi olla jopa hyödyllisempää kuin varsinaiseen työhön liittyvien prosessien virtaviivaistaminen.

tarkastelemalla alhaisimpia hyötysuhdemittareita voit ymmärtää suurimmat pullonkaulat

miten virtaustehokkuutta

laskentakaavaa käytetään. Ellet käytä jotain projektinhallintaohjelmistoa, joka sisältää nämä mittarit, voit laskea virtaustehokkuuden tällä yksinkertaisella kaavalla: Work / (work+wait) * 100%. Sitten voit visualisoida sen digitaalisesti tai jopa piirtää kaavion toimiston taululle.

Määrittele normaali virtaustehokkuutesi. Kuten kaikilla muillakin mittareilla, on mahdotonta vaatia normaaleja lukuja kaikista projekteista. Jotkut sanovat, että 15 prosentin merkki on OK useimmissa projekteissa, mikä tarkoittaa pohjimmiltaan sitä, että tarina kohta tai muu työ odottaa 85 prosenttia vastaan 15 prosenttia käsittelyaika. Johtamisen asiantuntija David J. Anderson LeanKanban School of Managementista ehdottaa, että 40 prosentin ja sitä korkeamman pitäisi olla useimpien joukkueiden tavoite.

hajota työn yksityiskohdat ennen virtaustehokkuuden kiinnittämistä. Kaavion avulla voidaan tarkastella tarkkoja ajanjaksoja, jolloin tehokkuus oli alhaisin. Ja nämä tiedot on analysoitava hyvin huolellisesti, koska todellinen syy ja sen korjaamiseksi ei paljastu niin helposti. Ennen kuin aloitat intensiivisiä toimia, tee perusteellinen tutkimus syitä.

Augment flow efficiency with blocker analysis. Hyvä keino ymmärtää edellinen kohta on lisätä virtauksen tehokkuutta blocker clustering analyysi. Jos jokin työ on estetty, se ansaitsee värillisen tarran tai muunlaisen visuaalisen signaalin, joka tuo nämä estäjät tiimin tietoon, jotta he voivat reagoida niihin.

voit merkitä, kuinka monta päivää osa työstä on estetty, ja priorisoida päätöslauselman

yleensä salpaajat kerääntyvät ryppäiksi, koska niillä on monia riippuvuuksia keskenään. Parempi estoanalyysi voidaan tehdä, jos ryhmittelet ne alkaen korkean tason yhtäläisyyksistä, kuten sisäisistä ja ulkoisista salpaajista, ja määrittelet sitten tarkemmin suunnittelun, puuttuvan sisällön tai muiden puuttuvien ominaisuuksien perusteella. Estoanalyysi on yksinkertainen tapa tutkia laaksoja virtaustehokkuudessa.

mittauskoodin laatu

Code coverage

Code coverage määrittelee, kuinka monta koodia tai lohkoa suoritetaan automaattisten testien aikana. Koodin kattavuus on kriittinen mittari testiohjatun kehityksen (TDD) käytäntöön ja jatkuvaan toimitukseen. Perinteisesti metriikka tulkitaan yksinkertaisella lähestymistavalla: mitä suurempi koodin kattavuus, sen parempi. Tämän mittaamiseen tarvitset yhden käytettävissä olevista työkaluista, kuten haalarit. Mutta ne kaikki toimivat jokseenkin samalla tavalla: kun suoritat testejä, työkalu tunnistaa, mitä koodiriveistä kutsutaan ainakin kerran. Prosenttiosuus kutsutaan rivit on koodin kattavuus.

haalarit esimerkiksi erittelevät koodin kattavuuden kuhunkin tiedostomittaukseen ja korostavat peitettyjä ja peittämättömiä rivejä

Kuinka käyttää koodipeittoa

keskity peittämättömiin riveihin äläkä yliarvioi peitettyjä rivejä. Jos koodiriviä kutsutaan kerran tai jopa useammin, se ei välttämättä tarkoita, että sen tukema ominaisuus toimii täydellisesti ja käyttäjät pysyvät tyytyväisinä. Koodirivin soittaminen ei aina riitä testaustehtävän lopettamiseen. Toisaalta, prosenttiosuus kattamaton linjat näyttää, mitä ei ole katettu lainkaan ja voi olla syytä testata.

priorisoi covered code, äläkä tähtää 100 prosenttiin. Vaikka tämä tuntuu counterintuitive, 100 prosenttia kattavuus ei tarkoita, että olet oikein testattu koodi. Projektissasi on koodi, jolla on merkitystä ja loput koodipohjasta. Koska testiautomaatio on yleensä kallis aloite, sen pitäisi priorisoida ominaisuudet ja vastaavat koodinpätkät.

Testiautomaatio manuaalista testausta vastaan

tämä mittaus määrittää, kuinka monta koodiriviä jonkin ominaisuuden sisällä on jo automatisoiduissa testeissä manuaalisesti testattavia vastaan. Tämä noudattaa suoraan aikaisempaa metrijärjestelmää, mutta sillä on erityinen käyttötapaus. Testiautomaation suhdetta manuaaliseen testaukseen käytetään vain silloin, kun tarvitset kriittisesti automaatiota regressioiden peittämiseen. Regressiotestaus tehdään sen tarkistamiseksi, onko jotain rikkoutunut ominaisuuspäivitysten jälkeen. Ja jos tuotteessanne tapahtuu jatkuvia parannuksia – kuten sen pitäisi – regression testaus olisi automatisoitava. Jos näin ei ole, manuaalisen laadunvarmistuksen asiantuntijoiden on toistettava samat testiskenaariot toistuvasti jokaisen päivityksen jälkeen.

voit käyttää samoja välineitä, joita käytetään koodin kattavuuteen tämän metriikan piirtämiseen

esittämällä automaattisen testikattavuuden ominaisuuskohtaisesti, voit priorisoida ominaisuudet, jotka 1) saattavat kärsiä regressiosta päivitysten jälkeen ja 2) joille automatisoidut testit ovat kriittisiä. Yleensä sinulla ei ole tarpeeksi aikaa ja henkilöresursseja kattamaan kaikkea automatisoiduilla testeillä kerralla, ellet työskentele testivetoisen kehityksen puitteissa. Niin, se on parempi priorisoida ominaisuuksia, jotka varmasti vaikuttavat käyttäjäkokemukseen.

McCabe Cyclomatic Complexity (MCC) of code

Code complexity-mittauksia käytetään arvioimaan ongelmien riskejä koodin testauksen ja ylläpidon aikana. Mitä suurempi on koodin monimutkaisuus, sitä vaikeampaa on varmistaa, että siinä on hyväksyttävä määrä vikoja ja että se pitää korkean ylläpidettävyyden. Yleisin tapa mitata koodin monimutkaisuutta on McCabe Cyclomatic Complexity Metric (MCC). Yksi kaavoista kompleksisuuden tulosten piirtämiseksi MCC: lle on seuraava:

MCC = edges-nodes + return statements

MCC on kuvassa yhtä kuin 3

tällä metriikalla kehittäjät eivät arvioi koodinsa monimutkaisuutta katsomalla sitä subjektiivisesti. Koska insinöörien skillsets eroavat toisistaan, heidän arvionsa vaihtelevat, mikä tekee koodin uudelleenjärjestelystä tai vikojen korjaamisesta haastavampaa pidemmällä aikavälillä. Markkinoilla on monia MCC-mittaustyökaluja, jotka voidaan yhdistää muihin koodin monimutkaisuuden mittauksiin, kuten koodihierarkian syvyyteen ja koodirivien lukumäärään.

MCC käyttää erityispiirteitä ja sudenkuoppia

tasapainottaa ihmisen ja koneen käsitystä koodin monimutkaisuudesta. Yksi tärkeimmistä syistä käyttää MCC on tehdä koodin luettavissa muiden kehittäjien. Koodin luettavuus vähentää riskejä, jotka liittyvät vanhojen koodien kanssa tekemisissä olevien uusien kehittäjien pitkäaikaiseen käyttöönottoon. Se myös yksinkertaistaa refactoring tiellä. Ongelmana tässä on se, että MCC-malli voi pitää joitakin monimutkaisia mutta luettavia menetelmiä mahdottomina hyväksyä. Ja jos pakotat kehittäjän muokkaamaan monimutkaisia menetelmiä moniksi osamenetelmiksi, voit saavuttaa päinvastaiset tulokset: monista yksinkertaisilla logiikoilla varustetuista menetelmistä voi tulla ihmiselle jopa vaikeammin ymmärrettäviä kuin yhdestä vielä monimutkaisesta menetelmästä.

älä tee MCC: stä rajoittavaa metriikkaa. Jotkut organisaatiot harjoittelevat kooditoimitusten lopettamista, jotka eivät läpäise MCC-testiä. Vaikka tämä voi mahdollisesti lisätä koodin yksinkertaisuutta, on luonnollista, että koodilla on monimutkaisia luokkia, menetelmiä ja toimintoja. Niiden estäminen kokonaan ei ole aina hyödyllistä. Hyvä käytäntö on asettaa yleinen koodin monimutkaisuus KPI kehittäjille, mikä kannustaa heitä lähestymään koodausta tietoisemmin ja ajattelemaan yksinkertaisuutta.

käytä MCC: tä koodikatselmuksessa. Toinen arvokas käytäntö MCC-testeissä on soveltaa sitä koodikatselmusten aikana, jotta työn laajuus rajataan tiettyjen koodinpätkien tarkasteluun silloin, kun virheriskit ovat suurimmat.

Code churn

Code churn on erittäin hyödyllinen visualisointi trendeistä ja vaihteluista, jotka tapahtuvat koodipohjalle sekä kokonaisprosessin että julkaisua edeltävän ajan kannalta. Churn mittaa, kuinka monta riviä koodia lisättiin, poistettiin tai muutettiin. Joskus kuvaajat näyttävät kaikki kolme mittausta.

tämä Microsoftin esimerkki sisältää kaikki kolme parametria, mutta voit käyttää niitä valikoivasti

vaikka seurantakoodin churn voi vaikuttaa hieman alkeelliselta metriikalta, se mahdollistaa koodin vakauden arvioinnin eri kehitysvaiheissa. Sinun pitäisi odottaa alhaisin vakaus aikana aikaisin sprints ja korkein vakaus – kanssa samanaikaisesti alhaisin Kirnu – juuri ennen vapautumista. Jos koodisi on erittäin epävakaa ja julkaisupäivä lähestyy, anna hälytys.

Code churnin käyttötapaukset

etsivät säännönmukaisuuksia. Säännölliset piikit koodinmuutoksissa saattavat paljastaa, että tehtäväsukupolvi ei ole tarpeeksi keskittynyt ja tuottaa useita suuria tehtäviä toistuvasti.

epäsäännölliset mutta korkeat piikit vaativat tutkimista. Jos sinulla on epäsäännöllisiä mutta voimakkaita piikkejä koodimuutoksissa, voit tutkia, mitkä tehtävät aiheuttivat tällaisia seismisiä piikkejä koodissasi ja harkita uudelleen riippuvuuksien tasoa, varsinkin jos uusien koodirivien määrä lisäsi myös muuttuneiden rivien määrää.

kiinnitä huomiota trendeihin. Vakaus tuotteen tulee melko kriittinen ennen julkaisua. Kuten mainitsimme, Kirnun määrä pitäisi olla laskeva trendi lähempänä joukkue saa vapauttaa. Kasvava trendi tarkoittaa mahdollista tuotteen epävakautta julkaisun jälkeen, koska on todennäköistä, että uutta koodia ei testata riittävästi.

Aim for progress, not control

aivan kuten muillakaan suoritusmittareilla, ketterillä mittareilla ei aina ole erillisiä vastauksia tai toimivia vinkkejä, jotka sinetöisivät menestyksen. Kuitenkin, sinun pitäisi käyttää tietoa ne tarjoavat aloittaa keskustelun, suorittaa arviointi, ja tarjota oman suunnitelman käsitellä ongelmallisia kysymyksiä.

vaikka mittarit antavat numeerisen kuvan tiimin suorituksesta ja yleisestä tyytyväisyydestä työhön, älä kiinnitä niihin huomiota. Ottaen huomioon, että ketteriä mittareita ei ole standardoitu, on turha vertailla eri joukkueiden onnistumisia. Sen sijaan varmista, että omaksut tiimisi palautteen, käynnistät säännölliset keskustelut ja ravitset ilmapiiriä, jossa on yhteisiä tavoitteita ja tukea.