Как да напишете потребителски истории (с примери и критерии за приемане)

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

Потребителските истории станаха популярни в екипите за гъвкава разработка, но са също толкова полезни, когато строите сами с AI инструмент за приложения. Добрата история е добър промпт.

Форматът

Потребителската история има три части:

Като [кой], искам [какво] за да [защо].

• Кой е конкретен вид потребител: посетител за първи път, платен член, рецепционист в клиника, администратор. Не „потребителят“.
• Какво е нещото, което иска да направи, с неговите думи. Не как работи екранът.
• Защо е резултатът, който го интересува. Това е частта, която хората пропускат, и тази, която ви спира да построите грешното нещо.

Пример:

Като член на фитнеса, искам да отменя резервация за групово занятие от телефона си, за да някой от списъка на чакащите да заеме мястото ми и да не ми бъде начислена такса за неявяване.

„Защо“-то ви казва две неща, които „какво“-то не казва: трябва да работи на телефон и участват списъкът на чакащите и правилата за таксата.

Критерии за приемане

Историята казва какво се иска. Критериите за приемане казват кога е готово. Те трябва да са достатъчно конкретни, за да се съгласят двама души дали всеки от тях е изпълнен.

Чест начин да ги запишете е Дадено / Когато / Тогава:

• Дадено е начално положение
• Когато потребителят направи нещо
• Тогава следва този резултат

За историята за резервация във фитнеса:

1. Дадено че имам резервация повече от 12 часа по-късно, когато натисна Отмени и потвърдя, тогава резервацията се премахва и виждам „Резервацията е отменена“.
2. Дадено че отменям резервация и занятието има списък на чакащите, когато отмяната се запише, тогава първият човек от списъка получава мястото и имейл.
3. Дадено че резервацията е по-малко от 12 часа напред, когато натисна Отмени, тогава виждам, че се прилага такса за късна отмяна, преди да потвърдя.
4. Дадено че съм на екран с ширината на телефон, тогава бутонът Отмени се вижда без хоризонтално превъртане.

Списък с обикновени точки също върши работа, стига всяка точка да е проверима. „Отмяната е лесна“ не е проверимо. „Отмяната отнема най-много две докосвания от списъка с резервации“ е.

Стъпка по стъпка: писане на добра история

Стъпка 1: Започнете от реален потребител и реален проблем

Изберете един тип потребител и нещо, с което се затруднява днес. Ако сте правили интервюта с клиенти, използвайте техните думи. „Винаги забравям да се отпиша и ми се начислява“ е по-добра отправна точка от „добави функция за отмяна“.

Стъпка 2: Напишете историята в един ред

Попълнете шаблона. Ако не можете да напишете убедителна част „за да“, попитайте се дали функцията изобщо е нужна.

Стъпка 3: Добавете три до шест критерия за приемане

Покрийте първо основния успешен случай, после важните вариации: друга роля, празно състояние, лимит, грешка. Ако пишете повече от шест, историята вероятно е твърде голяма.

Стъпка 4: Отбележете какво е извън обхвата

Един ред спестява много връщане назад: „Извън обхвата: възстановяване на суми за платени занятия; администратори, които отменят вместо членове.“ Това спира историята да расте, докато я строите.

Стъпка 5: Проверете я спрямо INVEST

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

Не е нужно да оценявате всяка история. Най-полезно е, когато една история ви изглежда грешна и искате да разберете защо.

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

Как да разделите история, която е твърде голяма

Големите истории са там, където проектите спират. Често срещани начини за разделяне:

• По роля на потребителя. Членовете отменят собствените си резервации; служителите отменят всяка.
• По стъпка от потока. Разглеждане на занятия; резервиране на занятие; получаване на напомняне.
• Първо простият случай. Отменете безплатно занятие сега; таксите и възстановяването на суми — в по-късна история.
• По вариация на данните. Първо поддържайте една локация, после няколко.
• Щастливият път, после грешките. Първо го построете да работи, после добавете обработката за пълни занятия, изтекли абонаменти и така нататък.

Всяка част все още трябва да е нещо, което потребител би използвал и забелязал.

Използване на потребителски истории като промптове

Потребителската история с критерии за приемане е много близка до добър промпт за AI инструмент за приложения. Тя дава на AI кой, какво, защо и дефиниция за завършено. Изпращайте по една история на съобщение:

Като член на фитнеса, искам да отменя резервация за занятие от телефона си, за да може някой от списъка на чакащите да заеме мястото ми. Критерии за приемане:

1. Отмяната е при всяка резервация в Моите резервации, със стъпка за потвърждение.
2. Отмяна повече от 12 часа преди занятието просто премахва резервацията.
3. По-малко от 12 часа преди: покажи „Прилага се такса за късна отмяна от 5 $“ преди потвърждението и запиши таксата в резервацията.
4. Ако занятието има списък на чакащите, първият човек получава мястото и имейл.
5. Работи на екран с ширина на телефон. Извън обхвата: възстановявания, отмени от служители за членове. Построй това, после провери всеки критерий в предварителния преглед и ми кажи кои минават.

Можете също да помолите AI да изготви истории от груба идея и после да ги редактирате сами:

Ето идеята ми за приложение: [две или три изречения]. Напиши потребителските истории за първа версия, групирани по тип потребител, всяка с 3 до 5 критерия Дадено/Когато/Тогава. Отбележете кои са задължителни за старт и кои могат да почакат.

Винаги прочитайте и редактирайте резултата. AI не знае вашите потребители; вие ги знаете.

Критериите за приемане служат и като план за тестване. Когато историята е построена, минете през всеки критерий сами. Нашето ръководство за тестване на приложението ви преди старт разширява това.

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

• Документ за изискванията на продукта описва целия продукт: проблема, потребителите, обхвата. Потребителските истории са подробните части вътре в него. Вижте как да напишете PRD с AI.
• Доклад за грешка описва нещо, което е счупено, спрямо история, която вече е построена. Вижте как да напишете добър доклад за грешка.
• MVP е най-малкият набор от истории, който доставя основната стойност. Вижте какво е MVP.

Чести грешки

• „Като потребител…“ Твърде общо. Назовете конкретния тип потребител.
• Пропускане на „за да“. Без причината не можете да правите разумни компромиси.
• Записване на решението вместо нуждата. „Искам падащо меню“ заключва дизайн, преди някой да е помислил за него.
• Критерии, които не може да се тестват. „Лесно“, „бързо“ и „интуитивно“ са пожелания, а не критерии.
• Истории, които всъщност са епоси. „Управлявам акаунта си“ е десет истории.
• Записване на всички истории предварително. Напишете следващите няколко подробно; останалите дръжте като едноредови описания, докато стигнете до тях.

Истории в Mythex

В Mythex режимът Plan е добро място да превърнете идея в истории: агентът обсъжда подхода, преди да редактира каквото и да е. Когато историята е готова, преминете към Build и я поставете, по една история на съобщение. След всяка от тях /test може да кликне през предварителния преглед и да провери потока, а всеки отговор можете да върнете с Revert to this point, ако е тръгнал в грешна посока. Вижте ефективните промптове в документацията и нашето ръководство за как да пишете промптове за AI инструменти за приложения.

Контролен списък за потребителска история

• Назовава конкретен тип потребител
• Описва нужда, не дизайн
• Съдържа реална част „за да“
• Има три до шест проверими критерия за приемане
• Покрива поне един граничен случай или грешка
• Казва какво е извън обхвата
• Достатъчно малка, за да се построи и тества наведнъж
• Критериите са проверени след строене, един по един

Въпроси