Overhold dine deadlines: metoder, som udviklere bruger til at estimere indsats

Hej allesammen! Der er en kolossal mængde teori, som du skal kende for at komme i gang med softwareudvikling. Nogle specialister (for eksempel backend-udviklere, der bruger Java og andre sprog) ved mere om det, mens andre (f.eks. frontend-udviklere, der bruger JavaScript og React Native) måske ved lidt mindre. Når det er sagt, skal begge grupper besidde en stor mængde ikke kun teknisk, men også "organisatorisk" viden. Denne "organisatoriske" viden er et område med overlapning for frontend- og backend-udviklere. I dag vil jeg tale om et aspekt af denne ikke-tekniske, organisatoriske viden. I dag vil vi tale om estimering af indsats . For jeg har kun erfaring med at bruge Agile-metoden(som anses for at være den mest populære), mere specifikt Scrum-rammen, vil jeg overveje indsatsestimering i sammenhæng med Scrum . Lige i starten må jeg sige, at det er svært at estimere indsatsen. For mig er det en af ​​de mest udfordrende/ubehagelige aspekter af mit job som udvikler. Der er mange forskellige faktorer at overveje, som kan påvirke dit skøn over den indsats, der kræves for en opgave. Derudover vil fremtidige udviklingsplaner være baseret på dine estimater.

Hvad hvis du giver et dårligt skøn?

Hvis en udvikler estimerer langt flere timer til en opgave, end der i sidste ende bliver brugt på opgaven, kan deres ekspertise blive sat i tvivl, da estimatet var så unøjagtigt. Det var med andre ord et vildt gæt. På samme tid, hvis en udvikler ikke får arbejdet gjort inden for den forudsagte tid, bringer hun kundens planer om at frigive produktet eller den nye funktion i fare. Dette er forretning, og forretning er penge. Få kunder vil være tilfredse med sådan en slip. Faktisk er det derfor, jeg ikke kan lide estimering - for nogle gange er det super vanskeligt nøjagtigt at bestemme den tid, der kræves for at fuldføre en opgave.

Sådan laver du et tidsestimat

Som regel foretages estimater i timer eller historiepoint. Min personlige præference er at lave estimeringsprocessen ved hjælp af historiepunkter . Det er svært at tage fejl af konkrete fysiske objekter, men historiepunkter er lidt mere abstrakte. Softwareudviklingsteams giver typisk estimater som mængder af tid: timer, dage, uger, måneder. Disse tidsestimater er primært baseret på personlig erfaring, gætværk og/eller intuition. I dette tilfælde ser udviklere blot på opgaven og udtrykker deres antagelse om, hvor meget tid det vil tage dem. Som følge heraf er disse skøn meget sjældent nøjagtige, fordi der er for mange faktorer, der kan påvirke arbejdets varighed. Derfor bruger mange teams, der bruger Agile- metoden, også storypoints. Lad os dykke ned!

Hvad er historiepunkter?

Et historiepunkt er en måleenhed til at udtrykke et estimat af den samlede indsats, der kræves for at implementere et bestemt stykke funktionalitet fuldt ud. Det vil sige, vi taler om relativkompleksitet. Teams tildeler et estimat i historiepoint baseret på arbejdets kompleksitet, mængden af ​​arbejde og risiko eller usikkerhed. Disse værdier tildeles normalt for mere effektivt at opdele arbejdet i mindre stykker og derved eliminere tvetydighed. Over tid hjælper dette teams med at forstå, hvad de kan udrette i en given periode og hjælper dem mere præcist med at planlægge efterfølgende stykker arbejde. Det lyder måske fuldstændigt modstridende for dig, men denne abstraktion er virkelig praktisk: den presser teamet til at træffe svære beslutninger om arbejdets kompleksitet. Lad os tage et kig på nogle af grundene til at bruge historiepunkter, når du planlægger:

• Du kan undgå unøjagtige tidsvurderinger.
• I modsætning til estimater lavet i tidsenheder, lader historiepunkter dig tage højde for overheadomkostninger: kommunikation mellem teammedlemmer og kunden, forskellige teamdiskussioner og planlægningsaktiviteter samt uforudsete situationer.
• Hvert hold vil vurdere deres arbejde ved hjælp af forskellige skalaer, hvilket betyder, at deres kapacitet (målt i point) vil være forskellig.
• Ved at definere en skala for tildeling af hvert historiepunkt kan du hurtigt tildele point uden megen kontrovers.

Hvordan man IKKE bruger historiepunkter

Desværre bliver historiepunkter ofte misbrugt. Historiepunkter kan være vildledende, når de bruges til at vurdere mennesker, definere detaljerede deadlines og ressourcer, og når de forveksles med et præstationsmål. I stedet bør teams bruge dem til at forstå omfanget/kompleksiteten af ​​hver opgave og til at sætte prioriteter. Måske skal de dele, der anses for at være sværere, tages fat først, så de kan klares inden afslutningen af ​​spurten , og muligvis flytte lettere opgaver til senere. Lad mig minde dig om, hvad en sprint er i sammenhæng med Scrum- metoden: Længden af ​​denne tidsperiode bestemmes, når udviklingen begynder, og aftales mellem teamet og kunden. Dette kan være en periode på to uger eller en måned eller en hvilken som helst anden periode. Indsatsestimaterne laves som udgangspunkt i begyndelsen af ​​hver sprint for at planlægge det arbejde, der kan afsluttes ved sprintens afslutning, når det færdige arbejde er leveret til kunden. Demoen hjælper dig med at se dine fremskridt i udviklingen af ​​produktet, modtage feedback fra kunden og justere projektets forløb efter kundens vision. Men vi afviger lidt. Lad os vende tilbage til estimaterne. Det ville være for subjektivt kun at have én udvikler til at give estimater for alle opgaverne. Så denne proces er normalt en teamindsats. Der er en del teknikker, som teams kan bruge til at generere estimater. I dag vil vi se på den mest populære teknik: scrum poker . Denne teknik kræver en manager, der vil fungere som moderator for scrum poker . Dette kan være en person, der er en scrum master eller muligvis en PM .

Hvad er Scrum poker?

Scrum poker , eller planlægningspoker, er en estimeringsteknik, der er baseret på at nå til enighed. Det bruges hovedsageligt til at vurdere kompleksiteten af ​​det kommende arbejde eller den relative størrelse af softwareudviklingsopgaver. Jeg siger med det samme scrum pokerer en almindelig praksis for softwareudvikling, og du skal vide, hvad det handler om. Det involverer normalt en app eller et websted for at lette et teams fælles oprettelse af et estimat for en bestemt opgave. Hvordan sker dette? Teamet tager noget fra efterslæbet (en ny opgave, noget funktionalitet) og diskuterer kort mulige faldgruber og andre nuancer forbundet med det. Derefter vælger hver deltager et kort med et tal, der afspejler deres kompleksitetsestimat. Åh, en ting mere, når vi laver disse estimater, bruger vi tal i Fibonacci-sekvensen i stedet for almindelige tal. Fibonacci-numre er populære i scrum poker, fordi der er et stadig større hul mellem dem (ligner niveauerne i en pyramide). Nogle opgaver vil være meget komplekse, og vi vil ikke kunne slippe afsted med et lille antal historiepunkter. Der er nogle usædvanlige kort, der har følgende betydninger:

Ukendt antal endepunkter

Uendelig lang opgave

Har brug for en pause

Mindre almindelige estimeringsmetoder bruger:

• T-shirt størrelser - S, M, L, XL
• Hunderacer - chihuahua, mops, gravhund, bulldog og så videre (personligt synes jeg, at dette er den mærkeligste måleenhed til estimering af indsats =D)

Teamet sammenligner derefter estimaterne givet af forskellige udviklere for den samme opgave. Hvis de er enige, så fantastisk! Hvis ikke, så skal årsagerne (argumenterne) til de forskellige skøn diskuteres. Derefter arbejder teamet sammen om at danne et samlet estimat, som alle accepterer, mere eller mindre. Så hvorfor bruges poker overhovedet til at planlægge seriøse softwareprojekter? Du må indrømme, at det er mærkeligt. Faktum er, at denne form for gamification tilskynder teammedlemmer til at tænke selvstændigt, og inviterer dem til at afsløre deres estimater på samme tid som deres holdkammerater. Dette undgår til gengæld at skabe en situation, hvor nogle teammedlemmer er afhængige af andres meninger. Hvis det ikke blev gjort på denne måde, ville mindre erfarne udviklere se på og fokusere på estimaterne fra mere erfarne teammedlemmer, og det ville gøre deres egne skøn mindre nyttige. Men samtidig at vise estimaterne gør dette stort set umuligt. Atlassian tilbyderen scrum poker app til brug i planlægningsprocessen.

Eksempel på estimering af indsats

Antag, at dit team har etableret følgende skala for at tildele historiepoint til estimater: Scrum poker spilles for hver opgave, og du giver et estimat som følger:

• Du har aldrig implementeret lignende funktionalitet før: +3
• Funktionaliteten er gennemsnitlig: +2
• Implementeringen vil være meget kompleks: +3
• At skrive test for funktionaliteten vil være meget kompleks: +3

Hvis du lægger hver komponent sammen, får du i alt 11 historiepoint, men der er ikke et sådant kort, så du foreslår 13. En kollega fremlægger følgende estimat for opgaven:

• Han har arbejdet med en lignende opgave før: +1
• Funktionaliteten er gennemsnitlig: +2
• Implementeringen vil være af gennemsnitlig kompleksitet: +2
• At skrive test for funktionaliteten vil være af gennemsnitlig kompleksitet: +2

Hans mellemresultat er 7 historiepoint, men det tal findes ikke i Fibonacci-serien, så han indsender kortet med det mest omtrentlige tal — 8. Andre teammedlemmer foretager også deres skøn baseret på deres subjektive synspunkter. Så viser alle deres kort, og du opdager, at næsten alle dine kollegaer gav et estimat på 13, undtagen den ene udvikler, der foreslog en 8. I dette tilfælde har han lov til at tale med og giver årsager til sit lavere estimat. Antag, at han giver denne begrundelse: han har tidligere arbejdet på den samme opgave, og det er ikke så svært, som det måske ser ud til. I sidste ende overbeviser han resten af ​​holdet om at ændre mening fra 13 til 8 historiepoint, og siger, at han vil hjælpe den, der ender med at tage denne opgave. Eller måske gør han det selv. Under alle omstændigheder gør det ikke Det er ligegyldigt, om de andre accepterer hans argumenter eller ej, for på en eller anden måde vil der blive tildelt et estimat til opgaven, og teamet vil gå videre til at overveje den næste. Til at begynde med vil estimaterne være unøjagtige, ligesom estimaterne for den mængde arbejde, du planlægger at få udført i den næste tidsperiode (sprint). Disse skøn er jo lavet ved hjælp af skøn. Efter nogen tid, måske tre måneder senere, vil teamet begynde at estimere den tid, der kræves til opgaver mere præcist, og den gennemsnitlige mængde arbejde, som teamet er i stand til at udføre i en sprint, vil blive tydeligt. Men dette er en proces for at lave en generel plan for arbejdets omfang. Det fokuserer hovedsageligt på tid, men i dette tilfælde kan der være mange forskellige relevante faktorer. Antag for eksempel, at en udvikler tog på ferie i to uger. Du bliver nødt til at skære en vis mængde planlagt arbejde (planlagt funktionalitet). Eller antag, at en ny udvikler er kommet med på holdet, men endnu ikke er helt oppe at køre, så du skal give hende tid til at blive fortrolig med projektet gennem enonboarding proces. Dette kan være to uger, give eller tage en uge, afhængigt af kompleksiteten af ​​projektet. Det var alt for i dag! Jeg håber, at jeg har forbedret din viden om estimering af indsats, et nødvendigt ikke-teknisk aspekt af softwareudvikling. Hvis du vil gå dybere ind i dette emne, og i detaljerne omkring scrum, anbefaler jeg stærkt, at du læser bogen "SCRUM" af Jeff Sutherland. Jeg kan ikke love noget om konsekvenserne, for efter at have læst den får du et irriterende ønske om at blive scrum master =D