Agil praksis for uinitierede og underinformerede kan undertiden fremstå som ad hoc-softwareudvikling og projektstyringsmetoder. Sandheden er langt anderledes.
Et af de 12 principper for agil software siger: "De bedste arkitekturer, krav og design fremgår af selvorganiserende teams", men de fleste organisationer, der anvender agil praksis, herunder scrum og Kanban, håndhæver nogle betydningsfulde procesproblemer og ritualer. F.eks. Implementerer mange organisationer agile planlægningspraksis, herunder estimering af historikpunkt, arkitekturstandarder og frigørelsesledelsesdiscipliner for at forbedre forretningspåvirkningen, kvaliteten og pålideligheden af applikationsudgivelser.
De fleste hold vælger at bruge et fleksibelt værktøj som Jira Software eller Azure DevOps til at styre backlogs, sprints og samarbejde mellem agile teams. Det primære formål med disse værktøjer er at centralt styre kravene, sprintstatus, workflow og samarbejde på tværs af agile teammedlemmer og flere agile teams. Jo mere stringent organisationer bruger disse værktøjer, jo mere kan disse værktøjer hjælpe ledere og teams med at identificere problemer, rapportere til interessenter om status og forbedre deres udførelse.
En af de mest almindelige rapporter uden for boksen er nedbrydningsrapporten. Da agil praksis sætter produktejere i stand til at prioritere efterslæbet på baggrund af kundefeedback, opfanger traditionelle rapporter som Gantt-diagrammer ikke den flydende karakter af agil udførelse. Grundlæggende for nedbrydningstabellen er, at det tegner sig for afsluttet arbejde, nyt arbejde tilføjet omfanget og andre omfangsændringer. Nedbrændingsdiagrammet kan give et hurtigt billede af, hvordan hold marcherer mod deres mål.
Læsning af et grundlæggende sprint burndown chart
Burndown-diagrammer har normalt tid på tværs af x-aksen og estimater på y-aksen. Mange hold estimerer i historiepunkter, men mange smidige værktøjer kan kortlægge nedbrydninger efter antallet af historier eller estimater i timer. I denne artikel antager jeg, at der bruges historiepunkter.
Sprint burndown-rapporten viser antallet af historiepunkter, der er inden for tidsintervallet. Når holdet gennemfører historier, viser diagrammet, hvordan de "brænder ned" listen over historier og andre typer arbejde (problemer i Jira, arbejdstyper i Azure DevOps), indtil arbejdet er afsluttet, eller sprinten slutter. Når hold udfører arbejdet, der er forpligtet til sprinten, skærer den afbildede linje x-aksen, hvilket indikerer, at alt er gjort.
Sprint nedbrud er den nemmeste at konceptualisere. På sprintens første dag forpligter holdet sig til nogle historier og det samlede antal historiepoint. Hvis du gennemgår udbrændingsdiagrammet den dag, skal du se et enkelt punkt på y-aksen, der repræsenterer antallet af point, som holdet forpligtede sig til på sprintens dag nul.
Når historier er markeret som færdige, viser sprintnedbruddet det resterende antal point, der skal gennemføres.
Hvordan bruges en sprintnedbrud i praksis? En sund nedbrydning viser en lineær og ideelt eksponentiel kurve ned til nul. Hvis kurven har en flad hældning i den tidlige del af en sprint, kan det indikere blokke eller meget igangværende arbejde, og at sprinten kan være i fare. En flad eller langsomt skrånende nedbrydning kan være meget problematisk, hvis der udføres meget test på kodefyldte historier, og hvis testarbejdet ikke kan begynde før de sidste par dage af sprinten.
En hurtigt faldende sprintnedbrud er generelt en god ting, men det kan indikere, at holdet underforpligter sig eller kun har valgt at påtage sig mindre historier i sprinten.
Episke nedbrændinger sporer fremskridt mod forretningsdrivende og tekniske drivere
Sprintafbrændinger er meget nyttige til at spore kortsigtet udførelse og hjælpe teams med succes at opfylde sprintforpligtelser. For bedre at spore fremskridt mod langsigtede mål giver episke og frigivelsesforbrændinger den nødvendige synlighed.
Episke nedbrud fungerer bedst, når hold definerer flere langvarige bestræbelser, såsom implementering af større slutbrugerfunktioner, tekniske gældsstrategier, forbedringer af ydeevnen eller procesudvikling. For at drage fordel af episke nedbrud skal efterslæbet have:
- Mellem fem og 15 epos, der varer mindst flere måneder og tager seks eller flere sprints at gennemføre.
- Funktioner, historier og historiestubber, der ruller op under eposet og repræsenterer en plan på højt niveau til at udføre på eposet.
- Skøn på højt niveau, ideelt set i fortællingspunkter for hver historie eller historiestub, der ruller op under eposerne.
Når disse er på plads, viser den episke nedbrydning ændringer til denne plan. Dens x-akse repræsenterer sprints, og y-aksen repræsenterer det samlede estimat af historier og historiestubber, der er tildelt epikken. I Jira Softwares episke udbrændingsdiagram ser du et søjlediagram med en farve, der repræsenterer historier afsluttet i sprinten, og et andet, der viser de tilføjede historiepunkter. Historiepunkter øges, når nye historier eller historiestubber føjes til eposet, eller når skøn ændres.
Der er flere måder at bruge det episke nedbrændingsdiagram på:
- Det illustrerer hastigheden af at udfylde funktioner og historier mod planen. Når planerne er nøjagtige og holdets hastighed er ensartede, kan det give en indikator, når eposens arbejde er afsluttet.
- De fleste smidige planer er ikke komplette, og hold tilføjer, ændrer og fjerner historier baseret på feedback fra slutbrugeren, opdagelsen af tekniske kompleksiteter og til at tackle teknisk gæld, der er indført under rejsen. Den episke nedbrud indikerer derefter, hvor langt væk fra planen epikken er baseret på, hvor meget efterslæbet vokser versus at blive afsluttet sprint for sprint.
- Episke nedbrud hjælper også benchmarkindsatsen på tværs af flere sprints og måler, hvor meget planlægnings- og leveringsarbejde der udføres i et epos versus andre.
Udgivelsesafbrydelser informerer holdene om udgivelser rammer dato og omfang
Avancerede teams, der fuldt ud automatiserer deres leveringsrørledninger med kontinuerlig integration, kontinuerlig test og kontinuerlig levering, behøver muligvis ikke frigivelsesnedbrydninger. Hold, der implementerer ofte, bør spore, hvilke funktioner og historier der er knyttet til udgivelsen, men frigivelsen af frigivelsen er ikke særlig nyttig, da den ofte sporer fremskridt med sprint.
For andre teams, der følger frigørelsesadministrationspraksis og standardiserer på multisprint-udgivelser, kan frigivelsen af udgivelsen være produktets ejer og teamets vigtigste værktøj.
Udgivelsesnedbruddet svarer til den episke nedbrydning, undtagen i stedet for at spore funktioner, historier og historiestubber, der er tildelt et epos, viser frigivelsesnedbrydningen, hvad der er tildelt en udgivelse. Aksen og bjælkerne er derefter identiske med episke nedbrydninger.
Hold, der bruger frigivelsesnedbrændinger, kan således spore omfang og tidslinje for en frigivelse. Hold, der er på sporet, vil se en nedbrudt skråning ned til x-aksen med en skråning, der er i overensstemmelse med holdets hastighed. Udgivelser, der kan afvige fra sporet, har enten en mindre hældning eller viser flere historiepunkter, der tilføjes (når mere omfang tilføjes til udgivelsen) end det, der afsluttes.
Jira Software hjælper dig med disse fremskrivninger. Forudsat at holdet har arbejdet på projektet i mindst tre sprints, beregner Jira Software en gennemsnitlig holdhastighed og forudsiger slutsprinten til en frigivelse baseret på denne hastighed.
Sprint, episke og frigivelsesnedbrud giver holdene nogle brugervenlige værktøjer til at tilpasse sig mål. Når hold har en fælles forståelse af omfanget, bliver enige om prioriteter, planlægger flere sprints fremad og mærker historier i deres efterslæb korrekt, fortæller burndowns historien om, hvorvidt planlægning og udførelse er tilpasset målene. Når de ikke er det, er de et datadrevet værktøj, der kan skabe diskussion om, hvilke justeringer der kan være behov for.
