agile methodology beginner s guide agile method
En komplet guide til Agile Methodology: (20+ detaljerede Agile Scrum Methodology Tutorials)
Dette er vejledningen til softwareudviklere og testere til at forstå og begynde at arbejde på det meget berømte Agil SCRUM-metode til softwareudvikling og test . Lær de grundlæggende, men vigtige terminologier, der bruges i Agile Scrum-processen sammen med et reelt eksempel på den komplette proces.
Vi har listet alle Agile tutorials i denne serie for din bekvemmelighed. Håber de vil være til enorm hjælp for dig.
Emner, der er omfattet: Hvad er Agile, Hvad er Scrum, Agile Methodology i softwareudvikling og test, Agile Testing, Agile Scrum Process, Scrum Methodology med Scrum Team og Scrum Master.
Hvad du lærer:
Agile Methodology Tutorials List
Tutorial # 1: Agile Scrum-metoder (Denne vejledning)
Tutorial # 2: Adræt manifest
Tutorial # 3: Scrum Team & deres roller og ansvar
Tutorial # 4: Scrum artefakter
Tutorial # 5: Scrum begivenheder
Tutorial # 6: Defektforsøg i Scrum
Tutorial # 7: Selvforsynende Scrum-hold
Tutorial # 8: Tre Amigo-principper
Tutorial # 9: SAFe - Skaleret agil ramme
Tutorial # 10: Agile Scrum Quiz
MERE anbefalede Agile Scrum Tutorials:
Tutorial # 11: Top agile estimeringsteknikker
Tutorial # 12: Agile Waterfall Hybrid Model
Vejledning nr. 13: Kanban vs Scrum vs Agile
Tutorial # 14: JIRA Agile vejledning
Tutorial # 15: Agile retrospektive møder
Tutorial # 16: Virksomhedsanalytikers rolle i SCRUM
Tutorial # 17: QA's rolle i Scrum
Værktøj og interviewspørgsmål:
Tutorial # 18: Agile testværktøjer
Tutorial # 19: Bedste agile projektstyringsværktøjer
Tutorial # 20: Top Agile Interview Spørgsmål
Tutorial # 21: Top Scrum Interview Spørgsmål
Lad os starte med den første tutorial i serien - Agile Scrum Introduction.
Introduktion til agil udvikling
Agile i softwareudvikling:
Agile er en af verdens mest anvendte og anerkendte rammer for softwareudvikling.
De fleste af organisationerne har vedtaget det i en eller anden form, men der er stadig lang vej at gå i løbet af deres adoptionsprogrammer. Det eneste mål med denne række tutorials er at indbringe teknologi og ikke-teknologiprofessionelle i Agile World.
Vi fører dig igennem den smidige rejse trin for trin, indtil du forstår filosofien bag at bruge Agile, dens fordele og hvordan du praktiserer den. Denne serie har til formål at udstyre og gøre det muligt for læserne at anvende Agile og Scrum-læring i deres arbejde.
Denne særlige tutorial er dedikeret til at forklare dig, hvorfor der var behov for Agile, og hvordan det blev oprettet. Det grundlæggende her er at få dig til at forstå begrebet Agile Adoption i Software Development Industries.
Agile historie
Agile blev født, da 17 mennesker med forskellige udviklingsmetoder baggrund på en smuk dag mødtes for at brainstorme, om der var en mulig alternativ løsning til softwareudvikling, der kunne føre til hurtigere udviklingstid og var mindre dokumentationstung.
På det tidspunkt skete softwareudvikling så længe, at da projekterne var klar til at blive leveret, var virksomheden gået fremad og kravene var ændret. Et projekt var således ikke i stand til at imødekomme forretningsbehovene, selvom det var i stand til at opfylde sine definerede mål.
Således mødtes disse mestre for forskellige softwaretekniske teknikker, og slutresultatet af deres møde var, hvad de kaldte 'det agile manifest', som vi vil diskutere detaljeret i den næste tutorial i denne serie.
Men den adræt, der blev født den dag, er ikke det, vi ser i dag i organisationer. Metoden, som de eksperter var enige om, blev beskrevet som 'let' og hurtig. Men den største gevinst ud af dette møde var tanken om, at hurtigere levering af et produkt og konstant feedback var nøglerne til at opnå succes inden for softwareudvikling.
De eksisterende vandfaldsteknikker var for besværlige og havde ingen mulighed for feedback, før det færdige produkt var klar til levering. Dette betød, at der ikke var plads til kursuskorrektion, og at kunden ikke havde noget syn på fremskridtene, før hele produktet var klar. Og det var det, disse eksperter ønskede at undgå.
De ønskede en løsning, der ville have plads til konstant feedback for at undgå omkostningerne ved omarbejdning på et senere tidspunkt.
Agile udfordringer
De eksisterende vandfaldsteknikker på det tidspunkt var for besværlige og havde ingen mulighed for feedback, før det færdige produkt var klar til levering. Det blev kaldt en vandfaldsmodel for udvikling, fordi holdene først sluttede et trin fuldstændigt, og først derefter flyttede de videre til næste trin.
Dette betød, at der ikke var plads til kursuskorrektion, og at kunden ikke havde noget syn på fremskridtene, før hele produktet var klar. Og det var det, disse eksperter ønskede at undgå. De ønskede en løsning, der ville have plads til konstant feedback for at undgå omkostningerne ved omarbejdning på et senere tidspunkt.
Og det er grunden til, at agil også handler om at være adaptiv og kontinuerlig forbedring, så meget som det handler om konstant feedback og leveringshastighed.
Hvad er smidige løfter?
Agile handler ikke kun om at anvende den fastlagte praksis i udvikling af software. Det medfører også en ændring i holdets tankegang, der får dem til at opbygge bedre software, arbejde sammen og til sidst lande dem som en glad kunde.
Agile værdier og principper gør det muligt for teamet at skifte fokus og ændre deres tankeproces for at opbygge bedre software.
Hvad er der agil?
Agile er ikke et sæt regler. Agile er ikke et sæt retningslinjer. Agile er ikke engang en metode. Agile er snarere et sæt principper, der tilskynder til fleksibilitet, tilpasningsevne, kommunikation og arbejdssoftware over planer og processer. Det er meget kortfattet fanget i det, der kaldes det agile manifest.
Agil softwareudvikling giver holdet mulighed for at arbejde mere effektivt og effektivt sammen om at udvikle komplekse projekter. Den består af praksis, der udøver iterative og inkrementelle teknikker, som let kan vedtages og viser gode resultater.
Når vi anvender Agile til handling, har vi forskellige Agile-baserede metoder og metoder. Disse metoder og metoder imødekommer alle behovene i en softwareudviklingsindustri lige fra software design og arkitektur, udvikling og test til projektledelse og leverancer.
Ikke kun det, Agile metoder og metoder åbner også mulighed for procesforbedring som en integreret del af hver levering.
Agile er en softwareudviklingsmetode, hvor et selvforsynende og tværfunktionelt team arbejder på at levere kontinuerlige leveringer gennem iterationer og udvikler sig gennem hele processen ved at indsamle feedback fra slutbrugerne.
Hvordan praktiserer man smidig?
Der er forskellige agile metoder, der er i praksis i forskellige diversificerede industrier.
De mest populære metoder blandt dem alle er dog:
- Scrum
- Kanban
- Ekstrem programmering
Alle disse metoder fokuserer på lean softwareudvikling og hjælper med at opbygge bedre software effektivt og effektivt.
Det er alt sammen med Agile Introduction. Delen er struktureret til at hjælpe dig med at forstå de kerneværdier og principper, der skal vedtages for et team til at arbejde i en Agile mode og tankegang.
Adræt Metodologi
Introduktion til smidige modeller:
vr headset, der fungerer med xbox one
Som vi alle ved, er Agile en softwareudviklingsmetode.
Vi har også lært om de værdier og principper, der blev nævnt i det agile manifest af grundlæggerne af agile. I vores indledende diskussioner kom vi også ind på forskellene mellem adræt og de traditionelle vandfaldsmodeller.
I denne vejledning får vi kendskab til fordelene og ulemperne ved den agile metode.
Vi vil se, hvad der er scrum? og hvordan adskiller det sig fra adræt. Derefter vil vi forstå de forskellige agile metoder, der bruges af forskellige organisationer, og hvordan kan vi implementere agile ved hjælp af dem.
Du vil også være i stand til at forstå forskellen og også fordelene / ulemperne ved disse metoder.
Fordele ved agil metode
Nedenfor er de forskellige fordele ved Agile Methodology:
- Kunderne får løbende et blik og fornemmelse af projektets fremskridt i slutningen af hver iteration / sprint.
- Hver sprint giver kunden en fungerende software, der opfylder deres forventninger i henhold til definitionen af gjort leveret af dem.
- Udviklingsteamene er meget lydhøre over for de skiftende krav og kan imødekomme ændringer selv i de avancerede stadier af udviklingen.
- Der er konstant tovejskommunikation, der holder kunderne involveret, og dermed har alle interessenter - forretning og teknisk - klar synlighed på projektets fremskridt.
- Produktets design er effektivt og opfylder forretningskravene.
Ulemper ved Agile Methodology
Selvom der er flere fordele ved Agile-metodologi, er der også visse ulemper involveret i den.
De er:
# 1) Omfattende dokumentation foretrækkes ikke, hvilket kan føre til, at agile teams fejlagtigt fortolker dette, da agile ikke kræver dokumentation. Så forsvinden går vild med dokumentation. Dette bør undgås ved løbende at spørge dig selv, om dette er tilstrækkelig information til at fortsætte eller ej.
#to) Nogle gange, i starten af projekterne, er kravene ikke krystalklare. Holdene kan fortsætte og finde ud af, at kundernes vision blev tilpasset igen, og i sådanne situationer skal holdene inkorporere mange ændringer, og det er også vanskeligt at måle slutresultatet.
Typer af smidige metoder
Der er adskillige smidige metoder i praksis over hele verden. Vi vil lære mere detaljeret om fire af de mest populære.
# 1) Scrum
Scrum kan let betragtes som den mest populære agile ramme. Udtrykket 'scrum' betragtes meget synonymt med 'smidigt' af de fleste praktikere. Men det er en misforståelse. Scrum er blot en af de rammer, hvormed du kan implementere smidig.
Ordet scrum kommer fra sportsrugby. Hvor spillerne krammer sig sammen i en sammenlåst position og skubber mod modstanderne. Hver spiller har en defineret rolle i deres position og kan spille både offensiv og defensiv i henhold til situationens krav.
På samme måde tror scrum i IT på bemyndigede selvstyrede udviklingsteams med tre specifikke og klart definerede roller. Disse roller inkluderer - Produktejer (PO), Scrum Master (SM) og udviklingsteamet bestående af programmører og testere . De arbejder sammen i iterative tidsbokse, der kaldes sprints.
Det første trin er PO's oprettelse af produktforsinkelse. Det er en opgaveliste over ting, der skal udføres af scrumteamet. Derefter vælger scrum-teamet de øverste prioritetselementer og prøver at afslutte dem inden for tidsfeltet kaldet en sprint.
En nemmere måde at huske alt dette på er at huske 3-3-5-rammen. Det betyder, at et scrumprojekt har 3 roller, 3 artefakter og 5 begivenheder.
Disse er -
Roller: PO, Scrum master og udviklingsteam.
Artefakter: Produktbacklog, Sprint BacklogogProduktforøgelse.
Begivenheder: Sprint, Sprint planlægning, Daily Scrum, Sprint review og Sprint retrospektiv.
Vi vil lære mere detaljeret om hver af disse i vores efterfølgende tutorials.
# 2) Kanban
Kanban er et japansk udtryk, der betyder et kort. Disse kort indeholder detaljer om det arbejde, der skal udføres på softwaren. Formålet er visualisering. Hvert teammedlem er opmærksom på det arbejde, der skal udføres gennem disse visuelle hjælpemidler.
Hold bruger disse Kanban-kort til kontinuerlig levering. Ligesom Scrum er Kanban også til at hjælpe holdene med at arbejde effektivt og fremme selvstyrede og samarbejdende teams.
Men der er også forskelle mellem disse to - ligesom under en scrumsprint er de emner, som et team arbejder på, rettet, og vi kan ikke tilføje varer til sprinten, mens vi i Kanban kan tilføje varer, hvis der er ledig kapacitet. Dette er især nyttigt, når kravene ofte ændres.
Tilsvarende er en anden forskel, at mens scrum har definerede roller som en PO, scrum master og udviklingsteam, er der ingen sådanne foruddefinerede roller i Kanban.
En anden forskel er, at mens scrum foreslår en prioritering af produktbacklogs, har Kanban ikke noget sådant krav, og det er helt valgfrit. Således kræver Kanban mindre organisering og undgår aktiviteter, der ikke tilføjer værdi, og er velegnet til de processer, der kræver lydhørhed over for ændringer.
# 3) Lean
Lean er en filosofi, der fokuserer på affaldsreduktion. Hvordan gør det det?
I lean deler du en proces i værdiskabende aktiviteter, ikke-værdiskabende aktiviteter og vigtige aktiviteter, der ikke tilføjer værdi. Enhver aktivitet, der kan klassificeres som en ikke-værditilvækkende aktivitet, er spild, og vi bør forsøge at fjerne det spild i processen for at gøre det slankere.
En slankere proces betyder hurtigere levering og mindre indsats spildt i opgaver, der ikke hjælper med at nå holdets mål. Dette hjælper med at optimere hvert trin i softwareudviklingscyklussen. Derfor blev de lean-principper tilpasset fra lean-produktion til softwareudvikling.
Lean softwareudvikling kan bruges i ethvert IT-projekt ved at anvende de syv lean-principper, der er vist nedenfor:
Disse er ret selvforklarende, som deres navne antyder. Fjernelse af spild er det første og vigtigste lean-princip, og vi så, hvordan man gør det, vi klassificerer bare aktiviteter som værdi og ikke-værditilvækst.
En ikke-værditilvækningsaktivitet kan være en hvilken som helst del af koden, der kan gøre den mindre robust, øge den involverede indsats og tage meget tid uden at tilføje en berettiget forretningsværdi. Det kan også være vage brugerhistorier eller dårlig test eller tilføjelse af funktioner, der ikke kræves i det store billede.
Det andet princip, der forstærker læring, er igen let at forstå, da et team har brug for forskellige færdigheder for at levere produkter i et hurtigt skiftende miljø med nye teknologier, der dukker op i hurtige varigheder.
At træffe sene beslutninger kan være givende under omstændigheder, hvor det reducerer omarbejdningen, som hvis der er forventede ændringer, så bedre udsætte det, så teamet ikke behøver at gentage arbejdet, da forretningens behov ændres.
Men der er altid en kompromis her, da holdene skal afveje dette med det fjerde princip om at levere hurtigere. Forsinkelse af beslutninger bør ikke påvirke den samlede levering og må ikke reducere arbejdstempoet. Det ene øje skal altid være på det komplette billede.
At have bemyndigede hold er også meget almindeligt i dag, og det er noget, som selv agile antyder. Bemyndigede hold er mere ansvarlige og kan træffe beslutninger hurtigere. Følelsen af ejerskab i et bemyndiget team fører til bedre resultater. For at styrke et hold skal de have lov til at organisere sig selv og træffe beslutninger alene.
Således ser vi, at magert og smidigt har meget til fælles med en skarp forskel - mens magert hold kan hjælpe med at forfine et produkt, er agile hold dem, der faktisk bygger produktet.
# 4) Ekstrem programmering (XP)
Ekstrem programmering er en anden mest populær agil teknik. I henhold til extremeprogramming.org blev det første XP-projekt startet den 6. marts 1996. De nævner også, at XP påvirker software-projektudvikling på 5 forskellige måder - kommunikation, enkelhed, feedback, respekt og mod. Disse kaldes XP-værdier.
Ud af disse starter det hele med kommunikation. XP-teams samarbejder med forretningsteams og andre programmerere regelmæssigt og begynder at opbygge kode fra den allerførste dag. Fokus her er ansigt til ansigt kommunikation så vidt muligt ved hjælp af de andre visuelle hjælpemidler.
Ekstreme programmører bygger også en simpel kode og begynder at få feedback på den fra selve den første dag. Fokus er på ikke at gå overbord eller forudsige krav, som ikke er delt. Dette holder designet enkelt og producerer netop det minimumsprodukt, der opfylder kravene.
Feedback hjælper teamet med at forbedre og producere en bedre kvalitet af arbejdet. Dette hjælper dem med at opbygge respekt for hinanden, når de lærer af hinanden og lærer, hvordan de deler deres synspunkter.
Dette giver dem også modet, da de ved, at de har samlet alles bedste ideer og produceret et godt produkt med feedback fra andre. Således er de heller ikke bange for at medtage ændringer eller modtage yderligere feedback på deres arbejde.
Dette er især nyttigt i projekter, hvor kravene ofte ændres. Konstant feedback vil hjælpe holdene med at inkludere disse ændringer med mod.
Således har vi set de forskellige agile metoder som Scrum, XP, Kanban og Lean sammen med deres respektive fordele og ulemper.
Nu kan vi let skelne mellem dem og også sætte pris på de subtilere forskelle mellem dem. Vi lærte også det grundlæggende i hver af disse metoder og så, hvordan vi anvender dem i vores projekter, når og når det er nødvendigt.
Lad os i næste del forstå alt om Scrum.
Scrummetodologi
SCRUM er en proces inden for agil metode, der er en kombination af den iterative model og den inkrementelle model.
Et af de største handicap ved det traditionelle Vandfaldsmodel var det - indtil den første fase er afsluttet, flytter applikationen ikke til den anden fase. Og ved en tilfældighed, hvis der er nogle ændringer i den senere fase af cyklussen, bliver det meget udfordrende at gennemføre disse ændringer, da det ville indebære en fornyet gennemgang af de tidligere faser og gentagelse af ændringerne.
Nogle af de vigtigste egenskaber ved SCRUM inkluderer:
- Selvorganiseret og fokuseret team.
- Ingen dokumenter med stort krav, snarere har en meget præcis og til-punkt historier.
- De tværfunktionelle teams arbejder sammen som en enkelt enhed.
- Luk kommunikation med brugerrepræsentanten for at forstå funktionerne.
- Har en bestemt tidslinje på maksimalt en måned.
- I stedet for at gøre hele 'tingen' ad gangen, gør Scrum lidt af alt med et givet interval.
- Ressourcekapacitet og tilgængelighed overvejes, inden der begås noget.
For at forstå denne metode godt er det vigtigt at forstå de vigtigste terminologier i SCRUM.
Læs også => Sådan leveres softwarefunktioner af høj værdi på kort tid ved hjælp af Agile Scrum Process
Vigtige SCRUM-terminologier
1) Scrum Team
Scrum-holdet er et hold bestående af 7 med + eller - to medlemmer. Disse medlemmer er en blanding af kompetencer og består af udviklere, testere, databasefolk, supportpersoner osv. Sammen med produktejeren og en scrummaster.
Alle disse medlemmer arbejder sammen i tæt samarbejde i et rekursivt og bestemt interval for at udvikle og implementere de nævnte funktioner. SCRUM holdsiddearrangement spiller en meget vigtig rolle i deres interaktion, de sidder aldrig i kabiner eller hytter, men et stort bord.
2) Sprint
Sprint er et foruddefineret interval eller tidsramme, hvor arbejdet skal afsluttes og gøre det klar til gennemgang eller klar til produktion. Denne tidsboks ligger normalt mellem 2 uger og 1 måned.
bedste program til at slippe af med vira
I vores daglige liv, når vi siger, at vi følger Sprint-cyklussen på 1 måned, betyder det simpelthen, at vi arbejder i en måned på opgaverne og gør den klar til gennemgang inden udgangen af den måned.
3) Produktejer
Produktejeren er den vigtigste interessent eller hovedbrugeren af den applikation, der skal udvikles. Produktejeren er den person, der repræsenterer kundesiden. Han / hun har den endelige autoritet og skal altid være tilgængelig for holdet.
Han / hun skal være tilgængelig, når nogen er i tvivl, der skal præciseres. Det er vigtigt for produktejeren at forstå og ikke tildele noget nyt krav midt i sprinten, eller når sprinten allerede er startet.
4) Scrum Master
Scrum Master er facilitator for scrum-teamet. Han / hun sørger for, at scrumteamet er produktivt og progressivt. I tilfælde af hindringer følger scrummester op og løser dem for holdet. SCRUM Master er mægler mellem PO og holdet.
Han / hun holder PO informeret om Sprintens fremskridt. Hvis der er vejspærringer eller bekymringer for holdet, diskuterer det med PO og får dem løst. Ligesom holdets Daily Standup sker en standup af SCRUM Master med PO hver dag.
Anbefalet læsning => Hvordan man kan være et godt teammentor, coach og en sand team-defender i en agil testverden?
5) Forretningsanalytiker (BA)
En forretningsanalytiker spiller en meget vigtig rolle i SCRUM. Denne person er ansvarlig for at få kravet færdigbehandlet og udarbejdet i kravdokumenterne (baseret på hvilke brugerhistorierne oprettes).
Hvis der er uklarheder i brugerhistorierne / acceptkriterierne, er han / hun den, som det tekniske (SCRUM) team henvender sig til, og han tager det derefter op til PO eller ellers løser det selv. I store projekter kan der være mere end 1 BA, men i mindre projekter fungerer SCRUM Master muligvis også som BA.
Det er altid en god praksis at have en BA, når projektet kick starter.
6) Brugerhistorie
Brugerhistorier er intet andet end kravene eller funktionen, der skal implementeres.
I scrum har vi ikke disse enorme kravsdokumenter, snarere er kravene defineret i et enkelt afsnit, typisk med formatet som:
Som en
jeg vil gerne
At opnå
For eksempel :
Som administrator vil jeg have en adgangskodelås, hvis brugeren indtaster en forkert adgangskode i tre på hinanden følgende gange for at begrænse uautoriseret adgang.
Der er nogle karakteristika ved brugerhistorier, som skal overholdes. Brugerhistorierne skal være korte, realistiske, kunne estimeres, komplette, omsættelige og testbare. En brugerhistorie ændres eller ændres aldrig midt i Sprint.
Det er SCRUM-mesterens og BA's (hvis relevant) ansvar at sikre, at PO'en har udarbejdet brugerhistorierne korrekt med et korrekt sæt af acceptkriterierne ”. Hvis der skal foretages ændringer, der vil påvirke sprintfrigørelsen, trækkes sådanne historier ud af sprinten, eller de udføres i henhold til de tilgængelige timer.
Hver brugerhistorie har et acceptkriterium, der skal være veldefineret og forstået af teamet.
Acceptkriterier detaljer ned i brugerhistorien, der leverer de støttende dokumenter. Det hjælper med at forfine brugerhistorien yderligere. Alle fra holdet kan skrive ned acceptkriterierne. Testteamet baserer deres testsager / betingelser på disse acceptkriterier.
7) Epics
Epics er tvetydige brugerhistorier, eller vi kan sige, at det er de brugerhistorier, der ikke er defineret og opbevares til fremtidige sprints.
Bare prøv at forbinde det med livet, forestil dig at du tager på ferie. Når du går i næste uge, har du alt på plads, som f.eks. Dine hotelreservationer, sightseeing, rejsecheck osv. Men hvad med din ferieplan for næste år? Du har kun en vag idé om, at du kan gå til XYZ sted, men du har ingen detaljeret plan.
Et episk er ligesom dig næste års ferieplan, hvor du bare ved, at du måske vil hen, men hvor, hvornår, med hvem, alle disse detaljer har du ingen idé om på dette tidspunkt.
På lignende måde er der funktioner, som skal implementeres i fremtiden, hvis detaljer endnu ikke er kendt. For det meste begynder en funktion med en Epic og er derefter opdelt i historier, der kan implementeres.
8) Produktforsinkelse
Produktet bagud er en slags spand eller kilde, hvor alle brugerhistorier opbevares. Dette vedligeholdes af produktejeren. Produktet bagud kan forestilles som en ønskeliste for den produkt ejer, der prioriterer det efter virksomhedens behov.
Under planlægningsmødet (se næste afsnit) tages en brugerhistorie fra produktets efterslæb, så gør teamet brainstorming, forstår det og forfiner det og beslutter kollektivt, hvilke brugerhistorier de skal tage med produktets ejer.
9) Sprint-efterslæb
Baseret på prioriteten tages brugerhistorier fra Product Backlog som en ad gangen. Scrum-teamet brainstorms om det bestemmer gennemførligheden og beslutter historierne for at arbejde på en bestemt sprint. Den samlede liste over alle de brugerhistorier, som scrumteamet arbejder på en bestemt sprint, er kendt som Sprint-efterslæb.
10) Story Points
Historiepunkter er en kvantitativ indikation af kompleksiteten i en brugerhistorie. Baseret på historiens punkt bestemmes estimering og indsats for en historie.
Et historisk punkt er relativt og ikke absolut. For at sikre, at vores skøn og indsats er korrekte, er det vigtigt at kontrollere, at brugerhistorierne ikke er store. Jo mere præcis og mindre brugerhistorien er, desto mere præcis bliver estimeringen.
Hver brugerhistorie tildeles et historiepunkt baseret på Fibonacci-serien (1, 2, 3, 5, 8, 13 & 21). Højere er antallet, komplekset er historien.
For at være præcis
- Hvis du giver 1/2/3 story point betyder det, at historien er lille og af lav kompleksitet.
- Hvis du giver point som 5/8, er det et medium kompleks og
- 13 og 21 er meget komplekse.
Her består kompleksiteten af både udvikling plus testindsats.
For at bestemme et historiepunkt sker der brainstorming inden for scrum-teamet, og teamet beslutter kollektivt et historiepunkt.
Det kan forekomme, at udviklingsteamet giver en historiepunkt på 3 til en bestemt historie, for for dem kan det være 3 linjer med kodeskift, men testteamet giver 8 historikpoint, fordi de føler, at denne kodeændring vil påvirke større moduler, så testindsatsen ville være større. Uanset hvad du giver, skal du retfærdiggøre det.
Så i denne situation sker der brainstorming, og holdet accepterer samlet et enkelt punkt.
Når du beslutter dig for et historiepunkt, skal du huske nedenstående faktorer:
- Historiens afhængighed med anden applikation / modul.
- Ressourceens færdighedssæt.
- Historiens kompleksitet.
- Historisk læring.
- Acceptkriterier for brugerhistorien.
Hvis du ikke er opmærksom på en bestemt historie, skal du ikke dimensionere den.
Når en historie er = eller> 8 point, opdeles den i 2 eller flere historier.
11) Nedbrændt diagram
Nedbrændt diagram er en graf, der viser den estimerede v / s faktiske indsats for scrumopgaverne.
Det er en sporingsmekanisme, hvormed de daglige opgaver spores for en bestemt sprint for at kontrollere, om historierne skrider frem mod afslutningen af de engagerede historiepunkter eller ej.
Eksempel : For at forstå dette skal du kontrollere nedenstående figur:
Jeg har antaget:
- 2 ugers sprint (10 dage)
- 2 ressourcer, der faktisk arbejder på sprinten.
'Historie' -> Denne kolonne viser brugerhistorier taget for sprinten.
'Opgave' -> Denne kolonne viser listen over den opgave, der er knyttet til brugerhistorien.
'Indsats' -> Denne kolonne viser indsatsen. Nu er denne foranstaltning den samlede indsats for at fuldføre opgaven. Det skildrer ikke den indsats, som en bestemt person har gjort.
“Dag 1 - dag 10” -> Denne kolonne (r) viser de timer, der er tilbage til at fuldføre historien. Se venligst, at timen IKKE er den time, der allerede er færdig, MEN de timer, der stadig er tilbage.
“Anslået indsats” -> Er den samlede indsats. For “Start” er det simpelthen summen af hele den enkelte opgave: SUM (C5: C15)
Et samlet antal indsats, der skal afsluttes på 1 dag, er 70/10 = 7. Så i slutningen af dag 1 skal indsatsen reduceres til 70 - 7 = 63. På samme måde beregnes det for alle dage til dag 10, hvor den anslåede indsats skal være 0 (række 16)
“Faktisk indsats tilbage” -> Som navnet antyder, er den indsats, der faktisk er tilbage for at færdiggøre historien. Det kan også ske, at den faktiske indsats stiger eller falder end den anslåede.
Du kan bruge de indbyggede funktioner og Kort i Excel til at oprette dette nedbrændingsdiagram.
Trin for nedbrændt diagram ville være:
- Indtast alle historierne (Kolonne A5 - A15).
- Indtast alle opgaver (kolonne B5 - B15).
- Indtast dagene (dag 1 - dag 10).
- Indtast startindsatsen (summer opgaverne C5 - C15).
- Anvend formlen for at beregne den 'estimerede indsats' for hver dag (dag 1 til dag 10). Indtast formlen ved D15 (C16- $ C $ 16/10), og træk den i alle dage.
- Indtast den faktiske indsats for hver dag. Indtast formlen ved D17 (SUM (D5: D15)) for at opsummere den reelle indsats tilbage, og træk den i alle de andre dage.
- Vælg det, og opret diagrammet som følger:
12) Hastighed
Det samlede antal story point, som et scrum team arkiverer i en sprint, kaldes Velocity. Scrum-teamet bedømmes eller henvises til af dets hastighed. Når det er sagt, skal man huske på, at målet her IKKE er at nå de maksimale historiepoint, men at have en kvalitet, der kan leveres under hensyntagen til scrum-holdets komfortniveau.
For eksempel : For en bestemt sprint: det samlede antal brugerhistorier er 8 med historiepoint som vist nedenfor.
Så her vil hastigheden være summen af historiens point = 30
Definition af Udført:
En sprint er markeret som udført, når alle historierne er afsluttet, alle dev, research, QA-opgaver er markeret som 'Completed', alle bugs er fix-closed, ellers dem, der kan gøres senere (som ikke helt relaterede eller er mindre vigtige) trækkes ud og tilføjes i efterslæbet, kodekontrol og enhedstest er afsluttet, de estimerede timer har mødt de faktiske timer, der er lagt op i opgaverne, og vigtigst af alt er der givet en vellykket demo til PO og interessenterne.
Aktiviteter udført i SCRUM-metodologi
# 1) Planlægningsmøde
Et planlægningsmøde er udgangspunktet for Sprint. Det er mødet, hvor hele scrum-teamet samles, SCRUM Master vælger en brugerhistorie baseret på prioriteten fra produktets efterslæb og teamets brainstorms på det.
Baseret på diskussionen beslutter scrum-teamet kompleksiteten i historien og størrelser den i henhold til Fibonacci-serien. Teamet identificerer opgaverne sammen med de bestræbelser (i timer), der ville blive gjort for at fuldføre implementeringen af brugerhistorien.
Mange gange forud for planlægningsmødet med et ”Pre-Planning-møde”. Det er ligesom lektier, som scrumteamet gør, inden de sidder til det formelle planlægningsmøde. Holdet forsøger at nedskrive de afhængigheder eller andre faktorer, som de gerne vil diskutere i planlægningsmødet.
# 2) Udførelse af sprintopgaver
Som navnet antyder, er dette det egentlige arbejde, som scrumteamet har udført for at udføre deres opgave og tage brugerhistorien til 'Udført' -tilstand.
# 3) Daglig standup
Under sprintcyklussen mødes scrumteamet hver dag i ikke mere end 15 minutter (kan være et stand-up-opkald, der anbefales at have i starten af dagen) og angive 3 point:
- Hvad gjorde holdmedlemmen i går?
- Hvad planlagde teammedlemmen at gøre i dag?
- Eventuelle hindringer (vejspærringer)?
Det er Scrum-mester, der letter dette møde. Hvis ethvert teammedlem står over for nogen form for vanskeligheder, følger scrummasteren op for at få det løst. I Stand ups gennemgås bestyrelsen også og viser i sig selv holdets fremskridt.
# 4) Gennemgå møde
Ved afslutningen af hver sprintcyklus mødes SCRUM-teamet igen og demonstrerer de implementerede brugerhistorier for produktejeren. Produktejeren kan krydse verificere historierne i henhold til dets acceptkriterier. Det er igen Scrum-mesterens ansvar at præsidere dette møde.
Også i SCRUM-værktøjet lukkes Sprint, og opgaverne markeres som udført.
# 5) Retrospektivt møde
Det retrospektive møde sker efter gennemgangsmødet.
SCRUM-teamet mødes, diskuterer og dokumenterer følgende punkter:
- Hvad gik godt under Sprint (bedste praksis)?
- Hvad gik ikke godt i Sprint?
- Erfaringer
- Action ting.
Scrum-teamet skal fortsætte med at følge den bedste praksis, ignorere 'ikke bedste praksis' og implementere de erfaringer, der er draget i de efterfølgende sprints. Det retrospektive møde hjælper med at implementere den løbende forbedring af SCRUM-processen.
Hvordan processen udføres? Et eksempel!
Efter at have læst om de tekniske jargoner i SCRUM. lad mig prøve at demonstrere hele processen med et eksempel.
Eksempel:
Trin 1 : Lad os have et SCRUM-team på 9 personer bestående af 1 produkt ejer, 1 Scrum master, 2 testere, 4 udviklere og 1 DBA.
Trin 2 : Sprinten besluttes at følge en 4 ugers cyklus. Så vi har 1-måneders sprint, der starter 5. juni til 4thjuli.
Trin # 3 : Produktejeren har den prioriterede liste over brugerhistorier i produktforsinkelsen.
Trin # 4: Holdet beslutter at mødes den 4thJuni til 'Pre Planning' -mødet.
- Produktejeren tager 1 historie fra produktets bagud, beskriver den og overlader det til teamet at brainstorme om det.
- Hele teamet diskuterer og kommunikerer direkte til produktejeren for klart at have forstået brugerhistorien.
- På en lignende måde tages forskellige andre brugerhistorier. Hvis det er muligt, kan holdet også gå videre og dimensionere historierne.
Efter alle diskussionerne går individuelle teammedlemmer tilbage til deres arbejdsstationer og
- Identificer deres individuelle opgaver for hver historie.
- Beregn det nøjagtige antal timer, de skal arbejde på. Lad os kontrollere, hvordan medlemmet afslutter disse timer.
Samlet antal arbejdstimer = 9
Minus 1 time til en pause minus 1 time til møder minus 1 time til e-mails, diskussioner, fejlfinding osv.
Så den faktiske arbejdstid = 6.
Et samlet antal arbejdsdage i løbet af Sprint = 21 dage.
Samlet antal timer tilgængelige = 21 * 6 = 126.
Medlemmet har orlov i 2 dage = 12 timer (Dette varierer for hvert medlem, nogle kan tage orlov og andre måske ikke.)
Antal faktiske timer = 126 - 12 = 114 timer.
Dette betyder, at medlemmet faktisk vil være tilgængeligt i 114 timer til denne sprint. Så han vil nedbryde sin individuelle sprintopgave på en sådan måde, at der i alt nås 114 timer.
Trin # 5 : På 5thjuni mødes hele Scrum-teamet til ”Planning Meeting”.
- Den endelige dom af brugerhistorien fra produktets efterslæb er færdig, og historien flyttes til Sprint-efterslæbet.
- For hver historie erklærer hvert teammedlem deres identificerede opgaver, hvis det er nødvendigt kan de have en diskussion om disse opgaver, kan størrelse eller ændre størrelsen på det (husk Fibonacci-serien !!).
- Scrum-mesteren eller teamet indtaster deres individuelle opgaver sammen med deres timer for hver historie i et værktøj.
- Når alle historierne er afsluttet, noterer Scrum master den indledende hastighed og starter formelt Sprint.
Trin # 6 : Når Sprint er startet, baseret på de tildelte opgaver, begynder hvert teammedlem at arbejde på disse opgaver.
Trin # 7 : Holdet mødes dagligt i 15 minutter og diskuterer 3 ting:
- Hvad gjorde de i går?
- Hvad de planlægger at gøre i dag?
- Eventuelle hindringer (vejspærringer)?
Trin # 8 : Scrummesteren sporer fremskridtene dagligt ved hjælp af “Burn down chart”.
Trin 9 : I tilfælde af hindringer følger Scrum-mester op for at løse dem.
Trin # 10 : Den 4thJuli mødes holdet igen til gennemgangsmødet. Et medlem demonstrerer den implementerede brugerhistorie for produktejeren.
Trin # 11 : Den 5thJuli mødes holdet igen til Retrospective, hvor de diskuterer
- Hvad gik godt?
- Hvad gik ikke godt?
- Action ting.
Trin # 12 : Den 6thJuli mødes holdet igen til forudplanlægningsmøde til næste sprint, og cyklussen fortsætter.
SCRUM Aktivitetsværktøjer
Der er flere værktøjer, der kan bruges i vid udstrækning til sporing af scrum-aktiviteter.
Nogle af dem inkluderer:
I den kommende tutorial vil vi kaste lys over Agile Manifesto, som er en forestilling, der driver effektive Agile Teams.
Om forfatterne: Denne serie er skrevet af følgende STH-teammedlemmer: Shruti Shrivastava - En professionel Scrum Master med 9 års erfaring på tværs af BFSI, e-handel og B2B-domæner. Shruti er ekspert i automatiseringstest og førende scrum-teams.Anshul Kumar Srivastava - En resultatorienteret Product Management professionel og Agile praktiserende læge med 7 års erfaring på tværs af BFSI og Telecom sektorer.
Anbefalet læsning
- Agile Scrum Online Quiz: Test din viden om Agile Scrum
- Kanban vs Scrum vs Agile: En detaljeret sammenligning for at finde forskelle
- Sådan leveres softwarefunktioner af høj værdi på kort tid ved hjælp af Agile Scrum-processen
- Agilt manifest: Forståelse af smidige værdier og principper
- SAFe Agile Tutorial: Hvad er Scaled Agile Framework
- 30+ Top Scrum Interview Spørgsmål og svar (2021 LIST)
- Agile Vs Waterfall: Hvilken er den bedste metode til dit projekt?
- Top 31 Agile Interview Spørgsmål og svar