Agile-methodologie: een beginnershandleiding voor Agile-methode en Scrum

agile methodology beginner s guide agile method

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Selecteer Het Besturingssysteem Kies Een Projectieprogramma (Optioneel)

Beschrijf Uw Probleem

Een complete gids voor Agile-methodologie: (20+ gedetailleerde tutorials over Agile Scrum-methodologie)

Dit is de gids voor softwareontwikkelaars en testers om het zeer bekende te begrijpen en eraan te werken Agile SCRUM-methodologie voor softwareontwikkeling en testen Leer de basale maar belangrijke terminologieën die in het Agile Scrum-proces worden gebruikt, samen met een echt voorbeeld van het volledige proces.

We hebben alle Agile Tutorials in deze serie voor uw gemak op een rijtje gezet. Ik hoop dat ze je enorm zullen helpen.

Behandelde onderwerpen: Wat is Agile, wat is Scrum, Agile-methodologie in softwareontwikkeling en -testen, Agile-testen, Agile Scrum-proces, Scrum-methodologie met Scrum Team en Scrum Master.

inleiding tot agile ontwikkeling

Wat je leert:

Agile Methodology Tutorials List

Tutorial # 1: Agile Scrum-methodologieën (Deze tutorial)
Tutorial # 2: Agile Manifest
Tutorial # 3: Scrum Team en hun rollen en verantwoordelijkheden
Tutorial # 4: Scrum-artefacten
Tutorial # 5: Scrum-evenementen
Tutorial # 6: Defect Triaging in Scrum
Tutorial # 7: Zelfvoorzienende Scrum-teams
Tutorial # 8: Drie Amigo-principe
Tutorial # 9: SAFe - Geschaald agile framework
Tutorial # 10: Agile Scrum-quiz

MEER aanbevolen Agile Scrum-tutorials:

Tutorial # 11: Top Agile schattingstechnieken
Tutorial # 12: Agile waterval hybride model
Tutorial # 13: Kanban versus Scrum versus Agile
Tutorial # 14: JIRA Agile-zelfstudie
Tutorial # 15: Agile retrospectieve vergaderingen
Tutorial # 16: Rol van bedrijfsanalisten in SCRUM
Tutorial # 17: De rol van QA in Scrum

Tools en interviewvragen:

Tutorial # 18: Agile testtools
Tutorial # 19: Beste Agile Project Management Tools
Tutorial # 20: Top Agile sollicitatievragen
Tutorial # 21: Top Scrum Interview Vragen

Laten we beginnen met de eerste tutorial in de serie - Agile Scrum-introductie.

Inleiding tot Agile Development

Agile in softwareontwikkeling:

Agile is een van 's werelds meest gebruikte en erkende raamwerken voor softwareontwikkeling.

De meeste organisaties hebben het in een of andere vorm aangenomen, maar er is nog een lange weg te gaan in de volwassenheid van hun adoptieprogramma's. Het enige doel van deze reeks tutorials is om technologie- en niet-technologische professionals in de Agile World te integreren.

We zullen u stap voor stap door het agile-traject leiden totdat u de filosofie achter het gebruik van Agile begrijpt, de voordelen ervan en hoe u het kunt oefenen. Deze serie is bedoeld om de lezers toe te rusten en in staat te stellen om Agile en Scrum leren toe te passen in hun werk.

Deze specifieke tutorial is bedoeld om u uit te leggen waarom er behoefte was aan Agile en hoe het werd gemaakt. Het fundamentele hier is om u het concept van Agile Adoption in Software Development Industries te laten begrijpen.

Geschiedenis van Agile

Agile werd geboren toen op een mooie dag 17 mensen met verschillende ontwikkelmethodologieën samenkwamen om te brainstormen over een mogelijke alternatieve oplossing voor softwareontwikkeling die zou kunnen leiden tot snellere ontwikkelingstijd en minder documentatie zwaar.

In die tijd duurde de softwareontwikkeling zo lang dat tegen de tijd dat projecten klaar waren om te worden opgeleverd, het bedrijf vooruit was gegaan en de vereisten waren veranderd. Een project was dus niet in staat om aan de zakelijke behoeften te voldoen, ook al kon het wel aan de gedefinieerde doelstellingen voldoen.

Zo kwamen deze voorvechters van verschillende software-engineeringtechnieken bij elkaar en het eindresultaat van hun ontmoeting was wat zij het 'agile manifest' noemden, dat we in de volgende tutorial van deze serie in detail zullen bespreken.

Maar de behendigheid die die dag werd geboren, is niet wat we vandaag in organisaties zien. De methodologie waarover de experts het eens waren, werd omschreven als ‘lichtgewicht’ en snel. Maar de belangrijkste overwinning van deze bijeenkomst was de gedachte dat een snellere levering van een product en constante feedback de sleutels waren tot succes bij softwareontwikkeling.

De bestaande watervaltechnieken waren te omslachtig en er was geen voorziening voor feedback totdat het eindproduct gereed was om te worden geleverd. Hierdoor was er geen ruimte voor koerscorrectie en had de klant pas zicht op de voortgang als het hele product gereed was. En dat wilden deze experts vermijden.

Ze wilden een oplossing met ruimte voor constante feedback om de kosten van nabewerking in een later stadium te vermijden.

Agile uitdagingen

De bestaande watervaltechnieken waren op dat moment te omslachtig en er was geen voorziening voor feedback totdat het eindproduct gereed was om te worden geleverd. Het werd een watervalmodel van ontwikkeling genoemd omdat de teams eerst een stap helemaal afmaakten en pas daarna doorgingen naar de volgende stap.

Hierdoor was er geen ruimte voor koerscorrectie en had de klant pas zicht op de voortgang als het hele product gereed was. En dat wilden deze experts vermijden. Ze wilden een oplossing met ruimte voor constante feedback om de kosten van nabewerking in een later stadium te vermijden.

En daarom gaat agile ook over adaptief zijn en continue verbetering, evenals over constante feedback en snelheid van levering.

Wat zijn Agile-beloften?

Agile beloften

Agile gaat niet alleen over het toepassen van de vaste werkwijzen bij het ontwikkelen van software. Het brengt ook een verandering in de mentaliteit van het team met zich mee, wat hen ertoe aanzet om betere software te bouwen, samen te werken en uiteindelijk een tevreden klant te maken.

Agile waarden en principes stellen het team in staat om hun focus te verleggen en hun denkproces om betere software te bouwen te veranderen.

Wat is Agile precies?

Agile is geen set regels. Agile is geen set richtlijnen. Agile is niet eens een methodologie. Agile is eerder een reeks principes die flexibiliteit, aanpassingsvermogen, communicatie en werkende software aanmoedigen boven plannen en processen. Het is zeer beknopt vastgelegd in wat het agile manifest wordt genoemd.

Agile softwareontwikkeling stelt het team in staat om efficiënter en effectiever samen te werken bij het ontwikkelen van complexe projecten. Het bestaat uit oefeningen die iteratieve en incrementele technieken oefenen die gemakkelijk kunnen worden toegepast en geweldige resultaten opleveren.

Om Agile in actie toe te passen, hebben we verschillende op Agile gebaseerde methoden en methodologieën. Deze methoden en methodologieën voorzien in alle behoeften van een softwareontwikkelingsindustrie, van softwareontwerp en -architectuur, ontwikkeling en testen tot projectbeheer en leveringen.

Niet alleen dat, Agile-methoden en -methodologieën bieden ook ruimte voor procesverbetering als integraal onderdeel van elke levering.

Agile is een benadering van softwareontwikkeling waarbij een zelfvoorzienend en multifunctioneel team werkt aan het leveren van continue leveringen door middel van iteraties en zich gedurende het proces ontwikkelt door feedback te verzamelen van de eindgebruikers.

Hoe Agile te oefenen?

Er zijn verschillende Agile Methodieken die in de praktijk worden toegepast in verschillende gediversifieerde industrieën.

flexibele methodologieën

De meest populaire methodologieën zijn echter:

Scrum
Kanban
Extreem programmeren

Al deze methodologieën zijn gericht op slanke softwareontwikkeling en helpen bij het effectief en efficiënt bouwen van betere software.

Dat is alles met Agile Introductie. Het deel is gestructureerd om u te helpen de kernwaarden en principes te begrijpen die zullen worden aangenomen om een team te laten werken in een Agile-modus en -mentaliteit.

Behendig Methodologie

Inleiding tot Agile-modellen:

Agile methodologie

welke laag van het OSI-model werkt met frames?

Zoals we allemaal weten, is Agile een methodologie voor softwareontwikkeling.

We hebben ook geleerd over de waarden en principes die in het agile manifest door de oprichters van agile genoemd werden. In onze eerste gesprekken gingen we ook voorbij aan de verschillen tussen agile en de traditionele watervalmodellen.

In deze tutorial maken we kennis met de voor- en nadelen van de agile methodiek.

We zullen zien wat scrum is? en hoe verschilt het van agile. Dan zullen we de verschillende agile-methodologieën begrijpen die door verschillende organisaties worden gebruikt en hoe we agile kunnen implementeren door ze te gebruiken.

U zult ook het verschil en ook de voor- / nadelen van deze methodologieën kunnen waarderen.

Voordelen van Agile-methodologie

Hieronder staan de verschillende voordelen van Agile Methodology:

De klanten krijgen aan het einde van elke iteratie / sprint continu een kijkje en gevoel van de voortgang van het project.
Elke sprint biedt de klant een werkende software die voldoet aan hun verwachtingen volgens de door hen verstrekte definitie van gedaan.
De ontwikkelingsteams reageren behoorlijk goed op de veranderende eisen en kunnen zelfs in de gevorderde ontwikkelingsstadia aanpassingen maken.
Er is een constante tweerichtingscommunicatie waardoor de klanten betrokken blijven, zodat alle belanghebbenden - zakelijk en technisch - duidelijk zicht hebben op de voortgang van het project.
Het ontwerp van het product is efficiënt en voldoet aan de zakelijke vereisten.

Nadelen van Agile-methodologie

Hoewel er verschillende voordelen zijn van de Agile-methodologie, zijn er ook bepaalde nadelen aan verbonden.

Zij zijn:

# 1) Uitgebreide documentatie heeft niet de voorkeur, wat ertoe kan leiden dat agile teams dit verkeerd interpreteren omdat agile geen documentatie nodig heeft. Dus de strengheid gaat verloren op documentatie. Dit moet worden vermeden door uzelf voortdurend af te vragen of dit voldoende informatie is om door te gaan of niet.

#twee) Soms zijn aan het begin van de projecten de eisen niet glashelder. De teams kunnen doorgaan en ontdekken dat de visie van de klanten opnieuw is afgestemd en in dergelijke situaties moeten de teams veel veranderingen doorvoeren en is het ook moeilijk om het eindresultaat te peilen.

Soorten Agile-methodologieën

Er zijn verschillende agile methodologieën in de praktijk over de hele wereld. We gaan meer in detail leren over vier van de meest populaire.

Agile methodologieën typen

# 1) Scrum

Scrum kan gemakkelijk worden beschouwd als het meest populaire agile framework. De term ‘scrum’ wordt door de meeste beoefenaars veel beschouwd als synoniem voor ‘agile’. Maar dat is een misvatting. Scrum is slechts een van de frameworks waarmee u agile kunt implementeren.

Het woord scrum komt van sportrugby. Waar de spelers samen kruipen in een in elkaar grijpende positie en tegen de tegenstanders duwen. Elke speler heeft een bepaalde rol in zijn positie en kan zowel aanvallend als verdedigend spelen, afhankelijk van de eisen van de situatie.

Evenzo gelooft de scrum in IT in krachtige zelfsturende ontwikkelingsteams met drie specifieke en duidelijk gedefinieerde rollen. Deze rollen omvatten - Product Owner (PO), Scrum Master (SM) en het ontwikkelteam bestaande uit de programmeurs en testers Ze werken samen in iteratieve tijdsboxen, sprints genaamd.

De eerste stap is het creëren van de product backlog door de PO. Het is een takenlijst met dingen die het scrumteam moet doen. Vervolgens selecteert het scrumteam de items met de hoogste prioriteit en probeert het deze af te maken binnen het tijdvak dat een sprint wordt genoemd.

Een gemakkelijkere manier om dit alles te onthouden, is door het 3-3-5-raamwerk te onthouden. Het betekent dat een scrumproject 3 rollen, 3 artefacten en 5 gebeurtenissen heeft.

Dit zijn

Rollen: PO, Scrum-master en ontwikkelingsteam.

Artefacten: Product Backlog, Sprint BacklogenProductstijging.

Evenementen: Sprint, Sprint-planning, Dagelijkse Scrum, Sprintbeoordeling en Sprint retrospectief.

3-3-5 kader

We zullen in onze volgende tutorials meer in detail over elk van deze te weten komen.

# 2) Kanban

Kanban is een Japanse term die een kaart betekent. Deze kaarten bevatten details van het werk dat aan de software moet worden gedaan. Het doel is visualisatie. Elk teamlid is door deze visuele hulpmiddelen op de hoogte van het werk dat moet worden gedaan.

Teams gebruiken deze Kanban-kaarten voor continue levering. Net als Scrum is Kanban ook bedoeld om de teams te helpen effectief te werken en om zelfsturende en samenwerkende teams te promoten.

Maar er zijn ook verschillen tussen deze twee - zoals tijdens een scrumsprint staan de items waaraan door een team wordt gewerkt vast en kunnen we geen items aan de sprint toevoegen, terwijl we in Kanban items kunnen toevoegen als er beschikbare capaciteit is. Dit is vooral handig wanneer de vereisten vaak veranderen.

Evenzo is een ander verschil dat hoewel de scrum de rollen van een PO, scrummaster en ontwikkelingsteam heeft gedefinieerd, er geen dergelijke vooraf gedefinieerde rollen in Kanban zijn.

Een ander verschil is dat, hoewel de scrum een prioritering van productachterstanden suggereert, Kanban een dergelijke vereiste niet heeft en volledig optioneel is. Kanban vereist dus minder organisatie en vermijdt activiteiten die geen waarde toevoegen en is geschikt voor de processen die reactievermogen op veranderingen vereisen.

# 3) Mager

Lean is een filosofie die zich richt op afvalvermindering. Hoe doet het dat?

Bij lean verdeelt u een proces in waardetoevoegende activiteiten, niet-waardetoevoegende activiteiten en essentiële niet-waardetoevoegende activiteiten. Elke activiteit die kan worden aangemerkt als een activiteit die geen waarde toevoegt, is een verspilling en we moeten proberen die verspilling in het proces te verwijderen om het slanker te maken.

Een gestroomlijnder proces betekent snellere levering en minder inspanning die wordt verspild aan taken die niet helpen om de teamdoelen te bereiken. Dit helpt om elke stap in de softwareontwikkelingscyclus te optimaliseren. Daarom werden de lean-principes aangepast van lean manufacturing naar softwareontwikkeling.

Lean-softwareontwikkeling kan in elk IT-project worden gebruikt door de zeven lean-principes toe te passen die hieronder worden weergegeven:

zeven lean principes

Deze spreken voor zich, zoals hun namen suggereren. Het elimineren van verspilling is het eerste en belangrijkste lean-principe en we hebben gezien hoe we dat moeten doen, we classificeren activiteiten gewoon als waarde en niet-toegevoegde waarde.

Een activiteit die geen waarde toevoegt, kan elk deel van de code zijn dat deze minder robuust maakt, de inspanning vergroot en veel tijd in beslag neemt zonder dat er gerechtvaardigde bedrijfswaarde wordt toegevoegd. Het kunnen ook vage gebruikersverhalen zijn of slecht testen of het toevoegen van functies die niet vereist zijn in het grote geheel.

Het tweede principe dat leren versterkt is, is weer gemakkelijk te begrijpen, aangezien een team verschillende vaardigheden nodig heeft om producten te leveren in een snel veranderende omgeving met nieuwe technologieën die snel opduiken.

Het nemen van late beslissingen kan lonend zijn in omstandigheden waarin het herwerk vermindert, zoals als er veranderingen worden verwacht, stel het dan beter uit zodat het team het werk niet opnieuw hoeft uit te voeren als de bedrijfsbehoeften veranderen.

Maar er is hier altijd een afweging, omdat de teams dit in evenwicht moeten brengen met het vierde principe van sneller leveren. Uitstel van beslissingen mag geen invloed hebben op de algehele uitvoering en mag het werktempo niet verminderen. Eén oog moet altijd op het volledige plaatje gericht zijn.

Het hebben van mondige teams is tegenwoordig ook heel gebruikelijk en dit is iets dat zelfs agile suggereert. Empowered teams zijn meer verantwoordelijk en kunnen sneller beslissingen nemen. Het gevoel van eigenaarschap in een empowered team leidt tot betere resultaten. Om een team kracht bij te zetten, moeten ze de mogelijkheid krijgen om zichzelf te organiseren en zelf beslissingen te nemen.

We zien dus dat lean en agile veel gemeen hebben met één groot verschil - terwijl lean teams kunnen helpen om een product te verfijnen, zijn agile teams degenen die het product daadwerkelijk bouwen.

# 4) Extreme programmering (XP)

Extreme programmering is een andere meest populaire agile-techniek. Volgens extremeprogramming.org werd het eerste XP-project gestart op 6 maart 1996. Ze vermelden ook dat XP de ontwikkeling van softwareprojecten op 5 verschillende manieren beïnvloedt: communicatie, eenvoud, feedback, respect en moed. Dit worden de waarden van XP genoemd.

Hieruit begint het allemaal met communicatie. XP-teams werken regelmatig samen met bedrijfsteams en collega-programmeurs en beginnen vanaf de eerste dag met het bouwen van code. Hierbij ligt de focus zoveel mogelijk op face-to-face communicatie met behulp van de andere visuele hulpmiddelen.

Extreme programmeurs bouwen ook een eenvoudige code en krijgen er vanaf de eerste dag zelf feedback op. De focus ligt op het niet overdrijven of het voorspellen van vereisten die niet zijn gedeeld. Dit houdt het ontwerp eenvoudig en levert slechts het minimale product op dat aan de eisen voldoet.

Feedback helpt het team om het werk te verbeteren en een betere kwaliteit te produceren. Dit helpt hen respect voor elkaar op te bouwen terwijl ze van elkaar leren en leren hoe ze hun mening kunnen delen.

Dit geeft hen ook de moed omdat ze weten dat ze de beste ideeën van iedereen hebben verzameld en een goed product hebben geproduceerd met feedback van anderen. Ze zijn dus ook niet bang om wijzigingen door te voeren of om verdere feedback op hun werk te krijgen.

Dit is vooral handig bij projecten waar de eisen vaak zullen veranderen. Constante feedback zal de teams helpen om deze veranderingen met moed op te nemen.

We hebben dus de verschillende agile methodologieën gezien, zoals Scrum, XP, Kanban en Lean, samen met hun respectievelijke voor- en nadelen.

Nu kunnen we gemakkelijk onderscheid maken tussen hen en ook de subtielere verschillen tussen hen waarderen. We leerden ook de basisprincipes van elk van deze methodologieën en zagen hoe we ze in onze projecten konden toepassen wanneer dat nodig was.

Laten we in het volgende deel alles over Scrum begrijpen.

Scrum-methodologie

SCRUM is een proces in agile methodologie dat een combinatie is van het iteratieve model en het incrementele model.

Een van de grootste handicaps van de traditionele Waterval model was dat - totdat de eerste fase is voltooid, gaat de applicatie niet naar de andere fase. En als er zich in de latere fase van de cyclus enkele veranderingen voordoen, wordt het toevallig een hele uitdaging om die veranderingen door te voeren, aangezien het zou betekenen dat de eerdere fasen opnieuw moeten worden bekeken en de veranderingen opnieuw moeten worden uitgevoerd.

Agile scrum-testen

Enkele van de belangrijkste kenmerken van SCRUM zijn:

Zelfgeorganiseerd en gefocust team.
Geen enorme vereiste documenten, maar een zeer precieze en to the point verhalen.
De multifunctionele teams werken samen als een enkele eenheid.
Nauwe communicatie met de gebruikersvertegenwoordiger om de functies te begrijpen.
Heeft een duidelijke tijdlijn van maximaal één maand.
In plaats van het hele 'ding' in één keer te doen, doet Scrum een beetje van alles met een bepaald interval.
De capaciteit en beschikbaarheid van middelen worden overwogen voordat iets wordt vastgelegd.

Om deze methodologie goed te begrijpen, is het belangrijk om de belangrijkste terminologieën in SCRUM te begrijpen.

Lees ook Hoe u hoogwaardige softwarefuncties in een korte periode kunt leveren met behulp van Agile Scrum-proces

Belangrijke SCRUM-terminologieën

1) Scrum-team

Het scrumteam is een team van 7 met + of - twee leden. Deze leden zijn een mix van competenties en bestaan uit ontwikkelaars, testers, databasemensen, ondersteuningsmensen etc. samen met de producteigenaar en een scrummaster.

Al deze leden werken nauw samen voor een recursief en welomlijnd interval om de genoemde functies te ontwikkelen en te implementeren. SCRUM-teamzitopstelling speelt een zeer belangrijke rol in hun interactie, ze zitten nooit in hokjes of hutten, maar een enorme tafel.

Scrum-team

2) Sprint

Sprint is een vooraf gedefinieerd interval of tijdsbestek waarin het werk moet worden voltooid en gereed moet worden gemaakt voor beoordeling of gereed voor productie-implementatie. Dit tijdvak ligt meestal tussen 2 weken en 1 maand.

maak een string-array in java

Als we in ons dagelijks leven zeggen dat we de Sprint-cyclus van 1 maand volgen, betekent dit simpelweg dat we een maand aan de taken werken en deze tegen het einde van die maand klaar maken voor evaluatie.

3) Product Owner

De product owner is de key stakeholder of de hoofdgebruiker van de te ontwikkelen applicatie. De product owner is de persoon die de klantzijde vertegenwoordigt. Hij / zij heeft de uiteindelijke bevoegdheid en moet altijd beschikbaar zijn voor het team.

Hij / zij moet bereikbaar zijn als iemand twijfels heeft die verduidelijking behoeven. Het is belangrijk voor de product owner om in het midden van de sprint of wanneer de sprint al is begonnen te begrijpen en geen nieuwe eis toe te kennen.

4) Scrum Master

Scrum Master is de facilitator van het scrumteam. Hij / zij zorgt ervoor dat het scrumteam productief en progressief is. In het geval van eventuele belemmeringen, volgt de scrummaster deze op en lost deze op voor het team. SCRUM Master is de bemiddelaar tussen de PO en het team.

Hij / zij houdt de PO op de hoogte van de voortgang van de Sprint. Als er obstakels of problemen zijn voor het team, bespreekt u dit met de PO en zorgt ervoor dat deze worden opgelost. Net als de Daily Standup van het team, vindt er elke dag een stand-up van de SCRUM Master met de PO plaats.

Aanbevolen om te lezen Hoe word je een goede teammentor, coach en een echte teamverdediger in een agile testwereld?

5) Bedrijfsanalist (BA)

Een Business Analist speelt een zeer belangrijke rol in SCRUM. Deze persoon is verantwoordelijk voor het finaliseren en opstellen van de vereiste in de vereiste documenten (op basis waarvan de gebruikersverhalen worden gemaakt).

Als er onduidelijkheden zijn in de gebruikersverhalen / acceptatiecriteria, is hij / zij degene die wordt benaderd door het technische (SCRUM) team en neemt hij het vervolgens over naar de PO of lost hij indien mogelijk zelf op. Bij grootschalige projecten kan er meer dan 1 BA zijn, maar bij kleinschalige projecten kan de SCRUM Master ook als BA fungeren.

Het is altijd een goede gewoonte om een BA te hebben als het project begint.

6) Gebruikersverhaal

Gebruikersverhalen zijn niets anders dan de vereisten of functie die moet worden geïmplementeerd.

In de scrum hebben we niet die enorme requirementsdocumenten, maar worden de vereisten gedefinieerd in een enkele alinea, meestal met de volgende indeling:

Als een
ik wil
Bereiken

Bijvoorbeeld

Als beheerder wil ik een wachtwoordvergrendeling hebben voor het geval de gebruiker 3 opeenvolgende keren een onjuist wachtwoord invoert om ongeautoriseerde toegang te beperken.

Er zijn enkele kenmerken van gebruikersverhalen die moeten worden nageleefd. De gebruikersverhalen moeten kort, realistisch, geschat, volledig, onderhandelbaar en toetsbaar zijn. Een user story wordt nooit midden in de Sprint aangepast of gewijzigd.

Het is de verantwoordelijkheid van de SCRUM Master en de BA (indien van toepassing) om ervoor te zorgen dat de PO de User Stories correct heeft opgesteld met een juiste set van Acceptatiecriteria ”. Als er wijzigingen moeten worden aangebracht die van invloed zijn op de sprintrelease, worden dergelijke verhalen uit de sprint gehaald of worden ze gedaan volgens de beschikbare uren.

Elk gebruikersverhaal heeft een acceptatiecriterium dat goed moet worden gedefinieerd en begrepen door het team.

Acceptatiecriteria beschrijven het gebruikersverhaal dat de ondersteunende documenten levert. Het helpt om het gebruikersverhaal verder te verfijnen. Iedereen van het team kan de acceptatiecriteria opschrijven. Het testteam baseert zijn testcases / condities op deze acceptatiecriteria.

7) Epics

Epics zijn dubbelzinnige user stories of we kunnen zeggen dat dit de user stories zijn die niet gedefinieerd zijn en bewaard worden voor toekomstige sprints.

Probeer het gewoon in verband te brengen met het leven, stel je voor dat je op vakantie gaat. Als je volgende week gaat, heb je alles op zijn plaats, zoals je hotelboekingen, bezienswaardigheden, reischeques, enz. Maar hoe zit het met je vakantieplan voor volgend jaar? Je hebt alleen een vaag idee dat je naar XYZ-plaats mag gaan, maar je hebt geen gedetailleerd plan.

An Epic is net als je vakantieplan voor volgend jaar, waarbij je gewoon weet dat je misschien wel wilt gaan, maar waar, wanneer, met wie, al deze details, heb je op dit moment geen idee.

Op een vergelijkbare manier zijn er functies die in de toekomst moeten worden geïmplementeerd waarvan de details nog niet bekend zijn. Meestal begint een functie met een Epic en wordt vervolgens opgesplitst in verhalen die kunnen worden geïmplementeerd.

8) Productachterstand

De product backlog is een soort bucket of bron waar alle user stories worden bijgehouden. Dit wordt onderhouden door de Product Owner. De productachterstand kan worden voorgesteld als een verlanglijst van de producteigenaar die er prioriteit aan geeft volgens de zakelijke behoeften.

Tijdens het planningsgesprek (zie volgende paragraaf) wordt één user story uit de product backlog gehaald, vervolgens brainstormt het team, begrijpt het en verfijnt het en besluit samen met tussenkomst van de product owner welke user stories er mee gaan.

9) Sprint Backlog

Op basis van de prioriteit worden gebruikersverhalen een voor een uit de Product Backlog gehaald. Het Scrum-team brainstormt erover, bepaalt de haalbaarheid en beslist over de verhalen om aan een bepaalde sprint te werken. De collectieve lijst van alle user stories waarmee het scrumteam aan een bepaalde sprint werkt, staat bekend als Sprint backlog.

Sprint achterstand

10) Verhaalpunten

Storypoints zijn een kwantitatieve indicatie van de complexiteit van een user story. Op basis van het verhaalpunt worden de inschatting en inspanningen voor een verhaal bepaald.

Een verhaalpunt is relatief en niet absoluut. Om er zeker van te zijn dat onze inschatting en inspanningen kloppen, is het belangrijk om te controleren of de gebruikersverhalen niet groot zijn. Hoe nauwkeuriger en kleiner het gebruikersverhaal is, des te nauwkeuriger zal de schatting zijn.

Elk gebruikersverhaal wordt toegewezen aan een verhaalpunt op basis van de Fibonacci-reeks (1, 2, 3, 5, 8, 13 & 21). Hoger is het nummer, het complex is het verhaal.

Precies zijn

Als je een 1/2/3 verhaalpunt geeft, betekent dit dat het verhaal klein en laag is.
Als je punten geeft als 5/8, is het een gemiddeld complex en
13 en 21 zijn zeer complex.

Hier bestaat complexiteit uit zowel ontwikkeling als testinspanning.

Om een verhaalpunt te bepalen, wordt er gebrainstormd binnen het scrumteam en bepaalt het team gezamenlijk een verhaalpunt.

Het kan gebeuren dat het ontwikkelteam een verhaalpunt van 3 geeft aan een bepaald verhaal, omdat het voor hen misschien 3 regels codewijziging zijn, maar het testteam geeft 8 verhaalpunt omdat ze het gevoel hebben dat deze codewijziging invloed heeft op grotere modules, dus de testinspanning zou groter zijn. Welk verhaalpunt je ook geeft, je moet het rechtvaardigen.

Dus in deze situatie wordt er gebrainstormd en gaat het team collectief akkoord met één verhaalpunt.

Houd bij elke beslissing over een verhaalpunt rekening met de onderstaande factoren:

De afhankelijkheid van het verhaal met andere applicatie / module.
De vaardigheidsset van de resource.
De complexiteit van het verhaal.
Historisch leren.
Acceptatiecriteria van het gebruikersverhaal.

Als je een bepaald verhaal niet kent, pas het dan niet op maat aan.

Telkens wanneer een verhaal = of> 8 punten is, wordt het opgesplitst in 2 of meer verhalen.

11) Burn-down grafiek

Burn-down chart is een grafiek die de geschatte v / s werkelijke inspanning van de scrumtaken laat zien.

Het is een volgmechanisme waarmee voor een bepaalde sprint de dagelijkse taken worden gevolgd om te controleren of de verhalen vorderen in de richting van de voltooiing van de toegewijde verhaalpunten of niet.

Voorbeeld : Raadpleeg de onderstaande afbeelding om dit te begrijpen:

Burn Down-diagram 1

Ik heb aangenomen:

2 weken sprint (10 dagen)
2 middelen die daadwerkelijk aan de sprint werken.

'Verhaal' -> Deze kolom toont de gebruikersverhalen die voor de sprint zijn gemaakt.

'Taak' -> Deze kolom toont de lijst van de taak die aan het gebruikersverhaal is gekoppeld.

'Inspanning' -> Deze kolom toont de inspanning. Deze maat is nu de totale inspanning om de taak te voltooien. Het geeft niet de inspanning weer die door een specifiek individu is geleverd.

'Dag 1 - Dag 10' -> Deze kolom (men) toont de uren die er over zijn om het verhaal te voltooien. Let erop dat het uur NIET het uur is dat al gedaan is, MAAR de uren die nog over zijn.

'Geschatte inspanning' -> Is het totaal van de inspanning. Voor de 'Start' is het gewoon de som van de gehele individuele taak: SUM (C5: C15)

Een totaal aantal inspanningen dat in 1 dag moet worden voltooid, is 70/10 = 7. Dus aan het einde van dag 1 zou de inspanning moeten verminderen tot 70 - 7 = 63. Op een vergelijkbare manier wordt het berekend voor alle dagen tot dag 10, wanneer de geschatte inspanning 0 zou moeten zijn (rij 16)

'Werkelijke inspanning resterend' -> Zoals de naam al doet vermoeden, is de inspanning eigenlijk overgebleven om het verhaal te voltooien. Het kan ook gebeuren dat de feitelijke inspanningen toenemen of afnemen dan geschat.

U kunt de ingebouwde functies en Grafiek in Excel gebruiken om deze burndown-grafiek te maken.

Burn Down Chart-stappen zijn:

Voer alle verhalen in (kolom A5 - A15).
Voer alle taken in (kolom B5 - B15).
Voer de dagen in (dag 1 - dag 10).
Voer de startinspanningen in (som de taken C5 - C15 op).
Pas de formule toe om de 'geschatte inspanningen' voor elke dag te berekenen (dag 1 tot en met dag 10). Voer de formule in op D15 (C16- $ C $ 16/10) en sleep deze voor alle dagen.
Voer voor elke dag de werkelijke inspanningen in. Voer de formule in op D17 (SUM (D5: D15)) om de werkelijke resterende inspanningen op te tellen en sleep deze voor alle andere dagen.
Selecteer het en maak het diagram als volgt:

Burn Down-diagram 2

12) Snelheid

Het totale aantal storypoints dat een scrumteam archiveert in een sprint, wordt Velocity genoemd. Het Scrum-team wordt beoordeeld of verwezen naar zijn snelheid. Dat gezegd hebbende, moet in gedachten worden gehouden dat het doel hier NIET is om de maximale verhaalpunten te bereiken, maar om een kwalitatief hoogstaand product te hebben, met respect voor het comfortniveau van het scrumteam.

Bijvoorbeeld : Voor een bepaalde sprint: het totale aantal gebruikersverhalen is 8 met verhaalpunten, zoals hieronder weergegeven.

Scrum-snelheid

Dus hier is de snelheid de som van de verhaalpunten = 30

Definitie van gedaan:

Een Sprint wordt gemarkeerd als Gereed wanneer alle verhalen zijn voltooid, alle ontwikkel-, onderzoeks-, QA-taken zijn gemarkeerd als 'Voltooid', alle bugs zijn opgelost-gesloten anders degene die later kunnen worden gedaan (zoals niet volledig gerelateerd of minder belangrijk) worden uitgetrokken en toegevoegd aan de backlog, de code review en unit testing is voltooid, de geschatte uren hebben voldaan aan de werkelijke uren die in de taken zijn gestoken en het belangrijkste is dat er een succesvolle demo is gegeven aan de PO en de belanghebbenden.

Activiteiten uitgevoerd in SCRUM-methodologie

# 1) Vergadering plannen

Een planningsgesprek is het uitgangspunt van Sprint. Het is de bijeenkomst waar het hele scrumteam samenkomt, de SCRUM Master selecteert een user story op basis van de prioriteit uit de product backlog en het team brainstormt erover.

Op basis van de discussie bepaalt het scrumteam de complexiteit van het verhaal en bepaalt het de afmetingen volgens de Fibonacci-serie. Het team identificeert de taken samen met de inspanningen (in uren) die zouden worden gedaan om de implementatie van het gebruikersverhaal te voltooien.

Vaak wordt de planningsvergadering voorafgegaan door een “Pre-Planning meeting”. Het is net als huiswerk dat het scrumteam doet voordat ze voor de formele planningsbijeenkomst gaan zitten. Het team probeert de afhankelijkheden of andere factoren op te schrijven die ze in het planningsgesprek willen bespreken.

# 2) Uitvoering van sprinttaken

Zoals de naam suggereert, zijn dit het daadwerkelijke werk dat door het scrumteam wordt gedaan om hun taak te volbrengen en het gebruikersverhaal in de status 'Gereed' te brengen.

# 3) Dagelijkse stand-up

Tijdens de sprintcyclus komt het scrumteam elke dag bijeen voor niet meer dan 15 minuten (kan een stand-up call zijn, aanbevolen aan het begin van de dag) en noemt 3 punten:

Wat heeft het teamlid gisteren gedaan?
Wat was het teamlid van plan vandaag te doen?
Eventuele belemmeringen (wegversperringen)?

Het is de Scrum-master die deze bijeenkomst faciliteert. In het geval dat een teamlid met problemen wordt geconfronteerd, volgt de scrummaster om het op te lossen. Bij Stand-ups wordt ook het bord beoordeeld en toont op zichzelf de voortgang van het team.

# 4) Herzieningsvergadering

Aan het einde van elke sprintcyclus komt het SCRUM-team weer samen en demonstreert de geïmplementeerde user stories aan de product owner. De producteigenaar kan de verhalen kruiselings verifiëren volgens de acceptatiecriteria. Het is opnieuw de verantwoordelijkheid van de Scrum-master om deze bijeenkomst te leiden.

Ook in de SCRUM-tool wordt de Sprint afgesloten en worden de taken gemarkeerd als voltooid.

# 5) Retrospectieve bijeenkomst

De nacontrole vindt plaats na de review meeting.

Het SCRUM-team ontmoet, bespreekt en documenteert de volgende punten:

Wat ging er goed tijdens de Sprint (Best practices)?
Wat ging er niet goed in de Sprint?
Les geleerd
Actie-items.

Het Scrum-team moet de best practices blijven volgen, de 'not best practices' negeren en de geleerde lessen tijdens de daaropvolgende sprints implementeren. De retrospectieve bijeenkomst helpt om de continue verbetering van het SCRUM-proces te implementeren.

Hoe verloopt het proces? Een voorbeeld!

Na gelezen te hebben over de technische jargons van SCRUM. laat me proberen het hele proces te demonstreren met een voorbeeld.

Voorbeeld:

Stap 1 : Laten we een SCRUM-team hebben van 9 mensen, bestaande uit 1 producteigenaar, 1 Scrum-master, 2 testers, 4 ontwikkelaars en 1 DBA.

Stap 2 : De Sprint is besloten om een cyclus van 4 weken te volgen. We hebben dus een Sprint van 1 maand van 5 juni tot 4 juni^thvan juli.

Stap 3 : De Product Owner heeft de geprioriteerde lijst met user stories in de product backlog.

Stap 4: Het team besluit om op 4 te ontmoeten^thJuni voor de 'Pre Planning' meeting.

De product owner haalt 1 verhaal uit de product backlog, beschrijft het en laat het aan het team over om erover te brainstormen.
Het hele team bespreekt en communiceert rechtstreeks met de producteigenaar om het gebruikersverhaal duidelijk te hebben begrepen.
Op een vergelijkbare manier worden verschillende andere gebruikersverhalen gemaakt. Indien mogelijk kan het team doorgaan en de verhalen ook op maat maken.

Na alle discussie gaan individuele teamleden terug naar hun werkplekken en

Identificeer hun individuele taken voor elk verhaal.
Bereken het exacte aantal uren waarop ze gaan werken. Laten we eens kijken hoe het lid deze uren afsluit.

Totaal aantal werkuren = 9
Min 1 uur voor een pauze, min 1 uur voor vergaderingen, min 1 uur voor e-mails, discussies, probleemoplossing etc.
Dus de werkelijke werkuren = 6.
Totaal aantal werkdagen tijdens de Sprint = 21 dagen.
Totaal aantal beschikbare uren = 21 * 6 = 126.
Het lid is 2 dagen met verlof = 12 uur (dit verschilt per lid, sommigen kunnen verlof opnemen en anderen niet.)
Aantal werkelijke uren = 126 - 12 = 114 uur.

Dit betekent dat het lid daadwerkelijk 114 uur beschikbaar zal zijn voor deze sprint. Hij zal zijn individuele sprinttaak dus zo afbreken dat in totaal 114 uur wordt gehaald.

Stap # 5 : Op de 5^thvan juni komt het hele Scrum-team bijeen voor de “Planning Meeting”.

Het definitieve oordeel van het gebruikersverhaal uit de product backlog is gedaan en het verhaal wordt verplaatst naar de Sprint Backlog.
Voor elk verhaal geeft elk teamlid zijn geïdentificeerde taken aan, indien nodig kunnen ze een discussie hebben over die taken, het formaat of de grootte wijzigen (denk aan de Fibonacci-reeks !!).
De Scrum-master of het team voeren hun individuele taken samen met hun uren voor elk verhaal in een tool in.
Nadat alle verhalen zijn voltooid, noteert de Scrum-master de initiële Velocity en start formeel de Sprint.

Stap # 6 : Zodra de Sprint is gestart, op basis van de toegewezen taken, begint elk teamlid aan die taken te werken.

Stap # 7 : Het team komt dagelijks 15 minuten bijeen en bespreekt 3 zaken:

Wat hebben ze gisteren gedaan?
Wat zijn ze van plan vandaag te doen?
Eventuele belemmeringen (wegversperringen)?

Stap # 8 : De scrum master houdt dagelijks de voortgang bij met behulp van “Burn down chart”.

Stap # 9 : In het geval van enige belemmering, volgt de Scrum-master om deze op te lossen.

Stap # 10 : Op 4^thIn juli komt het team weer samen voor de beoordelingsvergadering. Een lid demonstreert het geïmplementeerde gebruikersverhaal aan de producteigenaar.

Stap # 11 : Op 5^thIn juli komt het team weer samen voor de Retrospective, waar ze discussiëren

Wat ging goed?
Wat ging er niet goed?
Actie-items.

Stap # 12 : Op 6^thIn juli komt het team opnieuw samen voor de pre-planning meeting voor de volgende sprint en de cyclus gaat verder.

scrum agile methodologieproces

SCRUM-activiteitstools

Er zijn verschillende tools die op grote schaal kunnen worden gebruikt voor het volgen van scrum-activiteiten.

Sommigen van hen zijn:

In de komende tutorial zouden we licht werpen op het Agile Manifest, een idee dat effectieve Agile Teams aandrijft.

Volgende tutorial

Over de Auteurs: Deze serie is geschreven door de volgende STH-teamleden: Shruti Shrivastava - Een professionele Scrum Master met 9 jaar ervaring in BFSI-, E-commerce- en B2B-domeinen. Shruti is een expert in automatiseringstests en leidt scrumteams.

Anshul Kumar Srivastava - Een resultaatgerichte productmanagementprofessional en Agile-beoefenaar met 7 jaar ervaring in de BFSI- en telecomsector.

Aanbevolen literatuur

Agile Scrum Online Quiz: test uw kennis van Agile Scrum
Kanban versus Scrum versus Agile: een gedetailleerde vergelijking om verschillen te vinden
Hoe u hoogwaardige softwarefuncties in een korte periode kunt leveren met behulp van Agile Scrum-proces
Agile Manifesto: Agile waarden en principes begrijpen
SAFe Agile-zelfstudie: wat is Scaled Agile Framework
30+ Top Scrum Interview Vragen en Antwoorden (2021 LIST)
Agile versus waterval: wat is de beste methode voor uw project?
Top 31 Agile interviewvragen en antwoorden