Si të shkruani histori përdoruesi (me shembuj dhe kritere pranimi)
Një histori përdoruesi është një përshkrim i shkurtër i një veçorie nga pikëpamja e përdoruesit: „Si [lloj përdoruesi], dua [qëllim] që [arsye].“ Nën të shkruani kriteret e pranimit, disa kushte specifike që duhet të jenë të vërteta që historia të konsiderohet e përfunduar. Mbajeni çdo histori mjaft të vogël për t’u ndërtuar dhe testuar në një herë, dhe shkruani kriteret në atë mënyrë që këdo t’i kontrollojë.
Historitë e përdoruesit u popullarizuan nga ekipet agjile të softuerit, por janë po aq të dobishme kur ndërtoni vetë me një ndërtues aplikacionesh me AI. Një histori e mirë është një prompt i mirë.
Formati
Një histori përdoruesi ka tre pjesë:
Si [kush], dua [çfarë] që [pse].
- Kush është një lloj i caktuar përdoruesi: një vizitor për herë të parë, një anëtar që paguan, një recepsioniste klinike, një admin. Jo „përdoruesi“.
- Çfarë është gjëja që dëshiron të bëjë, me fjalët e tij. Jo si funksionon ekrani.
- Pse është rezultati që i intereson. Është pjesa që njerëzit e kapërcejnë, dhe ajo që ju ndalon të ndërtoni gabimisht.
Shembull:
Si anëtar i palestrës, dua të anuloj një rezervim klase nga telefoni im që dikush në listën e pritjes të mund ta marrë vendin tim dhe unë të mos paguaj tarifë për mungesë.
„Pse“-ja të tregon dy gjëra që „çfarë“-ja nuk i tregoi: duhet të funksionojë në telefon, dhe janë të përfshira listat e pritjes dhe rregullat e tarifave.
Kriteret e pranimit
Historia thotë çfarë kërkohet. Kriteret e pranimit thonë kur është e plotë. Duhet të jenë mjaft specifike, sa që dy persona të pajtohen nëse secili kalon ose jo.
Një mënyrë e zakonshme për t’i shkruar është Given / When / Then:
- Given një situatë fillestare
- When përdoruesi bën diçka
- Then ky është rezultati
Për historinë e rezervimit në palestër:
- Given kam një rezervim më shumë se 12 orë larg, when shtyp Anulo dhe konfirmo, then rezervimi hiqet dhe shoh „Rezervimi u anulua“.
- Given anuloj një rezervim dhe klasa ka listë pritjeje, when anulimi ruhet, then personi i parë në listën e pritjes merr vendin dhe një email.
- Given një rezervim më pak se 12 orë larg, when shtyp Anulo, then shoh që zbatohet një tarifë anulimi në fund para se të konfirmoj.
- Given jam në një ekran me gjerësi telefoni, then butoni Anulo është i dukshëm pa lëvizur horizontalisht.
Një listë e thjeshtë kontrolli funksionon gjithashtu, me kusht që çdo pikë të jetë e testueshme. „Anulimi është i lehtë“ nuk është e testueshme. „Anulimi merr të shumtën dy klikime nga lista e rezervimeve“ është.
Hap pas hapi: si të shkruani një histori të mirë
Hapi 1: Nisuni nga një përdorues real dhe një problem real
Zgjidhni një lloj përdoruesi dhe diçka me të cilën përballet sot. Nëse keni bërë intervista me klientët, përdorni fjalët e tyre. „Gjithmonë harroj të anuloj dhe më merr pagesën“ është një pikënisje më e mirë sesa „shto veçori anulimi“.
Hapi 2: Shkruani historinë me një rresht
Plotësoni shabllonin. Nëse nuk mund ta shkruani një „pse“ bindëse, pyesni nëse veçoria duhet fare.
Hapi 3: Shtoni tre deri në gjashtë kritere pranimi
Mbuloni rastin kryesor të suksesit së pari, pastaj variacionet e rëndësishme: një rol tjetër, një gjendje boshe, një kufi, një gabim. Nëse po shkruani më shumë se gjashtë, histori ka gjasa të jetë shumë e madhe.
Hapi 4: Shënoni çfarë është jashtë shtrirjes
Një rresht kursen shumë shkëmbim: „Jashtë shtrirjes: rimbursime për klasa të paguara; adminë që anulojnë në emër të anëtarëve.“ E ndalon historinë të rritet ndërsa e ndërtoni.
Hapi 5: Kontrolloni me INVEST
INVEST është një listë e zakonshme kontrolli për histori të mira. Një histori duhet të jetë:
| Shkronja | Do të thotë | Test i shpejtë |
|---|---|---|
| I | E pavarur | Mund të ndërtohet pa pritur një histori tjetër |
| N | E negociueshme | Përshkruan nevojën, jo një dizajn fiks |
| V | E vlefshme | Një përdorues do ta vërejë nëse lançohet |
| E | E vlerësueshme | Mund të merrni me mend përafërsisht madhësinë |
| S | E vogël | Ndërtohet dhe testohet në një seancë |
| T | E testueshme | Çdo kriter pranimi mund të kontrollohet |
Nuk ju duhet të vlerësoni çdo histori. Është më e dobishme kur një histori duket e gabuar dhe doni të dini pse.
Shembuj të mirë dhe të dobët
| Histori e dobët | Problemi | Histori më e mirë |
|---|---|---|
| Si përdorues, dua një panel. | Pa përdorues specifik, pa arsye, e pa testueshme | Si pronar dyqani, dua të shoh porositë dhe të ardhurat e sotme në një ekran, që të di me një sy nëse dita po shkon mirë. |
| Si admin, dua që baza e të dhënave të ketë një kolonë statusi. | Përshkruan implementimin, jo një nevojë | Si admin, dua të shënoj porositë si të dërguara, që klientët të ndalojnë së pyeturi me email ku janë. |
| Si klient, dua të menaxhoj llogarinë time. | Shumë e madhe: mbulon shumë veçori | Si klient, dua të ndryshoj adresën time email, që faturat të shkojnë në kutinë e re. |
| Si vizitor, dua që faqja të jetë e shpejtë. | Nuk është histori; është cilësi që të gjithë e duan | Shkruajeni si kriter në çdo histori, ose si objektiv të veçantë performance. |
Si të ndani një histori që është shumë e madhe
Historitë e mëdha janë ku projektet ngecin. Mënyra të zakonshme për t’i ndarë:
- Sipas rolit të përdoruesit. Anëtarët anulojnë rezervimet e tyre; stafi anulon çdo rezervim.
- Sipas hapit të rrjedhës. Shfleto klasat; rezervo një klasë; merr një kujtesë.
- Rasti i thjeshtë i pari. Anulo një klasë falas tani; trajto tarifat dhe rimbursimet në një histori të mëvonshme.
- Sipas variacionit të të dhënave. Mbështet një lokacion së pari, disa më vonë.
- Rruga kryesore, pastaj gabimet. Ndërtoje që të punojë, pastaj shto trajtimin për klasa të plota, pako të skaduara, e kështu me radhë.
Çdo pjesë duhet të jetë ende diçka që një përdorues mund ta përdorë dhe ta vërejë.
Përdorimi i historive të përdoruesit si prompte
Një histori përdoruesi me kritere pranimi është shumë afër një prompti të mirë për një ndërtues aplikacionesh me AI. I jep AI-së kush, çfarë, pse dhe një përkufizim të përfundimit. Dërgoni një histori për mesazh:
Si anëtar i palestrës, dua të anuloj një rezervim klase nga telefoni im që dikush në listën e pritjes të mund ta marrë vendin tim. Kriteret e pranimit:
- Anulo është te çdo rezervim në Rezervimet e mia, me një hap konfirmimi.
- Anulimi më shumë se 12 orë përpara klasës thjesht e heq rezervimin.
- Më pak se 12 orë përpara, shfaq „Zbatohet një tarifë anulimi vonë prej 5 $“ para konfirmimit, dhe regjistroje tarifën te rezervimi.
- Nëse klasa ka listë pritjeje, personi i parë merr vendin dhe një email.
- Punon në një ekran me gjerësi telefoni. Jashtë shtrirjes: rimbursime, staf që anulon për anëtarët. Ndërtoje, pastaj kontrollo çdo kriter në pamjen paraprake dhe më thuaj cilët kalojnë.
Mund t’i kërkoni edhe AI-së të hartojë histori nga një ide e papërpunuar, pastaj t’i redaktoni vetë:
Ja ide e aplikacionit tim: [dy ose tri fjali]. Shkruaj historitë e përdoruesit për një version të parë, të grupuara sipas llojit të përdoruesit, secila me 3 deri në 5 kritere Given/When/Then. Shëno cilat janë thelbësore për lançim dhe cilat mund të presin.
Gjithmonë lexojeni dhe redaktojeni rezultatin. AI nuk i njeh përdoruesit tuaj; ju i njihni.
Kriteret e pranimit shërbejnë edhe si plani juaj i testimit. Kur historia të jetë ndërtuar, kaloni vetë çdo kriter. Udhëzuesi ynë mbi testimin e aplikacionit tuaj para lançimit ndërton mbi këtë.
Ku përshtaten historitë e përdoruesit me dokumentet e tjera
- Një dokument kërkesash produkti përshkruan produktin e tërë: problemin, përdoruesit, shtrirjen. Historitë e përdoruesit janë pjesët e detajuara brenda tij. Shihni si të shkruani një PRD me AI.
- Një raport gabimi përshkruan diçka që është prishur kundrejt një historie që ishte ndërtuar më parë. Shihni si të shkruani një raport të mirë gabimi.
- Një MVP është grupi më i vogël i historive që jep vlerën bazë. Shihni çfarë është një MVP.
Gabimet më të zakonshme
- „Si përdorues…“ Shumë i paqartë. Emërtoni llojin e vërtetë të përdoruesit.
- Kalimi i „që“-së. Pa arsyen, nuk mund të bëni kompromise të arsyeshme.
- Shkrimi i zgjidhjes në vend të nevojës. „Dua një listë rënëse“ e ngulit një dizajn para se dikush të ketë menduar për të.
- Kritere që nuk mund të testohen. „Lehtë“, „shpejt“ dhe „intuitive“ janë dëshira, jo kritere.
- Histori që janë në të vërtetë epikë. „Menaxho llogarinë time“ është dhjetë histori.
- Shkrimi i çdo historie paraprakisht. Shkruani në detaje disa të ardhshme; mbani pjesën tjetër si një rresht deri kur të arrini tek ajo.
Historitë në Mythex
Në Mythex, modaliteti Plan është një vend i mirë për ta kthyer një ide në histori: agjenti diskuton qasjen para se të ndryshojë ndonjë gjë. Kur një histori është gati, kaloni në Build dhe ngjiteni, një histori për mesazh. Pas secilës, /test mund të klikojë përmes pamjes paraprake dhe të kontrollojë rrjedhën, dhe mund ta ktheni prapa çdo përgjigje me Kthehu në këtë pikë nëse shkoi keq. Shihni promptet efektive në dokumentacion, dhe udhëzuesin tonë mbi si të shkruani prompte për ndërtuesit e aplikacioneve me AI.
Lista e kontrollit për histori përdoruesi
- Emërton një lloj të caktuar përdoruesi
- Përshkruan një nevojë, jo një dizajn
- Përmban një arsye reale „që“
- Ka tre deri në gjashtë kritere pranimi të testueshme
- Mbulon të paktën një rast kufitar ose gabim
- Thotë çfarë është jashtë shtrirjes
- Mjaftueshëm e vogël për t’u ndërtuar dhe testuar në një herë
- Kriteret i kontrolloni një nga një pas ndërtimit
Pyetje
Cili është formati i një historie përdoruesi?
Shablloni i zakonshëm është: Si [lloj përdoruesi], dua [një qëllim] që [një arsye]. Pas tij vjen një listë kriteresh pranimi, një listë e shkurtër kushtesh që duhet të jenë të vërteta që historia të konsiderohet e përfunduar.
Çfarë janë kriteret e pranimit?
Kriteret e pranimit janë kushte specifike, të testueshme, që përcaktojnë kur një histori përdoruesi është e plotë. Shpesh shkruhen si Given / When / Then: duke pasur një situatë fillestare, kur përdoruesi bën diçka, atëherë ndodh një rezultat i caktuar.
Sa e madhe duhet të jetë një histori përdoruesi?
Mjaftueshëm e vogël për t’u ndërtuar dhe testuar brenda një seance, dhe ende me vlerë në vetvete. Nëse një histori ka më shumë se pesë ose gjashtë kritere pranimi ose mbulon disa ekrane, ndajeni sipas rolit të përdoruesit, sipas hapit të rrjedhës, ose sipas rastit të thjeshtë së pari dhe rasteve kufitare më vonë.
A janë të dobishme historitë e përdoruesit kur ndërtoni me AI?
Po. Një histori përdoruesi me kritere pranimi është afër një prompti ideal: thotë për kë është veçoria, çfarë i duhet dhe saktësisht si të kontrollohet që funksionon. Dërgimi i një historie për mesazh e mban edhe ndryshimin e AI-së të vogël dhe të lehtë për t’u testuar.