Käyttäjä tarinat ovat yksinkertaisia, mutta erittäin tehokas konstruktioita: ne kuvaavat kappaletta toiminnallisuutta käyttäjän näkökulmasta ilmaistuna vankka, kompakti tavalla. Ne heijastavat sitä, mitä tietty käyttäjäluokka tarvitsee ja mitä arvoa sillä on saavutettava. Formaatti on hyvin yksinkertainen ja helppokäyttöinen. Variaatioita on useita, muun muassa:

miksi Käyttäjätarinoita?

Käyttäjätarinat tarjoavat erinomaisen tavan määritellä tuotteesi selkeästi., Joukko hyvin määriteltyjä, priorisoidut käyttäjätarinat voi auttaa sinua ilmaisemaan toiminnallisuutta tuotteen käyttämällä plain englanti’ — ei teknisiä ja täytäntöönpanoa koskevia yksityiskohtia.

’käyttäjä tarina’ lähestymistapa antaa mielekäs tuote keskusteluja, sekä sisällä tuotekehitys ja ulkoisten sidosryhmien kanssa.

oikein kirjoitetut käyttäjätarinat tarjoavat vankan pohjan viestinnälle ja yhteistyölle — keskittyen siihen, mikä on käyttäjälle tärkeintä., Verrattuna muihin tapoja pyydystää ja dokumentointi käyttäjien vaatimukset ja tuote-eritelmän, ne on ainakin seuraavia etuja:

  1. Käyttäjän tarinoita auttaa saavuttamaan cross-joukkue selvyyttä siitä, mitä rakentaa, kenelle, miksi ja milloin. Koska ne ovat helppo määritellä, ymmärtää ja tarkistaa, he voivat tullut standardi tapa kommunikoida ja yhteenveto tuotteen toiminnallisuuteen sekä teknisiä ja ei-teknisiä jäseniä. Ne ovat erittäin hyödyllisiä tuotteen laajuutta koskevissa keskusteluissa tai teknisten syväsukellusten syöttöpisteinä. Ne ovat agile Engineeringin keskeisiä elementtejä.,
  2. Käyttäjätarinat kannustavat ei-teknisiin jäseniin. Nykyaikaiset ohjelmistoprojektit ovat tyypillisesti monimutkaisia, ja niihin liittyy monenlaisia teknologioita, lyhenteitä ja toteutusvaihtoehtoja. Monissa tapauksissa, terminologiaa tai tekninen kieli ei ole yleisesti ymmärretään — jopa yhden joukkueen — siis esittelyssä ”melua” ja riskit hankkeen. Käyttäjätarinat poistavat tämän teknisen ulottuvuuden, joten kuka tahansa tiimin jäsen voi osallistua, yksinkertaisesti ajattelemalla ”käyttäjänä”., Joukkue voi käyttää ei-teknistä kieltä ja tehokkaasti yhteistyötä määriteltäessä, haastava tai priorisoimalla käyttäjätarinoita. Vaikutus yhteistyöhön ja tiimidynamiikkaan voi olla merkittävä.
  3. ne auttavat määrittelemään koko tuotteen — joukko kiinteitä, viisaasti-priorisoituja tarinoita. Tuotekehitystiimi voi ajatella isosti, määritellä käyttäjien tarinoiden superjoukon ja määrittää sitten prioriteetit (jotka heijastavat käyttäjän odotusarvoa, monimutkaisuutta, riippuvuuksia ja muita liiketoiminnan painopisteitä). Sinun ei tarvitse tehdä vaikeita päätöksiä ja liputtaa kohteita ”Out of scope”., Sen sijaan, voit asettaa alemman prioriteetin nämä ”hullu” ideoita, kun siirrytään käyttäjän tarinoita heijastavat ydintoiminnallisuutta tuotteen. Määritellään ’leikata linjat’, jotka määrittävät kunkin iteraation, vaihe tai versio, on sitten kyse käytettävissä olevien resurssien ja nopeus joukkue.

suurten Käyttäjäkertomusten kirjoittaminen

formaatti on suoraviivainen, ja tarinoiden kirjoittaminen on helppoa. Mutta hienojen kirjoittaminen voi olla hieman hankalaa. Tässä muutamia ohjeita harkittavaksi:

Käyttäjätarinat ≠ tehtävät

Käyttäjätarinat eivät ole tehtäviä., Itse asiassa yksi tarina voi tarvita satoja yksittäisiä tehtäviä onnistuneesti toimitetaan. Tehtävät liittyvät toteutukseen, käyttäjätarinat määrittelyyn.

kun kokoat tarinoitasi, keskity selkeyttämään tuotteen ominaisuuksia — mitä, ei miten.

pysy korkealla tasolla

sinun on oltava korkeatasoinen, mutta myös tarkka ja asiallinen. Tarinoiden on oltava yksinkertaisia ja kiinteitä. Tämä auttaa tiimin jäseniä ja sidosryhmiä ymmärtämään syvällisesti käyttäjien tarpeita ja välttää käyttämästä aikaa selkeyttämällä buzzwords -, terminologia-ja lyhenteitä. Käytä vain yksinkertaista ja tarkkaa kieltä.,

Ymmärtää käyttäjiä

Sinun täytyy löytää ja tutkia todellinen käyttäjät oman tuote — kaapata niiden profiilit, näkemyksiä, odotuksia, ja liittyy ’kipupisteitä.”Käyttäjätutkimus ja muut tekniikat voivat tuottaa oivalluksia, joiden avulla voit paremmin ymmärtää käyttäjiä ja heidän tarpeitaan.

tekniikoista riippumatta tarvitset avainkäyttäjien joukon — mieluiten personoiden muodossa — ennen kuin alat koota käyttäjien tarinoita.,

Ajattele kuin käyttäjä

<kuten tietyn luokan käyttäjä/ persoona /rooli> osa käyttäjän tarina, määrittää kulma, näkökulma — miten tietty käyttäjä kokee toiminnallisuus tiivistää tarinan.

Tämä on erittäin tärkeää — tuotteen omistaja ja koko joukkueen täytyy ajatella käyttäjän näkökulmasta ja ymmärtää taustalla olevat tarpeet ja odotusarvo.,

Ajattele isosti

Kun kuvataan tuotteen kehitysjonon käyttäjän tarinoita, ei ole hyvä syy rajoittaa ajattelua budjetti, aika, toteutettavuus tai kustannuksia.

hyvä käytäntö on ajatella isosti ja antaa ”hullujen” käyttäjätarinoiden mennä ruuhkaan. Laajennetun tuotekannan ylläpitämisen hallinnolliset yleiskustannukset ovat pienet; siitä saatava arvo — tuotteen selkeyden, vision ja mahdollisuuksien kannalta — on valtava.,

Käytä eepokset

Eepokset voi olla muodoltaan korkeamman tason tarinoita, jotka kuvaavat suuria paloja toiminnallisuus — ne yleensä vaativat huomattavan määrän työtä, useiden sprintissä. Toinen tapa ajatella eepoksia on niihin liittyvien, pienempien tarinoiden ryhmittelyt/ kontit, jotka kaikki palvelevat yhteistä tavoitetta. Eepokset ovat hyviä tarinoiden järjestämiseen ja kokonaiskuvan antamiseen.,

Älä hävitä — priorisoida sen sijaan

Koska tehokas priorisointi prosessi, se on hyvä käytäntö pitää rikastuttaa tuotteen kehitysjono, jossa uusi käyttäjä tarinoita, joissa kuvataan uuden käyttäjän vuorovaikutusta skenaarioita, ’random ideoita, tai lähtö tuote innovaatiotoimintaan.

mahdollisen melun hallitsemiseksi sinun on ryhmiteltävä ja priorisoitava uudet merkinnät oikein. Joka tapauksessa, älä suodattaa pois/hävitä kohteita ruuhkaa: de-rajatut kohteet ovat yleensä unohdetaan, kun de-priorisoidut kohteet ovat edelleen löydettävissä ja voi tulla merkityksellisiä oikeissa olosuhteissa.,

kontekstista riippuen käyttäjien tarinoiden priorisointi voi olla hankala prosessi. Sinun täytyy arvioida arvo kunkin tarinan, käyttäjän ja liiketoiminnan. Sinun täytyy koko monimutkaisuus, arvioida toteutettavuus ja kustannukset/ponnistus rakentaa ja vapauttaa ominaisuus. Sinun täytyy tunnistaa rajat riippuvuudet backlog-täytäntöönpano erityinen tilaus välillä tiettyjä merkintöjä.

Setup for success — not just acceptance

tiimit määrittelevät usein käyttäjien hyväksymistestit ja niihin liittyvät hyväksymiskriteerit. Hyväksyminen ei kuitenkaan riitä-sinun täytyy perustaa menestykseen., Tuotepäällikkö, tarvitset enemmän kuin vahvistus siitä, että se toimii niin kuin sen pitäisi ” tai ” mukaan silmälasit.’

tarvitsemme mittareita, jotka ovat myös liittyy suoraan käyttäjien palautetta, syömällä, kuinka onnellinen ja kihloissa todellinen käyttäjät ovat. Kun hyväksyminen on hyvä ohjata kehitystä elinkaaren ominaisuus, menestys on kyse keskipitkän/pitkän aikavälin vaikutuksia ja arvo luodaan todellinen käyttäjät oman tuotteen. Sinun täytyy määritellä sekä — tuotteen ja/tai eeppinen ja/tai tarinan tasolla.

Tag stories, add metadata

Complex-tuotteet vaativat satoja käyttäjätarinoita., Helpomman navigoinnin ja hallinnon, sinun täytyy tehokkaasti nimetä, luokitella, ja tag tarinoita. Kun ensimmäiset versiot tarina, sinun tulisi välttää uudelleennimeäminen tai radikaalisti muuttaa sen kuvaus, koska tämä saattaa aiheuttaa sekaannusta ja puutteita joukkueessa.

tarinoidesi metatietojen asianmukainen hallinta—Tila, edistyminen, linkit, prioriteetit, resurssit jne. – auttaa tutkimaan, seuraamaan ja ymmärtämään ruuhkaa.

älä tartu tahmeisiin muistiinpanoihin!,

Kyllä, seinä on täynnä värikkäitä muistilappuja näyttää fancy ja auttaa joukkue näyttää kiireinen ja tuottelias 🙂 Mutta tarvitset vakavia järjestelmän ja erityisiä työkaluja, joiden avulla voit hallita asianmukaisesti, rikastuttaa, priorisoida ja jakaa tarinoita.,

erityistapauksissa, kuten aivoriihi tai ajatuksia istunto, se on okei kaapata ensimmäiset käyttäjän tarinoita käyttämällä sticky notes—edellyttäen, että et sitten asiakirjan kaikki ne osaksi oikea tuote hallintajärjestelmä. Jos et, ja vain pitää tarinoita tahmea muistiinpanoja, mahdollisuudet ovat, että menetät mahdollisuuksia selkeyden, innovaation, tehokkuuden ja yhteistyön.,

tarvitset vielä TIEDOT

joilla on priorisoitu joukko hyvin määriteltyjä käyttäjätarinoita on suuri, mutta se on vasta alkua. Tiimin on analysoitava tarinat-teknisestä näkökulmasta-ja luotava tarvittavat tekniset esineet.

Ihannetapauksessa tarinat kartoitetaan tiettyyn dokumentaatioon, joka tarjoaa kaikki tarvittavat tekniset yksityiskohdat ohjelmistotekniikan näkökulmasta. Ne tarjoavat maahantulon pistettä yksityiskohtainen tekninen erittely asiakirjoja ja muita yksityiskohtaisia esineitä.,

Visualisointi auttaa

aina päällä (digitaalinen) visualisointi top-prioriteetti käyttäjän tarinoita luokittain, teema, tai eeppinen voisi olla erittäin hyödyllinen yhteistyö ja linjaus tiimien ja sidosryhmien kanssa. Yhdessä tilastot, kysymyksiä, salpaajat, ja edistymisen indikaattoreita, tarina, kartta voidaan tarjoilla kautta interaktiivisia näyttöjä yhteistyön tilaa.

Käyttäjätarinat tarjoavat oivan tavan nopeasti ja tarkasti kuvata ohjelmistotuotteen tai-järjestelmän toimivuutta., He ovat myös erittäin tehokas syömällä lähdöt aivoriihi-istuntoja, suunnitella kiri, hackathons, ja muut innovaatio-led-prosesseja, — jossa on virta ideoita on kiinni kompakti, jäsennelty tavalla.