Kasutajalood, mittefunktsionaalsed nõuded ja ärakasutajalood

Kasutajaloo (user story) konseptsioon on tarkvaraarenduses väga tuttav. Selle formaat ja ülesehitus üldiselt lihtsad – “<Rollina> tahan <teha seda>, et <saavutada midagi>”. Näiteks:

“Bussijuhina tahan näha nimekirja järgmise päeva liinidest, et saaksin ennast ette valmistada”.

Kasutajalood keskenduvad enamasti mingile funktsionaalsusele, seega toote omanikule (product owner)/tellijale/lõppkasutajale lihtsalt mõistetavad, seega ka hinnatavad-võrreldatavad (prioritiseeritavad). Mittefunktsionaalsed nõuded on aga sageli märksa udusemad – “süsteem peab toetama 1000 samaaegset kasutajat”. Keda see huvitama peaks, mis on selle prioriteet?

Teatud pingutusega võib ka mittefunktsionaalsed nõuded ümber kirjutada kasutajalugudeks:

• Suurem osa lehekülgi peab avanema alla 1 sekundi, sealhulgas kõik enamkasutatavad leheküljed. ->
  • Kasutajana tahan, et kõik enamkasutatavad leheküljed avaneks alla 1 sekundi, et minu töös ei oleks tarbetuid katkestusi süsteemi taga oodates.
• Süsteemi peab saama kasutada Chrome, Firefox, IE kui ka Safari veebilehitsejaga ->
  • Kasutajana tahan süsteemi kasutada nii Chrome, Firefox, IE kui ka Safari veebilehitsejaga, et ma ei peaks arvutisse installeerima spetsiaalset brauserit.
• Info allikas, selle muutmise ja hävitamise fakt peavad olema tuvastatavad ->
  • CIOna tahan, et kogu info allikas, selle muutmise ja hävitamise akt on tuvastavad, et saaksin vajadusel esitada neid tõendina kohtusse.

Ja nii edasi. See aitab tellijat ühe või teise nõude tähtsuse hindamisel ja ideaalses scrumi-maailmas backlog’i (ametlik tõlge “tegemate tööde nimekiri” on selgelt pikk. Päkkloog? Varn (nagu homse varn)? Tööde kuhi?) järjestamisel ning tööde tellimisel.

Päris kasutajalood need aga siiski ei ole, sest noh, 1 sekundi reegel peab jääma kehtima igavesest ajast igavesti ja seega on üsna keeruline võtta kätte ja see ära realiseerida. Realiseeritav tundub olevat pigem mingisugune koormustesti/monitoorimise lugu. Näiteks:

“Projektijuhina tahan, et iga tarne järgselt jookseks automaatselt koormustest, mis tuvastab 1 sekundi reeglile vastavust, et ennetada jõudlusprobleeme.”

Omaette ooper on arenduse käigus selguvate vigade, probleemide või täiendustega, mis ei tulene otseselt nõuetest. Näiteks leitakse mingi turvaauk; vajadus muuta arhitektuuri (reafaktoreerida); kasutajaliidese ebakõla; lihtsalt kole kood. Ükski neist ei pruugi tunduda kliendile/lõppkasutajale eriti tähtis – kõik ju toimib muidu ka. Arendaja mõttes on need aga tõsised asjad, millel hiljem võivad olla tõsised tagajärjed.

Üks viis neid teadvustada ja prioriteeti tõsta on ärakasutajalood (abuser story). Põhimõtteliselt on tegu negatiivsete kasutajalugudega, millel on ROI(1) (return on investment) asemel ROI(2) (risk of inactivity). Tavaliselt räägitakse neist turvalisuse juures ja tüüpiline näide:

“Kurja häkkerina tahan varastada krediitkaartide andmeid, et saaksin kalleid asju osta”.

Ärakasutaja võib aga olla ka laisk kasutaja, agar klikkija, lihtsalt hästi palju kasutajaid, ajahädas arendaja, halb liidestatud süsteem ja nii edasi. Näiteks:

“Laisa kasutajana ma ei viitsi otsida ja sisestada aadressi juurde postiindeksit ja jätan selle täitmata, et säästa ennast post.ee lehele minekust ja selle asemel midagi meeldivamat teha.”

“Ajahädas arendajana ma ei kontrolli enne koodi push’imist, kas minu koodimuudatus lõhub olemasolevat funktsionaalsust, et jõuda rohkem uusi funktsionaalsusi lisada”.

“Halva liidestatud süsteemina ma jätkan sobimatu vastuse puhul süsteemi pommitamist päringutega, et siiski oma vastus saada”.

Need lood on võib-olla juba arusaadavamad – esimesel juhul on risk on postindeksi puudumine või vale indeksi sisestamine. Võib-olla peaks olema teenus, mis ise indeksi leiab? Teisel juhul on risk toodangus ilmnevad regressioonid ja lahenduseks automaattestid (ja võib-olla commit hook vms). Kolmandal juhul on risk koormus süsteemile. Nüüd säilib lootus, et tellija/toote omanik suudab ka selliseid vigu ja täiendusi paremini koos teiste kasutajalugudega tähtsuse järjekorda sättida.

Ärakasutajalugu ei ole tegelikult päris kasutajalugu. Tal on küll sarnane formaat, ja kui kasutajalool on vastuvõtukriteeriumid (acceptance criteria), siis ärakasutajalool on kummutamiskriteeriumid (refutation criteria) ehk mingid tingimused, mille puhul võime öelda, et vastav ärakasutaja tegevus ei ole võimalik. Kuid ärakasutajalugu ei kirjelda kuidagi tegevust. Ideaalis oleks ärakasutajalugu eepos (epic), mille all oleks konkreetsed kasutajalood:

“Tavakasutajana tahan, et süsteem leiaks ise postiindeksi vastavalt aadressile, et ma ei saaks teha vigu ega peaks seda mujalt taga otsima”

“Projektijuhina/kasutajatoe juhina tahan, et peamised kasutusstsenaariumid oleksid kaetud automaattestidega, et ma ei peaks tegelema live-keskkonna regressioonidega.”

Ärakasutajalugu on üks võte, mis aitab pöörata tähelepanu riskidele, mis ühe või teise asja tegemata jätmisega kaasneda võivad ning leida seal seest tegelikke kasutajalugusid.

---