Velocity.... fart hvad kan man bruge det til?
Velocity er et ret simpelt koncept, som bygger på Mike Cohn's ide om at man skal estimere i størrelse og uddrive farten igennem udførelse - estimate size, derive duration - og på den måde opnå en empirisk kontrolleret forståelse for den fart, hvormed et givent projektteam kan eksekvere en given opgave (eller user story).
Den del som tiltaler mig er, at eksekveringen af "estimat-timer" (som Cohn ynder at kalde story points for at undgå forvirringen med kalender-timer) adskilles fra estimatet selv. I alt for mange år har man talt om at estimater aldrig stemmer overens med de faktiske timer, og så har man brugt ligeså lang tid på at udvikle metoder til at foretage beregninger på estimater up-front for at gøre dem mere præcise osv. Hvorfor?
For mig at se er det temmelig indlysende, at et estimat givet på et tidspunkt, hvor viden om projektet og de konkrete projektopgaver er lavest (=dvs i begyndelsen af et projekt), aldrig kan indfri et ønske om 100% præcision. Det gør dog ikke estimater ubrugelige. Estimater fortæller jo stadig om et projekts størrelse og kompleksitet i grove træk, og det er faktisk meget værdifuldt i forhold til planlægning af projektet, og måske endnu vigtigere: porteføljeplanlægning..
Hvad synes i? Bruger i velocity på jeres projekter? I givet fald hvilke erfaringer har i gjort jer med det?
Etiketter: teori
indsendt af Rune Mai kl.
10:29
2 kommentarer:
Har læst Cohn's bog, ' Agile Estimating and Planning' og blev meget inspireret, men mangler endnu at få 'Story points' prøvet af.
Det er helt klart, der er brug for noget andet end time-estimater, særligt i de tidligste planlægningsfaser.
Efter min erfaring er det største problem ultimativt, at kommunikere til projektets interessenter - særligt kunden og ledelsen - at de tidlige estimater er ekstremt luftige.
Angiver man nogenlunde realistisk usikkerhed (ala -50%->+300%) er man useriøs. Sætter man nok forudsætninger op, bliver estimatet ubrugeligt. Uanset hvad man gør, vil det endelige tal blive brugt imod en senere.
Cohn's forslag lyder rigtigt fornuftige, og det ville være spændende at høre om andres erfaringer både på team og i forhold kunde/ledelse.
Det væsentlige at kommunikere til kunden og ledelsen er jo i princippet at story points i tidlige faser kun fortæller om et givent projekts kompleksitet. Hvis der er behov for timer, så kan man forsøge at få udviklere til at komme med et bud på, hvor mange iterationer det ca. vil tage, men dette bud vil naturligvis være upræcist.
Det vigtigste er dog, at lade både ledelse og kunde forstå, at pointene konverteres til timer, når de eksekveres i en sprint. Så efter første sprint får man en ok ide om projektets varighed, efter anden sprint en bedre ide og efter trejde sprint en bedre ide... osv. Du kan evt. lave et gennemsnit på de tre første sprints efter 3. sprint og kalkulere efter det. Det fede ved denne måde er, at dine estimater udspringer empirisk af det konkrete arbejde --> altså hvor lang tid tager det at eksekvere et point.
En anden væsentlig pointe ved ovenstående er, at det også "tvinger" udviklingsteamet at fokusere på at levere værdi fra første sprint af, for ellers bliver projektet jo afblæst (="Har i kun leveret to point på en sprint? Så tager det jo 3 år"). Det kan nemlig være ret svært at levere i de første sprint, da tendensen er at levere infrastruktur såsom arkitektur, kernekomponenter etc.
Send en kommentar
<< Startside