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.

---