agile estimation techniques
Sanna uppskattningar i ett smidigt projekt: En fullständig insikt med exempel på smidig uppskattning
Det är mycket viktigt att göra Agile Estimation på olika nivåer. Detta görs för korrekt planering, hantering och uppskattning av de totala ansträngningar som vi ska använda för att implementera, testa och leverera den önskade produkten till kunderna i termer av tid inom de angivna tidsfristerna.
Med brist på uppskattningar i Agile Project, kanske det inte finns någon ordentlig planering och hantering som kan sluta med att leverera den oönskade produkten och därmed lämna kunden missnöjd.
Berättelse poäng Uppskattningar görs i Agile-projekt med olika tekniker som Planning Poker, Bucket System, Affinity Mapping, etc. Olika uppskattningsmallar på olika nivåer används för detta ändamål som Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , Mall för användarberättelse etc.
Vad du kommer att lära dig:
- Introduktion
- Beräkningar av berättelser i smidig
- Rekommenderat verktyg
- Olika smidiga uppskattningstekniker
- Beräkning av budget i smidig
- Uppskattningsmallar i Agile Development Project
- Stadier av uppskattning i smidigt projekt
- Slutsats
- Rekommenderad läsning
Introduktion
Nedan följer de tre huvudnivåerna för Agile Estimation.
# 1) Projekt- eller förslagsnivå är den som använder snabbfunktionspunktsanalys under de inledande faserna av projektutvecklingen.
# 2) Släppnivå inkluderar tilldelning av berättelsepunkter till användarberättelserna som kan hjälpa till att definiera ordningen på användarberättelserna baserat på prioriteten och kan också hjälpa till att avgöra vilka berättelser som kan tas i aktuell version och vilka som kan tas senare.
# 3) Sprintnivå är den där användarberättelserna delas in i uppgifterna och uppskattade timmar tilldelas uppgifterna enligt deras komplexitet. Här definierar vi också den person som ansvarar för uppgiften tillsammans med statusen för uppgifterna.
Denna information kan senare användas för att beräkna budgeten för Agile-projektet. Beräkning av budget är avgörande för att säkerställa att projektet inte går över budgeten på grund av uppgiften före och efter iteration eller av andra skäl.
Beräkningar av berättelser i smidig
Beräkningar av Story Points är en jämförande analys för att grovt uppskatta produktens eftersläpningsartiklar med relativ storlek. Teammedlemmarna för att uppskatta användarberättelser inkluderar: Product Owner, Scrum Master, Developers, Testers and Stake holders.
Nedan följer några steg för att nå det slutliga beslutet om relativ storlek:
# 1) Analysera alla användarberättelser och identifiera bas- eller referensberättelsen. Det är viktigt för att göra relativ storlek. Denna berättelse kan väljas från den aktuella eftersläpningen eller den som vi har gjort tidigare. Denna berättelse bör väljas som referensberättelse efter godkännande av alla medlemmar.
#två) Välj en annan historia från den aktuella produktbackloggen och teammedlemmarna kan diskutera eventuella frågor eller tvivel med produktägaren, samtidigt som de förstår kraven i berättelsen. Produktägaren är ansvarig för att klargöra alla deras frågor och tvivel.
# 3) Gör en lista över de saker som ska tas hand när du implementerar användarberättelsen. Dessa kan göras genom att skriva anteckningar i anteckningsdelen av verktyget eller genom att lägga till punktpunkter på berättelsekortet. Detta görs mest av Scrum Master.
# 4) Några vanliga frågor bland deltagarna anges nedan:
- Design: Vad är den tidigare och obligatoriska kunskapen som vi borde ha innan vi börjar arbeta med den?
- Kodning: Hur mycket kodning som krävs för att implementera den här användarberättelsen. Har vi stött på någon liknande användarberättelse tidigare?
- Enhetstestning: Krävs några föremål för att göra enhetstester för den här användarberättelsen?
- Integrationstestning: Påverkar den här berättelsen de andra funktionerna i samma modul och andra moduler också?
- Godkännande testning: Vilka poäng ska man ta hand om för att leverera den önskade produkten enligt önskemål från kunderna?
- Expertis: Har någon av deltagarna gjort en liknande berättelse tidigare och är en expert på den?
# 5) Gör relativ storlek för den valda berättelsen. Om det kräver samma mängd arbete och ansträngning, tilldela det samma nr. poäng, som tilldelats referensberättelsen. Om det kräver mer ansträngning, tilldela det något högre värde. Om det kräver mindre ansträngning, tilldela det något lägre värde.
# 6) Nå enighet med alla deltagare för att slutföra den relativa storleken för vald användarberättelse enligt definitionen av gjort.
bästa gratis Windows 10-systemoptimeraren
# 7) Efter relativ storleksändring av alla produkter i eftersläpningen, se till att om alla användarberättelser med samma nr. poäng som tilldelats dem, kräver samma ansträngning och storlek för att vara konsekventa.
Rekommenderat verktyg
# 1) Agile Poker
Agile Poker är en välkänd app för Jira för snabb och bekväm planering och uppskattningar för både avlägsna och samlokaliserade team.
Att komma igång med Agile Poker är enkelt och enkelt eftersom det inspirerades av tre uppskattningsmetoder för branschstandard: Planering av Poker®, Wideband Delphi och Magic Estimation (även känd som tyst gruppering, affinitetsestimering, simplaneringsstorlek eller relativa uppskattningar).
=> Ladda ner Agile Poker Tool härOlika smidiga uppskattningstekniker
Det finns många tekniker för att göra uppskattningar i ett Agile Project. Huvudprinciperna för att göra uppskattningar inkluderar relativ uppskattning, diskussioner för att få mer information om saker vars uppskattningar behöver göras och säkerställa engagemang för hela teamet mot de uppgifter som tilldelats dem.
Det finns huvudsakligen 7 Agile Project Estimation Techniques:
# 1) Planera poker
- I denna uppskattningsteknik sitter alla människor som ska göra uppskattningarna i en rund cirkel för Planning Poker-sessionen.
- Varje uppskattning har en uppsättning planeringspokerkort med värden: 0,1,2,3,5,8,13,20,40 och 100. Dessa värden representerar berättelsespoäng eller mått i vilket laget uppskattar.
- I början av sessionen läser produktägaren eller kunden upp användarberättelsen och beskriver alla dess funktioner och krav.
- Efter att berättelsen har lästs ut sker diskussionerna mellan uppskattarna och med produktägaren / kunden. Uppskattarna kan ställa frågor eller klargöra sina tvivel hos produktägaren.
- Efter diskussionerna ombeds alla uppskattare att välja ett kort för att uppskatta en användarberättelse. Om alla uppskattare ger samma värde blir det den slutliga uppskattningen.
- Om värdena är olika förklarar de uppskattare som ger de högsta och lägsta värdena sina åsikter och varför de valde detta värde tills enighet uppnås.
- En bra teknik när liten nr. föremål beräknas i ett litet team.
=> Mer detaljerad läsning på Planering av pokeruppskattningsteknik .
# 2) Storlekar på T-shirt
- Precis som i fallet med T-shirts ser vi storlekar: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). Ett liknande tillvägagångssätt följs här. Artiklarna uppskattas i T-shirtstorlekar.
- Detta är en perfekt teknik för att ge en grov uppskattning av den stora eftersläpningen av varor.
- Användbar när snabb och grov uppskattning behöver göras. Senare kan dessa storlekar omvandlas till nej enligt kravet.
- En relativ storlek (mestadels Medium) bestäms efter ömsesidig diskussion och överenskommelse mellan lagmedlemmarna eller uppskattarna. Sedan tilldelas nej till objekten enligt den relativa storleken som tilldelas medelstorleken.
- Nackdel: Det som verkar L för någon kan tyckas vara XL för någon.
- Alla uppskattare tilldelar artiklarna sin egen storlek. Efter diskussioner och lösning av skillnaderna uppnås enighet om att få den slutliga uppskattningen.
# 3) Dot Röstning
- Detta är i grunden en rankningsmetod för att bestämma ordningen på produktbackloggen från historier med högsta prioritet till lägsta prioritet. Detta görs för att välja de viktigaste berättelserna som ska tas vidare.
- För att börja med detta, lägg upp alla användarberättelser tillsammans med deras beskrivning på väggen eller tavlan med gula klistermärken eller på ett sätt som skiljer dem för att få rösterna.
- Alla intressenter får 4 till 5 prickar (mestadels i form av klistermärken, pennor eller markörer kan också användas för att göra prickar).
- Alla intressenter uppmanas att ge sina röster om de användarberättelser som de föredrar.
- Produktägare beställer eftersläpningsprodukter från de mest föredragna (en med flest prickar) till de minst föredragna (en med minst antal prickar).
- Det kan vara fallet, där få intressenter är missnöjda med beslutet. I det här fallet delas användarberättelserna i tre grupper efter diskussionerna: hög prioritet, låg prioritet och medel prioritet. Användarberättelser med hög prioritet läggs ut på väggen för att få rösterna. Detta görs tills den slutgiltiga ordern uppnås med samtliga intressenters samtycke.
# 4) Bucket-systemet
- Det är en bra teknik när ett stort nr. föremål uppskattas med stort nr. av deltagarna. Det är snabbare och mer rimligt än att planera poker.
- Olika skopor skapas med värden: 0,1,2,3,4,5,8,13,20,30,50,100, 200.Detta kan förlängas om det behövs. Dessa hinkar är inget annat än kort som representerar värden ordnade sekventiellt på ett bord.
- Berättelserna måste placeras i dessa där uppskattaren finner dem lämpliga. Alla föremål som ska uppskattas är skrivna på korten.
- Välj ett föremål slumpmässigt och lägg det i hink 8. Detta används endast som referens. Välj en annan historia slumpmässigt, diskutera alla dess funktioner och krav med gruppen och placera den i rätt hink efter konsensus. På samma sätt plockas det tredje föremålet och placeras i en lämplig hink.
- Skopssekvensen kan också ändras, om gruppen känner att det första objektet som valts, ska tillhöra skopan 1 istället för skopa 8.
- Divide and Conquer-metoden följs. Alla återstående objekt delas upp mellan alla deltagare. Alla deltagare kan placera objektet utan godkännande av andra deltagare.
- Föremålen ska placeras ordentligt. Inget föremål kan placeras mellan skoporna.
- Om en deltagare inte förstår produktens efterslagsartikel eller om de andra deltagarna har slutfört att placera sina användarberättelser kan användarberättelserna överföras till de andra deltagarna.
- Äntligen utförs Sanity-kontroll av alla deltagare. Om någon deltagare hittar en fel hink tilldelad ett objekt, kan de ge den information om andra deltagare och diskutera med dem. Detta görs tills enighet uppnås för hela produktstocken.
- Handledaren bör göra en kontroll av att ingen flyttar föremålen om inte sanityskontrollen är genomförd.
- Detta görs också för att uppnå den prioriterade ordningen på produktens eftersläpsposter.
# 5) Stor / osäker / liten
- Detta är en grov version och är en förenkling av skopsystemet där det bara finns tre storlekar: Large, Small och Uncertain.
- Deltagarna eller uppskattarna uppmanas att placera objekten i en av kategorierna. Först väljs de enkla användarberättelserna och placeras i stora och små kategorier. Sedan tas de komplexa föremålen upp.
- Det är en bra teknik när det finns jämförbara artiklar i produktbackloggen.
# 6) Affinitetsmappning
- En bra teknik när laget är litet och nej. av eftersläpningsposter är mindre.
- Första steget är tyst relativ storlek: På en vägg placeras ett kort med ”Mindre” på vänster sida och kortet med ”Större” skrivet på placeras på höger sida. Produktägare tillhandahåller en delmängd av artiklarna till alla deltagare. Alla deltagare uppmanas att dimensionera varje artikel i förhållande till storleken på korten på väggen, med tanke på den ansträngning som krävs för att genomföra dem. Det är deltagarens ensamma beslut utan diskussion med de andra gruppmedlemmarna. Produktägare eller intressent är närvarande för att klargöra deltagarens tvivel. Produktbackloggobjekt som är för tvetydiga för att förstås av teammedlemmarna för uppskattning placeras separat. Det tar 5-20 minuter.
- Redigering av vägg: Teammedlemmarna kan ändra platsen för föremålen på väggen. De kan diskutera design- och implementeringskrav med de andra gruppmedlemmarna. Denna aktivitet kan stängas när liten förändring sker på väggen. Det tar cirka 20-60 minuter .
- Placera objekt på rätt plats: Efter diskussionerna placerar teamet produktens eftersläpsposter i sina relativa och lämpliga positioner. Vi kan använda T-shirtstorlek, Fibonacci-serien etc. här för att relativt uppskatta storleken på objekten.
- Produktägare utmaning: Produktägaren kan hitta en viss skillnad i uppskattningarna som görs av teamet och måste diskutera fler funktioner eller kraven för ett föremål med teamet. Efter diskussioner görs slutliga uppskattningar.
- Exportera till Project Backlog Management Tool: För att säkerställa att informationen om de slutliga uppskattningarna inte går förlorad exporterar du den till ett verktyg för produkthantering.
# 7) Beställningsmetod
- En bra teknik när det är stort nr. föremål och små nr. av människor är där.
- Det ger exakta relativa storlekar för produktens eftersläpningsartiklar.
- En skala bereds från låg till hög. Alla föremål placeras slumpmässigt på den. Varje deltagare ombeds att flytta ett objekt på skalan åt gången. Rörelsen kan vara en uppåt, en nedåt eller skicka svängen till en annan medlem.
- Detta fortsätter tills alla deltagare är nöjda och inte vill flytta något på skalan.
- Detta ger också den prioriterade ordningen på produktbackloggen.
Beräkning av budget i smidig
Beräkning av budgetar spelar en viktig roll i Agile-projekt. Detta görs för att säkerställa vad som är den faktiska budgeten som tillhandahålls, vilken mer budget som krävs och hur ska vi dela upp budgeten för olika poster i produktbackloggen.
Den använder data som samlats in från tidigare projekt och använder den matematiska formeln för att få den uppskattade budgeten för det aktuella projektet.
Nedan följer steg för att beräkna budgeten i ett Agile-projekt:
# 1) Lista ner alla projektkrav och gör uppskattningar för dem som använder Planning Poker, Bucket System, Fibonacci-serien etc. Alla teammedlemmar bör komma överens om de uppskattningar som gjorts för de angivna kraven efter tydlig analys och förståelse för användarberättelserna. Uppskattningar görs baserat på de funktioner som ska implementeras i en användarberättelse.
#två) Bestäm varaktigheten för de iterationer som kallas Sprints och de eftersläpsprodukter som tilldelats den. Det är vanligtvis 2 till 3 veckor långt. Användarberättelserna väljs i en sekvens som börjar med användarberättelsen med maximal prioritet, flyttar till lägre prioritet och med minst prioriterad användarberättelse i slutet. Detta hjälper till att avgöra vilka användarberättelser som måste hämtas i den första sprinten och vilka berättelser som kan tas upp senare.
# 3) Förbered utbränt diagram för att ge en tydlig bild av hur mycket arbete som återstår att göra kontra hur mycket tid som återstår för implementering. Det ger i princip hastigheten på ett agilt team. Det ger en tydlig bild av hur laget beter sig och hur det förväntas bete sig.
Lagets framsteg mäts i termer av Slutförda uppgifter, Återstående ansträngning, Idealisk nedgång och Återstående uppgifter som visas nedan:
# 4) Lägg till ytterligare kostnader som inköp av utrustning, verktyg, infrastruktursupport, få licenser för programvaruverktygen som ska användas, Project Management Tools, Antivirusinstallation och uppdateringar.
# 5) Lägg till pre- och postterationsbudgetar. Alla smidiga medlemmar ska vara tvärfunktionella, men det finns gränser för det. Allt som görs av en teammedlem utanför hans expertis betraktas som pre iteration eller post iteration arbete. Detta arbete före och efter Iteration kräver ytterligare budget för implementering.
# 6) Håll koll på de dolda riskerna. Riskerna i Agile-projektet inkluderar: Risken för att projektet går över budgeten, Frånvaron av teammedlemmar, Medlemmarna har ingen tydlig eller fullständig kunskap, Medlemmarna har inte de nödvändiga färdigheterna, tidsfristerna har överskridits etc.
Uppskattningsmallar i Agile Development Project
Det finns många uppskattningsmallar som utarbetas på olika nivåer i Agile-utvecklingsprojektet. Det enda syftet är att tydligt ange de uppskattningar som krävs för att genomföra ett krav eller en artikel och spåra dess framsteg.
De viktigaste mallarna är som nämnts nedan:
1) Agil projektplanmall:
Det ger en hög bild av hur mycket tid som krävs för att leverera kraven på kraven och vilken status de har. Den nämner också den person som är ansvarig för den specifika uppgiften.
(Obs: Klicka på valfri bild för en förstorad vy)
2) Agile release plan mall:
Det ger detaljer om de uppgifter som motsvarar kraven, tillsammans med deras status och Sprint där de måste utföras.
3) Agile Product Backlog Mall:
Den beskriver den fullständiga produktstock som definierats för projektet. Den ger detaljerade uppgifter om Sprints tillsammans med status, prioritet, berättelsespoäng och huruvida de tilldelas en Sprint eller om det finns någon ytterligare uppgift som defekter etc.
4) Agile Sprint Backlog-mall:
Den ger en beskrivning av användarberättelserna som nämns i eftersläpningen för en viss Sprint. Det ger de totala berättelsespoängen som tilldelats en användarberättelse och hur dessa delas in i olika uppgifter. Det ger också status för motsvarande uppgifter och vad är det arbete som utförs dagligen för motsvarande uppgifter.
5) Agil testplanmall:
Det delar upp hela testscenariot i underscenarier. Det ger detaljer om underscenarier som Implementeringsdatum, Förväntat resultat, Verkligt resultat, Status etc.
Det nämner också projektnamnet, kompatibel webbläsare, versionen av applikationen som testas, testfall-ID för ett valt scenario, skriven av, testad av, beskrivning etc.
6) Agile User Story Mall:
Det ger detaljerna specifika för analysen av användarberättelsen som Vilka roller krävs för att en specifik funktionalitet ska testas, vad är förkravet (miljöinställning och länkar aktiverade) och vad är det förväntade resultatet?
7) Agil vägkartmall:
Det ger en riktning till projektet i företaget, på kort och lång sikt. Det hjälper till att ställa förväntningar inom företaget. Och översikten över vart projektet är på väg.
Stadier av uppskattning i smidigt projekt
I ett agilt projekt görs uppskattningar på tre nivåer som nämns nedan:
- Projekt / förslagsnivå: Den totala funktionella storleken för hela applikationen uppskattas med QFPA-metoden (Quick Function Point Analysis) när endast höga krav finns tillgängliga.
- Släppnivå: Berättelsespoäng tilldelas användarberättelserna som hjälper till att bestämma nej. av utsläpp planerade inom ett projekt och nr. av användarberättelser som ska tas i en release och sprint.
- Sprintnivå: Uppskattade timmar tilldelas uppgifterna för användarberättelserna inom en sprint. Detta görs för att säkerställa engagemanget för utvecklingen för att leverera användarberättelser med i en sprint.
S1, S2, S3, S4, S5, S6 är sprints.
# 1) Förslag eller uppskattning av projektnivå
Det är en mycket hög uppskattning för projektet. Den fokuserar på det totala antalet krav i artikeln Backlog. Funktionspunkter används för att uppskatta storleken på programvaran / projektet innan en detaljerad beskrivning av funktionskraven dokumenteras.
Funktionspunkter är det allmänt accepterade sättet att beräkna programvarans storlek. Det fokuserar på funktionerna som finns i mjukvaruprojekten. En funktionspunkt är ett mått som omvandlar kraven eller användarberättelser till ett nummer.
Under de inledande faserna av projektet rekommenderas det att använda QFPA-metoden (Quick Function Point Analysis).
Metoden Quick Function Point Analysis är en unik metod för att uppskatta FP när endast höga krav finns tillgängliga.
Hur beräknar jag den totala funktionella storleken?
- Förstå alla funktionerna i en applikation med hjälp av domenexperter.
- Identifiera och lista alla möjliga funktioner i en applikation.
- Datalagringsfunktioner klassificeras i interna logiska filer (data som lagras internt i applikationen) och externa gränssnittsfiler (data som endast används för referensändamål).
- Transaktionsfunktioner klassificeras i externa ingångar (data som kommer från externa källor till applikation), externa utgångar (härledda data går från applikation till extern) och externa förfrågningar (data hämtad från en eller flera externa ingångar och externa utgångar).
- Beräkna FP-storlek för varje funktion genom att beräkna dess genomsnittliga komplexitet.
- Sammanfatta FP-storleken på alla funktioner för att få applikationens totala funktionella storlek.
- Minst två personer med expertis inom FP-analys bör beräkna oberoende, matcha resultat och lösa skillnaderna.
Exempel för uppskattning av projektnivå:
Nedan följer listan över krav för ett projekt, som i produktbackloggen:
- En användare ska kunna logga in på webbplatsen genom att ange användarnamn och lösenord.
- Efter lyckad inloggning ska en användare tas till huvudsidan med höger och vänster rutor definierade.
- En användare bör ha möjlighet att logga ut från applikationen.
- En giltig användare har möjlighet att ändra lösenordet genom att tillhandahålla aktuella referenser.
Teamet använder en snabb FP-uppskattning för att uppskatta projektets storlek.
Nedan följer analysen:
- Datalagringsfunktionen här lagrar användaruppgifter för att logga in och ändra lösenordet.
- Eftersom autentiseringsuppgifterna lagras inom applikationsgränsen lagras de i ILF: er (interna logiska filer).
- Transaktionsfunktionerna inkluderar:
- Användarinloggning och visning av huvudsidan.
- Användarutloggning och visning av utloggningsskärmen.
- Möjlighet att ändra lösenord.
Nedan följer stegen för att uppskatta projektstorleken med hjälp av snabbfunktionspunktsanalys:
STEG # 1: Lista ner alla datafunktioner
Datafunktion | Typ | UFP | |||||
---|---|---|---|---|---|---|---|
US-02 | TAS-07 | Godkännande test av intern kund | Godkännande testning | QA Team på plats | 8 | Ej påbörjad | 6 |
Information om användaruppgifter | ILF | 10 |
UFP (Unadjusted Function Point) är hämtat från Caper Jones Table.
STEG # 2: Lista ner alla transaktionsfunktioner
Transaktionsfunktion | Typ | UFP |
---|---|---|
Logga in och visa huvudsidan | EQ | 4 |
Logga ut och visa utloggningsskärmen | EQ | 4 |
Ändra lösenord | NEJ | 4 |
UFP (Unadjusted Function Point) är hämtat från Caper Jones Table.
STEG # 3: Hämta den uppskattade projektstorleken i Funktionspunkter
UFP = Data FP + Transaction FP
UFP = 10 + 12 = 22 UFP
FP = UFP * VFP = 22 * 1 = 22 FP (förutsatt VFP (värdejusteringsfaktor = 1)
Produktivitet = 16 FP / månad (Normal Standard)
c ++ konvertera char till int
Ansträngning = FP / Produktivitet = 22/16 personers månad = 1,37 person månad
# 2) Uppskattning av släppnivå
Uppskattningar av utsläppsnivå görs under planeringsutgåvan. Det är nästa aktivitet efter uppskattning av projektnivå. De prioriterade kraven hämtas från Product Backlog som är i form av User Stories.
Användarberättelserna uppskattas i termer av berättelsespoäng under lanseringsplaneringen som fokuserar på att uppskatta storleken på programvaran som ska levereras för den utgåvan. På det här sättet planeras inga utgivningar och totalt antal berättelsespoäng i varje utgåva.
En storypoint representerar i grunden den relativa insats som krävs för att implementera en funktion eller funktionalitet, jämfört med de andra funktionerna. Det är i grund och botten för storlek på produktbackloggen.
Beräkning av berättelsepoäng görs på basis av:
- Komplexiteten i funktionen som ska implementeras.
- Alla medlemmars erfarenhet och tekniska färdigheter.
S1, S2, S3, S4, S5 är sprints.
Steg för att tilldela berättelse pekar till en användarberättelse:
- Alla teammedlemmar samlas runt ett bord som går igenom användarberättelserna i Sprint Backlog.
- Betydelsen av en berättelsepunkt och motsvarande ansträngning bestäms.
- En av gruppmedlemmarna läser upp en användarberättelse och ber sedan teammedlemmarna att tilldela de relativa berättelsepoängen.
- Om det finns en signifikant skillnad mellan de berättelsespoäng som tilldelats av teammedlemmarna så ger de en förklaring till berättelsespoäng som de har tilldelat och därmed når enighet i slutet.
- Processen upprepas 3-4 gånger tills det inte finns någon större skillnad mellan de uppskattningar som lagmedlemmarna ger.
- Storleksändring av berättelser hjälper till att avgöra hur många berättelser som ska tas inom en sprint och släpp.
Exempel på uppskattning av frigöringsnivå:
Det handlar om att skapa en prioriterad lista över användarberättelser som kallas Product Backlog. Produktägare skapar produktbacklogg och tillhandahåller affärsvärde för var och en av artiklarna i den.
User Story ID | Användarberättelse | Acceptanskriterier |
---|---|---|
US-01 | Som användare vill jag ha en inloggningsskärm där jag kan logga in i applikationen med mina uppgifter: användarnamn och lösenord | • En giltig användare ska kunna se inloggningsskärmen och tillhandahålla referenser. • Efter inloggning ska användaruppgifterna kontrolleras för äkthet. |
US-02 | Efter en lyckad inloggning vill jag som användare se huvudsidan med rubrik, vänster, höger rutor och alternativ för avloggning. | • En giltig användare ska kunna se hemskärmen vid lyckad inloggning. • Användaren ska kunna se sidhuvud, vänster och höger rutor tillsammans med alternativet för avloggning. |
US-03 | Som användare borde jag kunna logga ut framgångsrikt när jag klickade på alternativet för utloggning och efter utloggning skulle jag se utloggningsskärmen. | • När man är på huvudsidan bör användaren kunna klicka på knappen 'logga ut'. • Användaren ska loggas ut framgångsrikt genom att klicka på 'logga ut'. • Användaren ska se utloggningsskärmen efter utloggning. • Användaren ska kunna logga in igen efter utloggning. |
Vi kan använda metoderna nedan för beräkningar av berättelsespoäng:
- Numerisk storlek: 1 till 10
- Storlek på t-shirt: Varje krav klassificeras som Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL).
- Fibonacci-serien: Uppskattning gjord genom Fibonacci-sekvens (1,2,3,5,8,13,21,34,….)
Uppskattning av ovanstående användarberättelser genom Fibonacci-sekvensen:
Amerikanskt ID | Beräknade berättelsespoäng |
---|---|
US-01 | 8 |
US-02 | 3 |
US-03 | 4 |
# 3) Uppskattning av sprintnivå
Sprintnivåberäkningar görs under Sprint Planning. Högst prioriterade produktbackloggposter tas och delas in i olika uppgifter som Detaljer, Design, Analys, Utveckling, Skapa testfall, Utför testfall, Test av användaraccept etc.
Uppgifterna uppskattas i termer av uppskattade timmar, dvs. den tid som krävs för att slutföra uppgiften för en motsvarande användarberättelse. Bottom-Up-metoden används för uppskattningar av uppgifter där affärsbehovet delas upp i aktiviteter på låg nivå och varje aktivitet tilldelas uppskattade timmar.
Syftet med uppskattningarna är att veta hur många användarberättelser utvecklingsgruppen kan begå för en Sprint. Utvecklingen måste vara bekväm med engagemanget och produktägarna måste vara övertygade om att teamet kommer att uppfylla åtagandet.
S teps för att tilldela uppskattade timmar till uppgifterna:
- Teammedlemmarna plockar upp användarberättelserna och de uppmanas att uppskatta den faktiska ansträngningen, i termer av timmar eller dagar, för de uppgifter som motsvarar användarberättelsen.
- Om det finns en oenighet i dessa uppskattningar bland gruppmedlemmarna, så diskuterar de det och kommer till enighet.
- Om någon uppgift är mer än sex timmar delas den upp i mindre uppgifter.
- Om det finns två eller flera uppgifter med uppskattade timmar mindre än två, kombineras de för att bilda en ny uppgift.
Exempel för uppskattning av sprintnivå:
Det finns två delar av Sprint Planning-mötet:
- Första delen: Fokus ligger på att klargöra kraven för användarberättelser, utvalda från produktbackloggen.
- Andra delen: Fokus ligger på att dela upp kraven i uppgifter och uppskatta de timmar som krävs för att slutföra dem. Alla uppgifter som är nödvändiga för att leverera produktbackloggen ska inkluderas. Uppgifterna ska vara små. Helst bör en arbetsinsats inte vara mer än sex timmar.
Amerikanskt ID | Uppgifts-ID | Uppgifts beskrivning | Aktivitetsaktivitet | Tilldelats | Prioritet (1 = låg till 9 = högst) | Status | Beräknade arbetstid |
---|---|---|---|---|---|---|---|
US-01 | TAS-01 | Designa inloggningssida | Systemdesign | Amit | 9 | Avslutad | 3 |
US-01 | TAS-02 | Enhetstestplan och systemtestplan | Systemtestplan | Bud | 8 | Avslutad | 4 |
US-01 | TAS-03 | Utveckla inloggningssidan | Bygga | Utvecklingsteam | 7 | Avslutad | 5 |
US-01 | TAS-04 | Inloggningssida användarvalidering | Bygga | Utvecklingsteam | 6 | Pågående | 6 |
US-02 | TAS-05 | Systemtest framgång och misslyckade scenarier för inloggningssidan | Systemtest | QA Team Offshore | 5 | Ej påbörjad | 4 |
US-02 | TAS-06 | Integrationstestning av inloggningssidan | Integrationstestning | QA Team Offshore | 4 | Ej påbörjad | 3 |
Slutsats
Uppskattningarna i Agile-projektet spelar en viktig roll för att säkerställa korrekt riktning, planering och hantering. Det ger steg för hur man ska ta upp projektet i framtiden.
Teknikerna för att uppskatta berättelsespoäng som Planning poker, Bucket System etc. använder kort eller prickar med värden eller siffror tryckta på och tilldelar sedan dessa nr. till användarberättelserna för relativ uppskattning av storlek.
Det enda syftet är att ställa in objekten i en prioriterad ordning från maximal prioritet till minsta prioritet. De relativa storlekarna som uppskattas för produktens eftersläpsposter hjälper till att uppskatta eller beräkna den budget som krävs för projektet.
Hoppas att du skulle ha fått en bra inblick i uppskattningar av agila projekt. Du är välkommen att uttrycka dina tankar om denna handledning i kommentarfältet nedan.
Rekommenderad läsning
- Hur man gör en smidig uppskattningsprocess enkelt med att planera poker
- Agile Vs Waterfall: Vilken är den bästa metoden för ditt projekt?
- Uppskattningstekniker för programvarutestning (komplett testguide för uppskattning av testinsats)
- VersionOne-handledning: Allt-i-ett Agile Project Management Tool Guide
- Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in för JIRA (Review)
- TOPP 10 Bästa smidiga verktyg för projektledning 2021
- Grunden för en lyckad smidig resa: Hur man väljer rätt metod, verktyg och tekniker
- 4 steg mot att utveckla det agila testningstänkandet för framgångsrik övergång till smidig process