Agile Estimation Techniques: En sand estimering i et smidigt projekt

agile estimation techniques

Ægte skøn i et smidigt projekt: En komplet indsigt med eksempler på smidig skøn

Det er meget vigtigt at foretage Agile Estimation på forskellige niveauer. Dette gøres for korrekt planlægning, styring og estimering af den samlede indsats, som vi vil bruge til at implementere, teste og levere det ønskede produkt til kunderne med hensyn til tid inden for de angivne frister.

Med manglende skøn i Agile Project er der muligvis ingen ordentlig planlægning og ledelse, der kan ende med at levere det uønskede produkt og derved efterlade kunden utilfreds.

Historikpunkt Estimeringer udføres i Agile-projekter ved hjælp af forskellige teknikker som Planning Poker, Bucket System, Affinity Mapping osv. Forskellige estimationsskabeloner på forskellige niveauer bruges til dette formål som Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , User Story Template osv.

Hvad du lærer:

• Introduktion
• Skøn om fortællingspunkter i smidig
• Anbefalet værktøj
• Forskellige agile estimeringsteknikker
  • # 1) Planlægning af poker
  • # 2) T-shirtstørrelser
  • # 3) Punktafstemning
  • # 4) Bucket-systemet
  • # 5) Stor / Usikker / Lille
  • # 6) Affinitetskortlægning
  • # 7) Bestillingsmetode
• Beregning af budget i smidig
• Estimationsskabeloner i Agile Development Project
  • 1) Agil projektplanskabelon:
  • 2) Skabelon til agil frigivelsesplan:
  • 3) Skabelon til agil produktbacklog:
  • 4) Agile Sprint Backlog-skabelon:
  • 5) Agil testplanskabelon:
  • 6) Agile brugerhistorisk skabelon:
  • 7) Agil vejkortskabelon:
• Stadier af skøn i agilt projekt
  • # 1) Estimering af forslag eller projektniveau
  • # 2) Estimering af frigivelsesniveau
  • # 3) Estimering af sprintniveau
• Konklusion
• Anbefalet læsning

Introduktion

Nedenfor er de 3 hovedniveauer af Agile Estimation.

# 1) Projekt- eller forslagsniveau er den, der bruger Quick Function Point Analysis i de indledende faser af projektudviklingen.

# 2) Udgivelsesniveau inkluderer tildeling af historiepunkter til brugerhistorierne, der kan hjælpe med at definere rækkefølgen af ​​brugerhistorierne baseret på prioriteten og kan også hjælpe med at beslutte, hvilke historier der kan tages i den aktuelle udgivelse, og hvilke der kan tages senere.

# 3) Sprintniveau er den, hvor brugerhistorierne er opdelt i opgaverne, og estimerede timer tildeles opgaverne i henhold til deres kompleksitet. Her definerer vi også den person, der er ansvarlig for opgaven sammen med status for opgaverne.

Disse oplysninger kan senere bruges til at beregne budgettet for Agile-projektet. Beregning af budget er afgørende for at sikre, at projektet ikke går over budgettet på grund af pre- og post-iterationsopgaver eller af andre årsager.

Skøn om fortællingspunkter i smidig

Story Points estimeringer er en komparativ analyse til groft at estimere produktets efterslæbsposter med relativ størrelse. Teammedlemmerne til estimering af brugerhistorier inkluderer: Product Owner, Scrum Master, Developers, Testers and Stake indehavere.

Nedenfor er der få trin til at nå den endelige beslutning om relativ størrelse:

# 1) Analyser alle brugerhistorier og identificer basen eller referencehistorien. Det er vigtigt at lave relativ størrelse. Denne historie kan vælges fra den aktuelle produktforsinkelse eller den, som vi har gjort tidligere. Denne historie skal vælges som referencehistorie efter samtykke fra alle medlemmer.

#to) Vælg en anden historie fra den aktuelle produktbakke, og teammedlemmerne kan frit diskutere spørgsmål eller tvivl med produktejeren, mens de forstår historiens krav. Produktejer er ansvarlig for at afklare alle deres forespørgsler og tvivl.

# 3) Lav en liste over de ting, der skal tages hånd om, mens du implementerer brugerhistorien. Disse kan gøres ved at skrive noter i værktøjets noter eller ved at tilføje punkttegn på historikortet. Dette gøres for det meste af Scrum Master.

# 4) Nedenfor er der få almindelige spørgsmål blandt deltagerne:

• Design: Hvad er den forudgående og obligatoriske viden, som vi skal have, før vi begynder at arbejde på det?
• Kodning: Hvor meget kodning der kræves for at implementere denne brugerhistorie. Har vi stødt på nogen lignende brugerhistorie tidligere?
• Enhedstest: Er der behov for mock-objekter til at udføre enhedstest i denne brugerhistorie?
• Integrationstest: Påvirker denne historie de andre funktioner i det samme modul og andre moduler også?
• Acceptantestning: Hvilke punkter skal der sørges for at levere det ønskede produkt efter kundens ønske?
• Ekspertise: Har nogen af ​​deltagerne gjort en lignende historie før og er ekspert i den?

# 5) Foretag relativ størrelse for den valgte historie. Hvis det kræver samme mængde arbejde og kræfter, skal du tildele det samme nr. point, som tildelt referencehistorien. Hvis det kræver mere indsats, skal du tildele det en højere værdi. Hvis det kræver mindre indsats, skal du tildele det en lavere værdi.

# 6) Opnå konsensus med alle deltagerne for at færdiggøre den relative størrelse for den valgte brugerhistorie i henhold til definitionen af ​​færdig.

hvad er en .7z fil?

# 7) Når der er foretaget en relativ størrelse af alle produktets efterslæbsposter, skal du sikre dig, at hvis alle brugerhistorier med samme nr. af point, der er tildelt dem, kræver samme indsats og størrelse for at være konsistente.

Anbefalet værktøj

# 1) Agile Poker

Agile Poker er en velkendt app til Jira til hurtig og bekvem planlægning og skøn for både fjerntliggende og samlokaliserede hold.

Kom godt i gang med Agile Poker er enkelt og let, da det blev inspireret af tre industristandard estimeringsmetoder: Planlægning af Poker®, Wideband Delphi og Magic Estimation (også kendt som Silent Grouping, Affinity Estimation, Swimlanes Sizing eller Relative Estimations).

Forskellige agile estimeringsteknikker

Der er mange teknikker til at foretage skøn i et Agile-projekt. De vigtigste principper for at foretage skøn inkluderer relativ estimering, diskussioner for at få mere information om emner, hvis skøn skal udføres, og sikre engagementet fra hele holdet over for de opgaver, der er tildelt dem.

Der er hovedsageligt 7 Agile Project Estimation Techniques:

# 1) Planlægning af poker

• I denne estimeringsteknik sidder alle de mennesker, der skal foretage estimeringerne, i en rund cirkel til Planning Poker-sessionen.
• Hver estimator har et sæt planlægningspokerkort med værdier: 0,1,2,3,5,8,13,20,40 og 100. Disse værdier repræsenterer historiepunkter eller mål, som holdet estimerer.
• I starten af ​​sessionen læser produktejeren eller kunden brugerhistorien op og beskriver alle dens funktioner og krav.
• Når historien er læst op, finder diskussionerne mellem estimatorerne og med produktejeren / kunden sted. Estimatorerne kan stille spørgsmål eller afklare deres tvivl med produktejeren.
• Efter diskussionerne bliver alle estimatorer bedt om at vælge et kort for at estimere en brugerhistorie. Hvis alle estimatorer giver samme værdi, bliver det det endelige estimat.
• Hvis værdierne er forskellige, forklarer estimatorerne, der giver de højeste og laveste værdier, deres meninger, og hvorfor de valgte denne værdi, indtil der opnås enighed.
• En god teknik når lille nej. varer skal estimeres i et lille hold.

=> Yderligere detaljeret læsning om Planlægning af Poker Estimation Technique .

# 2) T-shirtstørrelser

• Ligesom i tilfælde af T-shirts ser vi størrelser: XS (ekstra lille), S (lille), M (medium), L (stor), XL (ekstra stor). En lignende tilgang følges her. Varerne estimeres i T-shirtstørrelser.
• Dette er en perfekt teknik til at give et groft skøn over det store efterslæb af varer.
• Nyttigt, når der skal foretages hurtig og grov estimering. Senere kan disse størrelser konverteres til nej i henhold til kravet.
• En relativ størrelse (for det meste Medium) bestemmes efter gensidig diskussion og enighed mellem holdmedlemmerne eller estimatorerne. Derefter tildeles nej til elementerne i henhold til den relative størrelse, der er tildelt mellemstørrelse.
• Ulempe: Hvad der synes L for nogen, kan synes at være XL for nogen.
• Alle estimatorer tildeler varerne deres egen størrelse. Efter diskussioner og løsning af uoverensstemmelserne opnås enighed om at få det endelige skøn.

# 3) Punktafstemning

• Dette er dybest set en placeringsmetode til at bestemme rækkefølgen af ​​Product Backlog fra historier med højest prioritet til historier med lavest prioritet. Dette gøres for at vælge de vigtigste historier, der skal videreføres.
• For at starte med dette skal du sende alle brugerhistorierne sammen med deres beskrivelse på væggen eller tavlen ved hjælp af gule klistermærker eller på en måde, der adskiller dem ved modtagelse af stemmerne.
• Alle interessenter får 4 til 5 prikker (for det meste i form af klistermærker, penne eller markører kan også bruges til at lave prik).
• Alle interessenter bliver bedt om at give deres stemmer til de brugerhistorier, som de foretrækker.
• Produktejer bestiller produktets efterslæbsposter fra de mest foretrukne (en med flest antal prikker) til den mindst foretrukne (en med mindst antal prikker).
• Det kan være tilfældet, hvor få interessenter er utilfredse med den besluttede rækkefølge. I dette tilfælde er brugerhistorierne opdelt i 3 grupper efter diskussionerne: høj prioritet, lav prioritet og mellem prioritet. Højprioriterede brugerhistorier er placeret på væggen for at modtage stemmerne. Dette gøres, indtil den endelige ordre opnås med samtykke fra alle interessenter.

# 4) Bucket-systemet

• Det er en god teknik, når et stort nr. varer skal estimeres med stort nr. af deltagerne. Det er hurtigere og mere rimeligt end at planlægge poker.
• Forskellige skovle oprettes med værdier: 0,1,2,3,4,5,8,13,20,30,50,100, 200.Dette kan udvides, hvis det kræves. Disse spande er intet andet end kort, der repræsenterer værdier, der er anbragt sekventielt på et bord.
• Historierne skal placeres i disse, hvor estimatoren finder dem egnede. Alle de poster, der skal estimeres, er skrevet på kortene.
• Vælg et emne tilfældigt og læg det i spand 8. Dette bruges kun til reference. Vælg en anden historie tilfældigt, diskuter alle dens funktioner og krav med gruppen, og placer den i den relevante spand efter konsensus. Tilsvarende plukkes tredje genstand og placeres i en passende spand.
• Spandssekvensen kan også ændres, hvis gruppen føler, at det første valgte emne skal høre til spand 1 i stedet for spand 8.
• Divide and Conquer tilgang følges. Alle de resterende emner er delt mellem alle deltagerne. Alle deltagere kan placere varen uden godkendelse fra andre deltagere.
• Varerne skal placeres korrekt. Ingen genstande kan placeres mellem skovlene.
• Hvis en deltager ikke forstår produktets backlog-emne, eller hvis de andre deltagere er færdige med at placere deres brugerhistorier, kan brugerhistorierne overføres til de andre deltagere.
• Endelig udføres Sanity-kontrol af alle deltagerne. Hvis en deltager finder en forkert skovl, der er tildelt en vare, kan de bringe den til andre deltagere og drøfte med dem. Dette gøres, indtil der opnås enighed om hele produktets efterslæb.
• Facilitatoren skal foretage en kontrol af, at ingen flytter varerne, medmindre der er foretaget sundhedsundersøgelse.
• Dette gøres også for at opnå den prioriterede rækkefølge af produktets efterslæbsposter.

# 5) Stor / Usikker / Lille

• Dette er en grov version og er forenkling af skovlesystem, hvor der kun er tre størrelser: Stor, Lille og Usikker.
• Deltagerne eller estimatorerne bliver bedt om at placere varerne i en af ​​kategorierne. For det første vælges de enkle brugerhistorier og placeres i store og små kategorier. Derefter tages de komplekse genstande op.
• Det er en god teknik, når der er sammenlignelige emner i Product Backlog.

# 6) Affinitetskortlægning

• En god teknik, når holdet er lille og nej. af efterslæbsposter er mindre.
• Første trin er Silent Relativ størrelse: På en væg placeres et kort med 'Mindre' skrevet på venstre side og kortet med 'Større' skrevet på den højre side. Produktejer leverer en delmængde af varerne til alle deltagere. Alle deltagere bliver bedt om at dimensionere hvert element i forhold til størrelserne på kortene på væggen i betragtning af den krævede indsats for at implementere dem. Det er deltagerens solo beslutning uden nogen diskussion med de andre holdmedlemmer. Produktejer eller interessent er til stede for at afklare deltagerens tvivl. Produktbacklog-emner, der er for tvetydige til, at teammedlemmerne kan forstå dem til estimering, placeres separat. Det tager 5-20 minutter.
• Redigering af væg: Holdmedlemmerne kan ændre placeringen af ​​emnerne på væggen. De kan diskutere design- og implementeringskrav med de andre teammedlemmer. Denne aktivitet kan lukkes, når der ikke sker lidt ændringer på væggen. Det tager cirka 20-60 minutter .
• Placering af genstande på de rigtige placeringer: Efter diskussionerne placerer teamet produktets efterslæbsposter i deres relative og passende positioner. Vi kan bruge størrelsen på T-shirt, Fibonacci-serien osv. Her til relativt at estimere størrelsen på varerne.
• Produktejerudfordring: Produktejeren kan finde en vis uoverensstemmelse i teamets skøn og har brug for at diskutere flere funktioner eller kravene til en vare med teamet. Efter diskussioner foretages endelige skøn.
• Eksporter til Project Backlog Management Tool: For at sikre, at oplysningerne om de endelige estimater ikke går tabt, skal du eksportere dem til et produktbacklog-styringsværktøj.

# 7) Bestillingsmetode

• En god teknik, når stor nr. varer og lille nr. af mennesker er der.
• Det giver nøjagtige relative størrelser for produktets efterslæbsposter.
• En skala udarbejdes, der spænder fra lav til høj. Alle emnerne placeres tilfældigt på den. Hver deltager bliver bedt om at flytte et element på skalaen ad gangen. Bevægelsen kan være en op, en ned eller vende drejningen til et andet medlem.
• Dette fortsætter, indtil alle deltagerne er tilfredse og ikke ønsker at flytte noget på skalaen.
• Dette giver også den prioriterede rækkefølge af varerne i Product Backlog.

Beregning af budget i smidig

Beregning af budgetter spiller en vigtig rolle i Agile projekter. Dette gøres for at sikre, hvad der er det faktiske budget, hvad der kræves mere budget, og hvordan skal vi opdele budgettet for forskellige poster i produktforsinkelser.

Det bruger de data, der er indsamlet fra de tidligere projekter, og bruger den matematiske formel til at få det anslåede budget for det aktuelle projekt.

Nedenfor er rækkefølgen af ​​trin til beregning af budgettet i et Agile-projekt:

# 1) Noter alle kravene til projektet, og gør skøn for dem ved hjælp af Planning Poker, Bucket System, Fibonacci-serier osv. Alle teammedlemmer skal være enige om de skøn, der er foretaget for de anførte krav efter klar analyse og forståelse af brugerhistorierne. Estimeringer foretages ud fra de funktioner, der skal implementeres i en brugerhistorie.

#to) Bestem varigheden af ​​gentagelserne kaldet Sprints og de produkter, der er tildelt produktbacklog. Det er normalt 2 til 3 uger langt. Brugerhistorierne vælges i en rækkefølge, der starter med brugerhistorien med maksimal prioritet, flyttes til mindre prioritet og med mindst prioriteret brugerhistorie i slutningen. Dette hjælper med at beslutte, hvilke brugerhistorier der skal afhentes i den første Sprint, og hvilke historier der kan tages op senere.

# 3) Forbered afbrændt diagram for at give et klart billede af, hvor meget arbejde der skal udføres versus hvor meget tid der er tilbage til implementering. Det giver dybest set hastigheden for et agilt hold. Det giver et klart billede af, hvordan holdet opfører sig, og hvordan det forventes, at det opfører sig.

Holdets fremskridt måles i form af afsluttede opgaver, resterende indsats, ideel nedbrydning og resterende opgaver som vist nedenfor:

# 4) Tilføj yderligere omkostninger som udstyrs køb, værktøjer, infrastruktursupport, at få licenser til de softwareværktøjer, der skal bruges, Project Management Tools, Antivirusinstallation og opdateringer.

# 5) Tilføj præ- og postterterationsbudgetter. Alle smidige medlemmer formodes at være tværfunktionelle, men der er grænser for det. Alt, der udføres af et teammedlem uden for hans ekspertise, betragtes som præ iteration eller post iteration arbejde. Dette arbejde før og efter ikteration kræver yderligere budget til implementering.

# 6) Hold øje med de skjulte risici. Risici i Agile-projektet inkluderer: Risiko for, at projektet går over budgettet, Fravær af teammedlemmer, Medlemmer har ikke en klar eller fuldstændig viden, Medlemmer har ikke de nødvendige færdigheder, deadlines er overskredet osv.

Estimationsskabeloner i Agile Development Project

Der er mange estimationsskabeloner, der udarbejdes på forskellige niveauer i Agile-udviklingsprojektet. Det eneste formål er at tydeligt angive de skøn, der kræves for at implementere et krav eller en vare og spore dens fremskridt.

De vigtigste skabeloner er som nævnt nedenfor:

1) Agil projektplanskabelon:

Det giver et højt overblik over, hvor meget tid der kræves for at levere kravene til funktionerne, og hvad er deres status. Den nævner også den person, der er ansvarlig for den specifikke opgave.

(Bemærk: Klik på et hvilket som helst billede for en forstørret visning)

2) Skabelon til agil frigivelsesplan:

Det giver frigivelsesoplysninger om de opgaver, der svarer til kravene, sammen med deres status og Sprint, som de skal udføres i.

3) Skabelon til agil produktbacklog:

Den beskriver den komplette produktforsinkelse, der er defineret for projektet. Det giver detaljerede opgaver for Sprints sammen med status, prioritet, historiepunkter, og om de er tildelt en Sprint, eller hvis der er nogle yderligere opgaver som mangler osv.

4) Agile Sprint Backlog-skabelon:

Det giver en beskrivelse af brugerhistorierne nævnt i efterslæbet for en bestemt Sprint. Det giver de samlede historiepoint, der er tildelt en brugerhistorie, og hvordan disse er opdelt i forskellige opgaver. Det giver også status for de tilsvarende opgaver, og hvad er det arbejde, der udføres dagligt for de tilsvarende opgaver.

5) Agil testplanskabelon:

Det opdeler hele testscenariet i underscenarier. Det giver detaljer om underscenarier som implementeringsdato, forventet resultat, faktisk resultat, status osv.

hvad er den bedste spionapp til Android

Det nævner også projektnavnet, den kompatible browser, versionen af ​​applikationen under test, testsag-id for et valgt scenario, skrevet af, testet af, beskrivelse osv.

6) Agile brugerhistorisk skabelon:

Det giver de specifikke detaljer for analysen af ​​brugerhistorien som Hvilke roller kræves for at en bestemt funktionalitet skal testes, hvad er det forudgående krav (miljøopsætning og links aktiveret) og hvad er det forventede resultat?

7) Agil vejkortskabelon:

Det giver en retning til projektet i virksomheden på kort og lang sigt. Det hjælper med at sætte forventninger inden for virksomheden. Og oversigten over, hvor projektet er på vej hen.

Stadier af skøn i agilt projekt

I et agilt projekt foretages estimater på 3 niveauer som nævnt nedenfor:

• Projekt / forslag niveau: Den samlede funktionelle størrelse for hele applikationen estimeres ved hjælp af QFPA-metoden (Quick Function Point Analysis), når kun krav på højt niveau er tilgængelige.
• Udgivelsesniveau: Historiepunkter tildeles brugerhistorierne, som hjælper med at bestemme nr. af udgivelser planlagt inden for et projekt og nr. af brugerhistorier, der skal tages i en frigivelse og sprint.
• Sprint niveau: Anslåede timer tildeles brugerhistoriens opgaver inden for en sprint. Dette gøres for at sikre udviklingsengagementet for at levere brugerhistorier med i en sprint.

S1, S2, S3, S4, S5, S6 er sprints.

# 1) Estimering af forslag eller projektniveau

Det er et meget højt skøn for projektet. Den fokuserer på det samlede antal krav i varen Product Backlog. Funktionspunkter bruges til at estimere størrelsen på softwaren / projektet, før en detaljeret beskrivelse af funktionskravene dokumenteres.

Funktionspunkter er den almindeligt accepterede måde at beregne størrelsen på softwaren på. Det fokuserer på de funktioner, der findes i softwareprojekterne. Et funktionspunkt er en metrik, der konverterer kravene eller brugerhistorierne til et tal.

I de indledende faser af projektet anbefales det at anvende QFPA-metode (Quick Function Point Analysis).

Metode til hurtig funktionspunktsanalyse er en unik tilgang til estimering af FP, når kun krav på højt niveau er tilgængelige.

Hvordan beregnes den samlede funktionelle størrelse?

• Forstå alle funktionerne i en applikation ved hjælp af domæneeksperter.
• Identificer og lister alle mulige funktioner i en applikation.
• Datalagringsfunktioner klassificeres i interne logiske filer (data gemt internt i applikationen) og eksterne interface-filer (data, der kun bruges til referenceformål).
• Transaktionsfunktioner klassificeres i eksterne indgange (data, der kommer fra eksterne kilder til anvendelse), eksterne udgange (afledte data går fra anvendelse til udvendigt) og eksterne forespørgsler (data hentet fra en eller flere eksterne indgange og eksterne udgange).
• Beregn FP-størrelse for hver funktion ved at beregne dens gennemsnitlige kompleksitet.
• Opsummer FP-størrelse for alle funktionerne for at få applikationens samlede funktionelle størrelse.
• Mindst to personer med ekspertise inden for FP-analyse skal beregne uafhængigt, matche resultater og løse forskellene.

Eksempel til estimering af projektniveau:

Nedenfor er listen over krav til et projekt som i Product Backlog:

• En bruger skal kunne logge ind på hjemmesiden ved at angive brugernavn og adgangskode.
• Efter vellykket login skal en bruger føres til hovedsiden med højre og venstre rude defineret.
• En bruger skal have mulighed for at logge ud af applikationen.
• En gyldig bruger har mulighed for at ændre adgangskoden ved at give aktuelle legitimationsoplysninger.

Holdet bruger en hurtig FP-estimering til at estimere projektstørrelsen.

Følgende er analysen udført:

• Datalagringsfunktionen her lagrer brugerlegitimationsoplysningerne for at logge ind og ændre adgangskoden.
• Da legitimationsoplysningerne er gemt inden for applikationsgrænsen, gemmes det i ILF'er (interne logiske filer).
• Transaktionsfunktionerne inkluderer:
  • Bruger login og visning af hovedsiden.
  • Brugerlogout og visning af logoutskærm.
  • Evne til at ændre adgangskoden.

Nedenfor er de trin, der er udført for at estimere projektstørrelsen ved hjælp af Quick Function Point Analysis:

TRIN # 1: Liste ned alle datafunktioner

UFP (Unadjusted Function Point) er taget fra Caper Jones Table.

TRIN # 2: Liste over alle transaktionsfunktioner

UFP (Unadjusted Function Point) er taget fra Caper Jones Table.

TRIN # 3: Udledning af den estimerede projektstørrelse i Funktionspunkter

UFP = Data FP + Transaktion FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (forudsat VFP (værdijusteringsfaktor = 1)

Produktivitet = 16 FP / måned (Normal Standard)

Indsats = FP / produktivitet = 22/16 personers måned = 1,37 person måned

# 2) Estimering af frigivelsesniveau

Estimeringer af frigivelsesniveau udføres under frigivelsesplanlægningen. Det er den næste aktivitet efter estimering af projektniveau. De prioriterede krav er taget fra Product Backlog, der er i form af brugerhistorier.

Brugerhistorierne estimeres i form af historiepunkter under frigivelsesplanlægningen, der fokuserer på at estimere størrelsen på den software, der skal leveres til den frigivelse. På denne måde er der ikke planlagt antal udgivelser og totalt antal fortællingspunkter i hver udgivelse.

Et historiepunkt repræsenterer dybest set den relative indsats, der kræves for at implementere en funktion eller funktionalitet, sammenlignet med de andre funktioner. Det er grundlæggende til dimensionering af Product Backlog-emner.

Estimering af historiepunkt udføres på basis af:

• Kompleksiteten af ​​den funktion, der skal implementeres.
• Erfaring og tekniske færdigheder hos alle medlemmer.

S1, S2, S3, S4, S5 er sprints.

Trin til tildeling af historie peger på en brugerhistorie:

• Alle teammedlemmer samles rundt om et bord, der gennemgår brugerhistorierne i Sprint Backlog.
• Betydningen af ​​et historiepunkt og tilsvarende indsats bestemmes.
• Et af teammedlemmerne læser en brugerhistorie op og beder derefter teammedlemmerne om at tildele de relative historiepunkter.
• Hvis der er en signifikant forskel mellem de historiepoint, der er tildelt af teammedlemmerne, giver de en forklaring på de historiepunkter, de har tildelt, hvorved de når enighed i slutningen.
• Processen gentages 3-4 gange, indtil der ikke er nogen større forskel mellem de estimater, som holdmedlemmerne giver.
• Størrelse af historier hjælper med at bestemme, hvor mange historier der skal tages inden for en sprint og frigivelse.

Eksempel på estimering af frigivelsesniveau:

Dette indebærer oprettelse af en prioriteret liste over brugerhistorier kaldet Product Backlog. Produktejer opretter produktbacklog og giver forretningsværdi for hver af de varer, der er angivet i den.

Vi kan bruge nedenstående metoder til estimering af Story Points:

• Numerisk størrelse: 1 til 10
• T-shirt størrelse: Hvert krav er klassificeret som Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL).
• Fibonacci-serien: Estimering foretaget gennem Fibonacci-sekvens (1,2,3,5,8,13,21,34,….)

Estimering af ovenstående brugerhistorier gennem Fibonacci-sekvensen:

# 3) Estimering af sprintniveau

Skøn over Sprint-niveau foretages under Sprint-planlægning. Produkthøjeste emner med højeste prioritet tages og opdeles i forskellige opgaver som Detailing, Design, Analyse, Udvikling, Opret testcases, Execute Test Cases, User Acceptance Testing osv.

Opgaver estimeres i form af estimerede timer, dvs. den tid, der kræves for at fuldføre opgaven for en tilsvarende brugerhistorie. The Bottom-Up Approach bruges til opgavestimaterne, hvor forretningskravene er opdelt i aktiviteter på lavt niveau, og hver aktivitet tildeles estimerede timer.

Formålet med estimaterne er at vide, hvor mange brugerhistorier udviklingsholdet kan forpligte sig til en Sprint. Udviklingen skal være fortrolig med forpligtelsen, og produktindehaverne skal være sikre på, at teamet leverer forpligtelsen.

S tip til tildeling af estimerede timer til opgaverne:

• Teammedlemmer henter brugerhistorierne, hvorefter de bliver bedt om at estimere den faktiske indsats i timer eller dage for de opgaver, der svarer til brugerhistorien.
• Hvis der er uenighed i disse skøn blandt holdmedlemmerne, så diskuterer de det og kommer til enighed.
• Hvis en opgave er mere end seks timer, opdeles den i mindre opgaver.
• Hvis der er to eller flere opgaver med estimerede timer mindre end to, kombineres de for at danne en ny opgave.

Eksempel på estimering af sprintniveau:

Der er to dele af Sprint Planning-mødet:

• Første del: Fokus er på at afklare kravene til brugerhistorier, der er valgt fra Product Backlog.
• Anden del: Fokus er på at opdele kravene i opgaver og estimere de nødvendige timer for at gennemføre dem. Alle de opgaver, der er nødvendige for at gøre Product Backlog-varen leverbare, skal medtages. Opgaverne skal være små. Ideelt set bør en opgaveindsats ikke vare mere end seks timer.

Konklusion

Estimaterne i Agile-projektet spiller en vigtig rolle for at sikre korrekt retning, planlægning og ledelse.Det giver trin til, hvordan man tager projektet op i fremtiden.

Teknikkerne til at estimere historiepunkter som planlægning af poker, Bucket System osv. Gør brug af kort eller prikker, der har værdier eller tal på, og tildel derefter disse nr. til brugerhistorierne for beregning af relativ størrelse.

Det eneste formål er at indstille varerne i en prioriteret rækkefølge fra maksimal prioritet til minimum prioritet. De anslåede relative størrelser for produktets efterslæbsposter hjælper med at estimere eller beregne det budget, der kræves til projektet.

Håber du ville have fået et godt indblik i Estimations of Agile Projects. Du er velkommen til at udtrykke dine tanker om denne vejledning i kommentarfeltet nedenfor.

Anbefalet læsning

• Sådan gør du en smidig estimeringsproces let med at planlægge poker
• Agile Vs Waterfall: Hvilken er den bedste metode til dit projekt?
• Software Test Estimation Techniques (Test Effort Estimation Complete Guide)
• VersionOne-vejledning: Alt-i-en Agile Project Management Tool Guide
• Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in til JIRA (anmeldelse)
• TOPP 10 bedste agile projektstyringsværktøjer i 2021
• Grundlaget for en vellykket smidig rejse: Hvordan man vælger den rigtige metode, værktøjer og teknikker
• 4 trin mod udvikling af Agile Testing Mindset for vellykket overgang til agil proces