Den rigtige måde at definere agile metrics på

Agile metrics er målinger, der bruges til at spore fremskridt og succes for et agilt projektteam.

Målingerne giver, når de er defineret på den rigtige måde, indsigt i teamets ydeevne, kvalitet, testeffektivitet eller overordnede effektivitet, og hvordan det udvikler sig over tid.

Det ultimative mål med agile metrics er at hjælpe teams med at identificere områder for forbedring og at træffe datadrevne beslutninger, der vil føre til bedre produkter, efterhånden som teamet skrider frem.

Det meste af tiden definerer virksomheder målinger, der enten er forfængelighedsmålinger eller rå tal, der vokser pænt fra venstre mod højre. De ser måske pæne ud på nogle dashboards, men de er normalt ubrugelige for holdet selv.

Deres formål er ikke at hjælpe teamet på nogen måde, men snarere at udfylde nogle rapporter til ledelse og derefter afslutte med nogle strategiske beslutninger. Desværre er det så holdet, der ikke forstår, hvorfor netop denne beslutning eksisterer.

I et hegn for at opfylde sådanne forkerte målinger forfalsker holdene derefter deres egne processer for at få målingene til at se gode ud. Men holdets output bliver slet ikke bedre.

Grundlæggende målinger

Der er mange måder, hvordan man adskiller metrics. Måske den mest grundlæggende er top-down og bottom-up.

➡️ Top-down betyder: Vi lederskab vil skabe målinger for dig, som vi ønsker, at I alle skal opfylde, og dit ultimative mål er at passe ind i grønne områder af dem. Vi er ligeglade med, om du – et hold kan lide dem eller ej; det er det, vi vil spore.

➡️ Bottom-up betyder: Vi – holdet skal forbedre os på de områder, og til det skal vi fokusere på disse ting. Vi definerer derfor målinger, der vil give os mulighed for at spore teamets fremskridt mod vores mål, og vi kan demonstrere over for dig – lederskab, hvordan det præcist forbedrede vores arbejde over tid.

Definition af god metrik

Så hvad skal en god metrik indeholde, eller hvordan skal den beskrives?

Den vigtigste egenskab er adfærdsændrende. Det betyder, at hver gang du ser på resultatet af metrikken, er det klart, hvad der skal ændres inde i teamet for at opnå forbedringer.

Så skal det være enkelt. Hvis du ikke kan forklare det med et par enkle sætninger, så alle de relevante lyttere kan forstå, så er der noget, der ikke er rigtig godt.

En god metrik er sammenlignelig over tid. Tag et øjebliksbillede af resultaterne på et tidspunkt, og gør det så igen engang senere. Læg dem ved siden af ​​hinanden. Hvis du ikke kan sammenligne de to resultater mellem hinanden, bør du overveje denne metrik en ekstra gang.

Til sidst, bedre end rene tal, hvor det er muligt, gør det til et forhold eller en procentdel. “10 nye åbne defekter under spurten” vil ikke fortælle meget. Det afhænger af, om du normalt har en eller 100.

Her er nogle eksempler på målinger, som jeg mener opfylder alle disse definitionskriterier. De har specifikt agile teams i tankerne. Der er tre hovedkategorier: Ydeevne, kvalitet og moral.

Kategorier af metrics

Ydeevnemålinger

Målet er at forstå, hvor gode holdet er til at indhente historier begået i en sprint. For at vurdere, om overengagement ikke er business as usual, eller om overførselshistorierne er en standard fra sprint til sprint.

Fra et agile præstationsperspektiv skal holdet stræbe efter at levere planlagt sprintindhold, som holdet forpligtede sig til i begyndelsen af ​​spurten.

Det betyder ikke, at vi ikke skal være fleksible i historieudveksling under spurten. Men det bør altid være en forhandling, der fører til en udveksling, ikke en tilføjelse. Holdets kapacitet vil ikke vokse, bare fordi nogen tilføjede nye historier inde i spurten.

Vi bringer denne metric for at holde øje med sådanne tilfælde og guider alle i teamet til at beskytte den kapacitet, de har til spurten.

Dette opbygger holdets pålidelighed og forudsigelighed.

#1. Sprintkapacitet vs. leverede historiepoint

Se historien om sprintkapacitet vs. leveret story points (SP) indhold over spurterne.

• Små afvigelser fra sprint til sprint er fint. Store hop i enhver retning signalerer, at noget er slukket.
• Samlet sprintkapacitet – et teammedlems ledige dag tilføjer én til den samlede kapacitet. F.eks. hvis holdet har 10 personer, og alle vil være tilgængelige i fuld sprint, så er den samlede kapacitet for spurten 100.

Bekræft sprintkapaciteten vs. gennemført SP fra sprint til sprint. Hvis teamet (under planlægningen) forpligter sig til en væsentlig større mængde SP, end teamet normalt kan gennemføre, så hæv denne risiko for teamet.

Målet skal være at have en samlet planlagt SP lig med eller mindre end den samlede gennemførte SP pr. sprint.

Du kan stadig have flere gennemførte SP end planlagt, hvis holdet gennemførte (mod slutningen af ​​spurten) alle planlagte historier, og holdet stadig har kapacitet til at tage den ekstra historie.

• Hvis holdet gentagne gange leverer mindre SP end planlagt, skal holdet ændre sin planlægning og tage mindre SP ind i næste sprint.

Værktøjer som monday.com, Atlassian Jira eller Asana giver alle en enkel måde at gemme og udtrække historiepoint for hver historie i spurterne. De kan endda generere det for dig automatisk efter hver sprintplanlægning.

#2. Nedbrændingsdiagram

Dette er en af ​​de målinger, som sandsynligvis de fleste af scrum-holdene har gemt et sted på dashboardet. Jeg er enig i, at dette måske endda ligner en ubrugelig ting at have. Holdet tager det sjældent i betragtning. Tværtimod vil lederen gerne påpege, hvordan historierne ser ud fra et højt niveau, og hvordan de ikke skrider godt frem (da de alle er åbne hele spurten).

Det, jeg gerne vil fremhæve, er, at på trods af det, bør I som team gå og tjekke nedbrændingsskemaet for jeres eget bedste. Hvis alle historier er åbne hele spurten og først lukket på sprintens sidste dag, skaber dette usikkerhed inde i holdet og frem mod sprintmålenes afslutning.

• Gennemgå dit sprintbræt for færdige historier.
• Tjek med holdet for at finde ud af, hvorfor små historier stadig er åbne, selvom de startede i begyndelsen af ​​spurten.
• Arbejd med teamet for at opbygge den tankegang, ikke for at holde historierne åbne længere end nødvendigt.
• Det ideelle nedbrændingsdiagram er normalt en teoretisk tilstand. Men jo tættere vi kommer på det, jo mere effektiv historiehåndtering har vi.

Agile administrationsværktøjer som Asana kan generere et nedbrændingsdiagram for dig automatisk for hver sprint.

Kilde: asana.com

#3. Sprint målopfyldelse

Dette sporer procentdelen af ​​sprintmål, som du gennemførte under hver sprint.

Du dokumenterer Sprint-målene separat, f.eks. på Confluence-siden / Jira, for hver sprint. Status skal tildeles, uanset om de blev opfyldt eller ej inden for spurten.

Selvom holdet ikke gennemførte alle historier inden for en sprint, kunne de stadig nå sprintmålet (f.eks. mangler der kun sidehistorier).

Vi vil sigte efter 100 % sprintmål fuldførelse hver sprint. Hvis det ikke er tilfældet, så find ud af, hvad holdet forhindrer.

• Hvis det er for mange parallelle emner i hver sprint, skal du reducere mængden af ​​dem.
• Hvis det er for mange ad hoc-historier, der tilføjes under spurten, skal du reducere dette, så det ikke påvirker de oprindelige sprintmål.
• Hvis sprintmålene er for store eller for udfordrende, så gør det nemmere. Det giver i hvert fald ingen mening at have store sprintmål, mens du ikke opfylder dem ved slutningen af ​​spurten.

Kodekvalitetsmålinger

Dette skal spore, hvor god koden er over tid. Det hjælper med at opretholde sunde udviklingsprocesser og reducerer tiden brugt på at løse problemer. Eller udviklerens inaktive tid forårsaget af at vente på kodeudførelsen under udviklings- og testaktiviteter.

Kilde: azuredevopslabs.com

#1. Automatiserede tests

Opret automatiserede enhedstest af udviklere for hver ændring, de foretager.

• Mål kodedækning ved hjælp af automatiserede tests – brug Azure Pipelines eller SonarCloud til at køre testene. Sigt efter 85 % dækning. Over 90% er ikke rigtig effektivt.
• Sørg for, at den automatiske enhedstestoprettelse er en del af definitionen af ​​udført for de nye historier.
• Indhent gammel kodetestdækning som en del af tekniske gældshistorier i efterslæbet.

#2. Kode kompleksitet

Evaluer unødvendige komplikationer, som koden opnår over tid, og reparer det aktivt ved hjælp af tekniske gældshistorier. Eller forhindre dem i at ske, hvis det er muligt.

Definer kodestandarder og retningslinjer for at uddanne udviklere til at følge dem. Sørg for, at de holder sig til kodningsreglerne for at minimere den urimelige stigning i kodekompleksitet. Regelmæssigt opdateret retningslinjerne baseret på holdets erfaringer.

Identificer kodelugte – indikatorer for potentielle problemer i koden, såsom duplikeret kode, lange metoder og ubrugte variable.

Peer reviews skal sikre, at kodestandarder anvendes på den nyoprettede kode.

Brug værktøjer som Azure Ado eller SonarCloud dashboards og rapporter til at opdage kodeproblemer.

#3. Manuelle trin i implementeringen

Spor, hvor mange manuelle trin teamet skal udføre for at frigive koden til test- eller produktionsmiljøer.

• Vores mål skal være at nå 0 her over tid.
• Opret tekniske gældshistorier, hvis det er nødvendigt for at bringe implementerings-/frigivelsespipelinen op til automatiseringens køreplan. Sænk gradvist de resterende manuelle trin i processerne fra sprint til sprint.

Moralmålinger

Dette er en metrik til at spore, hvordan teamet har det med deres arbejde og de processer, de håndterer dagligt.

#1. Sprint Retrospective Fulfillment

Du kan spore, hvor mange handlingspunkter der rent faktisk blev gennemført i den næste sprint.

• Scrum Master skal samle de tilbagevirkende møderesultater på teamets sider for at spore aftalte handlingspunkter.
• Holdet ville derefter holde styr på fremskridt.
• Projektledelsen kan derefter gennemgå, om handlingspunkterne skrider frem, eller hvad der forhindrer teamet i at gennemføre dem. Rediger derefter miljøet for at give teamet mulighed for at komme videre i de aftalte handlingspunkter.

Mindst 33 % eller 1 (afhængigt af hvad der er højere) af handlingspunkterne fra det forrige sprint vil blive overtaget i de næste sprints.

Hvis det er mindre end det, er der behov for ændringer for at give teamet mulighed for at implementere de forbedringer, de blev enige om.

Projektstyringsværktøjer indeholder klar-til-brug skabeloner til sprint retrospektive aktiviteter. Her er et eksempel fra monday.com:

Kilde: monday.com

#2. Team Samarbejde

Programmering af sporpar.

• Dann et naturligt par per historie for at arbejde sammen, dele observation, viden og succes. Opret underopgaver under historier, der ejes af forskellige teammedlemmer.

Spor Code anmeldelser fra peers initiativer.

• Peers bliver bedt om eller tager proaktivt handling for at gennemgå en andens historieoutput.

Metrikken kan udtrækkes fra monday.com/Asana/Jira-tavlen fra underopgaverne.

Mindst 50 % af historierne i spurten skal deles af teammedlemmer. Hvis det er mindre, så undersøg årsagerne og tag handlinger, hvor det giver mening.

For frivillige peer reviews, spor historierne med dedikerede underopgaver. I begyndelsen er 20 % af kodehistorier, der bliver gennemgået på denne måde, en god start. Gradvist over sprintene skal du opmuntre og motivere teamet til at arbejde mere sammen og øge det mod 50 % af kodehistorier pr. sprint som et mål.

#3. Teknisk gæld vs. nye funktionalitetshistorier

Kilde: atlassian.com

At give teamet mulighed for at løse deres egne gældshistorier vil øge teamets tilfredshed med deres arbejde.

• Tværtimod vil ophobningen af ​​tekniske gældsproblemer uden en plan for at løse dem gradvist demotivere holdet over tid. Og løsningen bliver mere ustabil, kompleks og svær at løse uden væsentlig omarbejdelse.

Teamet ved bedst, hvad der ikke fungerer godt med løsningen, selvom interessenterne eller slutbrugerne ikke ser det. Sådanne historier har den største indflydelse på selve udviklerteamet. For interessenterne kan de være usynlige. Derfor er det vigtigt at give teamet chancen for at arbejde med historier, der hjælper dem med at rydde op i udviklingsaktiviteterne.

Målet er at spore, hvor mange hævede tekniske gældshistorier, der bliver løst over tid, og om efterslæbet af sådanne historier kun vokser eller ej.

Holdet kan mærke historierne som TechDebt i backlog og give dem prioritet fra holdet, så de kan gå på toppen og blive udvalgt i spurter.

Afhængigt af i hvilken stat projektet er, og hvor mange tech-gæld der er identificeret i efterslæbet, vil du måske sikre dig, at TechDebt-efterslæbet ikke vokser med mere end 10 % fra sprint til sprint.

Prioriter tech-gældshistorierne og medtag dem i sprintene for at holde væksten i tech-gældsefterslæb i skak, så teamet får lov til at arbejde på tech-gældshistorierne 10-20 % af tiden hver sprint.

Afsluttende ord

Hvert projekt vil i sidste ende have brug for nogle målinger, enten fordi ledelsen ønsker at have dem, eller fordi teamet beslutter sig for at måle sin egen succes.

Det bedste, du kan gøre, er at begynde at opbygge dit bibliotek af metrikker, der er klar til at blive plukket og brugt; jo før jo bedre. Og mens du gør det, så sørg for, at du altid går efter adfærdsændrende målinger frem for alt.

Dernæst skal du tjekke usunde processer, der kan ødelægge din sprint.