Agile And Scrum Terminology: A Glossary For Agile / Scrum Concepts

agile scrum terminology

Dette er en omfattende guide for alle viktige Agile / Scrum terminologier og er en Alt i ett ordliste over Agile og Scrum begreper:

Som vi alle vet trenger Agile ingen introduksjon. Det er et rammeverk for programvareutvikling som brukes over hele verden.

Denne artikkelen er en omfattende guide over alle de smidige / scrum-konseptene du trenger å ha på fingertuppene.

Hva du vil lære:

• Agile manifest
• Hva er Scrum?
• Pillars Of Scrum
• Scrum Team
• Roller i Scrum
• Scrum-seremonier
• Agile Estimation Basics
• Scrum-gjenstander
• Definisjon av Ferdig
• Avstandsforbedring (pleie)
• Rask sammenligning med fossen
• Produktet etterslep
• Å bygge et Scrum Team
• Konklusjon
• Anbefalt lesing

Agile manifest

Agile-metoden er basert på Agile Manifesto. For mer informasjon om manifestet, sjekk Manifest for smidig programvareutvikling .

Hovedtaket fra det smidige manifestet kan forkortes til :

• Person-til-person-kommunikasjon er effektiv for prosessbinding.
• Arbeidsproduktet er bedre enn konvensjonell trinnvis dokumentasjon.
• Innblanding av klient / bedriftseier er avgjørende, og det samme er kontinuerlige tilbakemeldingsløkker.
• Endringer er uunngåelige. Derfor bør lagene omfavne dem og ønske dem velkommen.

Du vil se at selv om den smidige prosessen kommer med disse erklæringene, gir den ikke de nøyaktige konkrete trinnene for å oppnå det. Det gir teamene full frihet og autonomi til å gjøre sitt beste.

Over tid har freestyle utviklet seg til vanlig praksis. Hvorav den mest kjente er Scrum.

La oss starte definisjonene våre med det.

Hva er Scrum?

Scrum er en utviklingsmodell utviklet av Ken Schwaber og Jeff Sutherland og har vært i bruk siden 1990-tallet.

Arbeidet er delt inn i mindre krav (historier, epos og oppgaver) og sammensveisede team bygger og leverer i små avdrag. Tilbud søkes ofte og forbedringer gjøres på produktet i form av hyppige korte utgivelser.

Pillars Of Scrum

Søylene til Scrum forklares nedenfor i detalj:

• Åpenhet : Lagene er klar over hva som skjer og er åpne for å dele og hjelpe hverandre. Kommunikasjon flyter fritt via daglig stand up og uformell person-til-person-interaksjon.
• Undersøkelse : Hyppige og religiøse inspeksjoner av arbeidet er nøkkelen til Scrums suksess. Teamene kan identifisere, diagnostisere, feilsøke, fikse og komme tilbake på sporet på en enkel og pålitelig måte.
• Tilpasning : Scrum antar ikke at det de gjør er riktig. Det er periodiske sjekkpunkter i form av Sprintplanlegging, daglig scrum, sprintanmeldelse / retrospektive møter hvor teamet får gjennomgå og tilpasse seg.

Scrum Team

Scrum-lag er vanligvis små (5-9), og de er vanligvis kryssfunksjonelle i naturen. De inkluderer en Scrum Master , utvikler, tester (det er vanlig praksis å referere til alle smidige teammedlemmer som utviklere uavhengig av arbeidsfelt).

Andre tekniske teammedlemmer og viktigst av alt produktinnehaveren eller sponsoren. Agile plasserer alle sine spill på laget sitt. Så et selvorganisert A-team er kritisk og nesten en forutsetning for en vellykket smidig implementering.

Roller i Scrum

Nedenfor er de forskjellige rollene i Scrum:

• Produkteier: En produkteier eier etterslepet. Han er ansvarlig for produktet og formen det tar. Å opprettholde etterslep av produktet, ha en samlet produktvisjon og lede teamets mål mot det er det primære ansvaret for en produkteier.
• Utviklingsteam: Utviklingsteamet har ingen begrensede roller. Det forventes at de jobber tverrfunksjonelt og velger den beste tilnærmingen for å nå målet.
• Scrum Master: Det er scrummesterens jobb å sørge for at scrum implementeres på riktig måte. Scrum-mesteren kalles også som Tjenerleder for hele laget.

Scrum-seremonier

Agile stoler på noen få vaner for å holde seg på sporet og lykkes.

Noen av dem er nevnt nedenfor:

# 1) Daglig scrummøte: Dette er et typisk kort møte på 15 minutter der hvert teammedlem snakker om følgende punkter:

• Hva ble gjort i går?
• Hva er planlagt i dag?
• Er det noen hindringer underveis?

Dette formatet på møtet er veldig effektivt for å forstå hvilket arbeid som er ferdig, hva som gjenstår og hvordan teamet kan hjelpe hverandre om nødvendig.

Scrum Master letter dette møtet, men det er ikke til fordel for Scrum Master eller et sted å samle inn statusen. Det er en mulighet for teamet til å samhandle og kose seg sammen før de går hver til sitt for å erobre dagens oppgaver.

# 2) Sprint : En Sprint er en tidsboksen iterasjon (ofte 3 uker en gang, men kan være lengre eller kortere). Dette er en repeterende prosess og kan sees på som en serie med utvikling og levering.

# 3) Sprintplanlegging: Hensikten med sprintplanlegging er å planlegge hvordan du kan gjøre et sett med produktbacklog-historier til en økning av det produktet som kan sendes.

Det generelle formatet kan være som en todelt situasjon.

• Første halvdel - Teamet velger elementene de forplikter seg til å fullføre.
• Andre halvdel - Produkteier er tilgjengelig for spørsmål.

Teamet bestemmer hvordan det skal bygges. Dermed opprettes oppgavene og tildeles tilsvarende, noe som resulterer i Sprint Backlog.

# 4) Sprint gjennomgang / demo : Etter en sprint møtes teamet og interessentene, slik at arbeidet som er fullført kan vises.

De fullførte oppgavene sammenlignes med planlagte elementer, og funksjonaliteten som ikke er implementert blir utelatt. Varigheten på dette møtet er ikke mer enn 4 timer.

# 5) Sprint Retrospective: Dette møtet tilrettelegges av Scrum Master og hele teamet inkludert PO deltar.

Teamet diskuterer den siste Sprint ved å holde prosessforbedringsideene i fokus og bestemmer hvilke endringer som kan gjøres for å gjøre neste Sprint mer produktiv.

Normalt, dette møtet tar ikke mer enn 2 timer.

=> Anbefalt lese - Agile Retrospective Meetings

Agile Estimation Basics

Nedenfor er det grunnleggende grunnlaget for smidig estimering:

Innganger

• Produktetterslep og sprintetterslep.
• Historiske data, tidligere estimater for lignende oppgaver med faktiske innsatsverdier brukt på dem.

Anslåtte deltakere

• Teammedlemmer kjent med applikasjonen.
• Teammedlemmer som forstår applikasjonens integrering med andre systemer.
• Representasjon av ulike ferdigheter som kreves for fullføring av prosjektet.
• Bygge, distribuere og QA-teamrepresentanter.

Definisjon til Epic / Feature / Idea

• Dette er store brukerhistorier, vanligvis for store til å implementeres i en enkelt iterasjon.
• Idé / episk -> Historier -> Oppgaver (Én idé kan ha flere historier. En historie kan ha flere oppgaver. Historiens omfang er begrenset til en sprint. Alle oppgaver skal lukkes for å fullføre historien)

# 1) Teknikk for estimering av historiepunkt: Story point er et tall som forteller teamet hvor kompleks historien er.

I de fleste tilfeller brukes Fibonacci-serien eller T-skjorte størrelse. Vanligvis betraktes ett historiepunkt som tilsvarer en dags arbeid for en person.

Forholdet revideres imidlertid etter hver iterasjon basert på de faktiske dataene for gjennomsnittlig tid det tar å fullføre en enhet for en oppgave.

Fremgangsmåtene inkluderer:

• Del veldig store krav i små oppgaver.
• Velg et team med minst to estimatorer, the Scrum Master , Produkteier og de andre kan delta.
• Hver estimator tildeler privat historien sine poeng for en brukerhistorie (oppgave) og publiserer det samme.
• Historiepoeng for kravet tildeles av estimatorene basert på deres tidligere kunnskap om størrelsen på en lignende oppgave.
• Det forventes at anslagene vil avvike noe.
• Hvis estimater er forskjellige, forklarer høye og lave estimatorer estimatene.
• Etter dette gjøres enda en estimeringsrunde av alle estimatorene, og følger den samme prosessen til de alle konvergerer til samme nummer.

# 2) Planlegger poker: Denne interessante og morsomme teknikken blir forklart her: Hvordan gjøre smidig estimeringsprosess enkel med planlegging av poker

Merk :Det er mange andre teknikker for smidig estimering, men disse er de to mest fremtredende.

Scrum-gjenstander

De viktigste scrumgjenstandene er Product Backlog & Sprint Backlog . Dette er de som hjelper til med å overvåke de generelle sprintmålene.

# 1) Produktetterslep:

• En bestilt liste over “krav” som vedlikeholdes for et produkt / prosjekt.
• En liste kan også inneholde feil og ikke-funksjonelle gjenstander.
• Produkteier er ansvarlig for å sette opp prioriteringer i PBL.
• Produkteier er ansvarlig for å administrere Produktet Backlog.

# 2) Sprintforsinkelse:

• Oppgaveliste (også kjent som Backlog-element) for Sprint.
• Scrum Team er ansvarlig for å vedlikeholde dem ..
• Under sprinten, lagets medlemmer forventes å oppdatere sprintforsvaret ettersom ny informasjon er tilgjengelig.
• I tilfelle hvis noen av elementene blir ufullstendige eller delvis komplette, blir disse elementene satt tilbake i Produktet etterslep.

# 3) Nedbrent diagram:

liste over falske e-postadresser du kan bruke

• Det er et offentlig vist diagram som viser det fullførte og gjenværende arbeidet i sprinten.
• Viser det faktiske arbeidet som er fullført på dagtid.
• Vedlikeholdes av Scrum Master på en daglig basis.
• Det er to typer 'Slipp nedbrente diagrammer' og 'Sprint nedbrente diagrammer'.

Definisjon av Ferdig

Definisjon av Ferdig er forskjellig for forskjellige scrum-lag. Enkelt sagt er DoD en måte å fortelle når teamet vil oppnå målet via de tilgjengelige verktøyene. Det er kontrakten mellom PO og teamet.

Gjør møtt betyr at alle historiene fra etterslepet er utviklet i henhold til interessentens krav. Historier kan være ikke-tekniske eller kan ha flere oppgaver.

Avstandsforbedring (pleie)

Etterslep forbedring er ikke en kjerneprøve for scrum, men har blitt vedtatt som en måte å håndtere kvaliteten på etterslepsposter inn i en sprint.

Det er en kontinuerlig innsats for å gjennomgå varebeskyttelseselementene og kontrollere om de er riktig prioritert og forberedt på en måte som gjør dem klare og kjørbare for lag når de går inn i sprints via sprintplanleggingsaktiviteten.

Rask sammenligning med fossen

Produktet etterslep

Når vi beveger oss oppover, blir PBI-er opprettet og de er DYPE:

• D- Detaljert nok
• ER- Emergenc er
• ER- Antatt
• P- Prioritert

Og de er mer detaljerte for teamet.

Ting som en Scrum Master bør tilpasse seg:

• Fjerne hindringer
• Legge til rette
• Mentoring og undervisning
• Coaching

Dette er oppgavene som a Scrum Master skal utføre når Scrum er nylig implementert. Men etter hvert som teamet blir vant til Scrum (blir selvorganisert) har Scrum Master en oppgave å utføre, dvs. å 'OBSERVE'.

Å bygge et Scrum Team

Mens du bygger et team, Scrum Master kunne møte følgende utfordringer - Forming, Storming, Norming and Performing.

• Å danne- Der det ikke er noen relasjoner i et team.
• Storming- Hvor grensene mellom teammedlemmene ville bli lette.
• Normering- Når det er et godt forhold etablert i teamet.
• Utfører- Dette er den siste fasen der det bare er teamarbeid.

Som vi kan se, er den siste fasen hvor teamet virkelig fungerer som en Scrum Team . Men under denne transformasjonen, hvis det er noe forstyrrelse på noe tidspunkt, så tar det teamet tilbake til begynnelsen.

Konklusjon

Vi håper denne opplæringen kort har forklart alt det viktige Agile And Scrum Terminology . Se denne veiledningsserien Komplett guide til smidig metodikk for detaljer om Agile / Scrum-konsepter.

Glad smidighet!

Anbefalt lesing

• Agile Scrum Online Quiz: Test din kunnskap om Agile Scrum
• Selvforsynte Scrum-lag: Hvordan lage et selvforsynt team?
• 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
• Agile Methodology: A Beginner's Guide To Agile Method and Scrum
• SAFe Agile Tutorial: What is Scaled Agile Framework
• Scrum Team Roller og ansvar: Scrum Master og Produkteier