Agiilne arutelu agiilse arenduse teemadel

Nagu eelnevalt mainitud, olen mina üks vähekogenenud Scrum Master, aga proovin saada paremaks ja käisin TechEd Europe 2012 raames kahel üritusel –  AAP309 juba kirjutasin, aga lisaks ka BOF07, An Agile Talk on Agile, Peter Provost ja Klaus Even Enevoldsen. Et selle kohta slaide/salvestust pole, panen peast;)

Formaat oli iseenesest geniaalne. Põhimõtteliselt toimus arutelu nagu Scrum:

• tekitati teemade (küsimuste) backlog
• hinnati prioriteedid. Igal inimesel oli kaks häält.
• võeti küsimused sprindis (10 min) ette
• Sprindi lõpus:
  • Hääletati, kas küsimus on vastatud. Kui vastatud, siis oli tehtud, kui ei, läks tagasi backlogi
  • Lisati uusi teemasi backlogi ja hääletati prioriteedid ümber

Teemad oli ka muidugi huvitavad:

• Kuidas kaasata tiimi liikmeid (eriti neid, kes vastu punnivad)? Selgitada, õpetada ja harida, kui see ei aita, siis võib-olla polegi vastavat liiget vaja? St üks tõrvatilk rikub poti mee ja korralikult toimiv tiim kaalub üles ühe (või paar superstaari). Jah, alguses on ilmselt raske, aga pikas perspektiivis on sellest rohkem kasu.
• Mis on agiilse tarkvaraarenduse tulevik? Sama, mis kogu tarkvaraarendusel – continuous delivery ehk pidev tarne. Järjepidev koostöö ja tagasiside, arenduse ja nö hoolduse piiride hägustumine.
• Kui palju on vaja ette analüüsida? Nii palju, kui on vaja? St kasutuslugudele, mis kunagi töösse võib-olla ei jõuagi, pole väga mõtet aega kulutada, samas peab arendustiimidel olema alati tööd võtta, samuti nõuab täpsemate hinnangute andmine mingil tasemel analüüsi. Ehk siis mida kõrgemal mingi lugu backlogis on, seda detailsem analüüs peab olema tehtud. Kui ülesanne liigub sprinti, peab olema arendajale vajalikul tasemel analüüs tehtud.

Kõrvamärkus: vahel juhtub, et tehakse mingi asjaga tööd, aga sprindi lõpus otsustakse, et ikka ei ole valmis ning prioriteetide ümbervaatamisel selgub, et võib-olla me ikka ei taha seda. Ja see on täiesti normaalne.

Edasi sai aeg kahjuks otsa, aga sellegipoolest oli väga äge ja formaat, nagu öeldud, geniaalne. Hiljem küsisin veel Peterilt eraldi, et kas ja kuidas on võimalik teha agiilset arendus fikseeritud aja, raha ja nõuete korral. Vastus:

• sisemiselt saab Scrumi teha, kuigi kliendivaates pole sellel väga mõtet (sest kõik tuleb kindlaks ajaks ära teha)
• hinnangute andmisel anna hinnanguid ja korruta need 3. Või 5. Või 7. Kui sa aga tõepoolest projekti tahad, siis suured ninad keelduvad asju läbi korrutamast, mis ei muuda aga töö suurust. Seega reeglina võidab sellised pakkumised see, kes pakub ebareaalset hinda/tähtaega. Kui sina võidad, siis tõenäoliselt saad rahaliselt vastu pükse.
• üldiselt – need on halb variant, aga teinekord võib kliendi sissesöömiseks neid kasutada.

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.