Agiilsed ajahinnangud

Juhtumisi olen mina meie tiimi Scrum Master (võrdlemisi vähekogenud) ning ühtlasi aegajalt puutun kokku ajahinnangute muu sellisega. Seega sai käidud kahel Scrumi/agiilse arenduse loengul/arutelul, soojenduseks võtame esimese ehk AAP309, Making Agile Estimation Work,  Stephen Forte ja Joel Semeniuk.

• Ajahinnangud
  • Aegade algusest on tarkvaraarenduses olnud ajahinnangud probleemsed – tavaliselt valed, liiga optimistilikud.
  • Ajahinnang on hinnang (=ebatäpne, vastavalt hetke parimatele teadmistele, mis on ), mitte lubadus.
  • Anna ulatus, mitte üks number.
  • Ära anna hinnangut õhust, küsi täpsustavaid küsimusi – hinnang läheb täpsemaks.
  • Määramatuskoonus – alguses on sinu hinnang ebatäpne ~4x (nii üles kui alla, st hinnanguliselt 1 aastane projekt võib võtta 3 kuud-4 aastat), aga läheb järjest täpsemaks. Ajahinnang on täpne siis, kui projekt on lõpetatud.
  • Tuleb endale tunnistada (ja teistele selgeks teha), et ajahinnangud on subjektiivsed ja muutuvad.
  • Algne hinnang ongi ebatäpne ja peab muutuma (tuleb ümber hinnata), kuid läheb täpsemaks vastavalt sellele, kui hästi me probleeme tunneme.
• User stories ja story points
  • Väärtus kasutajale. As a <role> I would like to <action> in order to <the goal or business value>. Peaksid sisaldama ka vastuvõtukriteeriume – millal on valmis. Ei tohiks olla liiga pikk (üks lõik). Hiljem lüüakse väiksemateks (arendus)ülesanneteks. Liiga väiksed tükid hinnangu andmisel suurendavad ebatäpsust.
  • Inimestel on raske hinnata mingi asja suurust, aga lihtne võrrelda. Seega on meil baaslugu, millel on kindel arv punkte. Kõik tulevased kasutuslood hinnatakse võrdluses sellega – 2x suurem, 2x väiksem, sama jne. Eelis võrreldes tundidega on nt see, et erinevate inimeste hinnangud võivad sisaldada erinevaid asju – puhas arendus vs arendus koos testimise, projektijuhtimise, paigalduste, koolituste jms. Võrdlus on kõigil aga sama. Alles kunagi hiljem tõlgitakse punktid ümber tundideks.
  • Punktide andmine – planning poker, siis ei mõjuta teiste hinnangud. Tuleb leida konsensus, ühine arusaamine. Kui hinnangud on väga erinevad, saadakse asjadest erinevalt aru ja tuleb see läbi arutada.
• Backlog
  • Backlogis võib olla maksimaalselt 3 (või midagi taolist) kõrge prioriteediga tööd, 5 keskmist ja ülejäänud madalat
  • Prioriteet ja hinnangud on seotud, seega võiks eelnevalt hinnata ja siis prioritiseerida
  • Iga sprindi lõpus uued kasutuslood, bugid, hinnangud ja prioriteedid, seega muutub ka backlog ja seega järgmise sprindi sisu!
• Velocity
  • Palju story pointe suudab tiim sprindi läbida. Muutuv suurus, aga samuti muutub täpsemalt sprintide käigus.
  • See on see koht, kus story points tõlgitakse ümber tundideks!
• Re-estimate
  • Mõõdame tulemusi ja muudame vastavalt sellele hinnanguid.
  • Siin selgub, kas me oleme graafikus projekti lõpetamise mõttes. Lõpetamiseks minev aeg=(Backlog (punktides)/sprindi velocity (punktides))xsprindi pikkus. Alguses on hinnang jätkuvalt ebatäpne! Arvestada ka parandusteks kuluvat aega.
  • Kui ei ole graafikus, tuleb midagi muuta (traditsiooniline aeg/kvaliteet/funktsionaalsus kolmnurk)

TL,DR – agiilne arendus tähendabki pidevat muutumist: muutub backlog, hinnangud, ajakava, kasutuslood. Hinnangud ongi defintsiooni järgi alguses ~4x valed, aga lähevad projekti edenedes paremaks, mida paremini me tunneme ülesandeid, tiimi jms.

Lugemisvara:

• User Stories Applied – Mike Cohn
• Agile Estimating and Planning – Mike Cohn
• Agile Retrospectives –  Esther Derby, Diana Larsen
• slideshare🙂 – Stephen Forte, Joel Semeniuk

Muidu – väga huvitav ja mõnus huumor, mitmeid “ma tean, mida te tunnete”-hetki. Nii tore, et ma pole ainus.

 

---