Како да напишете кориснички приказни (со примери и критериуми за прифаќање)

Кориснична приказна е краток опис на функција од гледна точка на корисникот: „Како [тип на корисник], сакам [цел] за да [причина].“ Под неа пишувате критериуми за прифаќање — неколку конкретни услови што мора да бидат исполнети за приказната да се смета за завршена. Секоја приказна нека биде доволно мала за да се изгради и тестира одеднаш, а критериумите напишете ги така што секој би можел да ги провери.

Кориснички приказни ги популаризираа agile тимовите за софтвер, но се подеднакво корисни кога градите самостојно со AI алатка за апликации. Добра приказна е добар промпт.

Форматот

Корисничката приказна има три дела:

Како [кој], сакам [што] за да [зошто].

• Кој е одреден вид корисник: посетител што е прв пат тука, платен член, рецепционер во клиника, администратор. Не „корисникот“.
• Што е она што сака да го направи, со свои зборови. Не како функционира екранот.
• Зошто е исходот што му е важен. Тоа е делот што луѓето го прескокнуваат, а токму тој ве спречува да градите погрешна работа.

Пример:

Како член на теретана, сакам да откажам резервација за час од телефонот за да некој на листата на чекање може да го земе моето место и да не ми се наплати казна за непојавување.

Делот „зошто“ ви кажува две работи што „што“-то не ги кажало: мора да работи на телефон, а вклучени се листата на чекање и правилата за казните.

Критериуми за прифаќање

Приказната кажува што се бара. Критериумите за прифаќање кажуваат кога е завршено. Треба да бидат доволно конкретни за двајца луѓе да се согласат дали секој од нив минува.

Заеднички начин да се напишат е Given / When / Then:

• Given почетна состојба
• When корисникот направи нешто
• Then ова е резултатот

За приказната за резервација во теретана:

1. Given имам резервација подалеку од 12 часа, when допрам Откажи и потврдам, then резервацијата се брише и гледам „Резервацијата е откажана“.
2. Given откажувам резервација и часот има листа на чекање, when откажувањето се зачува, then првиот на листата на чекање ќе го добие местото и е-пошта.
3. Given резервација поблиску од 12 часа, when допрам Откажи, then пред да потврдам гледам дека важи казна за доцно откажување.
4. Given сум на екран со ширина на телефон, then копчето Откажи е видливо без скролување настрана.

Обична листа за проверка исто функционира, сè додека секоја ставка е проверлива. „Откажувањето е едноставно“ не е проверливо. „Откажувањето трае најмногу два допири од листата на резервации“ е.

Чекор по чекор: пишување добра приказна

Чекор 1: Почнете од вистински корисник и вистински проблем

Изберете еден тип на корисник и нешто со што се мачи денес. Ако сте разговарале со клиенти, користете ги нивните зборови. „Секогаш заборавам да откажам и ми се наплаќа“ е подобра почетна точка од „додај функција за откажување“.

Чекор 2: Напишете ја приказната во една линија

Пополнете го шаблонот. Ако не можете да напишете убедливо „за да“, прашајте се дали функцијата воопшто е потребна.

Чекор 3: Додајте три до шест критериуми за прифаќање

Прво покријте го главниот успешен случај, па важните варијации: друга улога, празна состојба, ограничување, грешка. Ако пишувате повеќе од шест, приказната е веројатно премногу голема.

Чекор 4: Забележете што е надвор од опсегот

Една линија заштедува многу префрлања: „Надвор од опсегот: поврат за платени часови; администратори што откажуваат во име на членови.“ Ја спречува приказната да расте додека градите.

Чекор 5: Проверете ја со INVEST

INVEST е заедничка листа за проверка за добри приказни. Приказната треба да биде:

Nе треба да ја оценувате секоја приказна. Најкорисно е кога приказната ви изгледа погрешно и сакате да дознаете зошто.

Добри и лоши примери

Како да поделите приказна што е премногу голема

Големите приказни се местата каде проектите застануваат. Вообичаени начини за делење:

• По улога на корисникот. Членовите ги откажуваат своите резервации; персоналот ги откажува туѓите.
• По чекор во текот. Прелистај часови; резервирај час; добиј потсетник.
• Прво едноставниот случај. Откажи бесплатен час сега; казни и поврати во подоцнежна приказна.
• По варијација на податоци. Прво поддржете една локација, а подоцна повеќе.
• Главен тек, па грешки. Прво изградете да работи, па додајте справување со полни часови, истечени пакети и слично.

Секој дел сепак треба да биде нешто што корисникот би можел да го користи и да го забележи.

Користење кориснички приказни како промптови

Кориснична приказна со критериуми за прифаќање е многу блиску до добар промпт за AI алатка за апликации. Му ги дава на AI кој, што, зошто и дефиниција за завршено. Испратете по една приказна во порака:

Како член на теретана, сакам да откажам резервација за час од телефонот за да некој на листата на чекање може да го земе моето место. Критериуми за прифаќање:

1. Откажи е на секоја резервација во Моите резервации, со чекор за потврда.
2. Откажување повеќе од 12 часа пред часот едноставно ја брише резервацијата.
3. Помалку од 12 часа пред, прикажи „Важи казна за доцно откажување од 5 долари“ пред потврдување и зачувај ја казната на резервацијата.
4. Ако часот има листа на чекање, првиот добива место и е-пошта.
5. Работи на екран со ширина на телефон. Надвор од опсегот: поврати, персоналот да откажува за членови. Изгради го ова, па провери го секој критериум во прегледот и кажи ми кои минуваат.

Можете и AI да ве замолите да нацрта приказни од груба идеја, а потоа самите да ги уредите:

Еве ја мојата идеја за апликација: [две или три реченици]. Напишете кориснички приказни за прва верзија, групирани по тип на корисник, секоја со 3 до 5 критериуми за прифаќање Given/When/Then. Означете кои се суштински за лансирање и кои можат да почекаат.

Секогаш прочитајте и уредете го резултатот. AI не ги знае вашите корисници; вие ги знаете.

Критериумите за прифаќање служат и како план за тестирање. Кога приказната ќе се изгради, поминете низ секој критериум самите. Нашиот водич за тестирање на апликацијата пред лансирање се надоврзува на ова.

Каде се вклопуваат кориснички приказни со други документи

• Документот за барања на производот го опишува целиот производ: проблемот, корисниците, опсегот. Кориснички приказни се деталните делови во него. Видете како да напишете PRD со AI.
• Извештај за грешка опишува нешто што е расипано во однос на приказна што веќе била изградена. Видете како да напишете добар извештај за грешка.
• MVP е најмалиот сет на приказни што ја испорачува основната вредност. Видете што е MVP.

Чести грешки

• „Како корисник…“ Премногу неопредено. Именувајте го вистинскиот тип на корисник.
• Прескокнување на „за да“. Без причината, не можете да правите разумни компромиси.
• Пишување решение наместо потреба. „Сакам падаечко мени“ го заклучува дизајнот пред да се размисли.
• Критериуми што не може да се тестираат. „Лесно“, „брзо“ и „интуитивно“ се желби, не критериуми.
• Приказни што всушност се епици. „Управувај со мојата сметка“ се десет приказни.
• Пишување на сите приказни однапред. Напишете детално следните неколку; останатите држете ги како едноредни до моментот кога ќе стигнете до нив.

Приказни во Mythex

Во Mythex, режимот Plan е добро место да се претвори идеја во приказни: агентот го разговара пристапот пред да менува било што. Кога една приказна е подготвена, префрлете се на Build и залепете ја, по една приказна во порака. По секоја, /test може да ја помине прегледот и да го провери текот, а секој одговор можете да го вратите со Врати на оваа точка ако тргнал погрешно. Видете ефективни промптови во документацијата и нашиот водич за пишување промптови за AI алатки за апликации.

Листа за проверка на кориснички приказни

• Именува конкретен тип на корисник
• Опишува потреба, не дизајн
• Вклучува вистинско „за да“
• Има три до шест проверливи критериуми за прифаќање
• Покрива барем еден рабен случај или грешка
• Ги наведува работите надвор од опсегот
• Доволно мала за да се изгради и тестира одеднаш
• Критериумите се проверени по изградбата, еден по еден

Прашања