agile methodology beginner s guide agile method
En komplett guide till Agile Methodology: (20+ detaljerade Agile Scrum Methodology Tutorials)
Det här är guiden för programvaruutvecklare och testare att förstå och börja arbeta med de mycket kända Agil SCRUM-metodik för programvaruutveckling och testning . Lär dig de grundläggande men viktiga terminologierna som används i Agile Scrum-processen tillsammans med ett verkligt exempel på hela processen.
Vi har listat alla Agile Tutorials i denna serie för din bekvämlighet. Hoppas att de kommer att vara till stor hjälp för dig.
Ämnen som behandlas: Vad är Agile, Vad är Scrum, Agile Methodology i mjukvaruutveckling och testning, Agile Testing, Agile Scrum Process, Scrum Methodology med Scrum Team och Scrum Master.
Vad du kommer att lära dig:
Agile Methodology Tutorials List
Handledning nr 1: Agile Scrum-metoder (Denna handledning)
Handledning nr 2: Agile Manifesto
Handledning nr 3: Scrum Team & deras roller och ansvar
Handledning nr 4: Scrum-artefakter
Handledning nr 5: Scrum-händelser
Självstudie nr 6: Defect Triaging In Scrum
Självstudie 7: Självförsörjande Scrum Team
Handledning # 8: Tre Amigo-principer
Handledning nr 9: SAFe - Skalad smidig ram
Handledning nr 10: Agile Scrum Quiz
MER Rekommenderade Agile Scrum Tutorials:
Handledning nr 11: De bästa teknikerna för smidig uppskattning
Handledning nr 12: Agile Waterfall Hybrid Model
Handledning nr 13: Kanban vs Scrum vs Agile
Handledning nr 14: JIRA Agile Handledning
Handledning nr 15: Agila retrospektiva möten
Handledning nr 16: Affärsanalytikernas roll i SCRUM
Handledning nr 17: QA: s roll i Scrum
Verktyg och intervjufrågor:
Handledning nr 18: Agila testverktyg
Handledning nr 19: Bästa Agile Project Management Tools
Handledning nr 20: Topp Agile intervjufrågor
Handledning nr 21: Top Scrum Intervju Frågor
Låt oss börja med den första självstudien i serien - Agile Scrum Introduction.
Introduktion till Agile Development
Agile i mjukvaruutveckling:
Agile är en av världens mest använda och erkända ramar för mjukvaruutveckling.
De flesta organisationer har antagit den i någon form eller den andra, men det finns fortfarande en lång väg att gå i mognaden av deras adoptionsprogram. Det enda syftet med denna handledningsserie är att få ombord teknik och icke-teknikare till Agile World.
Vi tar dig igenom den smidiga resan steg för steg tills du förstår filosofin bakom att använda Agile, dess fördelar och hur du övar den. Denna serie syftar till att utrusta och göra det möjligt för läsarna att tillämpa Agile och Scrum-lärande i sitt arbete.
Denna speciella handledning är avsedd för att förklara för dig varför det fanns ett behov av Agile och hur den skapades. Det grundläggande här är att få dig att förstå begreppet Agile Adoption i Software Development Industries.
Agile historia
Agile föddes när 17 personer med olika utvecklingsmetoder bakgrund en bra dag träffades för att brainstorma om det fanns en möjlig alternativ lösning till mjukvaruutveckling som kunde leda till snabbare utvecklingstid och var mindre dokumentationstung.
Vid den tiden brukade mjukvaruutveckling hända så länge att när projekten var klara att levereras hade verksamheten gått framåt och kraven hade förändrats. Således kunde ett projekt inte tillgodose affärsbehovet även om det kunde uppfylla sina definierade mål.
Således samlades dessa mästare för olika tekniker för mjukvaruteknik och slutresultatet av deras möte var vad de kallade 'agile manifest' som vi kommer att diskutera i detalj i nästa handledning i denna serie.
Men den smidiga som föddes den dagen är inte vad vi ser idag i organisationer. Metoden som experterna kom överens om beskrevs som ”lätt” och snabb. Men den största vinsten av detta möte var tanken att snabbare leverans av en produkt och konstant feedback var nycklarna för att uppnå framgång inom mjukvaruutveckling.
De befintliga vattenfallsteknikerna var för besvärliga och hade ingen möjlighet för feedback förrän den slutliga produkten var redo att levereras. Detta innebar att det inte fanns något utrymme för kurskorrigering och kunden hade ingen syn på framstegen förrän hela produkten var klar. Och det var vad dessa experter ville undvika.
De ville ha en lösning som skulle ha utrymme för ständig återkoppling för att undvika omarbetningskostnader i ett senare skede.
Smidiga utmaningar
De befintliga vattenfallsteknikerna vid den tiden var för besvärliga och hade ingen möjlighet för feedback förrän den slutliga produkten var redo att levereras. Det kallades en vattenfallsmodell för utveckling eftersom lagen först avslutade ett steg helt och först därefter gick de vidare till nästa steg.
Detta innebar att det inte fanns något utrymme för kurskorrigering och kunden hade ingen syn på framstegen förrän hela produkten var klar. Och det var vad dessa experter ville undvika. De ville ha en lösning som skulle ha utrymme för ständig återkoppling för att undvika omarbetningskostnader i ett senare skede.
Och det är därför agil handlar om att vara adaptiv och kontinuerlig förbättring, lika mycket som det handlar om konstant återkoppling och leveranshastighet.
Vad är Agile Promises?
Agile handlar inte bara om att använda de fastställda metoderna för att utveckla programvara. Det medför också en förändring av lagets tänkesätt som driver dem mot att bygga bättre programvara, arbeta tillsammans och så småningom landa dem som en lycklig kund.
Agila värden och principer gör det möjligt för teamet att flytta fokus och ändra sin tankeprocess för att bygga bättre programvara.
Vad exakt är smidig?
Agile är inte en uppsättning regler. Agile är inte en uppsättning riktlinjer. Agile är inte ens en metod. Snarare är Agile en uppsättning principer som uppmuntrar flexibilitet, anpassningsförmåga, kommunikation och arbetsprogramvara över planer och processer. Det fångas mycket kortfattat i det som kallas det smidiga manifestet.
Agil mjukvaruutveckling gör att teamet kan arbeta mer effektivt och effektivt tillsammans för att utveckla komplexa projekt. Den består av metoder som utövar iterativa och inkrementella tekniker som är lätta att använda och visar bra resultat.
När vi tillämpar Agile i handling har vi olika Agile-baserade metoder och metoder. Dessa metoder och metoder tillgodoser alla behov inom en mjukvaruutvecklingsindustri, från programvarudesign och arkitektur, utveckling och testning till projektledning och leveranser.
Inte bara det, Agile metoder och metoder öppnar också utrymme för processförbättring som en integrerad del av varje leverans.
Agile är ett programvaruutvecklingssätt där ett självförsörjande och tvärfunktionellt team arbetar med att göra kontinuerliga leveranser genom iterationer och utvecklas genom hela processen genom att samla in feedback från slutanvändarna.
Hur tränar man smidigt?
Det finns olika agila metoder som finns i praktiken i olika diversifierade branscher.
Men de mest populära metoderna bland dem alla är:
- Klunga
- Kanban
- Extrem programmering
Alla dessa metoder fokuserar på mager mjukvaruutveckling och hjälper till att bygga bättre programvara effektivt och effektivt.
Det är allt med Agile Introduction. Delen är strukturerad för att hjälpa dig att förstå de kärnvärden och principer som ska antas för att ett team ska arbeta i ett agilt läge och tänkesätt.
Vig Metodik
Introduktion till smidiga modeller:
vad är det bästa spionprogrammet för mobiltelefoner
Som vi alla vet är Agile en metod för mjukvaruutveckling.
Vi har också lärt oss om de värden och principer som nämndes i det agila manifestet av grundarna av agile. I våra inledande diskussioner kom vi också fram till skillnaderna mellan smidiga och traditionella vattenfallsmodeller.
I denna handledning kommer vi att lära känna fördelarna och nackdelarna med den smidiga metoden.
Vi får se vad som är scrum? och hur skiljer det sig från smidig. Då kommer vi att förstå de olika agila metoderna som används av olika organisationer och hur kan vi implementera agile med dem.
Du kommer också att kunna uppskatta skillnaden och även fördelarna / nackdelarna med dessa metoder.
Fördelar med Agile Methodology
Nedan följer de olika fördelarna med Agile Methodology:
- Kunderna får kontinuerligt en upplevelse av projektets framsteg i slutet av varje iteration / sprint.
- Varje sprint ger kunden en fungerande programvara som uppfyller deras förväntningar enligt definitionen av gjort som tillhandahålls av dem.
- Utvecklingsteamen är ganska lyhörda för de förändrade kraven och rymmer förändringar även i de avancerade utvecklingsstadierna.
- Det finns ständig tvåvägskommunikation som håller kunderna inblandade, så att alla intressenter - affärsmässiga och tekniska - har tydlig synlighet för projektets framsteg.
- Produktens design är effektiv och uppfyller affärskraven.
Nackdelar med Agile Methodology
Även om det finns flera fördelar med Agile-metodiken är det också vissa nackdelar som är inblandade i den.
Dom är:
# 1) Omfattande dokumentation är inte att föredra vilket kan leda till att agila team felaktigt tolkar detta eftersom agile inte kräver dokumentation. Så tuffheten går vilse i dokumentationen. Detta bör undvikas genom att ständigt fråga dig själv om detta är tillräcklig information för att fortsätta eller inte.
#två) Ibland, i början av projekten, är kraven inte kristallklara. Lagen kan fortsätta och upptäcka att kundernas vision har anpassats om och i sådana situationer måste lagen införliva många förändringar och det är svårt att mäta slutresultatet också.
Typer av smidiga metoder
Det finns flera smidiga metoder i praktiken över hela världen. Vi kommer att lära oss mer i detalj om fyra av de mest populära.
# 1) Scrum
Scrum kan lätt anses vara det mest populära agila ramverket. Termen 'scrum' anses mycket synonymt med 'smidig' av de flesta utövare. Men det är en missuppfattning. Scrum är bara en av ramarna som du kan implementera smidig.
Ordet scrum kommer från sportrugby. Där spelarna kramar sig i en sammanlåst position och trycker mot motståndarna. Varje spelare har en definierad roll i sin position och kan spela både offensiv och defensiv enligt situationens krav.
På samma sätt tror scrummet inom IT på bemyndigade självstyrda utvecklingsteam med tre specifika och tydligt definierade roller. Dessa roller inkluderar - Produktägare (PO), Scrum Master (SM) och utvecklingsteamet som består av programmerare och testare . De arbetar tillsammans i iterativa tidslådor som kallas sprints.
Det första steget är att PO: n skapar produktstocken. Det är en att göra-lista över saker som ska göras av scrumteamet. Då väljer scrumteamet de topprioriterade objekten och försöker avsluta dem inom tidsrutan som kallas en sprint.
Ett enklare sätt att komma ihåg allt detta är att memorera 3-3-5-ramverket. Det betyder att ett scrumprojekt har tre roller, 3 artefakter och 5 händelser.
Dessa är -
Roller: PO, Scrum master och utvecklingsteam.
Artefakter: Produktbacklog, Sprint BacklogochProduktinkrement.
Evenemang: Sprint, Sprint planering, Daily Scrum, Sprint recension och Sprint retrospektiv.
Vi kommer att lära oss mer i detalj om var och en av dessa i våra efterföljande handledning.
# 2) Kanban
Kanban är en japansk term som betyder ett kort. Dessa kort innehåller information om det arbete som ska göras med programvaran. Syftet är visualisering. Varje teammedlem är medveten om det arbete som ska göras genom dessa visuella hjälpmedel.
Team använder dessa Kanban-kort för kontinuerlig leverans. Precis som Scrum är Kanban också för att hjälpa lagen att arbeta effektivt och främjar självstyrda och samarbetsgrupper.
Men det finns också skillnader mellan dessa två - som under en scrumsprint är de saker som ett team arbetar med fixade och vi kan inte lägga till objekt i sprinten medan vi i Kanban kan lägga till artiklar om det finns ledig kapacitet. Detta är särskilt användbart när kraven ändras ofta.
På samma sätt är en annan skillnad att medan scrum har definierade roller som en PO, scrum master och utvecklingsteam finns det inga sådana fördefinierade roller i Kanban.
En annan skillnad är att även om scrum föreslår en prioritering av produktbackloggar har Kanban inget sådant krav och det är helt frivilligt. Således kräver Kanban mindre organisation och undviker aktiviteter som inte tillför värde och är lämplig för de processer som kräver respons mot förändringar.
# 3) Lean
Lean är en filosofi som fokuserar på avfallsminskning. Hur gör det?
I lean delar du upp en process i värdeskapande aktiviteter, aktiviteter som inte tillför värde och viktiga aktiviteter som inte skapar värde. Alla aktiviteter som kan klassificeras som en icke-värdetillförande aktivitet är slöseri och vi bör försöka ta bort det slöseriet i processen för att göra det smalare.
En smalare process innebär snabbare leverans och mindre slöseri med uppgifter som inte hjälper till att uppnå lagmålen. Detta hjälper till att optimera varje steg i programvaruutvecklingscykeln. Därför anpassades lean-principerna från lean-tillverkning till mjukvaruutveckling.
Lean-mjukvaruutveckling kan användas i vilket IT-projekt som helst genom att tillämpa de sju lean-principerna som visas nedan:
Dessa är helt självförklarande som namnen antyder. Att eliminera slöseri är den första och viktigaste lean-principen och vi såg hur man gör det, vi klassificerar bara aktiviteter som värde och icke-värde.
En icke-värdetilläggsaktivitet kan vara vilken del av koden som helst som kan göra den mindre robust, öka ansträngningen och ta mycket tid utan att lägga till berättigat affärsvärde. Det kan också vara vaga användarberättelser eller dålig testning eller lägga till funktioner som inte krävs i helheten.
Den andra principen att förstärka lärandet är återigen lätt att förstå eftersom ett team behöver olika färdigheter för att leverera produkter i en snabbt föränderlig miljö med ny teknik som dyker upp i snabba varaktigheter.
Att fatta sena beslut kan vara givande under omständigheter där det minskar omarbetningen, som om det förväntas några förändringar, fördröj det bättre så att teamet inte behöver göra om arbetet när verksamheten behöver förändras.
Men det finns alltid en avvägning här eftersom lagen måste balansera detta med den fjärde principen att leverera snabbare. Försenad beslut bör inte påverka den totala leveransen och får inte sänka arbetet. Ett öga ska alltid vara på hela bilden.
Att ha bemyndigade lag är också mycket vanligt nuförtiden och det är något som även smidig antyder. Bemyndigade team är mer ansvarsfulla och kan fatta beslut snabbare. Känslan av ägande i ett bemyndigat team leder till bättre resultat. För att bemyndiga ett team bör de få organisera sig och fatta beslut på egen hand.
Således ser vi att magert och smidigt har mycket gemensamt med en skarp skillnad - medan magerteam kan hjälpa till att förfina en produkt, så är agila team de som faktiskt bygger produkten.
# 4) Extrem programmering (XP)
Extrem programmering är en annan mest populär agil teknik. Enligt extremeprogramming.org startade det första XP-projektet den 6 mars 1996. De nämner också att XP påverkar utvecklingen av programvaruprojekt på fem olika sätt - kommunikation, enkelhet, feedback, respekt och mod. Dessa kallas XP-värden.
Av dessa börjar allt med kommunikation. XP-team samarbetar regelbundet med affärsteam och andra programmerare och börjar bygga kod från första dagen. Fokus här är ansikte mot ansikte kommunikation så långt som möjligt med hjälp av de andra visuella hjälpmedlen.
Extrema programmerare bygger också en enkel kod och börjar få feedback om den från själva första dagen. Fokus ligger på att inte gå överbord eller förutsäga krav som inte har delats. Detta håller designen enkel och producerar precis den minimiprodukt som uppfyller kraven.
Feedback hjälper teamet att förbättra och producera en bättre kvalitet på arbetet. Detta hjälper dem att bygga respekt för varandra när de lär sig av varandra och lär sig att dela sina åsikter.
Detta ger dem också modet eftersom de vet att de har samlat allas bästa idéer och producerat en bra produkt med feedback från andra. De är alltså inte rädda för att inkludera förändringar eller få ytterligare feedback om sitt arbete.
Detta är särskilt användbart i projekt där kraven kommer att förändras ofta. Konstant feedback kommer att hjälpa lagen att inkludera dessa förändringar med mod.
Således har vi sett de olika smidiga metoderna som Scrum, XP, Kanban och Lean tillsammans med deras respektive fördelar och nackdelar.
Nu kan vi enkelt skilja mellan dem och också uppskatta de subtilare skillnaderna mellan dem. Vi lärde oss också grunderna för var och en av dessa metoder och såg hur vi kan använda dem i våra projekt när det behövs.
I nästa del, låt oss förstå allt om Scrum.
Scrummetodik
SCRUM är en process inom smidig metodik som är en kombination av den Iterativa modellen och den inkrementella modellen.
En av de största handikapparna för den traditionella Vattenfall modell var att - förrän den första fasen är klar flyttas ansökan inte till den andra fasen. Och av en slump, om det finns några förändringar i det senare skedet av cykeln, blir det väldigt utmanande att genomföra dessa förändringar, eftersom det skulle innebära att de tidigare faserna skulle omprövas och ändringarna göras om.
Några av de viktigaste egenskaperna för SCRUM inkluderar:
- Självorganiserat och fokuserat team.
- Inga enorma krav dokument, snarare har en mycket exakt och till punkt berättelser.
- De tvärfunktionella teamen arbetar tillsammans som en enhet.
- Stäng kommunikationen med användarrepresentanten för att förstå funktionerna.
- Har en bestämd tidslinje på högst en månad.
- Istället för att göra hela 'saken' åt gången gör Scrum lite av allt med ett givet intervall.
- Resursförmåga och tillgänglighet beaktas innan något begås.
För att förstå den här metoden väl är det viktigt att förstå de viktigaste terminologierna i SCRUM.
Läs också => Hur man levererar högvärdiga programvarufunktioner på kort tid med Agile Scrum Process
Viktiga SCRUM-terminologier
1) Scrum Team
Scrum-teamet är ett team bestående av 7 med + eller - två medlemmar. Dessa medlemmar är en blandning av kompetenser och består av utvecklare, testare, databaspersoner, supportpersoner etc. tillsammans med produktägaren och en scrummaster.
Alla dessa medlemmar arbetar tillsammans i nära samarbete för ett rekursivt och bestämt intervall för att utveckla och implementera nämnda funktioner. SCRUM-gruppens sittarrangemang spelar en mycket viktig roll i deras interaktion, de sitter aldrig i bås eller stugor utan ett stort bord.
2) Sprint
Sprint är ett fördefinierat intervall eller tidsram där arbetet måste slutföras och göra det klart för granskning eller redo för produktion. Denna tidsruta ligger vanligtvis mellan 2 veckor och 1 månad.
vilka är stadierna i sdlc
I vårt dagliga liv när vi säger att vi följer en månads sprintcykel betyder det helt enkelt att vi jobbar i en månad på uppgifterna och gör den redo för granskning i slutet av den månaden.
3) Produktägare
Produktägaren är huvudintressenten eller huvudanvändaren av applikationen som ska utvecklas. Produktägaren är den person som representerar kundsidan. Han / hon har den slutliga myndigheten och bör alltid vara tillgänglig för laget.
Han / hon ska kunna nås när någon har några tvivel som behöver förtydligas. Det är viktigt för produktägaren att förstå och inte tilldela några nya krav mitt i sprinten eller när sprinten redan har startat.
4) Scrum Master
Scrum Master är facilitator för scrumteamet. Han / hon ser till att scrumteamet är produktivt och progressivt. Vid hinder följer scrummästaren upp och löser dem för laget. SCRUM Master är medlare mellan PO och teamet.
Han / hon informerar PO om sprintens framsteg. Om det finns några spärrar eller bekymmer för teamet, diskuterar du med PO och får dem lösta. Liksom lagets Daily Standup sker en standup av SCRUM Master med PO varje dag.
Rekommenderad läsning => Hur man kan vara ett bra teammentor, coach och en riktig lagförsvarare i en smidig testvärld?
5) Affärsanalytiker (BA)
En affärsanalytiker spelar en mycket viktig roll i SCRUM. Den här personen är ansvarig för att få kravet färdigt och utarbetat i kravdokumenten (baserat på vilka användarberättelserna skapas).
Om det finns några tvetydigheter i kriterierna för användarberättelser / godtagande är han / hon den som kontaktas av det tekniska teamet (SCRUM) och han tar det sedan upp till PO eller annars om möjligt löser på egen hand. I storskaliga projekt kan det finnas mer än 1 BA men i småskaliga projekt kan SCRUM Master också fungera som BA.
Det är alltid bra att ha en BA när projektet startar.
6) Användarberättelse
Användarberättelser är inget annat än kraven eller funktionen som måste implementeras.
I scrum har vi inte dessa enorma kravdokument, utan kraven definieras i ett enda stycke, vanligtvis med formatet som:
Som en
jag vill
Att uppnå
Till exempel :
Som administratör vill jag ha ett lösenordslås om användaren anger ett felaktigt lösenord tre gånger i rad för att begränsa obehörig åtkomst.
Det finns vissa egenskaper hos användarberättelser som bör följas. Användarberättelserna bör vara korta, realistiska, kan uppskattas, fullständiga, förhandlingsbara och testbara. En användarberättelse ändras aldrig eller ändras mitt i Sprint.
Det är SCRUM Master och BA (om tillämpligt) som ansvarar för att se till att PO har ritat användarberättelserna korrekt med en korrekt uppsättning av acceptanskriterierna ”. Om några ändringar som kommer att påverka sprintfrigöringen ska göras, dras sådana berättelser ur sprinten eller görs enligt tillgängliga timmar.
Varje användarberättelse har ett acceptanskriterium som ska definieras väl och förstås av teamet.
Godtagningskriterierna beskrivs i användarberättelsen som tillhandahåller stödjande dokument. Det hjälper till att ytterligare förfina användarberättelsen. Alla från teamet kan skriva ner acceptanskriterierna. Testgruppen baserar sina testfall / villkor på dessa acceptanskriterier.
7) Epics
Epics är otvetydiga användarberättelser eller vi kan säga att det här är de användarberättelser som inte definieras och förvaras för framtida sprints.
Försök bara relatera det till livet, föreställ dig att du ska på semester. När du åker nästa vecka har du allt på plats som hotellbokningar, sightseeing, resenärskontroll etc. Men vad sägs om din semesterplan för nästa år? Du har bara en vag uppfattning att du kan åka till XYZ, men du har ingen detaljerad plan.
En epik är precis som du nästa års semesterplan, där du bara vet att du kanske vill åka, men vart, när, med vem, alla dessa detaljer har du ingen aning om vid denna tidpunkt.
På liknande sätt finns det funktioner som krävs för att implementeras i framtiden vars detaljer ännu inte är kända. För det mesta börjar en funktion med en Epic och delas sedan upp till berättelser som kan implementeras.
8) Produktbacklog
Produktbackloggen är en slags hink eller källa där alla användarberättelser förvaras. Detta underhålls av produktägaren. Produktstocken kan föreställas som en önskelista för produktägaren som prioriterar den enligt företagets behov.
Under planeringsmötet (se nästa avsnitt) tas en användarberättelse från produktens eftersläpning, sedan gör teamet brainstorming, förstår det och förfinar det och bestämmer kollektivt vilka användarberättelser som ska tas med produktägaren.
9) Sprintbacklog
Baserat på prioriteten tas användarberättelser från produktbackloggen i taget. Scrum-teamet brainstormar om det bestämmer genomförbarheten och bestämmer berättelserna för att arbeta med en viss sprint. Den kollektiva listan över alla användarberättelser som scrumteamet arbetar på en viss sprint kallas Sprint-eftersläpning.
10) Storypoäng
Berättelsepoäng är en kvantitativ indikation på komplexiteten i en användarberättelse. Baserat på berättelsen bestäms uppskattning och ansträngningar för en berättelse.
En berättelse är relativ och inte absolut. För att säkerställa att vår uppskattning och ansträngningar stämmer är det viktigt att kontrollera att användarberättelserna inte är stora. Ju mer exakt och mindre användarberättelsen är, desto mer exakt blir uppskattningen.
Varje användarberättelse tilldelas en berättelsepunkt baserad på Fibonacci-serien (1, 2, 3, 5, 8, 13 & 21). Högre är antalet, komplexet är historien.
Att vara precis
- Om du ger 1/2/3 berättelse betyder det att berättelsen är liten och med låg komplexitet.
- Om du ger poäng 5/8 är det ett mediumkomplex och
- 13 och 21 är mycket komplexa.
Här består komplexiteten av både utveckling och testansträngning.
För att avgöra en storypoint sker brainstorming inom scrumteamet och teamet bestämmer kollektivt en storypoint.
Det kan hända att utvecklingsteamet ger en berättelsepoäng på 3 till en viss historia, för det kan det vara 3 rader med kodändring, men testteamet ger 8 berättelsepoäng eftersom de känner att denna kodförändring kommer att påverka större moduler så testansträngningen skulle vara större. Oavsett vilken berättelse du ger, måste du motivera det.
Så i den här situationen händer brainstorming och teamet samtycker gemensamt till en historia.
När du bestämmer dig för en berättelsepunkt, tänk på följande faktorer:
- Beroendets beroende med annan applikation / modul.
- Resursens skicklighetsuppsättning.
- Historiens komplexitet.
- Historiskt lärande.
- Acceptkriterier för användarberättelsen.
Om du inte är medveten om en viss historia, ska du inte storleksanpassa den.
Närhelst en berättelse är = eller> 8 poäng delas den upp i två eller flera berättelser.
11) Bränn ned diagram
Nedbränt diagram är ett diagram som visar den beräknade v / s faktiska ansträngningen för scrumuppgifterna.
Det är en spårningsmekanism genom vilken de dagliga uppgifterna för en viss sprint spåras för att kontrollera om berättelserna fortskrider mot slutförandet av de engagerade berättelsespoängen eller inte.
Exempel : För att förstå detta, se nedanstående bild:
Jag antar:
- 2 veckors sprint (10 dagar)
- 2 resurser som faktiskt arbetar på sprinten.
'Berättelse' -> Den här kolumnen visar användarberättelserna tagna för sprinten.
'Uppgift' -> Den här kolumnen visar listan över uppgiften som är kopplad till användarberättelsen.
'Ansträngning' -> Den här kolumnen visar ansträngningen. Nu är denna åtgärd den totala ansträngningen för att slutföra uppgiften. Det visar inte den ansträngning som någon specifik individ har lagt ned.
“Dag 1 - Dag 10” -> Den här kolumnen visar de timmar som återstår för att slutföra berättelsen. Se till att timmen INTE är den timme som redan har gjorts MEN de timmar som fortfarande är kvar.
“Beräknad insats” -> Är insatsen totalt. För 'Start' är det helt enkelt summan av hela den enskilda uppgiften: SUM (C5: C15)
Ett totalt antal ansträngningar som måste slutföras på en dag är 70/10 = 7. Så i slutet av dag 1 bör ansträngningen minska till 70 - 7 = 63. På samma sätt beräknas det för alla dagar till dag 10, då den beräknade ansträngningen ska vara 0 (rad 16)
“Faktisk ansträngning kvar” -> Som namnet antyder, är ansträngningen faktiskt kvar för att slutföra historien. Det kan också hända att de faktiska ansträngningarna ökar eller minskar än den beräknade.
Du kan använda de inbyggda funktionerna och Diagrammet i Excel för att skapa detta nedtappningsdiagram.
Steg för nedbränt diagram är:
- Ange alla berättelser (Kolumn A5 - A15).
- Ange alla uppgifter (kolumn B5 - B15).
- Ange dagarna (dag 1 - dag 10).
- Ange startinsatserna (summera uppgifterna C5 - C15).
- Använd formeln för att beräkna 'Beräknade insatser' för varje dag (dag 1 till dag 10). Ange formeln vid D15 (C16- $ C $ 16/10) och dra den under alla dagar.
- För varje dag, ange de faktiska ansträngningarna. Ange formeln vid D17 (SUM (D5: D15)) för att summera de verkliga ansträngningarna som finns kvar och dra den under alla andra dagar.
- Välj det och skapa diagrammet enligt följande:
12) Hastighet
Det totala antalet storypoäng som ett scrumlag arkiverar i en sprint kallas Velocity. Scrum-teamet bedöms eller refereras till av dess hastighet. Med detta sagt bör man komma ihåg att målet här inte är att uppnå maximala berättelsepoäng, utan att ha en kvalitet som kan levereras med respekt för scrumlagets komfortnivå.
Till exempel : För en viss sprint: det totala antalet användarberättelser är 8 med berättelsespoäng enligt nedan.
Så här kommer hastigheten att vara summan av berättelsespoängen = 30
Definition av Done:
En sprint är markerad som Klar när alla berättelser är färdiga, all utveckling, forskning, QA-uppgifter är markerade som 'Slutförda', alla buggar är fixade-stängda annars de som kan göras senare (som inte helt relaterade eller är mindre viktiga) dras ut och läggs till i eftersläpningen, kodgranskningen och enhetstestningen är klar, de beräknade timmarna har uppfyllt de faktiska timmarna som lagts upp i uppgifterna och viktigast av allt har en framgångsrik demo ges till PO och intressenter.
Aktiviteter gjort i SCRUM-metodik
# 1) Planeringsmöte
Ett planeringsmöte är utgångspunkten för Sprint. Det är mötet där hela scrumteamet samlas, SCRUM Master väljer en användarberättelse baserat på prioriteten från produktbackloggen och teamets brainstorms på den.
Baserat på diskussionen bestämmer scrumteamet komplexiteten i berättelsen och dimensionerar den enligt Fibonacci-serien. Teamet identifierar uppgifterna tillsammans med de ansträngningar (i timmar) som skulle göras för att slutföra implementeringen av användarberättelsen.
Många gånger föregås planeringsmötet av ett ”Pre-Planning-möte”. Det är precis som läxor som scrumteamet gör innan de sitter på det formella planeringsmötet. Teamet försöker skriva ner beroenden eller andra faktorer som de vill diskutera i planeringsmötet.
# 2) Utförande av sprintuppgifter
Som namnet antyder är detta det verkliga arbetet som scrumteamet har utfört för att utföra sin uppgift och ta användarberättelsen till “Klar”.
# 3) Daglig standup
Under sprintcykeln träffas scrumteamet varje dag i högst 15 minuter (kan vara ett stand-up-samtal, rekommenderas att ha under början av dagen) och ange 3 poäng:
- Vad gjorde teammedlemmen igår?
- Vad planerade teammedlemmen att göra idag?
- Några hinder (vägspärrar)?
Det är Scrum-mästaren som underlättar detta möte. Om någon lagmedlem står inför någon form av svårigheter följer scrummästaren upp för att få det löst. I stand-ups granskas styrelsen också och visar i sig teamets framsteg.
# 4) Granskningsmöte
I slutet av varje sprintcykel träffas SCRUM-teamet igen och visar de implementerade användarberättelserna för produktägaren. Produktägaren kan kryssverifiera berättelserna enligt dess acceptanskriterier. Det är återigen Scrum-mästarens ansvar att leda detta möte.
Även i SCRUM-verktyget stängs Sprint och uppgifterna markeras som klara.
# 5) Retrospektivt möte
Det retrospektiva mötet sker efter granskningsmötet.
SCRUM-teamet möter, diskuterar och dokumenterar följande punkter:
- Vad gick bra under Sprint (Best practices)?
- Vad gick inte bra i Sprint?
- Lärdomar
- Åtgärdsposter.
Scrum-teamet bör fortsätta att följa bästa praxis, ignorera 'inte bästa praxis' och implementera de lärdomar som har dragits under de efterföljande sprintarna. Det retrospektiva mötet hjälper till att genomföra den ständiga förbättringen av SCRUM-processen.
Hur processen görs? Ett exempel!
Efter att ha läst om de tekniska jargongerna i SCRUM. låt mig försöka demonstrera hela processen med ett exempel.
Exempel:
Steg 1 : Låt oss ha ett SCRUM-team på 9 personer bestående av 1 produktägare, 1 Scrum master, 2 testare, 4 utvecklare och 1 DBA.
Steg 2 : Sprinten bestäms att följa en 4 veckors cykel. Så vi har en månad Sprint från 5 juni till 4thi juli.
Steg 3 : Produktägaren har den prioriterade listan över användarberättelser i produktbackloggen.
Steg 4: Laget beslutar att träffas 4thJuni för mötet ”Pre Planning”.
- Produktägaren tar en berättelse från produktbackloggen, beskriver den och lämnar den åt teamet att brainstorma om den.
- Hela teamet diskuterar och kommunicerar direkt till produktägaren för att ha tydligt förstått användarberättelsen.
- På liknande sätt tas olika andra användarberättelser. Om möjligt kan laget också gå vidare och storleksanpassa berättelserna.
Efter alla diskussioner går enskilda teammedlemmar tillbaka till sina arbetsstationer och
- Identifiera deras individuella uppgifter för varje berättelse.
- Beräkna det exakta antalet timmar som de kommer att arbeta med. Låt oss kontrollera hur medlemmen avslutar dessa timmar.
Totalt antal arbetstimmar = 9
Minus 1 timme för en paus, minus 1 timme för möten, minus 1 timme för e-post, diskussioner, felsökning etc.
Så den faktiska arbetstiden = 6.
Totalt antal arbetsdagar under Sprint = 21 dagar.
Totalt antal tillgängliga timmar = 21 * 6 = 126.
Medlemmen har ledighet i två dagar = 12 timmar (Detta varierar för varje medlem, vissa kan ta ledighet och andra kanske inte.)
Antal faktiska timmar = 126 - 12 = 114 timmar.
Detta innebär att medlemmen faktiskt kommer att vara tillgänglig i 114 timmar för denna sprint. Så han kommer att bryta ner sin individuella sprintuppgift på ett sådant sätt att totalt 114 timmar uppnås.
Steg 5 : På 5thi juni möts hela Scrum-teamet för ”Planeringsmöte”.
- Den slutliga domen av användarberättelsen från produktbackloggen är klar och berättelsen flyttas till Sprint Backlog.
- För varje berättelse förklarar varje lagmedlem sina identifierade uppgifter, om det behövs kan de diskutera dessa uppgifter, ändra storlek eller ändra storlek på dem (kom ihåg Fibonacci-serien !!).
- Scrummästaren eller teamet anger sina individuella uppgifter tillsammans med sina timmar för varje berättelse i ett verktyg.
- När alla berättelser är färdiga noterar Scrum-mästaren den inledande hastigheten och startar formellt Sprint.
Steg 6 : När Sprint har startat, baserat på de tilldelade uppgifterna, börjar varje lagmedlem arbeta med dessa uppgifter.
Steg 7 : Teamet träffas dagligen i 15 minuter och diskuterar 3 saker:
- Vad gjorde de igår?
- Vad de planerar att göra idag?
- Några hinder (vägspärrar)?
Steg 8 : Scrummästaren spårar framstegen dagligen med hjälp av ”Burn down chart”.
Steg 9 : Vid hinder följer Scrum-mästaren upp för att lösa dem.
Steg # 10 : På 4thI juli träffas teamet igen för granskningsmötet. En medlem visar den implementerade användarberättelsen för produktägaren.
Steg # 11 : På 5thI juli träffas laget igen för retrospektivet, där de diskuterar
- Vad gick bra?
- Vad gick inte bra?
- Åtgärdsposter.
Steg # 12 : Den 6thI juli träffas laget igen för ett möte inför nästa sprint och cykeln fortsätter.
SCRUM Aktivitetsverktyg
Det finns flera verktyg som kan användas i stor utsträckning för att spåra scrumaktiviteter.
Några av dem inkluderar:
I den kommande handledningen skulle vi kasta ljus över Agile Manifesto som är ett begrepp som driver effektiva Agile Teams.
Om Författarna: Denna serie är skriven av följande STH-teammedlemmar: Shruti Shrivastava - En professionell Scrum Master med 9 års erfarenhet inom BFSI-, e-handels- och B2B-domäner. Shruti är expert på automatiseringstestning och ledande scrumteam.Anshul Kumar Srivastava - En resultatorienterad professionell produktadministration och agil med 7 års erfarenhet inom BFSI och telekom.
Rekommenderad läsning
- Agile Scrum Online Quiz: Testa din kunskap om Agile Scrum
- Kanban vs Scrum vs Agile: En detaljerad jämförelse för att hitta skillnader
- Hur man levererar högvärdiga programvarufunktioner på kort tid med Agile Scrum Process
- Agile Manifesto: Förstå agila värden och principer
- SAFe Agile Tutorial: Vad är Scaled Agile Framework
- 30+ Top Scrum-intervjufrågor och svar (2021 LIST)
- Agile Vs Waterfall: Vilken är den bästa metoden för ditt projekt?
- Topp 31 Agile intervjufrågor och svar