agile methodology beginner s guide agile method
En komplett guide til smidig metodikk: (20+ detaljerte veiledninger i Agile Scrum Methodology)
Dette er guiden for programvareutviklere og testere for å forstå og begynne å jobbe med de veldig berømte Agile SCRUM-metodikk for programvareutvikling og testing . Lær de grunnleggende, men viktige terminologiene som brukes i Agile Scrum-prosessen, sammen med et reelt eksempel på hele prosessen.
Vi har listet opp alle Agile Tutorials i denne serien for din bekvemmelighet. Håper de vil være til stor hjelp for deg.
Emner som dekkes: Hva er Agile, Hva er Scrum, Agile Methodology i programvareutvikling og testing, Agile Testing, Agile Scrum Process, Scrum Methodology med Scrum Team og Scrum Master.
Hva du vil lære:
Agile Methodology Tutorials List
Opplæring # 1: Agile Scrum-metoder (Denne opplæringen)
Opplæring nr. 2: Agile manifest
Opplæring # 3: Scrum Team og deres roller og ansvar
Opplæring # 4: Scrum-gjenstander
Opplæring # 5: Scrum-hendelser
Opplæring # 6: Defect Triaging In Scrum
Opplæring # 7: Selvforsynte Scrum Teams
Opplæring # 8: Tre Amigo-prinsipp
Opplæring 9: SAFe - Skalert smidig ramme
Opplæring # 10: Agile Scrum Quiz
MER Anbefalte Agile Scrum Tutorials:
Opplæring # 11: Topp smidige estimeringsteknikker
Opplæring # 12: Agile Waterfall Hybrid Model
Opplæring # 13: Kanban vs Scrum vs Agile
Opplæring # 14: JIRA Agile Tutorial
Opplæring # 15: Agile Retrospective Meetings
Opplæring nr. 16: Rollen for forretningsanalytikere i SCRUM
Opplæring nr. 17: QAs rolle i Scrum
Verktøy og intervjuspørsmål:
Opplæring # 18: Agile testverktøy
Opplæring # 19: Beste smidige prosjektledelsesverktøy
Opplæring nr. 20: Topp smidige intervjuspørsmål
Opplæring # 21: Topp Scrum intervju spørsmål
La oss starte med den første veiledningen i serien - Agile Scrum Introduction.
Introduksjon til smidig utvikling
Agile i programvareutvikling:
Agile er et av verdens mest brukte og anerkjente rammeverk for programvareutvikling.
De fleste av organisasjonene har adoptert det i en eller annen form, men det er fortsatt en lang vei å gå i løpet av deres adopsjonsprogrammer. Det eneste målet med denne serien av opplæringsprogrammer er å få ombord teknologi og fagfolk som ikke er teknologier inn i Agile World.
Vi tar deg gjennom den smidige reisen trinnvis til du forstår filosofien bak å bruke Agile, fordelene og hvordan du praktiserer den. Denne serien tar sikte på å utstyre og gjøre det mulig for leserne å bruke Agile og Scrum-læring i sitt arbeid.
Denne spesielle opplæringen er dedikert til å forklare deg hvorfor det var behov for Agile og hvordan den ble opprettet. Det grunnleggende her er å få deg til å forstå konseptet Agile Adoption i Software Development Industries.
Agile historie
Agile ble født da en person med 17 ulike utviklingsmetodikkbakgrunner en god dag kom sammen for å brainstorme om det var en mulig alternativ løsning for programvareutvikling som kunne føre til raskere utviklingstid og var mindre dokumentasjonstung.
På den tiden skjedde programvareutvikling så lenge at prosjektene var klare til å bli levert, hadde virksomheten gått videre og kravene hadde endret seg. Dermed var et prosjekt ikke i stand til å møte forretningsbehovet selv om det var i stand til å oppfylle de definerte målene.
Dermed kom disse forkjemperne for forskjellige teknikker for programvareteknikk sammen, og sluttresultatet av møtet deres var det de kalte 'det smidige manifestet' som vi vil diskutere i detalj i neste opplæring i denne serien.
Men den smidige som ble født den dagen er ikke det vi ser i dag i organisasjoner. Metodikken ekspertene ble enige om ble beskrevet som 'lett' og rask. Men den viktigste gevinsten av dette møtet var tanken på at raskere levering av et produkt og konstant tilbakemelding var nøklene for å oppnå suksess innen programvareutvikling.
De eksisterende fossefunsteknikkene var for tungvint og hadde ingen tilbakemeldinger før det endelige produktet var klart til levering. Dette betydde at det ikke var noe rom for kurskorrigering, og kunden hadde ikke noe syn på fremdriften før hele produktet var klart. Og det var det disse ekspertene ønsket å unngå.
De ønsket en løsning som ville ha rom for konstant tilbakemelding for å unngå kostnadene ved omarbeid på et senere tidspunkt.
Agile utfordringer
De eksisterende fosseteknikkene på den tiden var for tungvint og hadde ingen tilbakemeldinger før det endelige produktet var klart til levering. Det ble kalt en fossmodell for utvikling fordi lagene først fullførte ett trinn helt, og først etter det gikk de videre til neste trinn.
Dette betydde at det ikke var noe rom for kurskorrigering, og kunden hadde ikke noe syn på fremdriften før hele produktet var klart. Og det var det disse ekspertene ønsket å unngå. De ønsket en løsning som ville ha rom for konstant tilbakemelding for å unngå kostnadene ved omarbeid på et senere tidspunkt.
Og det er derfor smidig handler også om å være adaptiv og kontinuerlig forbedring, like mye som det handler om konstant tilbakemelding og leveringshastighet.
Hva er smidige løfter?
Agile handler ikke bare om å anvende den vanlige fremgangsmåten i utvikling av programvare. Det bringer også inn en endring i teamets tankesett som driver dem til å bygge bedre programvare, samarbeide og til slutt gi dem en lykkelig kunde.
Agile verdier og prinsipper gjør at teamet kan skifte fokus og endre tankeprosessen for å bygge bedre programvare.
Hva er smidig?
Agile er ikke et sett med regler. Agile er ikke et sett med retningslinjer. Agile er ikke en gang en metodikk. Snarere er Agile et sett med prinsipper som oppmuntrer til fleksibilitet, tilpasningsevne, kommunikasjon og arbeidsprogramvare over planer og prosesser. Det er veldig kortfattet fanget i det som kalles det smidige manifestet.
Agil programvareutvikling gjør at teamet kan samarbeide mer effektivt og effektivt om å utvikle komplekse prosjekter. Den består av praksis som utøver iterative og inkrementelle teknikker som lett blir vedtatt og viser gode resultater.
Når vi bruker Agile til handling, har vi forskjellige Agile-baserte metoder og metoder. Disse metodene og metodene dekker alle behovene til en programvareutviklingsindustri, helt fra programvaredesign og arkitektur, utvikling og testing til prosjektledelse og leveranser.
Ikke bare det, Agile metoder og metoder åpner også rom for prosessforbedring som en integrert del av hver levering.
Agile er en programvareutviklingsmetode der et selvforsynt og tverrfunksjonelt team jobber med å levere kontinuerlige leveranser gjennom iterasjoner og utvikler seg gjennom hele prosessen ved å samle tilbakemeldinger fra sluttbrukerne.
Hvordan trene smidig?
Det er forskjellige smidige metoder som er i praksis i forskjellige diversifiserte bransjer.
Imidlertid er de mest populære metodene blant dem alle:
- Scrum
- Kanban
- Ekstrem programmering
Alle disse metodene fokuserer på lean programvareutvikling og hjelper til med å bygge bedre programvare effektivt og effektivt.
Alt med Agile Introduction. Delen er strukturert for å hjelpe deg med å forstå kjerneverdiene og prinsippene som skal vedtas for at et team skal jobbe i en smidig modus og tankesett.
Agile Metodikk
Introduksjon til smidige modeller:
webtjenester testing intervju spørsmål og svar
Som vi alle vet, er Agile en programvareutviklingsmetode.
Vi har også lært om verdiene og prinsippene som ble nevnt i det smidige manifestet av grunnleggerne av smidige. I de første diskusjonene kjente vi også til forskjellene mellom smidige og de tradisjonelle fossemodellene.
I denne veiledningen vil vi bli kjent med fordelene og ulempene med den smidige metoden.
Vi får se hva som er scrum? og hvordan er det forskjellig fra smidig. Deretter vil vi forstå de forskjellige smidige metodikkene som brukes av forskjellige organisasjoner, og hvordan kan vi implementere smidige ved å bruke dem.
Du vil også kunne forstå forskjellen og fordelene / ulempene med disse metodene.
Fordeler med smidig metodikk
Nedenfor er de forskjellige fordelene med Agile Methodology:
- Kundene ser kontinuerlig på prosjektfremdriften på slutten av hver iterasjon / sprint.
- Hver sprint gir kunden en fungerende programvare som oppfyller deres forventninger i henhold til definisjonen av gjort levert av dem.
- Utviklingsteamene er ganske lydhøre overfor skiftende krav og kan imøtekomme endringer selv i de avanserte utviklingsstadiene.
- Det er konstant toveiskommunikasjon som holder kundene involvert, og dermed har alle interessenter - forretningsmessige og tekniske - klar synlighet på prosjektets fremdrift.
- Produktets design er effektiv og oppfyller forretningskravene.
Ulemper ved smidig metodikk
Selv om det er flere fordeler med Agile metodikk, er det også visse ulemper involvert i den.
De er:
#1) Omfattende dokumentasjon foretrekkes ikke, noe som kan føre til at smidige team tolker dette feil, ettersom smidig ikke krever dokumentasjon. Så taperingen går tapt på dokumentasjonen. Dette bør unngås ved kontinuerlig å spørre deg selv om dette er tilstrekkelig informasjon for å fortsette eller ikke.
#to) Noen ganger, i begynnelsen av prosjektene, er kravene ikke krystallklare. Teamene kan fortsette og finne ut at kundenes visjon ble justert på nytt, og i slike situasjoner må teamene innlemme mange endringer, og det er vanskelig å måle sluttresultatet også.
Typer av smidige metoder
Det er flere smidige metoder i praksis over hele verden. Vi skal lære mer detaljert om fire av de mest populære.
# 1) Scrum
Scrum kan lett betraktes som det mest populære smidige rammeverket. Begrepet 'scrum' er mye ansett synonymt med 'smidig' av de fleste utøvere. Men det er en misforståelse. Scrum er bare en av rammene som du kan implementere smidig på.
Ordet scrum kommer fra sportsrugby. Der spillerne kremmer seg sammen i en sammenlåst posisjon og skyver mot motstanderne. Hver spiller har en definert rolle i sin posisjon og kan spille både støtende og defensiv i henhold til situasjonens krav.
På samme måte tror scrum i IT på bemyndigede selvstyrte utviklingsteam med tre spesifikke og klart definerte roller. Disse rollene inkluderer - Produkteier (PO), Scrum Master (SM) og utviklingsteamet som består av programmerere og testere . De jobber sammen i iterative tidsbokser som kalles sprints.
Det første trinnet er opprettelsen av produktforsinkelsen av PO. Det er en oppgaveliste over ting som skal gjøres av scrumteamet. Deretter velger scrum-teamet de topprioriterte elementene og prøver å fullføre dem innen tidsboksen som kalles en sprint.
En enklere måte å huske alt dette på er å huske 3-3-5-rammeverket. Det betyr at et scrumprosjekt har 3 roller, 3 gjenstander og 5 arrangementer.
Disse er -
Roller: PO, Scrum master og utviklingsteam.
Gjenstander: Produktet etterslep, Sprint etterslepetogProduktøkning.
Arrangementer: Sprint, Sprint planlegging, Daily Scrum, Sprint anmeldelse og Sprint retrospektiv.
Vi vil bli kjent mer detaljert om hver av disse i de påfølgende veiledningene.
# 2) Kanban
Kanban er et japansk begrep som betyr et kort. Disse kortene inneholder detaljer om arbeidet som skal gjøres med programvaren. Hensikten er visualisering. Hvert teammedlem er klar over arbeidet som skal utføres gjennom disse visuelle hjelpemidlene.
Lag bruker disse Kanban-kortene for kontinuerlig levering. Akkurat som Scrum, er Kanban også for å hjelpe lagene til å jobbe effektivt og fremme selvstyrte og samarbeidende team.
Men det er også forskjeller mellom disse to - som under en scrumsprint, blir elementene som blir jobbet med av et team løst, og vi kan ikke legge til elementer i sprinten, mens vi i Kanban kan legge til elementer hvis det er ledig kapasitet. Dette er spesielt nyttig når kravene endres ofte.
Tilsvarende er en annen forskjell at mens scrum har definerte roller til en PO, scrum master og utviklingsteam, er det ingen slike forhåndsdefinerte roller i Kanban.
En annen forskjell er at mens scrum foreslår en prioritering av produktetterslep, har Kanban ikke noe slikt krav, og det er helt valgfritt. Dermed krever Kanban mindre organisering og unngår ikke-verdiskapende aktiviteter og er egnet for prosesser som krever respons mot endringer.
# 3) Lean
Lean er en filosofi som fokuserer på reduksjon av avfall. Hvordan gjør det det?
I lean deler du en prosess i verdiskapende aktiviteter, aktiviteter som ikke gir verdi og viktige aktiviteter som ikke gir verdi. Enhver aktivitet som kan klassifiseres som en ikke-verdiskapende aktivitet er avfall, og vi bør prøve å fjerne det svinnet i prosessen for å gjøre det slankere.
En slankere prosess betyr raskere levering og mindre sløseri med oppgaver som ikke hjelper til å nå lagets mål. Dette bidrar til å optimalisere hvert trinn i programvareutviklingssyklusen. Derfor ble lean-prinsippene tilpasset fra lean-produksjon til programvareutvikling.
Lean programvareutvikling kan brukes i ethvert IT-prosjekt ved å bruke de syv lean-prinsippene som er vist nedenfor:
Disse er ganske selvforklarende som navnene tilsier. Å eliminere svinn er det første og viktigste lean-prinsippet, og vi så hvordan vi gjør det, vi klassifiserer bare aktiviteter som verdi og ikke-verdiøkning.
En ikke-verdiøkende aktivitet kan være en hvilken som helst del av koden som kan gjøre den mindre robust, øke innsatsen og ta mye tid uten å tilføre forsvarlig forretningsverdi. Det kan også være vage brukerhistorier eller dårlig testing eller legge til funksjoner som ikke er påkrevd i det store bildet.
Det andre prinsippet om å forsterke læring er igjen lett å forstå da et team trenger ulike ferdigheter for å levere produkter i et raskt skiftende miljø med ny teknologi som dukker opp i raske varigheter.
Å ta sene beslutninger kan være givende i omstendigheter der det reduserer omarbeid, som om det er forventede endringer, så utsett det bedre, slik at teamet ikke trenger å gjøre om arbeidet ettersom virksomhetens behov endres.
Men det er alltid en kompromiss her da lagene må balansere dette med det fjerde prinsippet om å levere raskere. Forsinkelse av beslutninger bør ikke påvirke den samlede leveransen og må ikke redusere tempoet i arbeidet. Det ene øyet skal alltid være på hele bildet.
Å ha bemyndigede lag er også veldig vanlig i dag, og dette er noe som selv smidig antyder. Bemyndigede team er mer ansvarlige og kan ta beslutninger raskere. Følelsen av eierskap i et bemyndiget team fører til bedre resultater. For å styrke et team, bør de få lov til å organisere seg selv og ta avgjørelser på egenhånd.
Dermed ser vi at magert og smidig har mye til felles med en sterk forskjell - mens magre team kan hjelpe til med å avgrense et produkt, er smidige team de som faktisk bygger produktet.
# 4) Ekstrem programmering (XP)
Ekstrem programmering er en annen mest populær smidig teknikk. I følge extremeprogramming.org ble det første XP-prosjektet startet 6. mars 1996. De nevner også at XP påvirker programvareprosjektutvikling på 5 forskjellige måter - kommunikasjon, enkelhet, tilbakemelding, respekt og mot. Disse kalles verdiene til XP.
Av disse starter alt med kommunikasjon. XP-team samarbeider med forretningsteam og andre programmerere med jevne mellomrom og begynner å bygge kode fra den aller første dagen. Fokus her er ansikt til ansikt kommunikasjon så langt som mulig ved hjelp av de andre visuelle hjelpemidlene.
Ekstreme programmerere bygger også en enkel kode og begynner å få tilbakemelding på den fra selve den første dagen. Fokuset er å ikke gå overbord eller forutsi krav som ikke er delt. Dette holder designet enkelt og produserer akkurat det minimumsproduktet som tilfredsstiller kravene.
Tilbakemelding hjelper teamet til å forbedre og produsere en bedre kvalitet på arbeidet. Dette hjelper dem å bygge respekt for hverandre når de lærer av hverandre og lærer hvordan de kan dele sine synspunkter.
Dette gir dem også mot fordi de vet at de har samlet alles beste ideer og produsert et godt produkt med tilbakemelding fra andre. Dermed er de heller ikke redd for å inkludere endringer eller motta ytterligere tilbakemeldinger på sitt arbeid.
Dette er spesielt nyttig i prosjekter der kravene ofte vil endres. Konstant tilbakemelding vil hjelpe lagene å inkludere disse endringene med mot.
Dermed har vi sett de forskjellige smidige metodikkene som Scrum, XP, Kanban og Lean sammen med deres respektive fordeler og ulemper.
Nå kan vi enkelt skille mellom dem og også sette pris på de subtilere forskjellene mellom dem. Vi lærte også grunnleggende om hver av disse metodene og så hvordan vi kan bruke dem i prosjektene våre når og når det er nødvendig.
I neste del, la oss forstå alt om Scrum.
Scrummetodikk
SCRUM er en prosess innen smidig metodikk som er en kombinasjon av den Iterative modellen og den inkrementelle modellen.
Et av de største handicapene til det tradisjonelle Fossmodell var at - før den første fasen er fullført, flytter ikke søknaden til den andre fasen. Og ved en tilfeldighet, hvis det er noen endringer i det senere stadiet av syklusen, blir det veldig utfordrende å implementere disse endringene, da det vil innebære å revidere de tidligere fasene og gjøre om endringene.
Noen av nøkkelegenskapene til SCRUM inkluderer:
- Selvorganisert og fokusert team.
- Ingen store krav dokumenter, snarere har en veldig presis og til poenget historier.
- De tverrfunksjonelle teamene jobber sammen som en enkelt enhet.
- Tett kommunikasjon med brukerrepresentanten for å forstå funksjonene.
- Har en bestemt tidslinje på maksimalt en måned.
- I stedet for å gjøre hele 'tingen' om gangen, gjør Scrum litt av alt med et gitt intervall.
- Ressursevne og tilgjengelighet vurderes før du begår noe.
For å forstå denne metoden godt, er det viktig å forstå de viktigste terminologiene i SCRUM.
Les også => Hvordan levere høyverdige programvarefunksjoner på kort tid ved hjelp av Agile Scrum Process
Viktige SCRUM-terminologier
1) Scrum Team
Scrum-teamet er et team bestående av 7 med + eller - to medlemmer. Disse medlemmene er en blanding av kompetanse og består av utviklere, testere, databasefolk, supportpersoner etc. sammen med produkteieren og en scrummaster.
Alle disse medlemmene jobber i tett samarbeid for et rekursivt og bestemt intervall, for å utvikle og implementere nevnte funksjoner. SCRUM-lags sittearrangement spiller en veldig viktig rolle i deres samspill, de sitter aldri i avlukke eller hytter, men et stort bord.
2) Sprint
Sprint er et forhåndsdefinert intervall eller tidsramme der arbeidet må fullføres og gjøre det klart for gjennomgang eller klart for distribusjon av produksjonen. Denne tidsboksen ligger vanligvis mellom 2 uker og 1 måned.
enhetstesting integrasjonstesting systemtesting
I vårt daglige liv når vi sier at vi følger en-måneders sprint-syklus, betyr det ganske enkelt at vi jobber i en måned med oppgavene og gjør den klar for gjennomgang innen slutten av den måneden.
3) Produkteier
Produkteieren er den viktigste interessenten eller hovedbrukeren av applikasjonen som skal utvikles. Produkteieren er den personen som representerer kundesiden. Han / hun har den endelige autoriteten og bør alltid være tilgjengelig for teamet.
Han / hun skal være tilgjengelig når noen er i tvil som trenger avklaring. Det er viktig for produkteieren å forstå og ikke tildele noe nytt krav midt i sprinten eller når sprinten allerede har startet.
4) Scrum Master
Scrum Master er tilrettelegger for scrumteamet. Han / hun sørger for at scrumteamet er produktivt og progressivt. I tilfelle noen hindringer følger scrummaster opp og løser dem for teamet. SCRUM Master er megler mellom PO og teamet.
Han / hun holder PO informert om fremdriften i Sprint. Hvis det er noen sperringer eller bekymringer for teamet, diskuterer du med PO og får dem løst. I likhet med lagets Daily Standup, skjer en standup av SCRUM Master med PO hver dag.
Anbefalt lesing => Hvordan være et godt team mentor, coach og en ekte team-forsvarer i en smidig testverden?
5) Forretningsanalytiker (BA)
En forretningsanalytiker spiller en veldig viktig rolle i SCRUM. Denne personen er ansvarlig for å få kravet ferdig og utarbeidet i kravdokumentene (basert på hvilke brukerhistoriene er opprettet).
Hvis det er noen uklarheter i brukerhistoriene / akseptakriteriene, er han / hun den som blir kontaktet av det tekniske (SCRUM) teamet, og han tar det deretter opp til PO ellers hvis mulig løser seg selv. I store prosjekter kan det være mer enn 1 BA, men i småskala prosjekter kan SCRUM Master også fungere som BA.
Det er alltid en god praksis å ha en BA når prosjekt sparket starter.
6) Brukerhistorie
Brukerhistorier er bare kravene eller funksjonen som må implementeres.
I scrum har vi ikke de enorme kravdokumentene, men kravene er definert i et enkelt avsnitt, vanligvis med formatet som:
Som en
Jeg vil
Å oppnå
For eksempel :
Som administrator vil jeg ha en passordlås i tilfelle brukeren skriver inn feil passord i tre påfølgende ganger for å begrense uautorisert tilgang.
Det er noen kjennetegn ved brukerhistorier som bør følges. Brukerhistoriene skal være korte, realistiske, kunne estimeres, fullstendige, omsettelige og testbare. En brukerhistorie blir aldri endret eller endret midt i Sprint.
Det er ansvaret for SCRUM Master og BA (hvis aktuelt) å sørge for at PO har utarbeidet brukerhistoriene riktig med et riktig sett av akseptkriteriene ”. Hvis det skal gjøres endringer som vil påvirke sprintutgivelsen, trekkes slike historier ut av sprinten, eller gjøres i henhold til tilgjengelige timer.
Hver brukerhistorie har et akseptkriterium som skal være godt definert og forstått av teamet.
Akseptkriterier beskriver brukerhistorien som inneholder støttedokumentene. Det hjelper med å avgrense brukerhistorien ytterligere. Alle fra teamet kan skrive ned akseptkriteriene. Testteam baserer sine testtilfeller / betingelser på disse akseptkriteriene.
7) Epics
Epics er utvetydige brukerhistorier, eller vi kan si at dette er brukerhistoriene som ikke er definert og oppbevares for fremtidige sprints.
Bare prøv å relatere det med livet, forestill deg at du skal på ferie. Når du skal neste uke, har du alt på plass som hotellbestillinger, sightseeing, reisesjekk osv. Men hva med ferieplanen din for neste år? Du har bare en vag ide om at du kan gå til XYZ-sted, men du har ingen detaljert plan.
Et epos er akkurat som deg neste års ferieplan, hvor du bare vet at du kanskje vil dra, men hvor, når, med hvem, alle disse detaljene du ikke aner på dette tidspunktet.
På samme måte er det funksjoner som kreves implementert i fremtiden hvis detaljer ennå ikke er kjent. For det meste begynner en funksjon med en Epic og blir deretter brutt ned til historier som kan implementeres.
8) Produktet etterslep
Produktet etterslep er en slags bøtte eller kilde der alle brukerhistoriene oppbevares. Dette vedlikeholdes av produkteieren. Produktet etterslep kan forestilles som en ønskeliste for produkteieren som prioriterer det i henhold til virksomhetens behov.
Under planleggingsmøtet (se neste avsnitt) blir en brukerhistorie hentet fra produktetterslepet, så gjør teamet brainstorming, forstår det og finjusterer det og bestemmer samlet hvilke brukerhistorier de skal ta, med inngripen fra produkteieren.
9) Sprintforsinkelse
Basert på prioriteten, blir brukerhistorier hentet fra Product Backlog som en om gangen. Scrum-teamet brainstormer om det, bestemmer muligheten og bestemmer historiene for å jobbe med en bestemt sprint. Den kollektive listen over alle brukerhistoriene som scrumteamet jobber med en bestemt sprint er kjent som Sprint-etterslep.
10) Historiepoeng
Historiepoeng er en kvantitativ indikasjon på kompleksiteten i en brukerhistorie. Basert på historiens poeng bestemmes estimering og innsats for en historie.
Et historiepoeng er relativt og ikke absolutt. For å være sikker på at estimatet og innsatsen er riktig, er det viktig å sjekke at brukerhistoriene ikke er store. Jo mer presis og mindre brukerhistorien er, desto mer nøyaktig blir estimeringen.
Hver brukerhistorie tildeles et historiepunkt basert på Fibonacci-serien (1, 2, 3, 5, 8, 13 og 21). Høyere er tallet, komplekset er historien.
For å være presis
- Hvis du gir 1/2/3 historiepoeng, betyr det at historien er liten og med lav kompleksitet.
- Hvis du gir poeng som 5/8, er det et middels kompleks og
- 13 og 21 er svært komplekse.
Her består kompleksiteten av både utvikling pluss testing.
For å bestemme et historiepunkt, skjer idédugnad innen scrum-teamet, og teamet bestemmer samlet et historiepunkt.
Det kan hende at utviklingsteamet gir en historiepoeng på 3 til en bestemt historie, for for dem kan det være 3 linjer med kodeendring, men testteamet gir 8 historiepoeng fordi de føler at denne kodeendringen vil påvirke større moduler så testinnsatsen ville være større. Uansett hvilket historiepunkt du gir, må du begrunne det.
Så i denne situasjonen skjer brainstorming, og teamet samtykker samlet til ett historiepunkt.
Når du bestemmer deg for et historiepunkt, må du huske faktorene nedenfor:
- Avhengigheten av historien med annen applikasjon / modul.
- Ressursens ferdighetssett.
- Historiens kompleksitet.
- Historisk læring.
- Akseptkriterier for brukerhistorien.
Hvis du ikke er klar over en bestemt historie, må du ikke endre størrelsen på den.
Når en historie er = eller> 8 poeng, blir den delt inn i 2 eller flere historier.
11) Brenn ned diagrammet
Nedbrent diagram er en graf som viser den estimerte v / s faktiske innsatsen til scrum-oppgavene.
Det er en sporingsmekanisme der daglige oppgaver spores for en bestemt sprint for å sjekke om historiene utvikler seg mot fullføring av de forpliktede historiepoengene eller ikke.
Eksempel : For å forstå dette, sjekk figuren nedenfor:
Jeg antok:
- 2 ukers sprint (10 dager)
- 2 ressurser som faktisk jobber med sprinten.
'Historie' -> Denne kolonnen viser brukerhistoriene tatt for sprinten.
'Oppgave' -> Denne kolonnen viser listen over oppgaven som er knyttet til brukerhistorien.
'Innsats' -> Denne kolonnen viser innsatsen. Nå er dette tiltaket den totale innsatsen for å fullføre oppgaven. Det skildrer ikke innsatsen fra et bestemt individ.
“Dag 1 - dag 10” -> Denne kolonnen (e) viser timene som er igjen for å fullføre historien. Vennligst se at timen IKKE er den timen som allerede er gjort MEN timene som fortsatt er igjen.
“Anslått innsats” -> Er den totale innsatsen. For “Start” er det ganske enkelt summen av hele den enkelte oppgaven: SUM (C5: C15)
Totalt antall anstrengelser som må fullføres på 1 dag er 70/10 = 7. Så på slutten av dag 1, bør innsatsen reduseres til 70 - 7 = 63. På samme måte beregnes det for alle dager til dag 10, når den anslåtte innsatsen skal være 0 (rad 16)
“Faktisk innsats igjen” -> Som navnet antyder, er innsatsen faktisk igjen for å fullføre historien. Det kan også hende at den faktiske innsatsen øker eller avtar enn den estimerte.
Du kan bruke de innebygde funksjonene og kartet i Excel for å lage dette nedbruddskartet.
Nedbrent trinn vil være:
- Skriv inn alle historiene (Kolonne A5 - A15).
- Skriv inn alle oppgavene (Kolonne B5 - B15).
- Angi dagene (dag 1 - dag 10).
- Gå inn i startinnsatsen (Sum oppgavene C5 - C15).
- Bruk formelen for å beregne “Anslått innsats” for hver dag (dag 1 til dag 10). Skriv inn formelen på D15 (C16- $ C $ 16/10) og dra den i alle dager.
- For hver dag, skriv inn den faktiske innsatsen. Skriv inn formelen på D17 (SUM (D5: D15)) for å oppsummere den faktiske innsatsen som er igjen, og dra den i alle de andre dagene.
- Velg det og opprett diagrammet som følger:
12) Hastighet
Det totale antall historiepoeng som et scrumlag arkiverer i en sprint, kalles Velocity. Scrum-teamet blir bedømt eller referert til av hastigheten. Når det er sagt, bør det huskes at målet her IKKE er å oppnå maksimale historiepoeng, men å ha en kvalitet som kan leveres, med respekt for scrumlagets komfortnivå.
For eksempel : For en bestemt sprint: det totale antallet brukerhistorier er 8 som har historiepoeng som vist nedenfor.
Så her vil hastigheten være summen av historien poeng = 30
Definisjon av Done:
En Sprint er merket som Ferdig når alle historiene er fullført, alle dev, research, QA-oppgaver er merket 'Fullført', alle feil er fikset-lukket ellers de som kan gjøres senere (som ikke helt relaterte eller er mindre viktige) blir trukket ut og lagt til i etterslaget, er kodegjennomgang og enhetstesting fullført, de estimerte timene har oppfylt de faktiske timene som er lagt opp i oppgavene, og viktigst av alt er det gitt en vellykket demo til PO og interessentene.
Aktiviteter utført i SCRUM Methodology
# 1) Planleggingsmøte
Et planleggingsmøte er utgangspunktet for Sprint. Det er møtet der hele scrumteamet samles, SCRUM Master velger en brukerhistorie basert på prioriteten fra produktetterslepet og teamet brainstorms på det.
Basert på diskusjonen bestemmer scrumteamet kompleksiteten i historien og størrelser den i henhold til Fibonacci-serien. Teamet identifiserer oppgavene sammen med innsatsen (i timer) som vil bli gjort for å fullføre implementeringen av brukerhistorien.
Mange ganger innledes planmøtet med et ”Pre-Planning-møte”. Det er akkurat som lekser som scrumteamet gjør før de sitter på det formelle planleggingsmøtet. Teamet prøver å skrive ned avhengighetene eller andre faktorer som de ønsker å diskutere i planleggingsmøtet.
# 2) Utførelse av sprintoppgaver
Som navnet antyder, er dette det faktiske arbeidet som gjøres av scrumteamet for å utføre oppgaven og ta brukerhistorien til 'Ferdig' -tilstand.
# 3) Daglig standup
I løpet av sprintsyklusen møtes scrumteamet i ikke mer enn 15 minutter (kan være en stand-up call, anbefalt å ha i begynnelsen av dagen) og oppgi 3 poeng:
- Hva gjorde teammedlemmet i går?
- Hva planla teammedlemmet å gjøre i dag?
- Noen hindringer (veisperringer)?
Det er Scrum-mesteren som legger til rette for dette møtet. I tilfelle et teammedlem står overfor noen form for vanskeligheter, følger scrummesteren opp for å få det løst. I Stand ups blir styret også gjennomgått og viser i seg selv fremdriften i teamet.
# 4) Gjennomgangsmøte
På slutten av hver sprintsyklus møtes SCRUM-teamet igjen og demonstrerer de implementerte brukerhistoriene til produkteieren. Produkteieren kan kryssverifisere historiene i henhold til akseptkriteriene. Det er igjen Scrum-mesterens ansvar å lede dette møtet.
Også i SCRUM-verktøyet lukkes Sprint og oppgavene merkes som ferdige.
# 5) Retrospektivt møte
Det retrospektive møtet skjer etter gjennomgangsmøtet.
SCRUM-teamet møter, diskuterer og dokumenterer følgende punkter:
- Hva gikk bra under Sprint (Best practices)?
- Hva gikk ikke bra i Sprint?
- Lærdommer
- Handlingselementer.
Scrum-teamet bør fortsette å følge den beste fremgangsmåten, ignorere “ikke beste praksis” og implementere leksjonene som ble lært under de påfølgende sprintene. Det retrospektive møtet hjelper til med å implementere den kontinuerlige forbedringen av SCRUM-prosessen.
Hvordan prosessen gjøres? Et eksempel!
Etter å ha lest om de tekniske sjargongene til SCRUM. la meg prøve å demonstrere hele prosessen med et eksempel.
Eksempel:
Trinn 1 : La oss ha et SCRUM-team på 9 personer bestående av 1 produkteier, 1 Scrum master, 2 testere, 4 utviklere og 1 DBA.
Steg 2 : Sprinten besluttes å følge en 4 ukers syklus. Så vi har en måneds sprint fra 5. juni til 4.thjuli.
Trinn 3 : Produkteieren har den prioriterte listen over brukerhistorier i produktetterslepet.
Trinn 4: Teamet bestemmer seg for å møte på 4thJuni for ”Pre Planning” -møtet.
- Produkteieren henter en historie fra produktetterslepet, beskriver den og overlater det til teamet å brainstorme den.
- Hele teamet diskuterer og kommuniserer direkte til produkteieren for å ha klart forstått brukerhistorien.
- På en lignende måte er forskjellige andre brukerhistorier tatt. Hvis det er mulig, kan teamet fortsette og størrelsen på historiene også.
Etter hele diskusjonen, går individuelle teammedlemmer tilbake til arbeidsstasjonene sine og
- Identifiser deres individuelle oppgaver for hver historie.
- Beregn nøyaktig antall timer de skal jobbe med. La oss sjekke hvordan medlemmet avslutter disse timene.
Totalt antall arbeidstimer = 9
Minus 1 time for en pause, minus 1 time for møter, minus 1 time for e-post, diskusjoner, feilsøking osv.
Så den faktiske arbeidstiden = 6.
Totalt antall virkedager i løpet av Sprint = 21 dager.
Totalt antall tilgjengelige timer = 21 * 6 = 126.
Medlemmet har permisjon i to dager = 12 timer (Dette varierer for hvert medlem, noen kan ta permisjon og noen ikke.)
Antall faktiske timer = 126 - 12 = 114 timer.
Dette betyr at medlemmet faktisk vil være tilgjengelig i 114 timer for denne sprinten. Så han vil bryte ned sin individuelle sprintoppgave på en slik måte at totalt 114 timer er nådd.
Trinn 5 : På 5thjuni møtes hele Scrum-teamet til 'Planning Meeting'.
- Den endelige dommen over brukerhistorien fra produktetterslepet er ferdig, og historien flyttes til Sprint-etterslaget.
- For hver historie erklærer hvert teammedlem sine identifiserte oppgaver, hvis nødvendig kan de diskutere disse oppgavene, endre størrelse eller endre størrelsen på den (husk Fibonacci-serien !!).
- Scrum-mesteren eller teamet legger inn sine individuelle oppgaver sammen med timene for hver historie i et verktøy.
- Etter at alle historiene er fullført, noterer Scrum master den innledende hastigheten og starter Sprint formelt.
Trinn 6 : Når Sprint har startet, basert på oppgavene som er tildelt, begynner hvert teammedlem å jobbe med disse oppgavene.
Trinn 7 : Teamet møtes daglig i 15 minutter og diskuterer 3 ting:
- Hva gjorde de i går?
- Hva de planlegger å gjøre i dag?
- Noen hindringer (veisperringer)?
Trinn 8 : Scrummesteren sporer fremdriften daglig ved hjelp av 'Burn down chart'.
Trinn 9 : I tilfelle noen hindringer følger Scrum-mesteren opp for å løse disse.
Trinn # 10 : På 4thJuli møtes teamet igjen til gjennomgangsmøtet. Et medlem demonstrerer den implementerte brukerhistorien til produkteieren.
Trinn 11 : På 5thJuli møtes teamet igjen for Retrospective, hvor de diskuterer
- Hva gikk bra?
- Hva gikk ikke bra?
- Handlingselementer.
Trinn 12 : På 6thJuli møtes teamet igjen for forhåndsplanleggingsmøte for neste sprint, og syklusen fortsetter.
SCRUM Aktivitetsverktøy
Det er flere verktøy som kan brukes mye for sporing av scrum-aktiviteter.
Noen av dem inkluderer:
I den kommende opplæringen vil vi kaste lys over Agile Manifesto, som er en forestilling som driver effektive Agile Teams.
Om forfatterne: Denne serien er skrevet av følgende STH-teammedlemmer: Shruti Shrivastava - En profesjonell Scrum Master med 9 års erfaring på tvers av BFSI, e-handel og B2B-domener. Shruti er ekspert på automatiseringstesting og ledende scrumteam.Anshul Kumar Srivastava - En resultatorientert profesjonell produktledelse og smidig utøver med 7 års erfaring på tvers av BFSI og telekom.
Anbefalt lesing
- Agile Scrum Online Quiz: Test din kunnskap om Agile Scrum
- Kanban vs Scrum vs Agile: En detaljert sammenligning for å finne forskjeller
- Hvordan levere programvareegenskaper av høy verdi på kort tid ved hjelp av Agile Scrum Process
- Agile Manifesto: Forstå smidige verdier og prinsipper
- SAFe Agile Tutorial: What is Scaled Agile Framework
- 30+ spørsmål og svar fra toppscrumintervjuer (2021 LISTE)
- Agile Vs Waterfall: Hvilken er den beste metoden for prosjektet ditt?
- Topp 31 Agile intervju spørsmål og svar