Scrum vadovas | 21. Vartotojo istorijos klaidos

Vartotojų istorijos aprašo, kaip veikia nauja produkto funkcionalumas kasdieniame ar verslo kalba. Tačiau jų paruošimas reikalauja daug laiko, pastangų ir mąstymo. Šiandienos įraše mes nurodome dažniausiai pasitaikančias vartotojų istorijų klaidas ir siūlome, kaip su jomis elgtis.

Dažniausios vartotojų istorijų klaidos – turinys:

1. Įžanga
2. Problemos su 3W
3. Problemos su 3C
4. Vartotojų istorijų klaidos – santrauka

Įžanga

Vartotojų istorija gali būti puikus įrankis motyvuoti komandą siūlyti naujus sprendimus problemoms, pateiktoms iš vartotojo perspektyvos. Apie tai, kas yra vartotojų istorija, rašėme atskiroje įraše. O šioje straipsnyje pristatėme INVEST, kuris yra populiarus gerų vartotojų istorijų rašymo metodas. Šiandien mes sutelksime dėmesį į vartotojų istorijų klaidas.

Problemos su 3W

Tinkama vartotojų istorija atsako į klausimus:

• Kas? (Kas yra produkto tikslinis vartotojas?)
• Kas? (Kokias galimybes turi produktas ir ką jis gali padaryti?)
• Kodėl? (Kokiam tikslui tai tarnauja?)

Tačiau problemos gali lydėti atsakymus į kiekvieną iš šių klausimų. Mažiausiai dažna problema yra abejonė dėl to, kas turėtų pasikeisti produkte reaguojant į kliento poreikius. Todėl mes sutelksime dėmesį į problemas, susijusias su Kas? ir Kodėl?

Kas – vartotojo persona

Viena iš dažniausiai pasitaikančių klaidų, kurių daroma kuriant vartotojų istorijas, yra nepakankamai tikslus atsakymas į klausimą: kam? Kitaip tariant, kas yra vartotojas, kuriam skirta numatyta pakeitimo?

Dažnai bendras atsakymas, nurodantis Klientą arba Galutinį Vartotoją kaip pakeitimo gavėją, nėra pakankamas. Šios problemos sprendimas yra įsivaizduoti gavėją kaip konkretų personažą. Persona yra modelio vaizdas tikslinio kliento. Kitaip tariant, persona yra asmens, kuris naudos produktą konkrečiu būdu, atvaizdavimas.

Analizuodami savo vartotojų istoriją, galite pastebėti, kad ji pasakoja skirtingų žmonių istorijas tuo pačiu metu. Jei yra daug tikslinių vartotojų, verta apsvarstyti vartotojų istorijos padalijimą į mažesnius fragmentus, kad būtų išvengta prieštaringų, tarpusavyje nesuderinamų ar tiesiog neveiksmingų veiksmų.

Kodėl? – prastai apibrėžtas tikslas

Kartais paskutinė vartotojų istorijos dalis tampa problemų šaltiniu. Joje turėtų būti nurodyta verslo vertė pakeitimų, padarytų vykdant vartotojų istoriją. Pažvelkite į vartotojų istorijų klaidų pavyzdį, kur papildomos funkcionalumo aprašymas pakeičia tikslą:

Kaip klientas, noriu nusipirkti magišką lazdelę vienu paspaudimu, nes noriu kitą savaitę nusipirkti skraidantį kilimą.

Vietoj to, kad pateiktų priežastį, kodėl reikia pirkti magišką lazdelę, ši vartotojų istorija prideda dar vieną elementą potencialaus kliento pirkinių sąraše. Todėl, rengdami vartotojų istoriją, nepamirškite priežasčių, kodėl keičiasi produkto funkcionalumas.

Problemos su 3C

Mes galime suskaidyti darbą su vartotojų istorijomis į tris etapus, vadinamus 3C:

• Kortelė – Kortelė, kurioje saugoma vartotojų istorija
• Pokalbis – Pokalbis Scrum komandoje apie vartotojų istorijos kortelę
• Patvirtinimas – priimtinumo kriterijų apibrėžimas, patvirtinantis, kad užduotis buvo atlikta

Klaidos gali pasitaikyti bet kuriame iš šių etapų, kuriuos aprašome žemiau.

Kortelė

Atminties kortelė, kurioje saugoma vartotojų istorija, turi ribotą talpą. Todėl dažniausios problemos susijusios su vartotojų istorijos ilgiu ir apimtimi. Vartotojų istorija turi būti nuosekli ir be aplinkinių kalbų, kaip sakoma, iki tokio tikslaus laipsnio, kad kiekvienas žodis būtų svarbus.

Tai yra todėl, kad vartotojų istorijos kortelės problema turi dvi dimensijas. Viena yra tai, kaip ji suformuluota: trumpai ir turinti būtiną minimalų išvardijimą. Antra yra tikrasis vartotojų istorijos dydis. Viena bendra sakinio gali išreikšti didelį skaičių užduočių, kurių negalima įvykdyti per vieną Sprintą.

Pokalbis

Vartotojų istorijos vieno sakinio formulavimas yra pradinė taškas pokalbiui su plėtros komanda. Todėl neteisinga ją laikyti užduoties aprašymu. Tai neleidžia derėtis ir diskutuoti apie įvairius jos įgyvendinimo būdus. Vartotojų istorija neturėtų būti laikoma naujos produkto funkcionalumo reikalavimų aprašymu, tai labiau kvietimas pradėti pokalbį apie konkrečius techninius sprendimus, kurie atves prie verslo vertės, apibrėžtos vartotojų istorijoje, realizavimo.

Patvirtinimas

Apie priimtinumo kriterijus, kurie turi būti apibrėžti kiekvienai vartotojų istorijai, išsamiai rašėme tekste, aprašančiame kas yra vartotojų istorija. Tačiau viena iš dažnų klaidų yra neaiškumas dėl veiklos kriterijų.

Gerai parašyta vartotojų istorija apima situacijos aprašymą, kurioje ji įgyvendinama. Jos testas yra tas, kad vartotojas pasinaudoja nauja funkcionalumu, sukurtu plėtros komandos.

Naudingas įrankis vartotojų istorijos patvirtinimui yra priimtinumo testas. Tai paprastai būna kortelės, kurioje yra vartotojų istorija, kitoje pusėje.

Vartotojų istorijų klaidos – santrauka

Rengdami ir taikydami vartotojų istorijas, verta laikytis šių taisyklių:

• Tiksliai nustatykite vartotoją, paveiktą pakeitimo
• Aiškiai apibrėžkite naujos produkto funkcionalumo kūrimo tikslą
• Laikykite jos apimtį kuo trumpesnę
• Traktokite vartotojų istoriją kaip pradinį tašką sprendimų diskusijoms su plėtros komanda
• Nustatykite aiškias priimtinumo taisykles

Jei jums patinka mūsų turinys, prisijunkite prie mūsų užimtų bičių bendruomenės Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.