Vår Erfaring Med Å Bruke De Vanligste Agile Metrics

Vår Erfaring Med Å Bruke De Vanligste Agile Metrics

Bruk Av Agile metrics for å måle teamets produktivitet er en viktig del av Agile ‘ s filosofi. Teamledere og alle medlemmer bør se konsekvensene av sitt arbeid og bruke disse dataene til å forbedre arbeidsflyten og øke effektiviteten.

Sluttbrukere og klienter kan også dra nytte av Bruken Av Agile prosjektmålinger som fokuserer på å evaluere resultatet av produktet. Beregninger tillater scrum-mestere, utviklere, designere og testere å måle ytelsen til applikasjonen og spore om nåværende og tidligere oppgaver gjør produktet bedre.

I denne artikkelen går vi Gjennom Agile-beregninger som betyr noe, og deler vår erfaring med å bruke Dette Agile metrics-dashbordet til et virkelighetsprosjekt. Det viser seg, for å lede et team vellykket og levere resultater, trenger du ikke bare å vite hvilke beregninger som skal brukes, men hvordan du gjør det-vi deler hvordan vi fant ut det.

Typer Vanlige Agile metrics

klassifiseringen Av Agile metrics er ikke satt i stein — den er alltid i endring og restrukturering. Likevel har vi i løpet av årene sett fremveksten av tre hovedtyper Av Smidige beregninger i ulike Smidige rammer.

1. kanban — beregninger-disse beregningene er basert på måling av investert tid (syklustider) og leverte resultater (gjennomstrømming) og deres forhold.
2. Scrum metrics-beregninger, som er fokusert på planlegging og forståelse av arbeidsflyten og demonstrere hvor mye arbeid som ble utført i en gitt periode;
3. Lean metrics-kontinuerlig måling av produksjonseffektivitet og produktkvalitet med teknisk vurdering ved å teste funksjoner, sjekke for mulige feil og forutse negative effekter.

vi bruker alle tre typer metrics for å vurdere de viktigste aspektene av programvareutviklingsprosessen og resultatene: produktkvalitet, teamets produktivitet og helse.

agile quality metrics

før du begynner å måle lagets hastighet og effektivitet, må du vite om du generelt beveger deg i riktig retning. Hva er bruken i rask levering av alle utviklingsoppgaver, hvis oppgavene selv er dannet på feil måte? Prioriteten for hvert programvareutviklingsteam og leder er å sørge for at alle aktiviteter er relatert til å forbedre produktet — dette gjøres ved å måle kvaliteten og oppdage negative tendenser.

Rømte defekter

Hvert Agile-prosjekt har sprints eller arbeidssykluser, på slutten av hvilken en bestemt oppgave leveres. Etter at arbeidet var fullført, må lagets leder vurdere kvaliteten på turned-it-resultatene. Alle endringer, redigeringer og unfixed bugs er rømte feil-problemer som utviklere kunne ha løst, Men ikke. Registrer deres nøyaktige antall og natur for å vite hvilke feil som vanligvis unnslipper utviklernes øyne.

etter at du har gjort en rapport om feil som har forsvunnet og samlet inn konkret statistikk, må du diskutere resultatene med teamet ditt. Sørg for at hvert teammedlem vet hva slags feil teamet vanligvis savner. Hvis du har individuelle forslag, diskutere dem med gruppemedlemmer en-mot-en.

mislykkede distribusjoner

hvis produktet ble distribuert, men ikke utgitt eller ikke klarte å tiltrekke seg brukere, registreres dette som en mislykket distribusjon. Noen ganger skjer en mislykket distribusjon med beslutninger fra en av interessentene, eller forretningsmodellen viser seg å være upålitelig. Uansett hva som var årsaken til problemet, må du registrere alle mislykkede distribusjoner sammen med årsakene til feilen.

før du slipper en ny distribusjon, kan teamet alltid se på listen over tidligere mislykkede distribusjoner og undersøke om denne ikke kan gjennomgå samme prosess. Ved å analysere årsakene til feilen i tidligere versjoner kan du unngå fremtidige problemer.

Release Net Promoter Score (NPS)

Net Promoter-Poengsummen er beregningen som innebærer å evaluere brukernes reaksjoner i kvantitative (tall, statistikk, gjennomsnittsvurderinger) og kvalitative tilbakemeldinger (anmeldelser, direkte tilbakemelding, meldinger, e-post, samtaler). Etter at teamet har samlet inn og analysert tilbakemeldingen, foreslår hvert lagmedlem en poengsum som evaluerer hvor mye brukeren sannsynligvis vil anbefale produktet (vanligvis settes score i grenser fra 1 til 10).

agile project management metrics

når du har en full historikk over tidligere feil og suksesser, kan du analysere retningen for alle nåværende ufullstendige prosjekter og gi ut relevante oppgaver, avhengig av tidligere erfaringer. Etter at du har etablert utviklingsretningen — «hva du skal gjøre» av produktet, «må du vurdere lagets effektivitet-det er» hvordan gjør vi det » – faktoren. Du kan bruke Agile – prosjektberegninger for å vite om gruppemedlemmene oppfyller forventningene dine, forstår oppgavene deres, administrerer tidsfrister og om alle prosessene er koordinert og synkronisert.

Ledetid

Ledetid Er En beregning som gjør det mulig for team å sjekke hvor mye det tok for produktet backlog oppføring for å komme frem til slutten av sprinten. Den kan brukes til å spore produkter på ethvert utviklingsstadium, oppgave etter oppgave, eller vurdere de samlede tidskostnader, fra ideasjon til utgivelse. Det er en langsiktig beregning som utviklere kan bruke mens de planlegger sitt fremtidige arbeid og estimerer priser.

Pass på å registrere ledetid for hvert av prosjektene. Det er best å beholde både større bildestatistikk som dekker hele prosjektet, og har organisert sprintmålinger-slik at du kan undersøke hvert trinn separat.

Syklustid

hvis Ledetid er blant langsiktige teamytelsesberegninger, fokuserer syklustid på individuelle oppgaver. Denne beregningen evaluerer varigheten av en enkelt syklus, hvor en syklus tas av en oppgave, beregner antall sykluser per prosjekt, og måler oppnådde resultater for sluttbrukeren hvis produktet allerede er beta-testet eller utgitt.

med syklustid kan lagene umiddelbart se om en oppgave tar for mye tid, eller om noen teammedlemmer ikke leverer på sine ender. Denne kortsiktige beregningen gjør prosjektledelse mye enklere og bidrar til å raskt finne problemer når de oppstår.

Sprint burndown

denne metriske brukes både på kort og lang sikt. Ledere kan lage sprint burndown Scrum-rapporter i sanntid for å spore lagets fremgang på det nåværende prosjektet — for dette må de estimere totalt antall sprints og forutsi sannsynlige tidskostnader. Det kan også brukes langsiktig-ledere kan analysere rapporter om tidligere prosjekter, finne stadier som mislyktes forventede tidsrammer, og analysere årsaker til forsinkelser.

Viktigst, sprint burndown lar spore dynamikken i lagets arbeidsflyt. Noen medlemmer har en tendens til å ta arbeid langsommere i de første stadiene, mens andre brenner ut mot slutten av prosjektet. Med sprint burndowns kan teamledere oppdage disse tendensene, bestemme årsakene deres og hjelpe medlemmer med arbeidsdistribusjon og tidsstyring.

Epic& Release burndown

denne beregningen ligner Sprint Burndown — den eneste forskjellen er at den fokuserer på lagets produktivitet før og etter utgivelsen. Ledere kan legge til nye krav og innlemme oppgaver som er basert på sluttbrukernes tilbakemeldinger. Det er en forbedret versjon av sprint burndown, da den også inneholder oppgaver gitt etter utgivelsen av prosjektet.

Velocity

denne metriske evaluerer antall fullførte historikkpoeng over en bestemt periode. Basert på din historie, kan du forutse tid utgifter for fremtidige historien poeng. Nedgangen i lagets hastighet på bestemte sprints kan peke på misforståelser blant lagmedlemmer eller indikerte oppgaver som er vanskeligere enn tidligere forventet.

Ekstra Agile-beregninger

Agile-beregninger hjelper teamet med å kjenne prosjektet bedre og holde oversikt over mange viktige aspekter ved produktutvikling. Det er Også Smidige beregninger for toppledere som gjør det mulig å se det større bildet av utvikling og lagets velvære. Ifølge vår erfaring, disse ekstra beregninger bidra til å måle alle aspekter av arbeidet ditt. Likevel definerte vi de viktigste egenskapene som forteller mest om sluttproduktet og bidrar til å levere et fullstendig komplett resultat.

Kumulativ flyt

navnet på metriske kommuniserer klart sitt formål-å samle alle prosjektstrømmer og evaluere dem i et enkelt diagram. Å ha en slik graf vil gi deg en storskala visning — den kan sendes til prosjektinteressenter som ikke har tid til å analysere mer detaljerte Agile-rapporter.

diagrammet beskriver vanligvis følgende prosesser:

• Oppgaver i etterslep: hvor Mange oppgaver i etterslep gruppemedlemmer har over gitt tidsramme;
• Godkjent arbeid: hvor mange oppgaver blant planlagte aktiviteter ble fullført — teamlederen ser umiddelbart forskjellene mellom planlagte og fullførte aktiviteter;
• Bufferoppgaver: alt arbeid som venter på godkjenning, er definert til å være i en buffersone;
• Pågår: du må evaluere gjeldende arbeidsbelastning.

Kode churn

denne beregningen viser trender for endringer i kodebasen før utgivelsen. Churn-diagrammer viser hvor mye kode som ble lagt til, fjernet eller endret en gang om gangen. Ved tidlige spurter vil det være mange pigger og faller på grafen, fordi koden fortsatt er ustabil, men etter hvert som prosjektet utvikler seg, bør kodekreftgrafen bli stabil, uten drastiske oppturer og nedturer.

før utgivelsen, bør churn få en nedgang-legge til eller redigere kode før selve utgivelsen betyr at det ikke vil gjennomgå tilstrekkelig testing. Alt i alt, når det er en uregelmessighet På Agile diagrammer, undersøke årsakene.

Kontrolldiagram

et kontrolldiagram er et diagram hvor teamet kan se informasjon om varigheten av syklustidene. Det ideelle resultatet ville ha linjen på diagrammet jevnt går ned med tiden – det ville bety økningen av lagets hastighet-mindre tid er nødvendig per enkelt syklus. Et annet viktig aspekt er konsistens — syklustider må forbli selv uansett type oppgave-det betyr at du har riktig arbeidsfordeling.

Helseverdier

programvareutviklingsteam må fokusere på langsiktige prioriteringer, for eksempel å holde kommunikasjonen mellom medlemmene jevn og sjekke om alle er fornøyd. Agile er en fleksibel metodikk, som betyr at den kan tilpasse seg interessene til ulike medlemmer, så snart ledere vet hva de skal ta hensyn til. Slik finner vi ut om alle våre teammedlemmer er fornøyd med arbeidsflyten.

Lykke

hvis du har pålitelige, uformelle relasjoner i teamet ditt, er det lettere å starte med en åpen dialog med hvert medlem. Be alle om å rangere sin erfaring i selskapet fra 1 til 5. Du kan stille hjelpende spørsmål — hva er de beste og verste aspektene av deres arbeid, hva kan forbedres, og hva kan øke lykken? Hvis teamet ikke har vennlige kommunikasjonsvaner, kan bruk av anonyme undersøkelser føre til mer objektive resultater.

Lagmoral

lagmoral og lykke er ikke de samme tingene. Lykke har mer å gjøre med komfort, mens lagmoral er knyttet til produktivitet, selvtillit, evaluering av egne faglige kvaliteter. Igjen kan du be ansatte om å rangere deres moral fra 1 til 5 og stille følgende spørsmål;

• Har arbeidet i selskapet bidratt til å forbedre dine ferdigheter?
• Hvor mye utforskes ditt fulle potensial med gjeldende arbeidsbelastning?
• liker du arbeidet ditt?
• ser du de klare resultatene av arbeidet ditt?
• er du begeistret for nye prosjekter?

målet her er å forstå at lagets utviklingsstrøm går i riktig retning. Noen ganger tar programvareutviklingsteamets leder lønnsomme, men kjedelige oppgaver, og ignorerer medlemmers interesser. Denne undersøkelsen vil hjelpe deg å se om ansatte er begeistret og utfordret av sitt arbeid.

teammedlemsomsetning

hvis teamledere ofte erstatter teammedlemmer, betyr det at arbeidsmiljøet sannsynligvis er usunt. En viss omsetning over tid er sunn — faktisk vil du ikke ha noen tillegg av mennesker i årevis, da det ville bety stagnasjon. Du bør imidlertid passe på plutselige pigger i aktivitet-måneder da flere personer forlot laget, eller mange ble med. Hvis du plutselig får mange nye deltakere, må du være oppmerksom på onboarding-prosessen før du går direkte til det prosjektrelaterte arbeidet.

Målefordeler for sluttbrukere

Agile team bør vite hvor godt produktet passer behovene til en sluttbruker og bedriftseier. Dette gjøres med en omfattende kodeanalyse som bestemmer kodekvalitet og brukervennlighet for en sluttbruker, samt mulige vedlikeholdskomplikasjoner.

Statisk kodeanalyse

det er den enkle typen kodeanalyse når programvaren er inaktiv. Bare ved å overvåke kode automatisk med åpen kildekode-verktøy, kan du identifisere sikkerhetsproblemer, oppdage teknisk gjeld og feil, og sende problematiske kodefragmenter til søppelsamleren.

Dynamisk kodeanalyse

Dynamisk kodeanalyse krever at teamet kjører programvare for å evaluere opplevelsen sluttbrukerne har mottatt. Vi oppfordrer våre utviklere og testere til alltid å sette seg i brukernes sko, og utforske de vanligste scenariene. For eksempel kan de introdusere sine kolleger og familiemedlemmer til løsningen, og be om tilbakemelding-med mindre det ikke er forbudt i avtalen. Viktigst av alt, vi har et team AV QA-fagfolk som er fullt ansvarlige for dynamisk kodeanalyse — selv om vi tror at jo flere mennesker bidrar til å teste beregninger I Agile, desto bedre er sluttproduktkvaliteten.

slik bruker du de beste Agile-beregningene

av alle De Forskjellige Tilgjengelige Agile-beregningene, må du velge de som vil være relevante for teamet ditt og prosjektene dine på lang sikt. Å holde styr på disse viktige egenskapene bør være en vane, mens det ikke bør distrahere deg fra mer presserende arbeid. Her er hvordan vi sømløst innlemmet Agile beregninger i vår arbeidsflyt.

Fokus på ytelse, budsjett og kvalitet

du må sørge for at du etter at du har valgt alle beregningene, vil kunne få et klart bilde av arbeidets kvalitet, belastning, tidskostnader og budsjett. For det første setter vi opp kortsiktige beregninger som er relatert til våre aktive prosjekter: syklustid og hastighet for Smidig ytelsesevaluering, kodeanalyse for kodekvalitetsvurdering og kumulativ flyt for å holde oversikt over alle utviklingsprosesser og deres kostnader.

Under den første sprinten sørger vi for å gjøre følgende:

• Definer hvor mange spurter og sykluser prosjektet vil ha;
• Beregn tidskostnadene for hele prosjektet, og ta hensyn til kundens behov;
• Vurdere konkurransedyktige løsninger For å forstå sluttproduktets kompleksitet;
• Samle tilbakemeldinger fra våre teammedlemmer om deres forventninger til prosjektets mest spennende, utfordrende og vanskelige aspekter.

på Denne måten kan vi vite hvor mye tid vi vil bruke på å fullføre prosjektet, sette kvalitetsstandarder basert på lignende løsninger, og om teamet vårt er motivert til å jobbe med oppgavene eller ikke (det har stor innvirkning på produktiviteten).

Beregninger etter den første sprinten

her fokuserer vi på å få tilbakemelding fra klienten og alle teammedlemmer. Etter den første sprinten ønsker vi å vite at alle parter som er involvert i arbeidsflyten forstår prosessen og føler seg komfortable. Vi legger også vekt på å evaluere kodekvalitet – vi planlegger til og med kodeanalyse og teknisk gjeldsevaluering som en del av hver av våre neste sprints. Så snart de første linjene med kode ble skrevet, opprettholde kvaliteten er vår prioritet.

Hastighet kommer etter

Hastighet er en av de viktigste beregningene i våre prosjekter,men ikke nøkkelen. Vi avstår fra å basere vår dom på hastighetstall i begynnelsen. Strategien med å komme raskt gjennom de første trinnene er en katastrofe som venter på å skje-teamet kan hoppe over planlegging, eller glemme å spørre en klient flere viktige spørsmål. Vi rush ikke de første stadiene av produktet, la kunder og teammedlemmer finne sitt tempo.

Å Øke lagets hastighet blir en av våre prioriteringer når vi er på utførelsesstedet. Så snart alle funksjoner og design er lagt ut, forsøker vi å minimere tidskostnader og fullføre alle oppgaver så raskt som mulig.

Individuelle beregninger

hver av de brukte beregningene skal være tilgjengelig for hele teamet og individuelle medlemmer. Utviklere, testere, designere skal kunne se tempoet og resultatene av sitt arbeid, ikke bare et lag som helhet. For å få det til, bruker Vi produktivitetsverktøy og tidssporere, Som Jira og Hubstaff. Alle generelle rapporter synkroniseres med individuelle — medlemmer kan se hvilken prosentandel av samlet produktiv tid deres timer gjør.

Ofte stilte spørsmål

Hva ER KPI I Agile?

Nøkkelindikatorer I Agile er målbare verdier som viser teamets effektivitet i å oppnå forretningsmål. Kpi-er på høyt Nivå fokuserer på langsiktige resultater som avhenger av mange faktorer-hvor mange brukere som ble tiltrukket av sluttproduktet, konverteringsfrekvenser, tilbakemeldingskvalitet. Kpier på Lavt Nivå er kortsiktige verdier som ikke påvirkes av mange tilkoblede faktorer-tid brukt på prosjektet (vanligvis beregnet i timer), prosjektets budsjett (investering per oppgave), etc.

Agile Er en utviklingsmetodikk basert på kontinuerlig forbedring-programvareutvikling analyserer data og tilpasser seg den. Teamet analyserer Smidige Kpi-Er på ytelse og arbeidskvalitet, og implementerer endringer med en gang i neste sprint.

Hva Er Sprint beregninger?

sprint-beregninger er beregninger som evaluerer leveransene til programvareutviklingsteamet, og kontrollerer hvor mye verdi som ble levert til sluttkunden ved slutten av hver sprint . Denne verdien kan måles med en ny funksjon, designforbedringer eller feilsletting.

det neste målet med sprint metrics er å måle effektiviteten til teamet i forretningsvilkår-hvor raskt løsningen ble levert til markedet — hva er kundens tilbakemelding og konverteringsnivåene. Til slutt må beregninger vise utviklernes tilfredshet med prosjektet og med retningen laget tar generelt.

Hvorfor er beregninger viktige For Agile-prosjekter?

Hele poenget Med Agile-metoden er at utviklere alltid kan gjøre rettelser i prosessen etter hver sprint. Å ha konkrete data, statistikk og grafer gjør det mulig for utviklere å forstå hvilke endringer som skal gjøres for neste sprint, og gjør det mulig å evaluere sluttproduktets kvalitet — ellers ville det være lett å bli fanget i tekniske og organisasjonsdetaljer.

hva er en sprint I Agile?

en sprint er en klart definert periode med start-og sluttdato når laget er satt ut for å fullføre et bestemt antall oppgaver. Sprint er grunnlaget For Scrum, Agile og DevOps-lag deler arbeidsbelastningen i mindre håndterbare biter og sporer resultatene av hver sprint. Hver av disse periodene behandles som et mini-prosjekt med forhåndsplanlegging, risikovurdering, ansvarsoppgaver og etter sprintanalyse.

hvert prosjekt består av en serie sprints. Fordi hver sprint evalueres, er det enkelt å oppdage problemer tidlig og fjerne dem på neste sprint – slik at arbeidsflyten hele tiden optimaliseres.

Hva er beregningene for programvareutvikling?

programvareutviklingsmålinger er kvantitative verdier som gjør det mulig å måle programvareutviklingsprosjektets kvalitet, ytelse og teamets helse. De bidrar til å forbedre utviklingsprosessen etter hvert som prosjektet beveger seg og kan brukes til teamets fremtidige arbeid for å forbedre organisering og planlegging.

det er seks hovedtyper av programvareutvikling beregninger:

• Formelle kodemålinger-dette er objektive kvalitative verdier som beregner hvor mye arbeid som ble utført ved å bestemme antall kodelinjer( LOC), Instruksjonsbanelengde og andre.
• effektivitetsmålinger For Utviklere-teamet kan beregne oppgavekode, aktive dager og tid brukt på oppgaven.
• Agile prosessmålinger – når prosjektet er delt inn i sprints, kan teamet måle effektiviteten til mindre deler av prosjektet-ledetid (hvor mye tid ble brukt til et bestemt utviklingsstadium, som kan inneholde flere sprints), syklustid (en sprint faller vanligvis under en enkelt syklus) og hastighet (hvor mange oppgaver ble gjort i en bestemt tidsramme).
• operasjonelle beregninger-disse beregningene kontrollerer programvarens kjøreegenskaper og bestemmer hvor effektivt selskapets ansatte er til å opprettholde verktøyet uten hjelp fra tredjepart. Mean Time Between Failures og Mean Time To Recover (Mttr) kontrollerer hvordan programvaren vil kjøre under naturlige omstendigheter, og hvor utstyrt er det interne teamet i å håndtere lasten.
• Testberegninger-disse beregningene evaluerer kodedekningen-hvor mye kode som ble testet, antall feil og prosentandelen av teknisk gjeld.
• kundetilfredshet-teamet får innsikt i sluttbrukernes reaksjoner på produktet ved å måle Net Promoter-Score, Kundetilfredshetspoeng og Kundeinnsatsspoeng. Disse beregningene vurderer henholdsvis om brukerne vil anbefale produktet og om de er fornøyd med resultatet.

Agile beregninger er en del av programvarenettverk, og de kan bestå av andre kategorier, som du kan se fra vår guide.

Hva ER SDLC-beregninger?

SDLC ER en livssyklus for programvareutvikling – et sett av stadier som en typisk teknologi gjennomgår under oppfattelsen, utførelsen og ferdigstillelsen. EN gjennomsnittlig SDLC består av følgende trinn:

• Evaluere eksisterende systemer og definere deres egenskaper, fordeler, problemer;
• Definere krav til det nye prosjektet funksjonalitet, design, målgruppe, etc.;
• Designe systemet og skissere en typisk brukerbane;
• Utvikle programvaren, som betyr å skrive kode, forberede maskinvare og lage funksjoner;
• Testing av programvareytelse, funksjonalitet, sikkerhet, grensesnitt, etc.;
• Distribuere programvaren i sitt naturlige miljø, hvor teknologien vil kjøre langsiktig;
• Vedlikeholde systemet ved å oppdatere koden, erstatte eller redigere visse fragmenter, og fjerne feil.

HVERT TRINN AV SLDC kan måles med følgende egenskaper.

• Krav: teamet må samle alle kravene til prosjektet og evaluere implementeringen av hver av dem når det gjelder tid og penger;
• programvarekvalitet: Alle Smidige kvalitetsmålinger kan brukes i utviklingsstadiet AV EN SDLC;
• Testtilfeller: teamet må beregne antall utførte testaktiviteter, dens hastighet og endelig kodedekning;
• Defekter: for å måle effektiviteten i arbeidet må utviklere og testere være oppmerksomme på det nøyaktige antallet problemer som oppstår under utviklingen;
• Oppgaver: måling av tid brukt og penger tjent per oppgave kan vurdere om alle gruppemedlemmer Er Produktive eller ikke.

alle beregninger, beskrevet i vår guide, kan brukes på ulike stadier av Programvareutviklingens Livssyklus. Prosjektet er i høyeste behov for å overvåke nærmere utgivelsen fordi problemer kan hoper seg opp, og det er lett å gå glipp av en kritisk feil i produktet.

Hva er gjennomstrømning i Agile-beregninger?

det er metriske som beregner antall historier fullført per sprint. I Scrum er En lignende metrisk referert Til Som Sprinthastighet.

Konklusjon

Agile metrics sett opp en solid base for å ta informerte beslutninger gjennom et programvareutviklingsprosjekt. Utviklere kan bruke denne innsikten til å øke effektiviteten i de neste sprintene og stadig forbedre kvaliteten på produktet. Det er imidlertid verdt å merke seg at utviklingsmålinger ikke bør bli en absolutt prioritet i programvareutviklingsprosjektet. Utviklere bør først og fremst stole på prosjektbehov og målgruppepreferanser.

På Jelvix bruker Vi en personlig tilnærming til å bruke beregninger til prosjektet. Først diskuterer vi prosjektets MVP med kunden, undersøker målgruppen, analyserer konkurransedyktige løsninger, og bare da valgte de beregningene som passer best til prosjektet. Vi streber ikke etter å bruke hver ENESTE KPI-i stedet velger vi de som reflekterer prosjektets behov mest.