Kuidas kirjutada häid agiilseid kasutajalugusid

Üks esimesi samme kvaliteetse toote tarnimisel on heade kasutajalugude kirjutamine. Selles postituses kirjeldame, kuidas kirjutada häid kasutajalugusid ja mida peaks lisama.

Kasutajalugu on koht toote funktsionaalsuse jäädvustamiseks ja nagu nimigi ütleb, kirjeldavad kasutajalood, kuidas klient või kasutaja toodet kasutab.

Kasutaja lugu esindab väikest funktsionaalsust, millel on äriline väärtus, mida meeskond suudab pakkuda sprindis. Kasutajaloo ja traditsioonilise nõudedokumendi erinevus on detailide tase.


Nõudedokumendid sisaldavad tavaliselt palju teksti ja on väga üksikasjalikud, samas kui kasutajate lood põhinevad peamiselt vestlustel.

Kasutajaloo struktuuri saame jagada järgmiselt:


  • Vajaduse lühikirjeldus
  • Vestlused, mis juhtuvad mahajäämuse peibutamise ja sprindi planeerimise ajal detailide kindlustamiseks
  • Vastuvõtutestid, mis kinnitavad loo rahuldavat valmimist

Oluline punkt, mida kasutajalugude kirjutamisel meeles pidada, on see, et need on kirjutatud selle kasutaja vaatenurgast, kes toodet lõpuks kasutab, seetõttu on oluline, et kasutajalugude kirjutamisel tuvastaksime selgelt, kes on kasutaja.



Kuidas kirjutada häid kasutajalugusid

Rusikareeglina peaks hea kasutajalugu järgima INVEST-i lühendit:

Mina sõltumatud - kasutajate lood ei tohiks üksteisest sõltuda, nii et neid saab arendada mis tahes järjekorras.

N egotiable - vältige liiga palju detaile; hoia neid paindlikuna, et meeskond saaks kohandada, kui palju lugu rakendada.


V aluable - lugu peaks selle kasutajatele mingit väärtust pakkuma.

ON stimuleeritav - meeskond peab oskama lugu hinnata.

S kaubanduskeskus - kasutajate lood peaksid olema piisavalt väikesed, et mahuksid sprinti; suuri lugusid on raske hinnata ja planeerida.

T estable - tagada, et arendatavat saaks piisavalt kontrollida ja testida.


Millist vormingut kasutatakse kasutajate lugude kirjutamiseks?

Kasutajate lugudel on tavaliselt järgmine vorming:

_As, ma tahan nii, et.

Näide: a klient saidilt abc.com soovin a Logi sisse funktsionaalsust, et saaksin juurdepääs minu konto üksikasjadele veebis .

Nagu varem mainitud, pöörake erilist tähelepanu sellele, kes on toote kasutaja, ja vältige „Kasutaja” üldist rolli. Kui te ei tea, kes on kasutajad ja kliendid ning miks nad toodet kasutada tahaksid, peaksite seda tegema mitte kirjuta kasutajalugusid.


Jutustav

  • Kasutajaloo esimene osa on Narratiiv. 2–3 lauset, mida kasutatakse loo kavatsuse kirjeldamiseks. See on lihtsalt kavatsuse kokkuvõte.

Vestlused

  • Kasutajaloo kõige olulisem aspekt on vestlused, mis peaksid arendusmeeskonna, kliendi, tooteomaniku ja teiste sidusrühmade vahel pidevalt toimuma, et kasutajaloo üksikasjad kindlustada.

Vastuvõetavuse kriteeriumid

  • Vastuvõtukriteeriumid esindavad rahulolu tingimusi, mis on kirjutatud stsenaariumidena, tavaliselt vormis Gherkin (antud, millal, siis). Vastuvõtukriteeriumid pakuvad ka loo jaoks valmis definitsiooni.

Kes peaks kasutajalugusid kirjutama?

Enamasti kirjutab kasutajalugusid a Toote omanik või ärianalüütik ja prioriteetsed toote mahajäämuses. Kuid see ei tähenda, et kasutajalugude kirjutamine on ainult toote omaniku kohustus. Tegelikult saab kasutajate lugusid kirjutada iga meeskonnaliige, kuid tooteomaniku ülesanne on tagada kasutajalugude mahajäämuse olemasolu ja prioriteetsus.


Oluline on see, kas kasutajate lood ei peaks koheldakse nagu nõuete dokumenti, mis kirjutamisel antakse arendusmeeskonnale rakendamiseks.

Kasutajalugusid tuleks vaadelda kui vahendit tooteomaniku ja arendustiimi vaheliste vestluste ergutamiseks ning seepärast tuleks need koostada toote mahajäämuse hooldustööde käigus.

Arendustiimi kaasamise eelis kasutajalugude kirjutamise eeliseks on see, et kui on mingeid tehnilisi piiranguid, saab neid aegsasti esile tuua. Testijad saavad tõhusate vastuvõtukriteeriumide väljatöötamisel iseäranis lisaväärtust luua ja eelnevalt planeerida, mida ja kuidas katsetada tuleb.

Kui detailsed peaksid olema kasutajate lood?

Kasutajate lood keskenduvad kliendi väärtusele.

Põhiline erinevus kasutajalugude ja muude nõuete spetsifikatsioonide vahel on detailide tase. Kasutajalugu on tehtud töö metafoor, mitte töö täielik kirjeldus. Tegelikku tööd täiendatakse süsteemi arendamise edenedes kasutajaloo ümber toimuva koostöö kaudu.

Kui kirjeldus muutub liiga pikaks (rohkem kui see, mis mahub registrikaardile), peaksite kasutajalugu uuesti vaatama. Tõenäoliselt proovite lisada liiga palju üksikasju.

Pidage meeles, et kasutajaloo eesmärk on julgustada koostööd. See ei ole mõeldud töö iga aspekti dokumenteerimiseks, nagu tavaliselt traditsiooniliste nõuete avaldustes.

Pealegi võib kirjelduses sisalduv liiga palju teavet põhjustada vastuvõtukriteeriumites teabe puudumise.

Enne kui nõustute loo kallal töötama, peab meeskond mõistma vastuvõtukriteeriume. Need on hädavajalikud, et teada saada, mida tuleb kasutajaloo rahuldamiseks teha. Vastuvõtukriteeriumid peaksid olema piisavalt üksikasjalikud, et määratleda, millal kasutajalugu on täidetud, kuid mitte nii üksikasjalikud, et koostöö tühistada.

Kasutajalugude kirjutamisel levinud vead


  • Liiga ametlik või liiga detailne. Heade kavatsustega tooteomanikud püüavad sageli kirjutada äärmiselt üksikasjalikke kasutajalugusid. Kui meeskond näeb iteratsiooni planeerimisel lugu, mis näeb välja nagu IEEE nõuete dokument, eeldavad nad sageli, et kõik üksikasjad on olemas, ja jätavad detailse vestluse vahele.


  • Kasutajate lugude kirjutamine tehniliste ülesannete jaoks. Suur osa Agile'i võimsusest tuleneb tarkvarade töötava juurdekasvu olemasolu iga iteratsiooni lõpus. Kui teie lood on tegelikult vaid tehnilised ülesanded, ei jõua te sageli iga korduse lõpus töötava tarkvaraga ning kaotate prioriteetide määramisel paindlikkuse.


  • Vestluse vahele jätmine. Enne iteratsiooni planeerimist on lood tahtlikult ebamäärased. Kui jätate aktsepteerimiskriteeriumide vestluse vahele, võite liikuda vales suunas, puududa servajuhtumid või jätta tähelepanuta kliendi vajadused.

Kas teil on ülaltoodud teabele lisamiseks näpunäiteid heade kasutajalugude kirjutamiseks? Pange need julgelt kommentaaridesse.