Håll dina deadlines: metoder som utvecklare använder för att uppskatta ansträngning

Hej alla! Det finns en kolossal mängd teori som du behöver kunna för att komma igång med mjukvaruutveckling. Vissa specialister (till exempel backend-utvecklare som använder Java och andra språk) kan mer om det, medan andra (till exempel frontend-utvecklare som använder JavaScript och React Native) kanske vet lite mindre. Som sagt, båda grupperna måste ha en stor mängd inte bara tekniska, utan också "organisatoriska" kunskaper. Denna "organisatoriska" kunskap är ett område av överlappning för frontend- och backend-utvecklare. Idag vill jag prata om en aspekt av denna icke-tekniska, organisatoriska kunskap. Idag kommer vi att prata om ansträngningsuppskattning . Eftersom jag bara har erfarenhet av att använda Agile-metoden(vilket anses vara det mest populära), närmare bestämt Scrum-ramverket, kommer jag att överväga ansträngningsuppskattning i samband med Scrum . Redan i början måste jag säga att det är svårt att uppskatta ansträngning. För mig är det en av de mest utmanande/obehagliga aspekterna av mitt jobb som utvecklare. Det finns många olika faktorer att ta hänsyn till som kan påverka din uppskattning av den ansträngning som krävs för en uppgift. Dessutom kommer framtida utvecklingsplaner att baseras på dina uppskattningar.

Vad händer om du ger en dålig uppskattning?

Om en utvecklare uppskattar mycket fler timmar för en uppgift än vad som slutligen spenderas på uppgiften, kan deras expertis sättas i tvivel eftersom uppskattningen var så felaktig. Det var med andra ord en vild gissning. Samtidigt, om en utvecklare inte får jobbet gjort inom den förutsedda tiden, äventyrar hon kundens planer på att släppa produkten eller den nya funktionen. Det här är affärer och affärer är pengar. Få kunder kommer att vara nöjda med en sådan slip. Faktum är att det är därför jag inte gillar uppskattning - för ibland är det väldigt knepigt att exakt bestämma den tid som krävs för att slutföra en uppgift.

Hur man gör en tidsuppskattning

Som regel görs uppskattningar i timmar eller berättelsepoäng. Min personliga preferens är att göra uppskattningsprocessen med hjälp av berättelsepunkter . Det är svårt att missta sig om konkreta fysiska föremål, men berättelsepunkter är lite mer abstrakta. Programvaruutvecklingsteam tillhandahåller vanligtvis uppskattningar som tidsbelopp: timmar, dagar, veckor, månader. Dessa tidsuppskattningar baseras främst på personlig erfarenhet, gissningar och/eller intuition. I det här fallet tittar utvecklare helt enkelt på uppgiften och uttrycker sitt antagande om hur mycket tid det kommer att ta dem. Som ett resultat är dessa uppskattningar mycket sällan korrekta, eftersom det finns för många faktorer som kan påverka arbetets varaktighet. Det är därför många team som använder Agile -metoden också använder story points. Låt oss dyka in!

Vad är berättelsepoäng?

En berättelsepunkt är en måttenhet för att uttrycka en uppskattning av den totala ansträngning som krävs för att implementera en viss funktionalitet fullt ut. Det vill säga, vi pratar om relativkomplexitet. Teamen tilldelar en uppskattning i berättelsepoäng baserat på arbetets komplexitet, arbetsvolymen och risk eller osäkerhet. Dessa värden tilldelas vanligtvis för att mer effektivt dela upp arbetet i mindre bitar och därigenom eliminera oklarheter. Med tiden hjälper detta teamen att förstå vad de kan åstadkomma under en viss tidsperiod och hjälper dem att mer exakt planera efterföljande bitar av arbete. Detta kanske låter helt kontraintuitivt för dig, men denna abstraktion är verkligen praktisk: den pressar teamet att fatta svåra beslut om arbetets komplexitet. Låt oss ta en titt på några av anledningarna till att använda berättelsepunkter när du planerar:

• Du kan undvika felaktiga tidsuppskattningar.
• Till skillnad från uppskattningar gjorda i tidsenheter låter storypoints dig redogöra för overheadkostnader: kommunikation mellan teammedlemmar och kunden, olika teamdiskussioner och planeringsaktiviteter, såväl som oförutsedda situationer.
• Varje lag kommer att uppskatta sitt arbete med olika skalor, vilket innebär att deras kapacitet (mätt i poäng) kommer att vara olika.
• Genom att definiera en skala för att tilldela varje berättelsepoäng kan du snabbt tilldela poäng utan mycket kontrovers.

Hur man INTE använder berättelsepoäng

Tyvärr missbrukas ofta berättelsepunkter. Berättelsepunkter kan vara vilseledande när de används för att bedöma människor, definiera detaljerade deadlines och resurser och när de misstas för att vara ett prestationsmått. Istället bör teamen använda dem för att förstå omfattningen/komplexiteten för varje uppgift och för att prioritera. Kanske att de delar som betraktas som svårare bör tacklas först, så att de kan göras innan sprinten är slut, och eventuellt flytta lättare uppgifter till senare. Låt mig påminna dig om vad en sprint är i samband med Scrum- metoden: Längden på denna tidsperiod bestäms när utvecklingen påbörjas och avtalas mellan teamet och kunden. Detta kan vara en period på två veckor eller en månad, eller någon annan period. Som regel görs insatsuppskattningarna i början av varje sprint för att planera det arbete som kan slutföras till slutet av sprinten, när det avslutade arbetet levereras till kunden. Demon hjälper dig att se dina framsteg i att utveckla produkten, få feedback från kunden och anpassa projektets bana enligt kundens vision. Men vi avviker lite. Låt oss återgå till uppskattningar. Det skulle vara för subjektivt att bara ha en utvecklare som ger uppskattningar för alla uppgifter. Så denna process är vanligtvis ett lagarbete. Det finns en hel del tekniker som team kan använda för att generera uppskattningar. Idag ska vi titta på den mest populära tekniken: scrum poker . Denna teknik kräver en manager som kommer att fungera som moderator för scrumpokern . Detta kan vara någon som är en scrum master eller möjligen en PM .

Vad är Scrum poker?

Scrum poker , eller planeringspoker, är en uppskattningsteknik som bygger på att nå en överenskommelse. Den används huvudsakligen för att uppskatta komplexiteten i det kommande arbetet eller den relativa storleken på mjukvaruutvecklingsuppgifter. Jag ska genast säga att scrum pokerär en vanlig praxis för mjukvaruutveckling, och du måste veta vad det handlar om. Det involverar vanligtvis en app eller webbplats för att underlätta ett teams samarbetsskapande av en uppskattning för en viss uppgift. Hur går det till? Teamet tar något från eftersläpningen (en ny uppgift, viss funktionalitet) och diskuterar kortfattat möjliga fallgropar och andra nyanser förknippade med det. Sedan väljer varje deltagare ett kort med ett nummer som återspeglar deras komplexitetsuppskattning. Åh, en sak till, när vi gör dessa uppskattningar använder vi siffror i Fibonacci-sekvensen snarare än vanliga siffror. Fibonacci-nummer är populära inom scrumpoker, eftersom det blir ett allt större gap mellan dem (liknar nivåerna i en pyramid). Vissa uppgifter kommer att vara mycket komplexa och vi kommer inte att kunna komma undan med ett litet antal berättelsepoäng. Det finns några ovanliga kort som har följande betydelser:

Okänt antal slutpunkter

Oändligt lång uppgift

Behöver en paus

Mindre vanliga uppskattningsmetoder använder:

• T-shirtstorlekar - S, M, L, XL
• Hundraser — chihuahua, mops, tax, bulldog, och så vidare (personligen tycker jag att detta är den märkligaste måttenheten för ansträngningsuppskattning =D)

Teamet jämför sedan uppskattningarna från olika utvecklare för samma uppgift. Om de håller med, så bra! Om inte, måste skälen (argumenten) för de olika uppskattningarna diskuteras. Efter det arbetar teamet tillsammans för att bilda en enda uppskattning som alla accepterar, mer eller mindre. Så varför används poker ens för att planera seriösa mjukvaruprojekt? Du måste erkänna att detta är konstigt. Faktum är att denna typ av gamification uppmuntrar lagmedlemmar att tänka självständigt, och uppmanar dem att avslöja sina uppskattningar samtidigt som sina lagkamrater. Detta undviker i sin tur att skapa en situation där vissa teammedlemmar är beroende av andras åsikter. Om det inte gjordes på detta sätt skulle mindre erfarna utvecklare titta på och fokusera på uppskattningarna från mer erfarna teammedlemmar, och det skulle göra deras egna uppskattningar mindre användbara. Men att samtidigt visa uppskattningarna gör detta i princip omöjligt. Atlassian erbjuderen scrum pokerapp att använda i planeringen.

Exempel på ansträngningsuppskattning

Anta att ditt team upprättade följande skala för att tilldela berättelsepoäng till uppskattningar: Scrum poker spelas för varje uppgift, och du ger en uppskattning enligt följande:

• Du har aldrig implementerat liknande funktionalitet tidigare: +3
• Funktionen är medelstor: +2
• Implementeringen kommer att vara mycket komplex: +3
• Att skriva tester för funktionaliteten kommer att vara mycket komplext: +3

Lägger du ihop varje komponent får du totalt 11 berättelsepoäng, men det finns inget sådant kort, så du föreslår 13. En kollega lägger fram följande uppskattning för uppgiften:

• Han har arbetat med en liknande uppgift tidigare: +1
• Funktionen är medelstor: +2
• Implementeringen kommer att vara av genomsnittlig komplexitet: +2
• Att skriva tester för funktionaliteten kommer att vara av genomsnittlig komplexitet: +2

Hans mellanresultat är 7 berättelsepoäng, men den siffran finns inte i Fibonacci-serien, så han skickar in kortet med det mest ungefärliga antalet — 8. Andra teammedlemmar gör också sina uppskattningar baserat på deras subjektiva åsikter. Sedan visar alla sina kort och du upptäcker att nästan alla dina medarbetare gav en uppskattning på 13, förutom den ene utvecklaren som föreslog en 8:a. I det här fallet får han prata med och motiverar sin lägre uppskattning. Anta att han ger denna motivering: han arbetade tidigare med samma uppgift, och det är inte så svårt som det kan verka. Till slut övertygar han resten av teamet att ändra uppfattning från 13 till 8 berättelsepoäng, och säger att han kommer att hjälpa den som slutar med att ta den här uppgiften. Eller så kanske han gör det själv. Det gör det i alla fall inte Det spelar ingen roll om de andra accepterar hans argument eller inte, för på ett eller annat sätt kommer en uppskattning att tilldelas uppgiften, och teamet kommer att gå vidare för att överväga nästa. Inledningsvis kommer uppskattningarna att vara felaktiga, liksom uppskattningarna av mängden arbete som du planerar att få gjort under nästa tidsperiod (sprint). Dessa uppskattningar görs trots allt med hjälp av uppskattningar. Efter en tid, kanske tre månader senare, kommer teamet att börja uppskatta tiden som krävs för uppgifter mer exakt, och den genomsnittliga mängden arbete som teamet kan utföra i en sprint kommer att bli uppenbart. Men det här är en process för att göra en översiktsplan för arbetets omfattning. Den fokuserar främst på tid, men i det här fallet kan det finnas många olika relevanta faktorer. Anta till exempel att en utvecklare åkte på semester i två veckor. Du kommer att behöva minska en viss mängd planerat arbete (planerad funktionalitet). Eller anta att en ny utvecklare har anslutit sig till teamet, men ännu inte är helt uppdaterad, så du måste ge henne tid att bli bekant med projektet genom enintroduktionsprocessen . Detta kan vara två veckor, ge eller ta en vecka, beroende på projektets komplexitet. Det är allt för idag! Jag hoppas att jag har förbättrat dina kunskaper om ansträngningsuppskattning något, en nödvändig icke-teknisk aspekt av mjukvaruutveckling. Om du vill gå djupare in i detta ämne, och in i detaljerna kring scrum, rekommenderar jag starkt att du läser boken "SCRUM" av Jeff Sutherland. Jag kan inte ge några löften om konsekvenserna, för efter att ha läst den kommer du att få en irriterande önskan att bli en scrum master =D