Agile beregninger er målinger som brukes til å spore fremdriften og suksessen til et smidig prosjektteam.
Beregningene, når de er definert på riktig måte, gir innsikt i teamets ytelse, kvalitet, testeffektivitet eller generelle effektivitet og hvordan det utvikler seg over tid.
Det endelige målet med smidige beregninger er å hjelpe team med å identifisere områder for forbedring og å ta datadrevne beslutninger som vil føre til bedre produkter etter hvert som teamet utvikler seg.
Mesteparten av tiden definerer selskaper beregninger som enten er forfengelighetsmålinger eller råtall, og vokser fint fra venstre til høyre. De ser kanskje fine ut på noen dashbord, men de er vanligvis ubrukelige for teamet selv.
Hensikten deres er ikke å hjelpe teamet på noen måte, men heller å fylle ut noen rapporter for ledelse og deretter konkludere med noen strategiske beslutninger. Dessverre er det da teamet som ikke forstår hvorfor akkurat denne avgjørelsen eksisterer.
I et gjerde for å oppfylle slike feil beregninger, forfalsker teamene sine egne prosesser for å få beregningene til å se bra ut. Men resultatet til laget blir ikke bedre i det hele tatt.
Innholdsfortegnelse
Grunnleggende beregninger
Det er mange måter å skille beregningene på. Den kanskje mest grunnleggende er ovenfra og ned og nedenfra og opp.
➡️ Top-down betyr: Vi lederskap vil lage for deg beregninger vi vil at dere alle skal møte, og ditt endelige mål er å passe inn i grønne områder av disse. Vi har ikke noe imot om du – et lag liker dem eller ikke; det er dette vi ønsker å spore.
➡️ Bottom-up betyr: Vi – laget må forbedre oss på disse områdene, og for det må vi fokusere på disse tingene. Vi definerer derfor beregninger som vil tillate oss å spore fremgangen til teamet mot våre mål, og vi kan demonstrere for deg – lederskap nøyaktig hvordan det forbedret arbeidet vårt over tid.
Definisjon av god metrikk
Så hva bør en god beregning inneholde, eller hvordan beskrive den?
Den viktigste egenskapen er atferdsendring. Dette betyr at hver gang du ser på resultatet av beregningen, er det klart hva som må endres i teamet for å få forbedringer.
Da må det være enkelt. Hvis du ikke kan forklare det med noen enkle setninger slik at alle de relevante lytterne kan forstå, så er det noe som ikke er bra.
En god beregning er sammenlignbar over tid. Ta et øyeblikksbilde av resultater om gangen, og gjør det igjen en gang senere. Legg dem ved siden av hverandre. Hvis du ikke kan sammenligne de to resultatene mellom hverandre, bør du tenke over denne beregningen.
Til slutt, bedre enn rene tall, der det er mulig, gjør det til et forhold eller en prosentandel. «10 nye åpne defekter under sprinten» vil ikke si så mye. Det kommer an på om du vanligvis har en eller 100.
Her er noen eksempler på beregninger jeg tror oppfyller alle disse definisjonskriteriene. De har spesifikt agile team i tankene. Det er tre hovedkategorier: Ytelse, kvalitet og moral.
Kategorier av beregninger
Ytelsesberegninger
Målet er å forstå hvor gode teamet er til å ta igjen historier begått i en sprint. For å vurdere om overengasjement ikke er business as usual eller om overføringshistoriene er en standard fra sprint til sprint.
Fra et smidig prestasjonsperspektiv skal teamet strebe etter å levere planlagt sprintinnhold som laget forpliktet seg til i begynnelsen av sprinten.
Det betyr ikke at vi ikke skal være fleksible i historieutveksling under sprinten. Men det skal alltid være en forhandling som fører til en utveksling, ikke et tillegg. Lagets kapasitet vil ikke vokse bare fordi noen har lagt til nye historier inne på sprinten.
Vi tar med denne beregningen for å se opp for slike tilfeller og veileder alle i teamet for å beskytte kapasiteten de har for sprinten.
Dette bygger opp påliteligheten og forutsigbarheten til teamet.
#1. Sprintkapasitet vs. leverte historiepoeng
Se historien om sprintkapasitet vs. levert historiepoeng (SP) innhold over spurtene.
- Små avvik fra sprint til sprint er greit. Store hopp i alle retninger signaliserer at noe er av.
- Total sprintkapasitet – ett teammedlems tilgjengelige dag legger en til den totale kapasiteten. For eksempel, hvis laget har 10 personer og alle vil være tilgjengelige i full sprint, er den totale kapasiteten for sprinten 100.
Bekreft sprintkapasiteten kontra fullført SP fra sprint til sprint. Hvis teamet (under planleggingen) forplikter seg til en betydelig høyere mengde SP enn teamet vanligvis kan fullføre, øke denne risikoen for teamet.
Målet skal være å ha en total planlagt SP lik eller mindre enn totalt gjennomført SP per sprint.
Du kan fortsatt ha flere fullførte SP enn planlagt hvis laget fullførte (mot slutten av sprinten) alle planlagte historier og laget fortsatt har kapasitet til å ta den ekstra historien.
- Hvis laget gjentatte ganger leverer mindre SP enn planlagt, må laget endre planleggingen og ta mindre SP inn i neste sprint.
Verktøy som monday.com, Atlassian Jira eller Asana gir alle en enkel måte å lagre og trekke ut historiepoeng for hver historie i spurtene. De kan til og med generere det for deg automatisk etter hver sprintplanlegging.
#2. Nedbrenningsdiagram
Dette er en av beregningene sannsynligvis de fleste av scrum-teamene har gjemt et sted på dashbordet. Jeg er enig i at dette til og med kan se ut som en ubrukelig ting å ha. Teamet tar det sjelden i betraktning. Snarere liker lederen å påpeke hvordan historiene ser ut fra et høyt nivå og hvordan de ikke utvikler seg godt (ettersom de alle er åpne hele sprinten).
Det jeg vil fremheve er at til tross for det, bør dere som et team gå og sjekke nedbrenningsdiagrammet for deres eget beste. Hvis alle historier er åpne hele sprinten og først stengt på sprintens siste dag, skaper dette usikkerhet innad i laget og frem mot ferdigstillelse av sprintmålene.
- Se gjennom sprintbrettet ditt for fullførte historier.
- Sjekk med teamet for å finne ut hvorfor små historier fortsatt er åpne, selv om de startet på begynnelsen av sprinten.
- Arbeid med teamet for å bygge den tankegangen, ikke for å holde historiene åpne lenger enn nødvendig.
- Det ideelle nedbrenningsdiagrammet er vanligvis en teoretisk tilstand. Men jo nærmere vi kommer det, jo mer effektiv historiehåndtering har vi.
Agile administrasjonsverktøy som Asana kan generere et nedbrenningsdiagram for deg automatisk for hver sprint.
Kilde: asana.com
#3. Fullføring av sprintmål
Dette sporer prosentandelen av sprintmålene du fullførte i løpet av hver sprint.
Du dokumenterer sprintmålene separat, for eksempel på Confluence-siden / Jira, for hver sprint. Status skal tildeles enten de ble møtt eller ikke innenfor sprinten.
Selv om laget ikke fullførte alle historiene i løpet av en sprint, kunne de fortsatt oppnå sprintmålet (f.eks. mangler bare sidehistorier).
Vi skal sikte på 100 % sprintmål fullføring hver sprint. Hvis det ikke er tilfelle, finn ut hva teamet forhindrer.
- Hvis det er for mange parallelle emner i hver sprint, reduser mengden av dem.
- Hvis det er for mange ad hoc-historier som legges til i løpet av sprinten, reduser dette slik at det ikke påvirker de opprinnelige sprintmålene.
- Hvis sprintmålene er for store eller for utfordrende, gjør det enklere. Det har uansett ingen mening å ha store sprintmål uten å oppfylle dem ved slutten av sprinten.
Kodekvalitetsmålinger
Dette skal spore hvor god koden er over tid. Det bidrar til å opprettholde sunne utviklingsprosesser og reduserer tiden brukt på å løse problemer. Eller utviklerens inaktive tid forårsaket av å vente på kodekjøringen under utviklings- og testaktiviteter.
Kilde: azuredevopslabs.com
#1. Automatiserte tester
Lag automatiserte enhetstester av utviklere for hver endring de gjør.
- Mål kodedekning ved hjelp av automatiserte tester – bruk Azure Pipelines eller SonarCloud for å kjøre testene. Sikt på 85 % dekning. Over 90% er egentlig ikke effektivt.
- Sørg for at den automatiserte enhetstesten er en del av definisjonen av ferdig for de nye historiene.
- Ta igjen gammel kodetestdekning som en del av tekniske gjeldshistorier i etterslepet.
#2. Kodekompleksitet
Vurder unødvendige komplikasjoner koden får over tid og fiks det aktivt ved hjelp av tekniske gjeldshistorier. Eller hindre dem fra å skje hvis mulig.
Definer kodestandarder og retningslinjer for å lære utviklere å følge dem. Sørg for at de holder seg til kodingsreglene for å minimere den urimelige økningen i kodekompleksitet. Regelmessig oppdatert retningslinjene basert på erfaringene til teamet.
Identifiser kodelukter – indikatorer på potensielle problemer i koden, for eksempel duplisert kode, lange metoder og ubrukte variabler.
Fagfellevurderinger skal sikre at kodestandarder brukes på den nyopprettede koden.
Bruk verktøy som Azure Ado eller SonarCloud dashbord og rapporter for å oppdage kodeproblemer.
#3. Manuelle trinn i distribusjon
Spor hvor mange manuelle trinn teamet må gjøre for å frigi koden til test- eller produksjonsmiljøer.
- Målet vårt skal være å nå 0 her over tid.
- Lag tekniske gjeldshistorier om nødvendig for å bringe distribusjons-/frigjøringspipelinen opp til automasjonsveikartet. Senk gradvis de resterende manuelle trinnene i prosessene fra sprint til sprint.
Moralmålinger
Dette er en beregning for å spore hvordan teamet føler om arbeidet sitt og prosessene de håndterer daglig.
#1. Sprint retrospektiv oppfyllelse
Du kan spore hvor mange handlingspunkter som faktisk ble fullført i neste sprint.
- Scrum Master skal samle de retrospektive møteresultatene på teamets sider for å spore avtalte handlingspunkter.
- Teamet vil da følge med på fremgangen.
- Prosjektledelsen kan deretter vurdere om handlingspunktene går videre eller hva som hindrer teamet i å fullføre dem. Endre deretter miljøet for å la teamet komme videre i de avtalte handlingspunktene.
Minst 33 % eller 1 (avhengig av hva som er høyere) av handlingselementene fra forrige sprint vil bli tatt i bruk i de neste spurtene.
Hvis det er mindre enn det, er det nødvendig med endringer for å la teamet implementere forbedringene de ble enige om.
Prosjektstyringsverktøy inneholder klare til bruk maler for sprint retrospektive aktiviteter. Her er et eksempel fra monday.com:
Kilde: monday.com
#2. Team Samarbeid
Programmering av sporpar.
- Dann et naturlig par per historie for å jobbe sammen, dele observasjon, kunnskap og suksess. Lag underoppgaver under historier som eies av forskjellige teammedlemmer.
Spor kodeanmeldelser fra fagfelles initiativ.
- Peers blir bedt om eller tar proaktivt tiltak for å gjennomgå andres historieutgang.
Metrikken kan trekkes ut fra monday.com/Asana/Jira-tavlen fra underoppgavene.
Minst 50 % av historiene i spurten skal deles av teammedlemmer. Hvis det er mindre, undersøk årsakene og iverksett tiltak der det er fornuftig.
For frivillige fagfellevurderinger, spor historiene med dedikerte underoppgaver. I begynnelsen er 20 % av kodehistoriene som er anmeldt på denne måten en god start. Gradvis over spurtene skal du oppmuntre og motivere teamet til å jobbe mer samarbeid og øke det mot 50 % av kodehistoriene per sprint som mål.
#3. Teknisk gjeld vs. nye funksjonalitetshistorier
Kilde: atlassian.com
Å gi teamet muligheten til å løse sine egne gjeldshistorier vil øke teamets tilfredshet med arbeidet.
- Tvert imot, akkumulering av tekniske gjeldsproblemer uten en plan for å løse dem gradvis vil demotivere teamet over tid. Og løsningen vil bli mer ustabil, kompleks og vanskelig å løse uten betydelig omarbeiding.
Teamet vet best hva som ikke fungerer bra med løsningen, selv om interessentene eller sluttbrukerne ikke ser det. Slike historier har størst innvirkning på selve utviklerteamet. For interessentene kan de være usynlige. Derfor er det viktig å gi teamet sjansen til å jobbe med historier som vil hjelpe dem å rydde opp i utviklingsaktivitetene.
Målet er å spore hvor mange hevede tekniske gjeldshistorier som blir løst over tid og om etterslepet av slike historier bare vokser eller ikke.
Teamet kan merke historiene som TechDebt i backlog og gi dem prioritet fra teamet, slik at de kan gå på topp og bli valgt ut i spurter.
Avhengig av i hvilken stat prosjektet er og hvor mange teknologigjeld som er identifisert i etterslepet, vil du kanskje sikre at TechDebt-etterslepet ikke vokser med mer enn 10 % fra sprint til sprint.
Prioriter teknologigjeldshistoriene og inkluder dem i spurtene for å holde veksten av teknologigjeldsetterslepet i sjakk, slik at teamet får lov til å jobbe med teknologigjeldshistoriene 10–20 % av tiden hver sprint.
Siste ord
Hvert prosjekt vil etter hvert trenge noen beregninger, enten fordi ledelsen ønsker å ha dem eller fordi teamet bestemmer seg for å måle sin egen suksess.
Det beste du kan gjøre er å begynne å bygge biblioteket med beregninger klare til å bli plukket og brukt; jo før jo bedre. Og mens du gjør det, sørg for at du alltid går for atferdsendre beregninger fremfor alt.
Deretter kan du sjekke ut usunne prosesser som kan ødelegge spurten din.