Planning Poker er en estimeringsmetode, der ofte anvendes i forbindelse med agile softwareudvikling. Planning Poker sigter mod at skabe konsensus om estimater for udviklingsaktiviteterne i et software- eller webudviklingsprojekt.
Estimering er en svær kunst
Det er altid en vanskelig opgave at skulle vurdere kompleksiteten og omfanget af en feature i forbindelse med et it-projekt, og det typiske scenarie er, at udviklerne må estimere på baggrund af deres erfaringer med lignende udviklingsopgaver, som de i tidligere it-projekter har været involveret i. Det viser sig også ofte, at it-udviklere undervurderer udviklingsopgaver eller lader sig presse af forretningsledelsen til at acceptere estimater, som i sidste ende viser sig at være for optimistike, og så har man balladen, når budgetter og tidsplaner ikke holder.
Det er egentlig utroligt, så ofte man oplever, at voksne mennesker sidder og narrer hinanden i forbindelse med estimater på softwareudviklingsopgaver og web-projekter. Udviklerne afgiver estimater - forretningsledelsen presser på for at få reduceret estimaterne, således at tid og budget ser bedre ud, og i sidste ende kan man så bruge tiden på at skændes over, at de estimater, som alle egentlig godt var klar over ikke ville holde, rent faktisk ikke holder.
Poker Planning er dejligt provokerende
Når man arbejder med poker planning, så opdager udviklerne, at de bliver presset til at fremkomme med velbegrundede tidsestimater. Dette skyldes den særlige måde, hvorpå udviklerne kaster deres bud på et estimat på borde i løbet af en poker planning session. Lad os tage et eksempel:
Ex. udvikling af en funktion til oprettelse af en kunde
Der sidder 4 udviklere om bordet, og de har hver især nogle spillekort med tidsangivelser på. De skal nu hver for sig vurdere, hvor lang tid det vil tage at udvikle en funktion, der skal kunne oprette en kunde. Den enkelte udvikler vælger et spillekort med det timetal, som den pågældende udvikler mener, angiver et rimeligt estimat for udviklingen af funktionen. Vi skal nu forestille os, at der i denne poker planning session sidder 4 udviklere med hver deres kort med timeangivelser på, og at deres estimater f.eks. varierer fra 5 til 20 timer for udvikling af funktionen.
Udviklerne smider nu kortene på bordet, og det må nok forventes, at udvikleren med et estimat på 20 timer bliver noget overrasket over at se, at en anden udvikler har vurderet selvsamme opgave til blot 5 timer. Og udviklerne skal nu fremføre argumenter for deres estimater. Diskussionerne skulle så gerne føre frem til en konsensus i gruppen om et estimat, der i det pågældende tilfælde måske rent faktisk lander på 20 timer - det kunne jo være, at de øvrige udviklere havde undervurderet den pågældende opgave, og at udvikleren med buddet på 20 timer havde nogle rigtigt gode argumenter for sit estimat.
Poker Planning handler også meget om psykologi
Eftersom det er på den måde, at man ikke kender de andre udvikleres estimater, førend alle smider kortene på bordet, så undgår man ved poker planning, at udviklere påvirker hinanden med deres estimater. Der kan f.eks. nemt ske det, at man ikke har lyst til at sige, at man estimerer en opgave til 20 timer, hvis man ved, at en anden udvikler vurderer opgaven til blot 10 timer, og det omvendte kan naturligvis også være tilfældet.
Dermed tvinger poker planning udviklerne til at fremsætte deres oprigtige vurdering af omfanget af en udviklingsopgave, og der dannes basis for konstruktive diskussioner om estimaterne, hvilket typisk fører frem til estimater, som er grundigt drøftede og som der er konsensus om i gruppen.
Kontakt Codelean
Hvis du/I er interesserede i at høre mere om poker planning, så kontakt os på info@codelean.com eller ringe på telefon +45 36964766.
Estimering er en svær kunst
Det er altid en vanskelig opgave at skulle vurdere kompleksiteten og omfanget af en feature i forbindelse med et it-projekt, og det typiske scenarie er, at udviklerne må estimere på baggrund af deres erfaringer med lignende udviklingsopgaver, som de i tidligere it-projekter har været involveret i. Det viser sig også ofte, at it-udviklere undervurderer udviklingsopgaver eller lader sig presse af forretningsledelsen til at acceptere estimater, som i sidste ende viser sig at være for optimistike, og så har man balladen, når budgetter og tidsplaner ikke holder.
Det er egentlig utroligt, så ofte man oplever, at voksne mennesker sidder og narrer hinanden i forbindelse med estimater på softwareudviklingsopgaver og web-projekter. Udviklerne afgiver estimater - forretningsledelsen presser på for at få reduceret estimaterne, således at tid og budget ser bedre ud, og i sidste ende kan man så bruge tiden på at skændes over, at de estimater, som alle egentlig godt var klar over ikke ville holde, rent faktisk ikke holder.
Poker Planning er dejligt provokerende
Når man arbejder med poker planning, så opdager udviklerne, at de bliver presset til at fremkomme med velbegrundede tidsestimater. Dette skyldes den særlige måde, hvorpå udviklerne kaster deres bud på et estimat på borde i løbet af en poker planning session. Lad os tage et eksempel:
Ex. udvikling af en funktion til oprettelse af en kunde
Der sidder 4 udviklere om bordet, og de har hver især nogle spillekort med tidsangivelser på. De skal nu hver for sig vurdere, hvor lang tid det vil tage at udvikle en funktion, der skal kunne oprette en kunde. Den enkelte udvikler vælger et spillekort med det timetal, som den pågældende udvikler mener, angiver et rimeligt estimat for udviklingen af funktionen. Vi skal nu forestille os, at der i denne poker planning session sidder 4 udviklere med hver deres kort med timeangivelser på, og at deres estimater f.eks. varierer fra 5 til 20 timer for udvikling af funktionen.
Udviklerne smider nu kortene på bordet, og det må nok forventes, at udvikleren med et estimat på 20 timer bliver noget overrasket over at se, at en anden udvikler har vurderet selvsamme opgave til blot 5 timer. Og udviklerne skal nu fremføre argumenter for deres estimater. Diskussionerne skulle så gerne føre frem til en konsensus i gruppen om et estimat, der i det pågældende tilfælde måske rent faktisk lander på 20 timer - det kunne jo være, at de øvrige udviklere havde undervurderet den pågældende opgave, og at udvikleren med buddet på 20 timer havde nogle rigtigt gode argumenter for sit estimat.
Poker Planning handler også meget om psykologi
Eftersom det er på den måde, at man ikke kender de andre udvikleres estimater, førend alle smider kortene på bordet, så undgår man ved poker planning, at udviklere påvirker hinanden med deres estimater. Der kan f.eks. nemt ske det, at man ikke har lyst til at sige, at man estimerer en opgave til 20 timer, hvis man ved, at en anden udvikler vurderer opgaven til blot 10 timer, og det omvendte kan naturligvis også være tilfældet.
Dermed tvinger poker planning udviklerne til at fremsætte deres oprigtige vurdering af omfanget af en udviklingsopgave, og der dannes basis for konstruktive diskussioner om estimaterne, hvilket typisk fører frem til estimater, som er grundigt drøftede og som der er konsensus om i gruppen.
Kontakt Codelean
Hvis du/I er interesserede i at høre mere om poker planning, så kontakt os på info@codelean.com eller ringe på telefon +45 36964766.
Posts
No comments:
Post a Comment