Agile schattingstechnieken: een echte schatting in een agile project

agile estimation techniques

Echte schattingen in een Agile-project: een compleet inzicht met voorbeelden van Agile-schattingen

Het is erg cruciaal om Agile Estimation op verschillende niveaus te doen. Dit wordt gedaan voor een goede planning, beheer en inschatting van de totale inspanningen die we gaan gebruiken voor het implementeren, testen en leveren van het gewenste product aan de klanten in termen van tijd binnen de gestelde deadlines.

Bij gebrek aan schattingen in Agile Project, is er mogelijk geen goede planning en beheer die kunnen eindigen in het leveren van het ongewenste product en daardoor de klant ontevreden achterlaten.

Verhaalpunt Inschattingen worden gedaan in Agile-projecten met behulp van verschillende technieken zoals Planning Poker, Bucket System, Affinity Mapping, enz. Voor dit doel worden verschillende schattingssjablonen op verschillende niveaus gebruikt, zoals Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , User Story-sjabloon etc.

Wat je leert:

• Invoering
• Verhaal geeft schattingen aan in Agile
• Aanbevolen tool
• Verschillende Agile schattingstechnieken
  • # 1) Planning van poker
  • # 2) T-shirtmaten
  • # 3) Stemmen met punten
  • # 4) Het emmersysteem
  • # 5) Groot / onzeker / klein
  • # 6) Affiniteit in kaart brengen
  • # 7) Bestelmethode
• Budget berekenen in Agile
• Schattingsjablonen in Agile-ontwikkelingsproject
  • 1) Agile Projectplansjabloon:
  • 2) Agile Release Plan-sjabloon:
  • 3) Agile Product Backlog-sjabloon:
  • 4) Agile Sprint Backlog-sjabloon:
  • 5) Agile Testplan-sjabloon:
  • 6) Agile User Story-sjabloon:
  • 7) Agile Road Map-sjabloon:
• Stadia van schattingen in Agile-project
  • # 1) Schatting van voorstel of projectniveau
  • # 2) Schatting van het vrijgaveniveau
  • # 3) Schatting van het sprintniveau
• Gevolgtrekking
• Aanbevolen literatuur

Invoering

Hieronder staan ​​de 3 belangrijkste niveaus van Agile Estimation.

# 1) Project- of voorstelniveau is degene die Quick Function Point Analysis gebruikt tijdens de eerste fasen van de projectontwikkeling.

# 2) Vrijgaveniveau omvat het toewijzen van verhaalpunten aan de gebruikersverhalen die kunnen helpen bij het bepalen van de volgorde van de gebruikersverhalen op basis van de prioriteit en die ook kunnen helpen beslissen welke verhalen kunnen worden opgenomen in de huidige release en welke later kunnen worden opgenomen.

# 3) Sprintniveau is degene waar de gebruikersverhalen zijn onderverdeeld in de taken en de geschatte uren worden toegewezen aan de taken op basis van hun complexiteit. Hier definiëren we ook de persoon die verantwoordelijk is voor de taak, samen met de status van de taken.

Deze informatie kan later worden gebruikt om het budget voor het Agile-project te berekenen. Berekening van het budget is cruciaal om ervoor te zorgen dat het project het budget niet overschrijdt vanwege de pre- en post-iteratietaken of om andere redenen.

Verhaal geeft schattingen aan in Agile

Story Points-schattingen is een vergelijkende analyse om de productachterstand-items globaal te schatten met relatieve omvang. De teamleden voor het schatten van user stories zijn onder meer: ​​Product Owner, Scrum Master, Developers, Testers en Stakeholders.

Hieronder volgen enkele stappen om de uiteindelijke beslissing over de relatieve grootte te nemen:

# 1) Analyseer alle gebruikersverhalen en identificeer het basis- of referentieverhaal. Het is belangrijk voor relatieve maatvoering. Dit verhaal kan gekozen worden uit de huidige product backlog of degene die we eerder hebben gedaan. Dit verhaal moet met instemming van alle leden worden gekozen als het referentieverhaal.

#twee) Kies een ander verhaal uit de huidige Product Backlog en de teamleden zijn vrij om eventuele vragen of twijfels met de Product Owner te bespreken, terwijl ze de vereisten van het verhaal begrijpen. Product Owner is verantwoordelijk voor het verhelderen van al hun vragen en twijfels.

# 3) Maak een lijst van de dingen die u moet doen tijdens het implementeren van het gebruikersverhaal. Dit kan gedaan worden door notities te schrijven in het notitiegedeelte van de tool of door opsommingstekens toe te voegen aan de verhaalkaart. Dit wordt meestal gedaan door de Scrum Master.

# 4) Hieronder staan ​​enkele veelgestelde vragen onder de deelnemers:

• Ontwerp: Wat is de voorafgaande en verplichte kennis die we moeten hebben voordat we eraan beginnen te werken?
• Codering: Hoeveel codering is vereist om dit gebruikersverhaal te implementeren. Zijn we eerder een soortgelijk gebruikersverhaal tegengekomen?
• Testen van een eenheid: Zijn er nepobjecten vereist om unit-tests uit te voeren voor dit gebruikersverhaal?
• Integratietesten: Heeft dit verhaal invloed op de andere functionaliteiten van dezelfde module en ook op andere modules?
• Acceptatietest: Wat zijn de aandachtspunten om het gewenste product te leveren zoals gewenst door de klanten?
• Expertise: Heeft een van de deelnemers eerder een soortgelijk verhaal gedaan en is er een expert in?

# 5) Maak een relatieve grootte voor het geselecteerde verhaal. Als het dezelfde hoeveelheid werk en inspanning vereist, wijs het dan hetzelfde nummer toe. van punten, zoals toegewezen aan het referentieverhaal. Als het meer inspanning vereist, wijs het dan een hogere waarde toe. Als het minder moeite kost, wijs het dan een lagere waarde toe.

# 6) Bereik een consensus met alle deelnemers om de relatieve grootte voor het geselecteerde gebruikersverhaal te bepalen volgens de definitie van done.

wat is de netwerkbeveiligingssleutel op de router

# 7) Nadat de relatieve grootte van alle productachterstanditems is uitgevoerd, moet u ervoor zorgen dat alle gebruikersverhalen met hetzelfde nr. van de punten die aan hen zijn toegewezen, vereisen dezelfde inspanning en omvang om consistent te zijn.

Aanbevolen tool

# 1) Agile poker

Agile poker is een bekende app voor Jira voor snelle en gemakkelijke planning en schattingen voor zowel teams op afstand als op dezelfde locatie.

Aan de slag gaan met Agile Poker is eenvoudig en gemakkelijk omdat het werd geïnspireerd door drie industriestandaard schattingsmethoden: Planning Poker®, Wideband Delphi en Magic Estimation (ook bekend als Silent Grouping, Affinity Estimation, Swimlanes Sizing of Relative Estimations).

Verschillende Agile schattingstechnieken

Er zijn veel technieken om schattingen te doen in een Agile Project. De belangrijkste principes voor het maken van schattingen zijn onder meer relatieve schatting, discussies om meer informatie te krijgen over items waarvan de schattingen moeten worden gemaakt en ervoor te zorgen dat het hele team zich inzet voor de taken die aan hen zijn toegewezen.

Er zijn voornamelijk 7 Agile projectschattingstechnieken:

# 1) Planning van poker

• Bij deze Estimation-techniek zitten alle mensen die verondersteld worden de schattingen te doen, in een ronde cirkel voor de Planning Poker-sessie.
• Elke schatter heeft een set Planning Pokerkaarten met waarden: 0,1,2,3,5,8,13,20,40 en 100. Deze waarden vertegenwoordigen verhaalpunten of maatstaven waarin het team schat.
• Aan het begin van de sessie leest de producteigenaar of klant het gebruikersverhaal voor, waarin alle kenmerken en vereisten worden beschreven.
• Nadat het verhaal is voorgelezen, vinden de gesprekken tussen de schatters en met de producteigenaar / klant plaats. De schatters kunnen vragen stellen of hun twijfels ophelderen bij de product owner.
• Na de discussies wordt aan alle schatters gevraagd om één kaart te selecteren om een ​​gebruikersverhaal te schatten. Als alle schatters dezelfde waarde geven, wordt dat de definitieve schatting.
• Als de waarden verschillen, leggen de schatters die de hoogste en laagste waarden geven, hun mening uit en waarom ze deze waarde hebben gekozen, totdat er een consensus is bereikt.
• Een goede techniek als hij klein is. van items wordt geschat in een klein team.

=> Meer gedetailleerde lezing op Planning Poker Schatting Techniek ​

# 2) T-shirtmaten

• Net als bij T-shirts zien we de maten: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). Hier volgt een vergelijkbare aanpak: artikelen worden geschat in T-shirtmaten.
• Dit is een perfecte techniek om een ​​ruwe schatting te geven van de grote achterstand aan items.
• Handig wanneer een snelle en ruwe schatting moet worden gemaakt. Later kunnen deze formaten worden omgezet in nee's volgens de vereisten.
• Een relatieve grootte (meestal Medium) wordt bepaald na onderling overleg en akkoord van de teamleden of schatters. Vervolgens worden de nee's aan de items toegewezen volgens de relatieve grootte die is toegewezen aan Middelgrote.
• Nadeel: Wat voor iemand L lijkt, lijkt misschien XL voor iemand.
• Alle schatters kennen hun eigen maat toe aan de items. Na besprekingen en het oplossen van de mismatches, wordt een consensus bereikt om de definitieve schatting te krijgen.

# 3) Stemmen met punten

• Dit is in feite een rangschikkingsmethode om de volgorde van de Product Backlog te bepalen, van verhalen met de hoogste prioriteit tot verhalen met de laagste prioriteit. Dit wordt gedaan om de belangrijkste verhalen te selecteren die moeten worden voortgezet.
• Om hiermee te beginnen, plaats je alle gebruikersverhalen samen met hun beschrijving op de muur of het bord met behulp van gele plakbriefjes of op een manier die ze onderscheidt door het ontvangen van de stemmen.
• Alle belanghebbenden krijgen 4 tot 5 stippen (meestal in de vorm van stickers, pennen of markers kunnen ook worden gebruikt om stippen te maken).
• Alle stakeholders wordt gevraagd om hun stem uit te brengen op de user stories die ze verkiezen.
• Product Owner bestelt de product backlog-items van de meest geprefereerde (een met het meeste aantal stippen) naar de minst geprefereerde (een met het minste aantal stippen).
• Het kan zijn dat er maar weinig belanghebbenden zijn die niet tevreden zijn met het besluit dat is genomen. In dit geval worden de user stories na de discussies verdeeld in 3 groepen: hoge prioriteit, lage prioriteit en gemiddelde prioriteit. Gebruikersverhalen met hoge prioriteit worden op de muur geplaatst om de stemmen te ontvangen. Dit wordt gedaan totdat de definitieve bestelling is bereikt met instemming van alle belanghebbenden.

# 4) Het emmersysteem

• Het is een goede techniek bij een groot nee. van items zijn te schatten door groot aantal. van deelnemers. Het is sneller en redelijker dan Planning Poker.
• Er worden verschillende buckets gemaakt met waarden: 0,1,2,3,4,5,8,13,20,30,50,100, 200 Dit kan indien nodig worden uitgebreid. Deze emmers zijn niets anders dan kaarten die waarden vertegenwoordigen die opeenvolgend op een tafel zijn gerangschikt.
• De verhalen moeten daarbinnen worden geplaatst waar de schatter ze geschikt acht. Alle te schatten items staan ​​op de kaarten.
• Kies willekeurig een item en stop het in bucket 8. Dit wordt alleen ter referentie gebruikt. Kies willekeurig een ander verhaal, bespreek al zijn kenmerken en vereisten met de groep en plaats het bij consensus in de juiste emmer. Op dezelfde manier wordt het derde artikel gepickt en in een geschikte emmer geplaatst.
• De volgorde van de bucket kan ook worden gewijzigd, voor het geval de groep vindt dat het eerste gekozen item bij bucket 1 moet horen in plaats van bucket 8.
• Verdeel en heers aanpak wordt gevolgd. Alle overige items worden verdeeld over alle deelnemers. Alle deelnemers kunnen het item plaatsen zonder goedkeuring van andere deelnemers.
• De items moeten correct worden geplaatst. Er kan geen item tussen de emmers worden geplaatst.
• Als een deelnemer het product backlog item niet begrijpt of als de andere deelnemers klaar zijn met het plaatsen van hun user stories, dan kunnen de user stories worden overgedragen aan de andere deelnemers.
• Eindelijk wordt Sanity check uitgevoerd door alle deelnemers. Als een deelnemer een verkeerde bucket vindt die aan een item is toegewezen, kan hij dit onder de aandacht van andere deelnemers brengen en met hen bespreken. Dit wordt gedaan totdat er een consensus is bereikt over de volledige productachterstand.
• De facilitator moet controleren of niemand de items verplaatst, tenzij de geestelijke gezondheid wordt gecontroleerd.
• Dit wordt ook gedaan om de prioriteitsvolgorde van de product backlog-items te bereiken.

# 5) Groot / onzeker / klein

• Dit is een ruwe versie en is de vereenvoudiging van het emmersysteem waar er slechts drie maten zijn: groot, klein en onzeker.
• De deelnemers of schatters wordt gevraagd om de items in een van de categorieën te plaatsen. Allereerst worden de simpele user stories gekozen en in de grote en kleine categorieën geplaatst. Vervolgens worden de complexe items opgepakt.
• Het is een goede techniek als er vergelijkbare items in de Product Backlog staan.

# 6) Affiniteit in kaart brengen

• Een goede techniek als het team klein is en nee. van de achterstanden is minder.
• De eerste stap is Silent Relative Sizing: Op een muur wordt een kaart met ‘Kleiner’ erop geschreven aan de meest linkse kant en de kaart met ‘Groter’ erop wordt aan de meest rechtse kant geplaatst. Product Owner biedt een subset van de items aan alle deelnemers. Alle deelnemers wordt gevraagd om elk item op maat te maken in verhouding tot de maten op de kaarten aan de muur, rekening houdend met de inspanning die nodig is om ze te implementeren. Het is de individuele beslissing van de deelnemer zonder enige discussie met de andere teamleden. Product Owner of stakeholder is aanwezig om de twijfels van de deelnemer op te helderen. Product Backlog-items die te dubbelzinnig zijn om door de teamleden te worden begrepen voor een schatting, worden afzonderlijk geplaatst. Het duurt 5-20 minuten.
• Bewerken van muur: De teamleden kunnen de locatie van de items aan de muur wijzigen. Ze kunnen ontwerp- en implementatievereisten bespreken met de andere teamleden. Deze activiteit kan worden afgesloten als er weinig verandering aan de muur plaatsvindt. Het duurt ongeveer 20-60 minuten ​
• Items op de juiste locaties plaatsen: Na de besprekingen plaatst het team de items in de productachterstand op hun relatieve en geschikte posities. We kunnen hier T-shirtmaten, Fibonacci-series etc. gebruiken om de maat van de items relatief te schatten.
• Product Owner Challenge: De Product Owner kan enige discrepantie vinden in de schattingen van het team en moet meer functies of de vereisten voor een item met het team bespreken. Na besprekingen worden definitieve inschattingen gemaakt.
• Exporteren naar Project Backlog Management Tool: Om er zeker van te zijn dat de informatie over de definitieve schattingen niet verloren gaat, exporteert u deze naar een product backlog management tool.

# 7) Bestelmethode

• Een goede techniek als grote nee. van items en kleine nr. van de mensen zijn daar.
• Het geeft nauwkeurige relatieve maten voor de productachterstand-items.
• Er wordt een schaal opgesteld van laag naar hoog. Alle items worden er willekeurig op geplaatst. Elke deelnemer wordt gevraagd om een ​​item op de weegschaal tegelijk te verplaatsen. De beweging kan één omhoog, één omlaag zijn of de draai aan een ander lid overdragen.
• Dit gaat door totdat alle deelnemers tevreden zijn en geen enkel item op de weegschaal willen verplaatsen.
• Dit geeft ook de prioriteitsvolgorde van de Product Backlog-items.

Budget berekenen in Agile

Het berekenen van budgetten speelt een belangrijke rol bij Agile projecten. Dit wordt gedaan om er zeker van te zijn wat het werkelijk verstrekte budget is, welk budget er nog meer nodig is en hoe we het budget gaan verdelen over verschillende product backlog items.

Het gebruikt de gegevens die zijn verzameld van de vorige projecten en gebruikt de wiskundige formule om het geschatte budget voor het huidige project te krijgen.

Hieronder staat de volgorde van de stappen om het budget in een Agile project te berekenen:

# 1) Maak een lijst van alle vereisten van het project en voer de schattingen voor hen met behulp van Planning Poker, Bucket System, Fibonacci-serie enz. Alle teamleden moeten het eens worden over de schattingen die zijn gemaakt voor de vermelde vereisten na duidelijke analyse en begrip van de gebruikersverhalen. Er worden schattingen gemaakt op basis van de functies die in een gebruikersverhaal moeten worden geïmplementeerd.

#twee) Bepaal de duur van de iteraties genaamd Sprints en product backlog-items die eraan zijn toegewezen. Het duurt meestal 2 tot 3 weken. De gebruikersverhalen worden in een reeks gekozen, beginnend met het gebruikersverhaal met maximale prioriteit, naar een lagere prioriteit en aan het einde met het gebruikersverhaal met de minste prioriteit. Dit helpt om te beslissen welke user stories moeten worden opgepikt in de eerste Sprint en welke stories later kunnen worden opgepakt.

# 3) Bereid een uitgebrande grafiek voor om een ​​duidelijk beeld te geven van hoeveel werk er nog moet worden verzet en hoeveel tijd er nog over is voor implementatie. Het geeft in feite de voortgang van een agile team weer. Het geeft een duidelijk beeld van hoe het team zich gedraagt ​​en hoe het zich moet gedragen.

De voortgang van het team wordt gemeten in termen van voltooide taken, resterende inspanning, ideale burndown en resterende taken, zoals hieronder wordt weergegeven:

# 4) Voeg extra kosten toe, zoals de aanschaf van apparatuur, tools, infrastructuurondersteuning, licenties voor de te gebruiken softwaretools, projectbeheertools, antivirusinstallatie en updates.

# 5) Voeg budgetten voor en na de iteratie toe. Alle agile-leden zouden crossfunctioneel moeten zijn, maar er zijn grenzen aan. Alles wat een teamlid buiten zijn expertise doet, wordt beschouwd als pre-iteratiewerk of post-iteratiewerk. Deze pre- en post iteratiewerkzaamheden vereisen extra budget voor implementatie.

# 6) De verborgen risico's in de gaten houden. Risico's in het Agile-project zijn onder meer: ​​risico dat het project het budget overschrijdt, afwezigheid van teamleden, leden niet over een duidelijke of volledige kennis beschikken, niet over de vereiste vaardigheden beschikken, deadlines zijn overschreden enz.

Schattingsjablonen in Agile-ontwikkelingsproject

Er zijn veel schattingssjablonen die op verschillende niveaus worden opgesteld in het Agile-ontwikkelingsproject. Het enige doel is om duidelijk de schattingen te vermelden die nodig zijn om een ​​vereiste of item te implementeren en de voortgang ervan te volgen.

De belangrijkste sjablonen zijn zoals hieronder vermeld:

1) Agile Projectplansjabloon:

Het geeft een overzicht op hoog niveau van hoeveel tijd er nodig is om de kenmerken van de vereisten te leveren en wat hun status is. Het vermeldt ook de persoon die verantwoordelijk is voor een specifieke taak.

(Opmerking: klik op een afbeelding voor een vergrote weergave)

2) Agile Release Plan-sjabloon:

Het geeft vrijgavedetails van de taken die overeenkomen met de vereisten, samen met hun status en Sprint waarin ze moeten worden uitgevoerd.

3) Agile Product Backlog-sjabloon:

Het beschrijft de volledige productachterstand die voor het project is gedefinieerd. Het geeft details van de taken van de Sprints samen met de status, prioriteit, verhaalpunten en of ze zijn toegewezen aan een Sprint of dat er een extra taak is, zoals defecten enz.

4) Agile Sprint Backlog-sjabloon:

Het geeft een beschrijving van de user stories die genoemd worden in de backlog van een bepaalde Sprint. Het geeft het totale aantal verhaalpunten weer dat aan een gebruikersverhaal is toegewezen en hoe deze zijn opgedeeld in verschillende taken. Het geeft ook de status van de bijbehorende taken en wat het dagelijkse werk is voor de bijbehorende taken.

5) Agile Testplan-sjabloon:

Het splitst het hele testscenario op in subscenario's. Het geeft details van de sub-scenario's zoals implementatiedatum, verwacht resultaat, feitelijk resultaat, status etc.

Het vermeldt ook de projectnaam, compatibele browser, versie van de te testen applicatie, testcase-ID voor een geselecteerd scenario, geschreven door, getest door, beschrijving, enz.

6) Agile User Story-sjabloon:

Het geeft de details die specifiek zijn voor de analyse van het gebruikersverhaal, zoals: Wat zijn de rollen die nodig zijn om een ​​specifieke functionaliteit te testen, wat is de voorafgaande vereiste (omgeving ingesteld en koppelingen ingeschakeld) en wat is het verwachte resultaat?

7) Agile Road Map-sjabloon:

Het geeft richting aan het project in het bedrijf, op korte en lange termijn. Het helpt bij het stellen van verwachtingen binnen het bedrijf. En het overzicht van waar het project naartoe gaat.

Stadia van schattingen in Agile-project

In een Agile Project worden schattingen gedaan op 3 niveaus, zoals hieronder vermeld:

• Project- / voorstelniveau: De totale functionele omvang van de hele applicatie wordt geschat met behulp van de Quick Function Point Analysis (QFPA) -methode wanneer alleen vereisten van hoog niveau beschikbaar zijn.
• Vrijgaveniveau: Verhaalpunten worden toegewezen aan de gebruikersverhalen die helpen bij het bepalen van de nee. van geplande releases binnen een project en de nr. van gebruikersverhalen die moeten worden opgenomen in een release en sprint.
• Sprintniveau: Binnen een sprint worden geschatte uren toegewezen aan de taken van de user stories. Dit wordt gedaan om de inzet van de ontwikkeling voor het leveren van user stories in een sprint zeker te stellen.

S1, S2, S3, S4, S5, S6 zijn sprints.

# 1) Schatting van voorstel of projectniveau

Het is een schatting van zeer hoog niveau voor het project. Het richt zich op het totale aantal vereisten in het item Product Backlog. Functiepunten worden gebruikt om de omvang van de software / het project in te schatten voordat een gedetailleerde beschrijving van de functionele eisen wordt gedocumenteerd.

Functiepunten zijn de algemeen aanvaarde manier om de grootte van de software te berekenen. Het richt zich op de functionaliteiten in de softwareprojecten. Een functiepunt is een metriek die de vereisten of gebruikersverhalen omzet in een getal.

Tijdens de beginfase van het project wordt aanbevolen om de Quick Function Point Analysis (QFPA) -methode toe te passen.

Snelle functiepuntanalysemethode is een unieke benadering voor het schatten van FP wanneer alleen vereisten op hoog niveau beschikbaar zijn.

Hoe de totale functionele grootte te berekenen?

• Begrijp alle functionaliteiten van een applicatie met behulp van domeinexperts.
• Identificeer en som alle mogelijke functionaliteiten van een applicatie op.
• Gegevensopslagfuncties worden geclassificeerd in interne logische bestanden (gegevens die intern in de toepassing zijn opgeslagen) en externe interfacebestanden (gegevens die alleen voor referentiedoeleinden worden gebruikt).
• Transactiefuncties worden ingedeeld in externe invoer (gegevens afkomstig van externe bronnen naar toepassing), externe uitvoer (afgeleide gegevens gaan van toepassing naar buiten) en externe vragen (gegevens opgehaald uit een of meer externe invoer en externe uitvoer).
• Bereken de FP-grootte voor elke functie door de gemiddelde complexiteit ervan te berekenen.
• Som de FP-grootte van alle functies op om de totale functionele grootte van de applicatie te krijgen.
• Minstens twee personen met expertise in FP-analyse moeten onafhankelijk berekenen, resultaten matchen en de verschillen oplossen.

Voorbeeld voor schatting op projectniveau:

Hieronder vindt u de lijst met vereisten voor een project, zoals in Product Backlog:

• Een gebruiker moet op de website kunnen inloggen door de gebruikersnaam en het wachtwoord op te geven.
• Als u succesvol inlogt, moet een gebruiker naar de hoofdpagina worden geleid met gedefinieerde rechter- en linkerpanelen.
• Een gebruiker moet de mogelijkheid hebben om uit te loggen bij de applicatie.
• Een geldige gebruiker heeft de mogelijkheid om het wachtwoord te wijzigen door de huidige inloggegevens op te geven.

Het team gebruikt een snelle FP-schatting om de projectgrootte te schatten.

Hieronder volgt de analyse:

• De gegevensopslagfunctie hier is het opslaan van de gebruikersreferenties om in te loggen en het wachtwoord te wijzigen.
• Omdat de inloggegevens worden opgeslagen binnen de toepassingsgrens, worden ze opgeslagen in ILF's (Internal Logical Files).
• De transactiefuncties omvatten:
  • Gebruikerslogin en weergave van de hoofdpagina.
  • Uitloggen gebruiker en weergave van uitlogscherm.
  • Mogelijkheid om het wachtwoord te wijzigen.

Hieronder staan ​​de stappen die worden uitgevoerd om de projectgrootte te schatten met behulp van snelle functiepuntanalyse:

STAP # 1: Maak een lijst van alle datafuncties

UFP (Unadjusted Function Point) is overgenomen uit de Caper Jones-tabel.

STAP # 2: Maak een lijst van alle transactiefuncties

UFP (Unadjusted Function Point) is overgenomen uit de Caper Jones-tabel.

STAP # 3: Afleiden van de geschatte projectgrootte in Functiepunten

UFP = gegevens FP + transactie FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (uitgaande van VFP (waardeaanpassingsfactor = 1)

Productiviteit = 16 FP / maand (normale standaard)

Inspanning = FP / Productiviteit = 22/16 persoonsmaand = 1,37 persoonsmaand

# 2) Schatting van het vrijgaveniveau

Releaseschattingen worden gedaan tijdens de releaseplanning. Het is de volgende activiteit na schatting op projectniveau. De geprioriteerde vereisten zijn ontleend aan de Product Backlog in de vorm van gebruikersverhalen.

De user stories worden geschat in termen van story points tijdens de releaseplanning die zich richt op het inschatten van de omvang van de software die voor die release moet worden geleverd. Op deze manier is het aantal releases en het totaal aantal verhaalpunten in elke release gepland.

Een verhaalpunt vertegenwoordigt in feite de relatieve inspanning die nodig is om een ​​functie of de functionaliteit te implementeren, in vergelijking met de andere functies. Het is in feite bedoeld om de Product Backlog-items te dimensioneren.

Verhaalpuntschatting wordt gedaan op basis van:

• De complexiteit van de functie die moet worden geïmplementeerd.
• Ervaring en technische vaardigheden van alle leden.

S1, S2, S3, S4, S5 zijn sprints.

Stappen voor het toewijzen van verhaalpunten aan een gebruikersverhaal:

• Alle teamleden verzamelen zich rond een tafel en nemen de gebruikersverhalen door die aanwezig zijn in de Sprint Backlog.
• De betekenis van één verhaalpunt en de bijbehorende inspanning wordt bepaald.
• Een van de teamleden leest een gebruikersverhaal voor en vraagt ​​vervolgens aan de teamleden om de relatieve verhaalpunten toe te wijzen.
• Als er een significant verschil is tussen de verhaalpunten die door de teamleden zijn toegewezen, geven ze een verklaring voor de verhaalpunten die ze hebben toegewezen, waardoor ze aan het eind een consensus bereiken.
• Het proces wordt 3-4 keer herhaald totdat er geen groot verschil is tussen de schattingen van de teamleden.
• Het schalen van verhalen helpt bij het bepalen hoeveel verhalen worden opgenomen in een sprint en release.

Voorbeeld voor schatting van het releaseniveau:

Dit omvat het maken van een geprioriteerde lijst van gebruikersverhalen, genaamd Product Backlog. Product Owner creëert Product Backlog en biedt zakelijke waarde voor elk item dat erin wordt vermeld.

We kunnen de onderstaande methoden gebruiken voor schattingen van Story Points:

• Numerieke grootte: 1 tot 10
• Maatvoering T-shirt: Elke vereiste geclassificeerd als Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL).
• Fibonacci-reeks: Schatting gedaan via Fibonacci-reeks (1,2,3,5,8,13,21,34, ...)

Schatting van de bovenstaande gebruikersverhalen via de Fibonacci-reeks:

# 3) Schatting van het sprintniveau

Sprintniveau-schattingen worden gedaan tijdens Sprint Planning. Product backlog-items met de hoogste prioriteit worden genomen en onderverdeeld in verschillende taken zoals detaillering, ontwerp, analyse, ontwikkeling, testcases maken, testcases uitvoeren, gebruikersacceptatietesten enz.

teken tot geheel getal c ++

Taken worden geschat in termen van geschatte uren, d.w.z. de tijd die nodig is om die taak te voltooien voor een bijbehorend gebruikersverhaal. De bottom-up benadering wordt gebruikt voor de taakschattingen waarbij de zakelijke vereisten worden opgesplitst in activiteiten op laag niveau en aan elke activiteit geschatte uren worden toegewezen.

Het doel van de schattingen is om te weten hoeveel user stories het ontwikkelteam zich kan committeren aan een Sprint. De ontwikkeling moet comfortabel zijn met de toewijding en de producteigenaren moeten erop kunnen vertrouwen dat het team de inzet zal nakomen.

S teps voor het toewijzen van geschatte uren aan de taken:

• Teamleden pikken de user stories op en vervolgens wordt hen gevraagd om een ​​inschatting te maken van de daadwerkelijke inspanning, in uren of dagen, voor de taken die bij het user story horen.
• Als er tussen de teamleden onenigheid bestaat over deze schattingen, dan bespreken ze dat en komen ze tot een consensus.
• Als een taak meer dan zes uur duurt, wordt deze opgesplitst in kleinere taken.
• Als er twee of meer taken zijn met geschatte uren minder dan twee, dan worden ze gecombineerd om een ​​nieuwe taak te vormen.

Voorbeeld voor schatting van het sprintniveau:

De Sprint Planning-bijeenkomst bestaat uit twee delen:

• Eerste deel: De focus ligt op het verduidelijken van de vereisten voor gebruikersverhalen, geselecteerd uit de Product Backlog.
• Tweede deel: De nadruk ligt op het opsplitsen van de vereisten in taken en het inschatten van de uren die nodig zijn om deze te voltooien. Alle taken die nodig zijn om het Product Backlog-item leverbaar te maken, moeten worden opgenomen. De taken moeten klein zijn. Idealiter zou een taakinspanning niet meer dan zes uur mogen duren.

Gevolgtrekking

De schattingen in Agile-projecten spelen een belangrijke rol om te zorgen voor de juiste richting, planning en beheer. Het biedt stappen om het project in de toekomst op te pakken.

De technieken om verhaalpunten in te schatten, zoals Planning poker, Bucket System enz., Maken gebruik van kaarten of punten met waarden of nummers erop gedrukt en kennen deze nummers toe. naar de gebruikersverhalen voor een schatting van de relatieve grootte.

Het enige doel is om de items in een volgorde van prioriteit in te stellen, van maximale prioriteit naar minimale prioriteit. De relatieve omvang die voor de productachterstandposten wordt geschat, helpt bij het schatten of berekenen van het benodigde budget voor het project.

Ik hoop dat je een goed inzicht zou hebben gekregen in Estimations of Agile Projects. Voel je vrij om je mening over deze tutorial te geven in de comments hieronder.

Aanbevolen literatuur

• Hoe u een Agile schattingsproces gemakkelijk kunt maken met Planning Poker
• Agile versus waterval: wat is de beste methode voor uw project?
• Software Test Schatting Technieken (Test Inspanning Schatting Complete Gids)
• VersionOne-zelfstudie: All-in-one Agile Project Management Tool Guide
• Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in voor JIRA (Review)
• TOP 10 beste Agile projectmanagementtools in 2021
• Grondwerk voor een succesvolle Agile-reis: hoe u de juiste methode, tools en technieken kiest
• 4 stappen naar de ontwikkeling van de Agile-testmentaliteit voor een succesvolle overgang naar een Agile-proces