Hold tidsfristene dine: metoder som utviklere bruker for å estimere innsats

Hei alle sammen! Det er en kolossal mengde teori du trenger å kunne for å komme i gang med programvareutvikling. Noen spesialister (for eksempel backend-utviklere som bruker Java og andre språk) kan mer om det, mens andre (for eksempel frontend-utviklere som bruker JavaScript og React Native) kan litt mindre. Når det er sagt, må begge gruppene inneha en stor mengde ikke bare teknisk, men også "organisatorisk" kunnskap. Denne "organisasjonskunnskapen" er ett område med overlapping for frontend- og backend-utviklere. I dag vil jeg snakke om et aspekt ved denne ikke-tekniske, organisatoriske kunnskapen. I dag skal vi snakke om innsatsestimering . Fordi jeg kun har erfaring med å bruke Agile-metodikken(som regnes som den mest populære), mer spesifikt Scrum-rammeverket, vil jeg vurdere innsatsestimering i sammenheng med Scrum . Helt i begynnelsen må jeg si at det er vanskelig å beregne innsats. For meg er det en av de mest utfordrende/ubehagelige sidene ved jobben min som utvikler. Det er mange forskjellige faktorer å ta i betraktning som kan påvirke din vurdering av innsatsen som kreves for en oppgave. I tillegg vil fremtidige utviklingsplaner være basert på anslagene dine.

Hva om du gir et dårlig anslag?

Hvis en utvikler anslår langt flere timer for en oppgave enn det som til slutt blir brukt på oppgaven, kan ekspertisen deres settes i tvil siden anslaget var så unøyaktig. Det var med andre ord en vill gjetning. På samme tid, hvis en utvikler ikke får arbeidet gjort innen antatt tid, setter hun kundens planer om å gi ut produktet eller den nye funksjonen i fare. Dette er business, og business er penger. Få kunder vil være fornøyd med en slik slip. Det er faktisk derfor jeg ikke liker estimering - fordi noen ganger er det veldig vanskelig å nøyaktig bestemme tiden som kreves for å fullføre en oppgave.

Hvordan lage et tidsanslag

Som regel gjøres estimater i timer eller historiepoeng. Min personlige preferanse er å gjøre estimeringsprosessen ved å bruke historiepoeng . Det er vanskelig å ta feil av konkrete fysiske objekter, men historiepoeng er litt mer abstrakte. Programvareutviklingsteam gir vanligvis estimater som tidsmengder: timer, dager, uker, måneder. Disse tidsestimatene er hovedsakelig basert på personlig erfaring, gjetting og/eller intuisjon. I dette tilfellet ser utviklere ganske enkelt på oppgaven og uttrykker antagelsen om hvor mye tid det vil ta dem. Som et resultat er disse estimatene svært sjelden nøyaktige, fordi det er for mange faktorer som kan påvirke varigheten av arbeidet. Derfor bruker mange team som bruker Agile -metodikken også historiepoeng. La oss dykke inn!

Hva er historiepoeng?

Et historiepunkt er en måleenhet for å uttrykke et estimat av den totale innsatsen som kreves for å implementere en viss funksjonalitet fullt ut. Det vil si at vi snakker om relativkompleksitet. Team tildeler et estimat i historiepoeng basert på kompleksiteten til arbeidet, arbeidsvolumet og risiko eller usikkerhet. Disse verdiene er vanligvis tildelt for å mer effektivt dele opp arbeidet i mindre biter, og dermed eliminere tvetydighet. Over tid hjelper dette teamene til å forstå hva de kan oppnå i en gitt tidsperiode, og hjelper dem mer nøyaktig å planlegge påfølgende deler av arbeidet. Dette høres kanskje helt motintuitivt ut for deg, men denne abstraksjonen er virkelig nyttig: den presser teamet til å ta tøffe avgjørelser om kompleksiteten til arbeidet. La oss ta en titt på noen av grunnene til å bruke historiepunkter når du planlegger:

• Du kan unngå unøyaktige tidsanslag.
• I motsetning til estimater gjort i tidsenheter, lar historiepoeng deg gjøre rede for overheadkostnader: kommunikasjon mellom teammedlemmer og kunden, ulike teamdiskusjoner og planleggingsaktiviteter, så vel som uforutsette situasjoner.
• Hvert team vil estimere arbeidet sitt ved å bruke forskjellige skalaer, noe som betyr at deres kapasitet (målt i poeng) vil være forskjellig.
• Ved å definere en skala for å tildele hvert historiepoeng, kan du raskt tildele poeng uten mye kontrovers.

Hvordan IKKE bruke historiepoeng

Dessverre blir historiepoeng ofte misbrukt. Historiepunkter kan være misvisende når de brukes til å vurdere mennesker, definere detaljerte tidsfrister og ressurser, og når de forveksles med et resultatmål. I stedet bør teamene bruke dem til å forstå omfanget/kompleksiteten til hver oppgave og sette prioriteringer. Kanskje de delene som anses som vanskeligere bør takles først, slik at de kan gjøres før slutten av sprinten , og muligens flytte lettere oppgaver til senere. La meg minne deg på hva en sprint er i sammenheng med Scrum- metodikken: Lengden på denne tidsperioden bestemmes når utviklingen starter og avtales mellom teamet og kunden. Dette kan være en periode på to uker eller en måned, eller en hvilken som helst annen periode. Som regel gjøres innsatsestimatene ved starten av hver sprint for å planlegge arbeidet som kan gjennomføres til slutten av sprinten, når det ferdige arbeidet er levert til kunden. Demoen hjelper deg med å se fremgangen din i utviklingen av produktet, motta tilbakemeldinger fra kunden og justere prosjektets bane i henhold til kundens visjon. Men vi går litt bort. La oss gå tilbake til estimatene. Det ville vært for subjektivt å la bare én utvikler gi estimater for alle oppgavene. Så denne prosessen er vanligvis en teaminnsats. Det er ganske mange teknikker som team kan bruke for å generere estimater. I dag skal vi se på den mest populære teknikken: scrum poker . Denne teknikken krever en manager som vil fungere som moderator for scrum poker . Dette kan være noen som er en scrum master eller muligens en PM .

Hva er Scrum poker?

Scrum poker , eller planleggingspoker, er en estimeringsteknikk som er basert på å oppnå en avtale. Den brukes hovedsakelig til å estimere kompleksiteten til arbeidet som ligger foran eller den relative størrelsen på programvareutviklingsoppgaver. Jeg vil si med en gang at scrum pokerer en vanlig praksis for programvareutvikling, og du må vite hva det handler om. Det involverer vanligvis en app eller et nettsted for å lette et teams samarbeidsoppretting av et estimat for en bestemt oppgave. Hvordan skjer dette? Teamet tar noe fra etterslepet (en ny oppgave, noe funksjonalitet) og diskuterer kort mulige fallgruver og andre nyanser knyttet til det. Deretter velger hver deltaker et kort med et tall som gjenspeiler deres kompleksitetsestimat. Å, en ting til, når vi gjør disse estimatene, bruker vi tall i Fibonacci-sekvensen i stedet for vanlige tall. Fibonacci tall er populære i scrum poker, fordi det er et stadig større gap mellom dem (som ligner nivåene til en pyramide). Noen oppgaver vil være svært komplekse, og vi vil ikke kunne komme unna med et lite antall historiepoeng. Det er noen uvanlige kort som har følgende betydninger:

Ukjent antall endepunkter

Uendelig lang oppgave

Trenger en pause

Mindre vanlige estimeringsmetoder bruker:

• T-skjortestørrelser - S, M, L, XL
• Hunderaser - chihuahua, mops, dachshund, bulldog og så videre (personlig synes jeg dette er den merkeligste måleenheten for innsatsestimering =D)

Teamet sammenligner deretter estimatene gitt av forskjellige utviklere for samme oppgave. Hvis de er enige, så flott! Hvis ikke, må årsakene (argumentene) for de forskjellige estimatene diskuteres. Etter det jobber teamet sammen for å danne et enkelt anslag som alle godtar, mer eller mindre. Så hvorfor brukes poker til og med til å planlegge seriøse programvareprosjekter? Du må innrømme at dette er merkelig. Faktum er at denne typen gamification oppmuntrer teammedlemmer til å tenke selvstendig, og inviterer dem til å avsløre estimatene sine samtidig som lagkameratene. Dette unngår igjen å skape en situasjon der noen teammedlemmer er avhengige av andres meninger. Hvis det ikke ble gjort på denne måten, ville mindre erfarne utviklere se på og fokusere på estimatene gitt av mer erfarne teammedlemmer, og det ville gjøre deres egne estimater mindre nyttige. Men å vise estimatene samtidig gjør dette i hovedsak umulig. Atlassian tilbyren scrum poker-app for bruk i planleggingsprosessen.

Eksempel på innsatsestimering

Anta at teamet ditt har etablert følgende skala for å tildele historiepoeng til estimater: Scrum poker spilles for hver oppgave, og du gir et estimat som følger:

• Du har aldri implementert lignende funksjonalitet før: +3
• Funksjonaliteten er gjennomsnittlig: +2
• Implementeringen vil være svært kompleks: +3
• Å skrive tester for funksjonaliteten vil være svært kompleks: +3

Legger du sammen hver komponent, får du totalt 11 historiepoeng, men det er ikke noe slikt kort, så du foreslår 13. En medarbeider legger frem følgende anslag for oppgaven:

• Han har jobbet med en lignende oppgave før: +1
• Funksjonaliteten er gjennomsnittlig: +2
• Implementeringen vil være av gjennomsnittlig kompleksitet: +2
• Å skrive tester for funksjonaliteten vil være av gjennomsnittlig kompleksitet: +2

Hans mellomresultat er 7 historiepoeng, men det tallet finnes ikke i Fibonacci-serien, så han sender inn kortet med det mest omtrentlige tallet – 8. Andre teammedlemmer gjør også sine estimater basert på deres subjektive synspunkter. Så viser alle kortene sine, og du finner ut at nesten alle kollegene dine ga et estimat på 13, bortsett fra den ene utvikleren som foreslo en 8. I dette tilfellet har han lov til å snakke med og begrunner sitt lavere estimat. Anta at han gir denne begrunnelsen: han har tidligere jobbet med den samme oppgaven, og det er ikke så vanskelig som det kan virke. Til slutt overbeviser han resten av teamet om å ombestemme seg fra 13 til 8 historiepoeng, og sier at han vil hjelpe den som ender opp med å ta denne oppgaven. Eller kanskje han gjør det selv. I alle fall gjør det ikke Det spiller ingen rolle om de andre aksepterer argumentene hans eller ikke, for på en eller annen måte vil et estimat bli tildelt oppgaven, og teamet vil gå videre for å vurdere den neste. Til å begynne med vil estimatene være unøyaktige, og det samme vil anslagene for mengden arbeid du planlegger å få gjort i løpet av neste tidsperiode (sprint). Tross alt er disse estimatene gjort ved å bruke estimater. Etter en tid, kanskje tre måneder senere, vil teamet begynne å estimere tiden som kreves for oppgaver mer nøyaktig, og den gjennomsnittlige mengden arbeid som teamet er i stand til å utføre i en sprint vil bli tydelig. Men dette er en prosess for å lage en generell plan for arbeidsomfanget. Den fokuserer hovedsakelig på tid, men i dette tilfellet kan det være mange ulike relevante faktorer. Tenk deg for eksempel at en utvikler dro på ferie i to uker. Du må kutte en viss mengde planlagt arbeid (planlagt funksjonalitet). Eller anta at en ny utvikler har sluttet seg til teamet, men ennå ikke er helt oppdatert, så du må gi henne tid til å bli kjent med prosjektet gjennom enombordstigningsprosess . Dette kan være to uker, gi eller ta en uke, avhengig av kompleksiteten til prosjektet. Det var alt for i dag! Jeg håper jeg forbedret litt kunnskapen din om anstrengelsesestimering, et nødvendig ikke-teknisk aspekt ved programvareutvikling. Hvis du vil gå dypere inn i dette temaet, og i detaljene rundt scrum, anbefaler jeg på det sterkeste at du leser boken «SCRUM» av Jeff Sutherland. Jeg kan ikke love noe om konsekvensene, for etter å ha lest den får du et irriterende ønske om å bli scrummaster =D