Agile Estimation Techniques: En sann estimering i et smidig prosjekt

agile estimation techniques

Sanne estimeringer i et smidig prosjekt: Et komplett innblikk med eksempler på smidig estimering

Det er veldig viktig å gjøre smidig estimering på forskjellige nivåer. Dette gjøres for riktig planlegging, styring og estimering av den totale innsatsen vi skal bruke for å implementere, teste og levere det ønskede produktet til kundene når det gjelder tid innen de angitte tidsfrister.

Med manglende estimater i Agile Project, kan det hende at det ikke er noen ordentlig planlegging og ledelse som kan ende med å levere det uønskede produktet og dermed etterlate kunden misfornøyd.

Historiske poeng Estimeringer gjøres i Agile-prosjekter ved hjelp av forskjellige teknikker som Planning Poker, Bucket System, Affinity Mapping, etc. Ulike estimeringsmaler på forskjellige nivåer brukes til dette formålet som Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , Mal for brukerhistorie osv.

Hva du vil lære:

• Introduksjon
• Estimeringer av historiepoeng i smidig
• Anbefalt verktøy
• Ulike smidige estimeringsteknikker
  • # 1) Planlegger poker
  • # 2) T-skjorte størrelser
  • # 3) Punktstemming
  • # 4) Bucket System
  • # 5) Stor / usikker / liten
  • # 6) Affinitetskartlegging
  • # 7) Bestillingsmetode
• Beregning av budsjett i smidig
• Estimeringsmaler i smidig utviklingsprosjekt
  • 1) Agile prosjektplanmal:
  • 2) Agile utgivelsesplanmal:
  • 3) Agile Product Backlog Mal:
  • 4) Agile Sprint Backlog Mal:
  • 5) Agile testplanmal:
  • 6) Agile User Story Template:
  • 7) Agile veikartmal:
• Stadier av estimering i smidig prosjekt
  • # 1) Anslag om forslag eller prosjektnivå
  • # 2) Estimering av utgivelsesnivå
  • # 3) Estimering av sprintnivå
• Konklusjon
• Anbefalt lesing

Introduksjon

Nedenfor er de tre hovednivåene av smidig estimering.

# 1) Prosjekt- eller forslagsnivå er den som bruker Quick Function Point Analysis i de innledende fasene av prosjektutviklingen.

# 2) Utgivelsesnivå inkluderer tildeling av historiepoengene til brukerhistoriene som kan hjelpe til med å definere rekkefølgen på brukerhistoriene basert på prioriteten, og kan også hjelpe til med å bestemme hvilke historier som kan tas i den nåværende utgivelsen og hvilke som kan tas senere.

# 3) Sprintnivå er den der brukerhistoriene er delt inn i oppgavene og estimerte timer tildeles oppgavene i henhold til deres kompleksitet. Her definerer vi også personen som er ansvarlig for oppgaven sammen med statusen til oppgavene.

Denne informasjonen kan senere brukes til å beregne budsjettet for Agile-prosjektet. Beregning av budsjett er avgjørende for å sikre at prosjektet ikke går over budsjettet på grunn av pre- og post-iterasjonsoppgaver eller andre grunner.

Estimeringer av historiepoeng i smidig

Story Points estimeringer er en komparativ analyse for grovt å estimere produktets etterslagsvarer med relativ størrelse. Teammedlemmene for å estimere brukerhistorier inkluderer: Produkteier, Scrum Master, utviklere, testere og stakeholdere.

Nedenfor er noen få skritt for å nå den endelige avgjørelsen om relativ størrelse:

#1) Analyser alle brukerhistorier og identifiser basen eller referansehistorien. Det er viktig for å gjøre relativ størrelse. Denne historien kan velges fra den nåværende varen eller den som vi har gjort tidligere. Denne historien bør velges som referansehistorie etter samtykke fra alle medlemmer.

#to) Velg en annen historie fra den nåværende Product Backlog, og teammedlemmene står fritt til å diskutere spørsmål eller tvil med Produkteieren, mens de forstår historiens krav. Produkteier er ansvarlig for å avklare alle spørsmål og tvil.

# 3) Lag en liste over ting som skal tas vare på mens du implementerer brukerhistorien. Disse kan gjøres ved å skrive notater i notatdelen av verktøyet eller ved å legge til punktpunkter på historikkortet. Dette gjøres for det meste av Scrum Master.

# 4) Nedenfor er det noen vanlige spørsmål blant deltakerne:

• Design: Hva er den grunnleggende og obligatoriske kunnskapen vi bør ha før vi begynner å jobbe med den?
• Koding: Hvor mye koding som kreves for å implementere denne brukerhistorien. Har vi kommet over noen lignende brukerhistorie tidligere?
• Enhetstesting: Er det noen mock-objekter som kreves for å utføre enhetstesting for denne brukerhistorien?
• Integrasjonstesting: Påvirker denne historien de andre funksjonene til den samme modulen og andre moduler også?
• Akseptprøving: Hva er poengene som skal tas vare på for å levere det ønskede produktet slik kundene ønsker det?
• Ekspertise: Har noen av deltakerne gjort en lignende historie før, og er ekspert på den?

# 5) Gjør relativ størrelse for den valgte historien. Hvis det krever like mye arbeid og krefter, tildel det samme nei. poeng, som tildelt referansehistorien. Hvis det krever mer innsats, tilordne det en høyere verdi. Hvis det krever mindre innsats, tilordne det litt lavere verdi.

# 6) Oppnå enighet med alle deltakerne for å fullføre den relative størrelsen for den valgte brukerhistorien i henhold til definisjonen av ferdig.

hvordan man skriver manuelle testtilfeller

# 7) Etter at relativ størrelse på alle produktets forsinkelseselementer er utført, må du sørge for at hvis alle brukerhistoriene med samme nr. av poengene som er tildelt dem, krever samme innsats og størrelse for å være konsistente.

Anbefalt verktøy

# 1) Agile Poker

Agile Poker er en kjent app for Jira for rask og praktisk planlegging og estimeringer for både eksterne og samlokaliserte team.

Å komme i gang med Agile Poker er enkelt og enkelt ettersom det ble inspirert av tre industristandard estimeringsmetoder: Planning Poker®, Wideband Delphi og Magic Estimation (også kjent som Silent Grouping, Affinity Estimation, Swimlanes Sizing eller Relative Estimations).

Ulike smidige estimeringsteknikker

Det er mange teknikker for å gjøre estimeringer i et smidig prosjekt. Hovedprinsippene for å gjøre estimeringer inkluderer relativ estimering, diskusjoner for å få mer informasjon om elementer som må estimeres og sikre engasjement for hele teamet overfor oppgavene som er tildelt dem.

Det er hovedsakelig 7 smidige prosjektestimeringsteknikker:

# 1) Planlegger poker

• I denne estimeringsteknikken sitter alle menneskene som skal gjøre estimeringene, i en rund sirkel for Planning Poker-sesjonen.
• Hver estimator har et sett med planleggingspokerkort med verdier: 0,1,2,3,5,8,13,20,40 og 100. Disse verdiene representerer historiepoeng eller mål som laget estimerer.
• Ved starten av økten leser produkteieren eller kunden opp brukerhistorien og beskriver alle funksjonene og kravene.
• Etter at historien er lest opp, finner diskusjonene mellom estimatorene og med produkteieren / kunden sted. Estimatorene kan stille spørsmål eller avklare tvil med produkteieren.
• Etter diskusjonene blir alle estimatorer bedt om å velge ett kort for å estimere en brukerhistorie. Hvis alle estimatorer gir samme verdi, blir det det endelige estimatet.
• Hvis verdiene er forskjellige, forklarer estimatorene som gir de høyeste og laveste verdiene deres meninger og hvorfor de valgte denne verdien, til enighet er oppnådd.
• En god teknikk når liten nei. av varer skal estimeres i et lite team.

=> Ytterligere detaljert lesing på Planlegging av Poker Estimation Technique .

# 2) T-skjorte størrelser

• Akkurat som i tilfellet med T-skjorter, ser vi størrelser: XS (ekstra liten), S (liten), M (medium), L (stor), XL (ekstra stor). En lignende tilnærming følges her. Produktene er estimert i T-skjorte størrelser.
• Dette er en perfekt teknikk for å gi en grov estimering av den store etterslaget av varer.
• Nyttig når rask og grov estimering må gjøres. Senere kan disse størrelsene konverteres til nei i henhold til kravet.
• En relativ størrelse (for det meste Medium) avgjøres etter gjensidig diskusjon og enighet mellom teammedlemmene eller estimatorene. Deretter tildeles nei til elementene i henhold til den relative størrelsen som er tildelt Medium størrelse.
• Ulempe: Det som virker som L for noen, kan synes å være XL for noen.
• Alle estimatorer tilordner varene sin egen størrelse. Etter diskusjoner og løsning av uoverensstemmelsene oppnås enighet om å få det endelige estimatet.

# 3) Punktstemming

• Dette er i utgangspunktet en rangeringsmetode for å bestemme rekkefølgen på Product Backlog fra historiene med høyest prioritet til historier med lavest prioritet. Dette gjøres for å velge de viktigste historiene som skal tas videre.
• For å starte med dette, legg ut alle brukerhistoriene sammen med beskrivelsen på veggen eller tavlen ved hjelp av gule klistremerker eller på en måte som skiller dem for å motta stemmene.
• Alle interessenter får 4 til 5 prikker (for det meste i form av klistremerker, penner eller markører kan også brukes til å lage prikk).
• Alle interessenter blir bedt om å gi sine stemmer på brukerhistoriene de foretrekker.
• Produkteier bestiller produktets restriksjoner fra de mest foretrukne (en med flest antall prikker) til de minst foretrukne (en med minst antall prikker).
• Det kan være tilfelle der få interessenter er misfornøyde med den bestemte rekkefølgen. I dette tilfellet er brukerhistoriene delt inn i 3 grupper etter diskusjonene: høy prioritet, lav prioritet og middels prioritet. Brukerhistorier med høy prioritet blir lagt ut på veggen for å motta stemmene. Dette gjøres til den endelige bestillingen er oppnådd etter samtykke fra alle interessenter.

# 4) Bucket System

• Det er en god teknikk når et stort nei. av varene skal estimeres med stort nr. av deltakerne. Det er raskere og mer fornuftig enn Planning Poker.
• Forskjellige skuffer opprettes med verdier: 0,1,2,3,4,5,8,13,20,30,50,100, 200.Dette kan utvides om nødvendig. Disse bøttene er bare kort som representerer verdier som er ordnet sekvensielt på et bord.
• Historiene må plasseres innenfor disse der estimatoren finner dem passende. Alle elementene som skal estimeres er skrevet på kortene.
• Velg et element tilfeldig og legg det i bøtte 8. Dette brukes kun som referanse. Velg en annen historie tilfeldig, diskuter alle dens funksjoner og krav med gruppen, og legg den i riktig bøtte etter konsensus. Tilsvarende blir det tredje elementet plukket og plassert i en passende bøtte.
• Skuffesekvensen kan også endres, i tilfelle gruppen føler det første valgte elementet, skal tilhøre bøtte 1 i stedet for bøtte 8.
• Divide and Conquer tilnærming følges. Alle gjenværende gjenstander er delt mellom alle deltakerne. Alle deltakere kan plassere varen uten godkjenning fra andre deltakere.
• Elementene skal plasseres riktig. Ingen gjenstand kan plasseres mellom skuffene.
• Hvis en deltaker ikke forstår produktets etterslagsvare, eller hvis de andre deltakerne er ferdige med å plassere brukerhistoriene sine, kan brukerhistoriene overføres til de andre deltakerne.
• Til slutt utføres sunnhetskontroll av alle deltakerne. Hvis noen deltakere finner en feil bøtte tilordnet en vare, kan de bringe den til andre deltakere og diskutere med dem. Dette gjøres til det er oppnådd enighet for hele produktets etterslipp.
• Tilrettelegger bør sjekke at ingen beveger varene med mindre sunnhetskontroll er utført.
• Dette gjøres også for å oppnå den prioriterte rekkefølgen på produktets forsinkelsesvarer.

# 5) Stor / usikker / liten

• Dette er en grov versjon og er forenklingen av skuffesystemet der det bare er tre størrelser: Stor, Liten og Usikker.
• Deltakerne eller estimatorene blir bedt om å plassere elementene i en av kategoriene. For det første blir de enkle brukerhistoriene valgt og plassert i store og små kategorier. Deretter tas de komplekse elementene opp.
• Det er en god teknikk når det er sammenlignbare gjenstander i Product Backlog.

# 6) Affinitetskartlegging

• En god teknikk når laget er lite og nei. av etterslepsposter er mindre.
• Første trinn er Silent Relative Sizing: På en vegg er et kort med ‘Mindre’ skrevet på, plassert på venstre side og kortet med ‘Større’ skrevet på, er plassert på høyre side. Produkteier leverer en delmengde av varene til alle deltakerne. Alle deltakere blir bedt om å størrelse hvert element i forhold til størrelsene på kortene på veggen, med tanke på den innsatsen som kreves for å implementere dem. Det er deltakerens soloavgjørelse uten noen diskusjon med de andre teammedlemmene. Produkteier eller interessent er tilstede for å avklare deltakerens tvil. Produktet Backlog elementer som er for tvetydige til å forstå teammedlemmene for estimering plasseres separat. Det tar 5-20 minutter.
• Redigering av vegg: Teammedlemmene kan endre plasseringen av elementene på veggen. De kan diskutere design- og implementeringskrav med de andre teammedlemmene. Denne aktiviteten kan stenges når det ikke skjer små endringer på veggen. Det tar rundt 20-60 minutter .
• Plassere gjenstander på riktig sted: Etter diskusjonene plasserer teamet produktets restriksjoner i deres relative og passende posisjoner. Vi kan bruke størrelse på T-skjorte, Fibonacci-serien osv. Her for å relativt estimere størrelsen på varene.
• Produkteierutfordring: Produkteieren kan finne noe avvik i beregningene laget av teamet og trenger å diskutere flere funksjoner eller kravene til en vare med teamet. Etter diskusjoner gjøres endelige estimater.
• Eksporter til Project Backlog Management Tool: For å sikre at informasjonen om de endelige estimatene ikke går tapt, eksporterer du den til et produktbehandlingsverktøy.

# 7) Bestillingsmetode

• En god teknikk når stort nei. av gjenstander og lite nr. av mennesker er der.
• Det gir nøyaktige relative størrelser for produktets restanser.
• Det tilberedes en skala fra lav til høy. Alle elementene plasseres tilfeldig på den. Hver deltaker blir bedt om å flytte et element på skalaen, samtidig. Bevegelsen kan være en opp, en ned eller gi svingen til et annet medlem.
• Dette fortsetter til alle deltakerne er fornøyde og ikke vil flytte noe på skalaen.
• Dette gir også den prioriterte rekkefølgen på produktets etterslagsvarer.

Beregning av budsjett i smidig

Beregning av budsjetter spiller en viktig rolle i smidige prosjekter. Dette gjøres for å være sikker på hva som er det faktiske budsjettet som tilbys, hvilket mer budsjett som kreves, og hvordan skal vi dele budsjettet på forskjellige vareposter.

Den bruker dataene som er samlet inn fra de forrige prosjektene, og bruker den matematiske formelen for å få det estimerte budsjettet for det aktuelle prosjektet.

Nedenfor følger trinnene for å beregne budsjettet i et smidig prosjekt:

#1) Oppgi alle kravene til prosjektet og gjør estimater for dem å bruke Planning Poker, Bucket System, Fibonacci-serien osv. Alle teammedlemmene bør være enige i estimatene som er gjort for de oppførte kravene etter klar analyse og forståelse av brukerhistoriene. Estimeringer gjøres basert på funksjonene som skal implementeres i en brukerhistorie.

#to) Bestem varigheten av iterasjonene kalt Sprints og produktforsinkelseselementer som er tilordnet den. Det er vanligvis 2 til 3 uker lang. Brukerhistoriene blir valgt i en sekvens som begynner med brukerhistorien med maksimal prioritet, går til mindre prioritet, og med minst prioritet brukerhistorie på slutten. Dette hjelper til med å bestemme hvilke brukerhistorier som må hentes i den første Sprint og hvilke historier som kan tas opp senere.

# 3) Lag et nedbrent diagram for å gi et klart bilde av hvor mye arbeid som er igjen å gjøre mot hvor mye tid som er igjen for implementering. Det gir i utgangspunktet fremdriften for et smidig team. Det gir et klart bilde av hvordan teamet oppfører seg og hvordan det forventes å oppføre seg.

Lagets fremgang måles i form av fullførte oppgaver, gjenværende innsats, ideell nedbrenning og gjenværende oppgaver som vist nedenfor:

# 4) Legg til tilleggskostnader som kjøp av utstyr, verktøy, infrastrukturstøtte, få lisenser for programvareverktøyene som skal brukes, Project Management Tools, Antivirusinstallasjon og oppdateringer.

# 5) Legg til pre- og postterterasjonsbudsjetter. Alle smidige medlemmer skal være tverrfunksjonelle, men det er grenser for det. Alt som gjøres av et teammedlem utenfor hans kompetanse, betraktes som pre iterasjonsarbeid eller post iterasjonsarbeid. Dette pre- og postterteringsarbeidet krever ekstra budsjett for implementering.

# 6) Hold øye med de skjulte risikoene. Risikoen i Agile-prosjektet inkluderer: Risiko for at prosjektet går over budsjett, Fravær av teammedlemmer, Medlemmene har ikke klar eller fullstendig kunnskap, Medlemmene har ikke de nødvendige ferdighetene, fristene er krysset osv.

Estimeringsmaler i smidig utviklingsprosjekt

Det er mange estimeringsmaler som utarbeides på forskjellige nivåer i Agile utviklingsprosjekt. Det eneste formålet er å tydelig angi estimatene som kreves for å implementere et krav eller en vare og spore fremdriften.

Hovedmalene er som nevnt nedenfor:

1) Agile prosjektplanmal:

Det gir et høyt nivå oversikt over hvor lang tid det tar å levere funksjonene til kravene og hva som er deres status. Den nevner også personen som er ansvarlig for den spesifikke oppgaven.

(Merk: Klikk på et hvilket som helst bilde for en forstørret visning)

2) Agile utgivelsesplanmal:

Det gir utgivelsesdetaljer for oppgavene som samsvarer med kravene, sammen med status og Sprint der de må utføres.

3) Agile Product Backlog Mal:

Den beskriver den komplette varen som er definert for prosjektet. Den gir detaljer om oppgavene til Sprints sammen med status, prioritet, historiepoeng og om de er tilordnet en Sprint, eller om det er noen ekstra oppgaver som mangler etc.

4) Agile Sprint Backlog Mal:

Den gir en beskrivelse av brukerhistoriene som er nevnt i etterslaget til en bestemt Sprint. Det gir de totale historiepoengene som er tildelt en brukerhistorie, og hvordan disse deles inn i forskjellige oppgaver. Det gir også status for de tilsvarende oppgavene og hva er arbeidet som utføres daglig for de tilsvarende oppgavene.

5) Agile testplanmal:

Det bryter hele testscenariet inn i underscenarier. Det gir detaljer om underscenarier som implementeringsdato, forventet resultat, faktisk resultat, status etc.

Det nevner også prosjektnavnet, den kompatible nettleseren, versjonen av applikasjonen som testes, testsak-ID for et valgt scenario, skrevet av, testet av, beskrivelse osv.

6) Agile User Story Template:

Det gir detaljene som er spesifikke for analysen av brukerhistorien som Hva er rollene som kreves for at en spesifikk funksjonalitet skal testes, hva er forhåndskravet (miljøoppsett og koblinger aktivert) og hva er forventet utfall?

7) Agile veikartmal:

Det gir en retning til prosjektet i selskapet, på kort og lang sikt. Det hjelper med å sette forventninger i selskapet. Og oversikten over hvor prosjektet er på vei.

Stadier av estimering i smidig prosjekt

I et smidig prosjekt gjøres estimater på 3 nivåer som nevnt nedenfor:

• Prosjekt / forslag nivå: Total funksjonsstørrelse for hele applikasjonen er estimert ved hjelp av Quick Function Point Analysis (QFPA) -metoden når bare høye krav er tilgjengelig.
• Utgivelsesnivå: Historiepoeng tildeles brukerhistoriene som hjelper til med å bestemme nei. av utgivelser planlagt i et prosjekt og nr. av brukerhistorier som skal tas i en utgivelse og sprint.
• Sprintnivå: Estimerte timer tildeles oppgavene til brukerhistoriene i en sprint. Dette gjøres for å sikre engasjementet i utviklingen for å levere brukerhistorier med i en sprint.

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

# 1) Anslag om forslag eller prosjektnivå

Det er et veldig høyt nivå estimat for prosjektet. Den fokuserer på det totale antallet krav i Product Backlog-varen. Function Points brukes til å estimere størrelsen på programvaren / prosjektet før en detaljert beskrivelse av funksjonskravene blir dokumentert.

Funksjonspunkter er den allment aksepterte måten å beregne størrelsen på programvaren på. Den fokuserer på funksjonalitetene som finnes i programvareprosjektene. Et funksjonspunkt er en beregning som konverterer kravene eller brukerhistoriene til et tall.

I løpet av de første trinnene av prosjektet, anbefales det å ta i bruk Quick Function Point Analysis (QFPA) -metoden.

Quick Function Point Analysis-metoden er en unik tilnærming for å estimere FP når bare krav på høyt nivå er tilgjengelige.

Hvordan beregne total funksjonell størrelse?

• Forstå alle funksjonene til en applikasjon ved hjelp av domeneneksperter.
• Identifiser og lister opp alle mulige funksjoner i en applikasjon.
• Datalagringsfunksjoner er klassifisert i interne logiske filer (data som er lagret internt i applikasjonen) og eksterne grensesnittfiler (data som bare brukes som referanseformål).
• Transaksjonsfunksjoner er klassifisert i eksterne innganger (data som kommer fra eksterne kilder til applikasjon), eksterne utganger (avledede data går fra applikasjon til utenfor) og eksterne henvendelser (data hentet fra en eller flere eksterne innganger og eksterne utganger).
• Beregn FP-størrelse for hver funksjon ved å beregne den gjennomsnittlige kompleksiteten.
• Oppsummer FP-størrelsen på alle funksjonene for å få den totale funksjonelle størrelsen på applikasjonen.
• Minst to personer med ekspertise innen FP-analyse, bør beregne uavhengig, matche resultatene og løse forskjellene.

Eksempel for estimering av prosjektnivå:

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

• En bruker skal kunne logge inn på nettstedet ved å oppgi brukernavn og passord.
• Innlegg vellykket pålogging, en bruker skal føres til hovedsiden med høyre og venstre rute definert.
• En bruker skal ha et alternativ for å logge ut av applikasjonen.
• En gyldig bruker har muligheten til å endre passordet ved å oppgi gjeldende legitimasjon.

Teamet bruker en hurtig FP-estimering for å estimere prosjektstørrelsen.

Følgende er analysen gjort:

• Datalagringsfunksjonen her lagrer brukerlegitimasjonen for å logge på og endre passordet.
• Siden legitimasjonen er lagret innenfor applikasjonsgrensen, lagres den i ILFs (interne logiske filer).
• Transaksjonsfunksjonene inkluderer:
  • Brukerinnlogging og visning av hovedsiden.
  • Brukeravlogging og visning av utloggingsskjerm.
  • Evne til å endre passord.

Nedenfor er trinnene utført for å estimere prosjektstørrelsen ved hjelp av Quick Function Point Analysis:

TRINN # 1: Liste ned alle datafunksjonene

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

TRINN 2: Liste opp alle transaksjonsfunksjonene

hvordan du åpner .swf filen

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

TRINN # 3: Henter den estimerte prosjektstørrelsen i Funksjonspoeng

UFP = Data FP + Transaction FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (forutsatt VFP (Verdijusteringsfaktor = 1)

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

Innsats = FP / Produktivitet = 22/16 personers måned = 1,37 personers måned

# 2) Estimering av utgivelsesnivå

Estimeringer av utgivelsesnivå gjøres under planleggingen av utgivelsen. Det er neste aktivitet etter estimering av prosjektnivå. De prioriterte kravene er hentet fra Product Backlog, som er i form av brukerhistorier.

Brukerhistoriene er estimert i form av historiepoeng under utgivelsesplanleggingen, som fokuserer på å estimere størrelsen på programvaren som skal leveres for den utgivelsen. På denne måten er det ikke planlagt antall utgivelser og totalt antall historiepoeng i hver utgivelse.

Et historiepunkt representerer i utgangspunktet den relative innsatsen som kreves for å implementere en funksjon eller funksjonaliteten, sammenlignet med de andre funksjonene. Det er i utgangspunktet for å dimensjonere produktets forsinkelseselementer.

Beregning av historiepoeng gjøres på grunnlag av:

• Kompleksiteten til funksjonen som skal implementeres.
• Erfaring og tekniske ferdigheter til alle medlemmene.

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

Fremgangsmåte for tildeling av historie peker til en brukerhistorie:

• Alle teammedlemmene samles rundt et bord som går gjennom brukerhistoriene i Sprint Backlog.
• Betydningen av ett historiepunkt og tilsvarende innsats avgjøres.
• En av teammedlemmene leser opp en brukerhistorie og ber deretter teammedlemmene om å tildele de relative historiepoengene.
• Hvis det er en betydelig forskjell mellom historiepoengene som er tildelt av teammedlemmene, gir de en forklaring på historiepoengene de har tildelt, og oppnår dermed enighet på slutten.
• Prosessen gjentas 3-4 ganger til det ikke er noen stor forskjell mellom estimatene gitt av teammedlemmene.
• Dimensjonering av historier hjelper til med å bestemme hvor mange historier som blir tatt i løpet av en sprint og utgivelse.

Eksempel for estimering av utgivelsesnivå:

Dette innebærer å lage en prioritert liste over brukerhistorier kalt Product Backlog. Produkteier oppretter produktforsinkelse og gir forretningsverdi for hvert av elementene som er oppført i den.

Vi kan bruke metodene nedenfor for estimering av Story Points:

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

Estimering av de ovennevnte brukerhistoriene gjennom Fibonacci-sekvensen:

# 3) Estimering av sprintnivå

Anslag på sprintnivå gjøres under Sprintplanlegging. Produktetterslepsposter med høyest prioritet tas og deles inn i forskjellige oppgaver som detaljering, design, analyse, utvikling, oppretting av testtilfeller, utføring av testtilfeller, testing av brukeraksept etc.

Oppgaver blir estimert i form av estimerte timer, dvs. tiden det tar å fullføre oppgaven for en tilsvarende brukerhistorie. Bunn-opp-tilnærmingen brukes til oppgavestimeringene der forretningskravene er delt inn i aktiviteter på lavt nivå, og hver aktivitet tildeles estimerte timer.

Formålet med estimeringene er å vite hvor mange brukerhistorier, utviklingsteamet kan forplikte seg til en Sprint. Utviklingen må være komfortabel med forpliktelsen, og produkteierne må være sikre på at teamet vil oppfylle forpliktelsen.

S teps for å tildele estimerte timer til oppgavene:

• Teammedlemmer plukker opp brukerhistoriene. Deretter blir de bedt om å estimere den faktiske innsatsen, i form av timer eller dager, for oppgavene som tilsvarer brukerhistorien.
• Hvis det er uenighet i disse estimatene blant teammedlemmene, så diskuterer de det og kommer til enighet.
• Hvis en oppgave er mer enn seks timer, blir den delt inn i mindre oppgaver.
• Hvis det er to eller flere oppgaver med estimerte timer mindre enn to, kombineres de for å danne en ny oppgave.

Eksempel på estimering av sprintnivå:

Det er to deler av Sprint Planning-møtet:

• Første del: Fokus er på å avklare kravene til brukerhistorier, valgt fra Product Backlog.
• Andre del: Fokus er å dele opp kravene i oppgaver og estimere timene som kreves for å fullføre dem. Alle oppgavene som er nødvendige for å gjøre Product Backlog-varen leverbar, bør være inkludert. Oppgavene skal være små. Ideelt sett bør en oppgave ikke vare mer enn seks timer.

Konklusjon

Beregningene i Agile-prosjektet spiller en viktig rolle for å sikre riktig retning, planlegging og ledelse. Det gir trinn for hvordan du skal ta opp prosjektet i fremtiden.

Teknikkene for å estimere historiepoeng som Planning poker, Bucket System etc. bruker kort eller prikker som har verdier eller tall trykt på, og tilordner deretter disse nr. til brukerhistoriene for estimering av relativ størrelse.

Det eneste formålet er å sette varene i en prioritert rekkefølge fra maksimal prioritet til minimum prioritet. De relative størrelsene som er estimert for produktets forsinkelseselementer, hjelper til med å estimere eller beregne budsjettet som kreves for prosjektet.

Håper du ville ha fått et godt innblikk i Estimations of Agile Projects. Uttrykk gjerne tankene dine om denne opplæringen i kommentarfeltet nedenfor.

Anbefalt lesing

• Hvordan gjøre smidig estimeringsprosess enkel med planlegging av poker
• Agile Vs Waterfall: Hvilken er den beste metoden for prosjektet ditt?
• Estimeringsteknikker for programvaretest (komplett testguide)
• VersionOne-veiledning: Alt-i-ett Agile Project Management Tool Guide
• Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in for JIRA (Review)
• TOPP 10 Beste smidige prosjektledelsesverktøy i 2021
• Grunnarbeid for en vellykket smidig reise: Hvordan velge riktig metode, verktøy og teknikker
• 4 trinn mot utvikling av Agile Testing Mindset for vellykket overgang til smidig prosess