For de mange, som gerne vil vide noget om, hvordan det egentlig fungerer i praksis, så er der kommet et glimrende video interview på InfoQ med Niels Haugen om Planning Poker.
Når noget får så megen opmærksomhed, som Planning Poker har fået, så kommer der næsten selvfølgeligt også en modreaktion. En af disse stammer fra Jeff Atwood i hans blog Code Horror, hvor han har skrevet et indlæg med titlen Lets play Planning Poker! Han betegner meget rammende Planning Poker som en solid gruppedialog og en estimat baseret på en form for konsensus - eller som han siger, en wideband Delphi i ny indpakning. Wideband Delphi har sine problemer, og dem har Planning Poker i vid udstrækning arvet (jeg kommer ind på nogle af dem i min tidligere blog), så er man interesseret i planning poker, så bør man også lige kaste et blik på erfaringerne med wideband Delphi.
Jeff Atwood fortsætter med at sige, at de bedste estimater er de estimater, som baserer sig på historiske data - og det bruger han så som afsæt til at foreslå en alternativ teknik (som jeg ikke vil forholde mig til her). I Scrum vil man typisk bruge Planning Poker i ideal dage, og så bruge erfaringer med teamet produktivitet (dets velocity) til at omforme estimatet til mandedage. Ved at tage turen forbi velocity, så får man et element af historiske data med i udregningen - og man få muligheden for efterfølgende at justere planerne, når produktiviteten ændrer sig (f.eks. fordi at teamet bliver bedre over tid, men måske også fordi at vilkårene for teamets arbejde ændrer sig over tid).
Det er oplagt, at måler man systematisk velocity, så vil man efterhånden få justeret for eventuelle systematiske bias, som måtte eksistere i estimeringsprocessen. Og selvom begrebet idealdage er godt udgangspunkt, så vil en brug af velocity forudsætte en stabilitet i estimaterne, som gør at det ikke længere er idealdage man skal estimere i, men i højere grad "det som vi dengang troede at vi kunne nå på en ideal dag".
Scrum er en proces, hvor man i høj grad fokuserer på stadige forbedringer af arbejdet (arven fra Lean fornægter sig ikke), og derfor undrer det mig egentlig, at man ikke i stedet fokuserer på, at give teamet feedback på dets evne til at estimere, så estimaterne kunne forbedre sig. Måske er årsagen, at man ikke kan skille omfang fra effektivitet, og teamet kun skal have feedback på det dets evne til at forudsige omfang?
En anden modreaktion er ikke så meget imod Planning Poker som sådan, men mere imod at den baserer sig på User stories. James O. Coplien advarer os om, at user stories kun rummer krav, og at der er brug for en bedre forståelse af, hvad det er, som giver værdi for kunden. Det nærmeste jeg har kunnet finde på skrift er denne anbefaling fra hans blog med titlen Religion's Newfound Restaint on Progress:
That means using Use Cases [...] instead of XP-style user stories (so you understand feature interactions up-front), [...]Coplien fortsætter med en snusfornuftig advarsel om, at man i praksis skal overveje, hvad der er omkostningseffektivt. Det læser jeg på den måde, at han nok altid vil hævde at use cases er user stories overlegne, men at der selvfølgelig kan være situationer, hvor det bedste valg vil være user stories. Han opfordrer os mest af alt til at bruge hovedet!
Hvis vi lige trækker linjen tilbage til wideband delphi, så var grundlaget for den metode, en work breakdown structure. Det er et meget detajleret gæt på, hvad en løsning vil indebære, og langt fra den kravspecifikation som en userstory er. Uden at overfortolke Copliens budskab, så må man vel sige, at han opfordrer os til at overveje, om vi altid mener, at en kravspecifikation i virkeligheden er grundlag nok? Personligt har jeg en stærk tvivl - jeg har deltaget i en del planning poker sessioner, og det er tit at jeg sidder tilbage med en fornemmelse af, at vi er sprunget i mål med et estimat førend vi i virkeligheden har forstået, hvad opgaven gik ud på. Og alt det man overser, er jo 100% underestimeret!
Ingen kommentarer:
Send en kommentar