Шта су корисничка прича и критеријуми прихватања (примери)

Пример:

Као корисник ВхатсАпп-а желим да икона камере у пољу за писање ћаскања снима и шаље слике како бих могла да кликнем и делим своје слике истовремено са свим пријатељима.

Шта су критеријуми прихватања?

Критеријум прихватања је скуп прихваћених услова или пословних правила које функционалност или карактеристика треба да задовољи и испуни како би их власник / заинтересовани део прихватио.

Ово је веома важан део довршавања корисничке приче и власник производа и пословни аналитичар треба га врло пажљиво проучити, јер пропуштање једног критеријума може много коштати. Ово је једноставна нумерисана или набројана листа.

Његов формат је следећи:

' С обзиром на неки предуслов када нешто предузмем, онда очекујем резултат ”.

андроид интервју питања и одговори за 3 године искуства

Пример (в.р.т до горње корисничке приче):

• Узмимо у обзир да ћаскам са пријатељем и требало би да могу да снимим слику.
• Када кликнем на слику, требало би да могу да додам натпис на слику пре него што је пошаљем.
• Ако постоји неки проблем са покретањем камере телефона, појавиће се порука о грешци попут „Камера није успела да се покрене“. итд., треба приказати у складу с тим.

Дакле, Прича о кориснику дефинише захтев за било којом функционалношћу или особином, док Критеријуми за прихватање дефинишу „Дефиницију готовог“ за причу о кориснику или захтев.

Као КА, веома је важно дубоко разумети корисничку причу и њене критеријуме прихватања, а да чак ни једна сумња не остаје на „почетку тестирања“. Крећући се напред, схватимо зашто је изузетно важно копати се „дубоко“ у корисничке приче и критеријуме прихватања.

Копајући дубоко у корисничке приче

За почетак, прво схватимо важност ‘дубинског’ проучавања основне и темељне ствари тј. Приче корисника.

Следећи случајеви су моја стварна искуства.

Случај 1:

Пре три године радио сам на пројекту мобилне апликације, а производ је био апликација која је дизајнирана за достављаче.

Видели бисте достављача како долази код вас на доставу. И они имају мобилни телефон на којем од вас траже да дате потпис након испоруке. Овај потпис одражава се на порталу добављача курирских услуга попут ДТДЦ, ФедЕк итд.

Замислимо да је апликација за мобилне уређаје тек покренута и да њихови портали већ постоје и постоје.

Проблем: За Спринт, ваш власник производа има корисничку причу за ову мобилну апликацију која „Као администратор портала, требало би да могу да видим потпис који је достављач преузео у тренутку испоруке“ . Овде се портал (веб апликација) мења и ажурира у складу с тим да одражава потпис.

Као КА морате проверити да ли се потпис забележен у мобилној апликацији одражава како се очекује на порталу.

Ако погледате ову корисничку причу, изгледа једноставно, али овде постоји скривени захтев да „За историјске испоруке није постојала функција одражавања потписа, па шта би се требало догодити ако момци са портала гледају историјске испоруке?“ Да ли треба избрисати историјске податке? Да ли треба да дозволимо падове или грешке за такве податке?

Наравно, никако, са овим треба поступати љубазно.

Решење: Када се одговарајуће ДБ табеле ажурирају да би се додала нова колона за локацију Потпис, стари подаци би требало да имају НУЛЛ или 0 вредност коју треба проверити и приказати поруку у којој стоји „Не постоји потпис“.

Ово се може назвати пропустом власника производа или пословног аналитичара, али то мора бити учињено. Успешна примена једне функције, али разбијање нечега уз њу није пожељно за купце. То треба урадити заједно са истом корисничком причом и истим спринтом.

Случај # 2

Пре 6 година радио сам на апликацији за финансије за пензионисање (без БА), која је била глобална апликација, где су људи из финансија попут ЦА, саветници за финансије могли да је користе за различите валуте за пројектовање инвестиционих планова, уштеде итд. Током више година. велики период за своје купце.

Проблем: Власник производа вам даје корисничку причу која „Као саветник желим да видим извештај свог купца на основу пружених финансијских детаља“.

Овде су постојала 2 скривена захтева и назвао бих то некомплетном причом јер:

до) Извештаји треба да узимају у обзир дневни курс конверзије валуте, а не историјски као у последњем прегледаном извештају и

б) Ако се валута промени након пружања финансијских података клијента, извештаји би требало да се прикажу у промењеној валути.

Решење: Ову забринутост сам покренуо директно код нашег власника производа и обавестио сам га да оба обаве што пре. Сложио се са мном и створио 2 различите приче за предстојеће спринтеве са приоритетом.

Одузети: Они су ухваћени јер смо сви били врло добро упознати са производима, њиховим дизајном, структуром итд. Такво знање се може постићи само потпуним разумевањем производа, разумевањем интероперабилности модула и темељитим проучавањем корисничке приче иако је а 2 линер.

Правите белешке да бисте олакшали ствари и разговарајте са БА-има и програмерима о њиховом размишљању.

Дубински увид у критеријуме прихватања

Исцрпно разумевање критеријума прихватања и свих осталих услова и правила је још важније од разумевања корисничке приче. Јер ако је захтев непотпун или нејасан, може се предузети у следећем спринту, али ако се пропусти критеријум прихватања, сама корисничка прича не може да се објави.

Претпостављам да бисмо сви у неком тренутку користили нето банкарство, а већина га користи свакодневно и пуно преузимам своје историјске изјаве. Ако га пажљиво посматрате, постоје одређене посебне могућности за њихово преузимање.

Постоји могућност одабира врсте датотеке за преузимање ваше изјаве. Постоји могућност избора да ли желите да преузмете само кредите / задужење / оба.

Сада замислите да вам Власник производа даје ову корисничку причу „Као купац желим да преузмем извод свог рачуна како бих могао да видим све своје трансакције извршене за одређени период“.

Са следећим критеријумима прихватања:

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

Ако прођете кроз ово прихватање, овде недостају 3 ствари:

• Име и формат имена датотеке која ће се преузети.
• Које ће информације (називи колона) бити приказане у датотеци.
• Листа опција за одабир врсте трансакције коју купац жели, тј. Само терећења или само кредити или обоје.

Такви случајеви се могу догодити с времена на време, али ипак добро проучите сваки критеријум прихватања и покушајте га визуализирати у односу на корисничку причу. Што више дубоко проучите услове и правила пословања, то ће више бити и вашег знања о својству.

Грешке пронађене у почетној фази не коштају ништа у поређењу са оним што би могле коштати у фази „тестирања“.

Важност проналажења неслагања у корисничкој причи / критеријумима прихватања

Увек је важно дубоко заронити у корисничке приче и критеријуме прихватања у раној фази чак и пре него што развој или тестирање започне.

Јер укључује:

# 1) Губљење времена:

Ако се утврде одступања или грешке у корисничкој причи / критеријумима прихватања током развоја или тестирања, тада ће можда требати обавити много прераде у преосталом времену спринта.

Не дешава се да ће чак и ако је власник производа пропустио неколико ствари, преместити корисничку причу на надолазећи спринт. 95% шанси је да затраже од тима да изврши неопходну примену и пусти је у истом спринту.

Отуда то постаје ноћна мора за тим јер морају провести додатно време, доћи викендом или радити касно увече. То се може избећи проучавањем и расправом о корисничкој причи / критеријумима прихватања у најранијој могућој фази.

# 2) Губљење напора:

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

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

Закључак

Дубинско разумевање корисничке приче и критеријуми прихватања могу се постићи само трошењем огромног времена на њено проучавање.

На тржишту нема доступних посебних алата или курсева који би то урадили уместо вас, јер се овде ради о логичком размишљању, искуству и знању о производу.

Ако активно учествујете у састанцима пред планирањем, разговарате са дипломом БА, самостално учите, могу вам само помоћи да то постигнете. Што више напора уложите, више учите и растете.

Било да се ради о КА или програмерима, сви морају бити на истој страници о корисничким причама и њиховим критеријумима прихватања, само што се тада очекивања купца могу успешно постићи.

Имате ли нешто ново са нама о својим искуствима у раду са корисничким причама? Изнесите своје мисли у наставку !!

Препоручено читање

• МонгоДБ Стварање корисника и додељивање улога са примерима
• Пример узорка за извештај о испитивању прихватљивости са примерима
• Потврда идентитета корисника у МонгоДБ
• ЈМетер параметризација података коришћењем кориснички дефинисаних променљивих
• Уник дозволе: Дозволе за датотеке у Унику са примерима
• Шта је испитивање прихватљивости (потпун водич)
• Шта је тестирање прихватљивости корисника (УАТ): Комплетан водич
• Питхон ДатеТиме Водич са примерима