Определяне на потребителски истории и гъвкаво развитие
Основен принцип на съвременните процеси на развитие е пъргавото развитие . Тази методология за разработка набляга на използването на малки потребителски истории, за да се определи какво прави системата от гледна точка на потребителя, а не от техническа гледна точка. Потребителят се интересува дали продуктът е бърз, лесен за използване и решава проблема му. Не ги интересува дали следва 3-степенна архитектура, има Mongo DB или използва Rails или Asp.net.
Потребителски истории:
- Те са лесни за разбиране и всеки може да участва
- Работете итеративно; те могат и трябва да се променят или променят често
- Сравнете разработчиците, потребителите и бизнес специалистите около общи цели и очаквания
- Те са много по-лесни за четене от 400-странични документи с изисквания
Storyboard That предоставя идеална платформа за създаване на гъвкави потребителски истории и предизвикване на разговор във формат, който е много по -малко облагащ от текстова стена.
Епопея
В контекста на потребителските истории, „епос“ е просто много широка история, която по -късно ще бъде разбита на много конкретни потребителски истории. Започването с епос привежда всички в една визия на високо ниво. Епичната история закотвя проект отгоре надолу и ако няма смисъл да се изгражда епос, поддържащата работа също ще бъде загуба на усилия.
В тази история е много ясно каква е дългосрочната визия и как трябва да изглежда успехът. Една добра епична история трябва да включва:
- Настройка или контекст
- Актьори или потребители
- Цели и задачи
- Дейности и събития
Определяне на потребители
Особено при проектирането на софтуер е важно да имате добра визия за това какви ще бъдат потребителите. Не всеки потребител ще отговаря точно на тази визия и може да има няколко категории потребители, но тези дискретни визии се нуждаят от артикулация. Мисленето за потребителите първо предпазва от свръх инженеринг и свръх усложнения, предотвратявайки новия продукт да има по нещо за всеки и да бъде полезен за никого.
Създаване на история
След като епос е установен и потребителите са дефинирани, по -малки, по -специфични истории могат да бъдат конструирани за конкретни потребителски преживявания. Историите по-долу разбиват описаното по-горе на два разказа: търсене на поръчка и пренареждане на продукт.
Тези разкази не съдържат техническа информация; потребителите не се интересуват как се постигат резултатите, стига да изпълнява желаните задачи. По същия начин UX е изобразен общо, за да се избегне задушаване на иновациите или принуждаване на път. Като цяло историите трябва да бъдат:
- Малка - Под 10 дни работа
- Ценни - След като приключат, те трябва да доставят нещо използваемо
- Estimable - Може да създаде приблизителна оценка за това колко усилия са включени
Търся поръчка
Извършване на пренареждане
Разговор и планиране за тестване
Тези истории трябва да канят разговор и въпроси, като например:
- Това ли са правилните истории, които да съответстват на нашата епопея?
- Какви други истории трябва да бъдат създадени?
- Съответстват ли тези истории на това, което знаем за нашите потребители?
Съвсем разумно е да се създадат много истории; всъщност трябва да се насърчава. Някои от тези истории никога няма да бъдат използвани, но е важно да видите пътя, който те определят. Тази колекция от истории ще изхвърли допълнителни изисквания и ще повлияе на тестването.
Историите трябва да предизвикат и да информират дискусията за това как ще бъде тестван софтуерът и какви бизнес правила трябва да бъдат изрично дефинирани. Например:
- Колко бързо трябва да бъде търсенето?
- Има ли срок за повторни поръчки?
- Какво трябва да направи системата, ако е втората повторна поръчка? Пето?
- Какви тестове и последващи въпроси бихте имали?
© 2024 - Clever Prototypes, LLC - Всички права запазени.
StoryboardThat е търговска марка на Clever Prototypes , LLC и е регистрирана в Службата за патенти и търговски марки на САЩ