Agil praksis, for uinnvidde og underinformerte, kan noen ganger fremstå som ad hoc programvareutvikling og prosjektledelsesmetoder. Sannheten er langt annerledes.
Et av de 12 prinsippene for smidig programvare sier: "De beste arkitekturer, krav og design kommer fra selvorganiserende team," men de fleste organisasjoner som bruker smidig praksis, inkludert scrum og Kanban, håndhever noen viktige prosessrigheter og ritualer. For eksempel implementerer mange organisasjoner smidig planleggingspraksis, inkludert historiepunktsestimering, arkitekturstandarder og frigjøringsledelsesdisipliner for å forbedre virksomhetspåvirkning, kvalitet og pålitelighet av applikasjonsutgivelser.
De fleste lag velger å bruke et smidig verktøy som Jira Software eller Azure DevOps for å håndtere etterslep, sprint og samarbeid mellom smidige team. Hovedformålet med disse verktøyene er å sentralt administrere kravene, sprintstatus, arbeidsflyt og samarbeid på tvers av smidige teammedlemmer og flere smidige team. Men jo strengere organisasjoner bruker disse verktøyene, jo mer kan disse verktøyene hjelpe ledere og team med å identifisere problemer, rapportere til interessenter om status og forbedre gjennomføringen.
En av de vanligste ut-av-boksen-rapportene er nedbruddsrapporten. Siden smidig praksis gjør det mulig for produkteiere å prioritere om etterslaget basert på tilbakemeldinger fra kunder, klarer ikke tradisjonelle rapporter som Gantt-diagrammer å fange opp den flytende naturen til smidig utførelse. Grunnleggende for nedbrytningskartet er at det står for fullført arbeid, nytt arbeid lagt til omfanget og andre omfangsendringer. Nedbruddskartet kan gi et raskt bilde av hvordan lagene marsjerer mot sine mål.
Lese et grunnleggende sprint nedbruddskart
Burndown-diagrammer har vanligvis tid over x-aksen og estimater på y-aksen. Mange lag estimerer i historiepoeng, men mange smidige verktøy kan kartlegge nedbrudd etter antall historier eller estimater i timer. For denne artikkelen vil jeg anta at historiepoeng blir brukt.
Sprint-nedbruddsrapporten viser antallet historiepunkter som er i omfang for tidsintervallet. Når teamet fullfører historier, viser diagrammet hvordan de "brenner ned" listen over historier og andre typer arbeid (problemer i Jira, arbeidstyper i Azure DevOps) til arbeidet er fullført eller sprinten avsluttes. Når lag fullfører arbeidet som er forpliktet til sprinten, krysser den plottede linjen x-aksen, noe som indikerer at alt er gjort.
Sprint nedbrudd er den enkleste å konseptualisere. På den første dagen av sprinten forplikter teamet seg til noen historier og det totale antallet historiepoeng. Hvis du går gjennom nedbruddskartet den dagen, bør du se et enkelt punkt på y-aksen som representerer antall poeng teamet forpliktet seg til på sprintens dag null.
Når historier er markert som ferdig, viser sprintnedbruddet det gjenværende antall poeng som skal fullføres.
Hvordan brukes en sprintnedbrudd i praksis? En sunn nedbrudd viser en lineær og ideelt eksponentiell kurve ned til null. Hvis kurven har en flat skråning i den tidlige delen av en sprint, kan det indikere blokker eller mye pågående arbeid, og at sprinten kan være i fare. En flat eller sakte skrånende nedbrenning kan være veldig problematisk hvis det utføres mye testing på kodefullstendige historier, og hvis testarbeidet ikke kan begynne før de siste dagene av sprinten.
En raskt synkende sprintnedbrudd er generelt en god ting, men det kan tyde på at laget ikke forplikter seg eller bare har valgt å ta på seg mindre historier i sprinten.
Episke nedbrudd sporer fremgang mot forretningsdrivere og tekniske drivere
Sprintnedbrudd er svært nyttige for å spore kortsiktig gjennomføring og hjelpe team med å oppfylle sprintforpliktelser. For å bedre spore fremgang mot langsiktige mål, gir episke og frigjøringsforbrenninger den nødvendige synligheten.
Episke nedbrudd fungerer best når team definerer flere langvarige anstrengelser, for eksempel å implementere store sluttbrukeregenskaper, tekniske gjeldsstrategier, ytelsesforbedringer eller prosessutviklinger. For å dra nytte av episke nedbrudd, bør etterslepet ha:
- Mellom fem og 15 eposer som varer i flere måneder og tar seks eller flere spurter å fullføre.
- Funksjoner, historier og historiestubber som ruller under eposet og representerer en plan på høyt nivå for å utføre på eposet.
- Anslag på høyt nivå, ideelt sett i historiepoeng for hver historie eller historiestubbe som ruller opp under eposene.
Når disse er på plass, kartlegger den episke nedbrudd endringene i denne planen. Dens x-akse representerer sprints, og y-aksen representerer det totale estimatet av historier og historiestubber som er tildelt epikken. I Jira Softwares episke nedtrekksdiagram ser du et søylediagram med en farge som representerer historier fullført i sprinten og et sekund som viser historien som er lagt til. Historiepoeng øker når nye historier eller historiestubber blir lagt til i eposet, eller når estimatene endres.
Det er flere måter å bruke det episke nedbruddskartet på:
- Det illustrerer hastigheten på å fullføre funksjoner og historier mot planen. Når planene er nøyaktige og teamhastigheten er i samsvar, kan den gi en indikator når eposets arbeid er fullført.
- De fleste smidige planer er ikke fullførte, og teamene legger til, endrer og fjern historier basert på tilbakemelding fra sluttbrukere, oppdagelsen av tekniske kompleksiteter og for å adressere teknisk gjeld introdusert under reisen. Den episke nedbruddet indikerer da hvor langt utenfor planen epikken er basert på hvor mye etterslepet vokser kontra å bli fullført sprint for sprint.
- Episke nedbrudd hjelper også til med å måle innsatsen på tvers av flere sprinter og måle hvor mye planleggings- og leveringsarbeid som er gjort i ett epos versus andre.
Utgivelsesnedbrudd informerer team om utgivelser vil treffe dato og omfang
Avanserte team som automatiserer leveringsrørledninger med kontinuerlig integrering, kontinuerlig testing og kontinuerlig levering, trenger kanskje ikke frigjøringsnedbrenninger. Lag som distribuerer ofte, bør spore hvilke funksjoner og historier som er knyttet til utgivelsen, men utgivelsen er ikke veldig nyttig, da den ofte sporer fremgang med sprint.
For andre lag som følger utgivelsesadministrasjonspraksis og standardiserer på multisprint-utgivelser, kan utgivelsesnedbrudd være produktseierens og teamets viktigste verktøy.
Utgivelsesnedbruddet ligner på det episke utbruddet, bortsett fra i stedet for sporing av funksjoner, historier og historiestubber som er tildelt et epos, viser utgivelsesnedbruddet hva som er tildelt en utgivelse. Aksen og stolpene er da identiske med episke nedbrenninger.
Lag som bruker utgivelsesnedbrudd kan dermed spore omfang og tidslinje for en utgivelse. Lag som er på rett spor vil se en nedbakkehelling ned til x-aksen med en skråning som samsvarer med lagets hastighet. Utgivelser som kan dreie seg fra sporet, har enten en mindre skråning eller skildrer flere historiepoeng som legges til (når mer omfang legges til utgivelsen) enn det som fullføres.
Jira Software hjelper deg med disse anslagene. Forutsatt at teamet har jobbet med prosjektet i minst tre sprinter, vil Jira Software beregne en gjennomsnittlig laghastighet og forutsi sluttsprinten for en utgivelse basert på denne hastigheten.
Sprint-, episke- og frigjøringsnedbruddene gir teamene noen brukervennlige verktøy for å justere målene. Når team har en felles forståelse av omfanget, blir enige om prioriteringer, planlegger flere sprints fremover, og merker historier i deres etterspørsel på riktig måte, forteller nedbrudd historien om planlegging og gjennomføring er i tråd med målene. Når de ikke er det, er de et datadrevet verktøy som kan føre til diskusjon om hvilke justeringer som kan være behov for.
