Näin kirjoitat käyttäjätarinoita (esimerkkejä ja hyväksymiskriteerejä)

Käyttäjätarina on lyhyt kuvaus ominaisuudesta käyttäjän näkökulmasta: „Käyttäjänä [käyttäjätyyppi] haluan [tavoite], jotta [syy].” Sen alle kirjoitat hyväksymiskriteerit, muutamia tarkkoja ehtoja, joiden pitää täyttyä, jotta tarina katsotaan valmiiksi. Pidä jokainen tarina tarpeeksi pienenä, jotta sen voi rakentaa ja testata kerralla, ja kirjoita kriteerit niin, että kuka tahansa voi tarkistaa ne.

Käyttäjätarinat tulivat tunnetuiksi ketterissä ohjelmistotiimeissä, mutta ne ovat yhtä hyödyllisiä, kun rakennat yksin tekoälysovelluskehittäjällä. Hyvä tarina on hyvä kehote.

Muoto

Käyttäjätarinassa on kolme osaa:

Käyttäjänä [kuka] haluan [mitä] jotta [miksi].

• Kuka on tietty käyttäjätyyppi: ensikertainen kävijä, maksava jäsen, klinikan vastaanottovirkailija, ylläpitäjä. Ei „käyttäjä”.
• Mitä on se, minkä he haluavat tehdä, heidän omin sanoin. Ei sitä, miten näyttö toimii.
• Miksi on lopputulos, josta he välittävät. Sen ihmiset usein ohittavat, ja juuri se estää rakentamasta väärää asiaa.

Esimerkki:

Käyttäjänä kuntosalijäsenenä haluan peruuttaa ryhmäliikuntavarauksen puhelimellani, jotta jonotuslistalla oleva voi ottaa paikkani eikä minulta veloiteta poissaolomaksua.

„Miksi” kertoo kaksi asiaa, joita „mitä” ei kertonut: sen pitää toimia puhelimella, ja jonotuslista ja maksusäännöt ovat mukana.

Hyväksymiskriteerit

Tarina kertoo, mitä halutaan. Hyväksymiskriteerit kertovat, milloin se on valmis. Niiden pitää olla tarkkoja, jotta kaksi ihmistä olisi samaa mieltä siitä, täyttyykö jokainen.

Yleinen tapa kirjoittaa ne on Annettuna / Kun / Niin:

• Annettuna lähtötilanne
• Kun käyttäjä tekee jotakin
• Niin tämä on tulos

Kuntosalivarauksen tarinalle:

1. Annettuna minulla on varaus yli 12 tunnin päässä, kun napautan Peru ja vahvistan, niin varaus poistuu ja näen ilmoituksen „Varaus peruttu”.
2. Annettuna peruutan varauksen ja tunnilla on jonotuslista, kun peruutus tallentuu, niin jonotuslistan ensimmäinen henkilö saa paikan ja sähköpostin.
3. Annettuna varaus on alle 12 tunnin päässä, kun napautan Peru, niin näen ennen vahvistusta, että myöhäisperuutusmaksu koskee sitä.
4. Annettuna olen puhelimen levyisellä näytöllä, niin Peru-painike näkyy ilman vaakasuuntaista vierittämistä.

Yksinkertainen tarkistuslista käy myös, kunhan jokainen kohta on testattavissa. „Peruuttaminen on helppoa” ei ole testattavissa. „Peruutus vie korkeintaan kaksi napautusta varauslistalta” on.

Vaihe vaiheelta: hyvän tarinan kirjoittaminen

Vaihe 1: Lähde todellisesta käyttäjästä ja todellisesta ongelmasta

Valitse yksi käyttäjätyyppi ja asia, jossa he kamppailevat nyt. Jos olet tehnyt asiakashaastatteluja, käytä heidän sanojaan. „Unohdan aina peruuttaa ja minulta veloitetaan” on parempi lähtökohta kuin „lisää peruutusominaisuus”.

Vaihe 2: Kirjoita yhden rivin tarina

Täytä mallipohja. Jos et osaa kirjoittaa vakuuttavaa „jotta”-osaa, kysy, tarvitaanko ominaisuutta ylipäätään.

Vaihe 3: Lisää kolmesta kuuteen hyväksymiskriteeriä

Kata ensin pääasiallinen onnistumistapaus, sitten tärkeät vaihtoehdot: eri rooli, tyhjä tila, raja, virhe. Jos kirjoitat yli kuusi, tarina on luultavasti liian suuri.

Vaihe 4: Merkitse, mikä on rajauksen ulkopuolella

Yksi rivi säästää paljon edestakaista keskustelua: „Rajauksen ulkopuolella: maksullisten tuntien hyvitykset; ylläpitäjät, jotka peruvat jäsenen puolesta.” Se estää tarinaa kasvamasta rakentamisen aikana.

Vaihe 5: Tarkista INVEST-mallin mukaan

INVEST on yleinen tarkistuslista hyville tarinoille. Tarinan pitäisi olla:

Jokaista tarinaa ei tarvitse pisteyttää. Malli on hyödyllisin silloin, kun tarina tuntuu väärältä ja haluat tietää miksi.

Hyvät ja huonot esimerkit

Näin pilkot liian ison tarinan

Isot tarinat ovat kohta, jossa projektit jumittuvat. Yleisiä tapoja jakaa:

• Käyttäjäroolin mukaan. Jäsenet peruvat omat varauksensa; henkilökunta peruu minkä tahansa.
• Kulun vaiheen mukaan. Selaa tunteja; varaa tunti; saa muistutus.
• Yksinkertainen tapaus ensin. Peru ilmainen tunti nyt; käsittele maksut ja hyvitykset myöhemmässä tarinassa.
• Datan vaihtelun mukaan. Tue ensin yhtä toimipaikkaa, useita myöhemmin.
• Onnistunut polku ensin, sitten virheet. Rakenna ensin toimiva versio, lisää sitten käsittely täynnä oleville tunneille, vanhentuneille kausikorteille ja vastaaville.

Jokaisen palasen pitää silti olla jotakin, jota käyttäjä voisi käyttää ja huomata.

Käyttäjätarinat kehotteina

Käyttäjätarina hyväksymiskriteereineen on hyvin lähellä hyvää kehotetta tekoälysovelluskehittäjälle. Se kertoo tekoälylle kenelle, mitä, miksi ja mitä tarkoittaa valmis. Lähetä yksi tarina viestiä kohden:

Käyttäjänä kuntosalijäsenenä haluan peruuttaa ryhmäliikuntavarauksen puhelimellani, jotta jonotuslistalla oleva voi ottaa paikkani. Hyväksymiskriteerit:

1. Peru-painike on jokaisen varauksen kohdalla Varaukseni-näkymässä, ja siinä on vahvistusvaihe.
2. Peruutus yli 12 tuntia ennen tuntia poistaa vain varauksen.
3. Alle 12 tuntia ennen näytä ennen vahvistusta „Myöhäisperuutusmaksu 5 € koskee tätä”, ja kirjaa maksu varaukselle.
4. Jos tunnilla on jonotuslista, ensimmäinen henkilö saa paikan ja sähköpostin.
5. Toimii puhelimen levyisellä näytöllä. Rajauksen ulkopuolella: hyvitykset, henkilökunnan tekemät peruutukset jäsenten puolesta. Rakenna tämä, tarkista jokainen kriteeri esikatselussa ja kerro, mitkä menevät läpi.

Voit myös pyytää tekoälyä laatimaan tarinoita karkeasta ideasta ja muokata niitä itse:

Tässä on sovellusideani: [kaksi tai kolme lausetta]. Kirjoita käyttäjätarinat ensimmäiselle versiolle ryhmiteltyinä käyttäjätyypin mukaan, jokaisessa 3–5 Annettuna / Kun / Niin -hyväksymiskriteeriä. Merkitse, mitkä ovat julkaisun kannalta välttämättömiä ja mitkä voivat odottaa.

Lue ja muokkaa tulos aina. Tekoäly ei tunne käyttäjiäsi; sinä tunnet.

Hyväksymiskriteerit toimivat myös testisuunnitelmanasi. Kun tarina on rakennettu, käy jokainen kriteeri itse läpi. Oppaamme sovelluksesi testaamisesta ennen julkaisua rakentuu tämän päälle.

Missä käyttäjätarinat sopivat muiden asiakirjojen joukkoon

• Tuotevaatimusmäärittely kuvaa koko tuotteen: ongelman, käyttäjät, laajuuden. Käyttäjätarinat ovat siinä olevia yksityiskohtaisia osia. Katso näin kirjoitat PRD:n tekoälyllä.
• Virheraportti kuvaa jotakin, mikä on rikki verrattuna jo rakennettuun tarinaan. Katso näin kirjoitat hyvän virheraportin.
• MVP on pienin joukko tarinoita, joka tuo ydinarvon. Katso mikä on MVP.

Yleisimmät virheet

• „Käyttäjänä…” Liian epämääräinen. Nimeä todellinen käyttäjätyyppi.
• „jotta”-osan ohittaminen. Ilman syytä et voi tehdä järkeviä kompromisseja.
• Ratkaisun kirjoittaminen tarpeen sijaan. „Haluan pudotusvalikon” lukitsee suunnittelun ennen kuin kukaan on ajatellut sitä.
• Kriteerit, joita ei voi testata. „Helppo”, „nopea” ja „intuitiivinen” ovat toiveita, eivät kriteerejä.
• Tarinat, jotka ovat oikeasti epiikkoja. „Hallitse tiliäni” on kymmenen tarinaa.
• Kaikkien tarinoiden kirjoittaminen etukäteen. Kirjoita seuraavat muutama yksityiskohtaisesti; pidä loput yhden rivin muistiinpanoina, kunnes pääset niihin.

Tarinat Mythexissä

Mythexissä Suunnittelu-tila on hyvä paikka muuttaa idea tarinoiksi: agentti keskustelee lähestymistavasta ennen kuin muokkaa mitään. Kun tarina on valmis, vaihda Rakenna-tilaan ja liitä se, yksi tarina viestiä kohden. Jokaisen jälkeen /test voi klikkailla esikatselun läpi ja tarkistaa kulun, ja minkä tahansa vastauksen voit palauttaa Palauta tähän kohtaan -toiminnolla, jos muutos meni väärään suuntaan. Katso dokumentaation tehokkaat kehotteet ja oppaamme kehotteiden kirjoittamisesta tekoälysovelluskehittäjille.

Käyttäjätarinan tarkistuslista

• Nimeää tietyn käyttäjätyypin
• Kuvaa tarpeen, ei suunnitelmaa
• Sisältää todellisen „jotta”-syyn
• Sisältää kolmesta kuuteen testattavaa hyväksymiskriteeriä
• Kattaa vähintään yhden reunatapauksen tai virheen
• Kertoo, mikä on rajauksen ulkopuolella
• On tarpeeksi pieni rakennettavaksi ja testattavaksi kerralla
• Kriteerit tarkistettu rakentamisen jälkeen yksi kerrallaan

Kysymykset