При разработването на софтуер и управление на продукти, персонализираната история е неформално описание на естествен език на една или повече функции на софтуерната система. Примери за потребителска история често се пишат от гледна точка на крайния потребител или системния потребител. Те често се записват в картови сметки, в Post-it notes или в софтуер за управление на проекти. В зависимост от проекта, потребителските истории могат да бъдат написани от различни заинтересовани страни, включително клиенти, мениджъри или дизайнери на екипи.
Обяснение
Потребителските истории са вид граничен обект. Те допринасят за развитието на смисъла и комуникацията, т.е. те помагат на екипите от разработчици да систематизират разбирането си за системата и нейния контекст.
Примерите за потребителска история често се бъркат със системните изисквания. Изискване е официално описание на нуждата; персонализираната история е неформално описание на функцията.
Създаване
През 1998 г. Алистър Кокбърн посети проекта Chrysler в Детройт и C3 излезе с фразата "История на потребителя е обещание за разговор". С Extreme Programming (XP), потребителските истории са станали част от играта за планиране.
Изисквания
Как да направим добра потребителска история? През 2001 г. Рон Джефрис предлага формулата "Три Cs" за създаване на потребителски истории:
Карта (или често бележка) е материална твърда физическа токен за съхраняване на концепции.
Разговорът се провежда между заинтересованите страни (клиенти,потребители, разработчици, тестери и др.). Тя е устна и често се допълва от документация.
Потвърждението гарантира, че целта на разговора е постигната. Така че е написано в примерите и шаблоните на английската потребителска история.
В някои екипи, продуктовият мениджър (или собственик на продукт в Scrum) е отговорен основно за формулирането на потребителски истории и организирането им в продуктово портфолио. В други отбори всеки може да напише история на потребителя. Примери за потребителска история са написани за потребители или клиенти, за да повлияят на функционалността на разработваната система. Потребителските истории могат да бъдат разработени чрез обсъждане със заинтересованите страни, на базата на хора или просто компилирани. Така че е написано в официалното ръководство Как да направим картографиране на потребителска история.
Методи
Като централна част на много гъвкави методологии, като например планирането на играта XP, собствените истории определят какво трябва да бъде вградено в програмен проект. Персонализираните истории се основават на приоритетите на клиентите (или на собственика на продукта в Scrum), за да посочат кои са най-важните за системата и ще бъдат разбити на задачи и оценени от разработчиците. Един от начините за оценяване е на скалата на Фибоначи. Това ще бъде истински пример за добра "потребителска страница"! Когато вашите собствени истории се прилагат, разработчиците трябва да имат възможност да говорят за това с клиента. Кратки истории могат да бъдат трудни за тълкуване, може да изискват някои основни познания или изискванията може да са се променили след писането на историята. Един или повече тестове за приемане трябва да бъдат прикрепени към всеки потребител на историята в даден момент, което позволява на разработчика да провери кога е готов, и да позволи на клиента да го провери. Без точна формулировка на изискванията може да има дълги неконструктивни аргументи, когато продуктът трябва да бъде доставен.
Противоречиво положение
Няма убедителни доказателства, че използването на персонализирани истории увеличава успеха на софтуерната продуктивност или производителността на разработчиците. Независимо от това, собствените им истории улесняват търсенето на смисъл без прекомерно структуриране на проблемите, свързани с успеха. Ограниченията за потребителските истории включват:
Проблем с мащабирането.
Трудно е да се поддържат персонализирани истории, написани на малки физически карти, които е трудно да се увеличат за големи проекти и са проблематични за географски разпределени екипи.
Неясен, неофициален и непълен набор от правила.
Комуникативна стойност
Потребителските истории се считат за начало на разговор. Като неформални, те са отворени за много интерпретации. Накратко, те не съдържат всички подробности, необходими за изпълнението на функцията. Следователно историите не са подходящи за сключване на официални споразумения или писане на правни договори.
Липса на нефункционални изисквания
Потребителските истории рядко включват изисквания за ефективност или функционални изисквания, така че нефункционалните тестове (като времето за отговор) могат да бъдат пропуснати.Много контексти използват собствени истории, които също са групирани по смисъла и организационните причини. Различните употреби зависят от гледна точка, например, от гледна точка на потребителя като собственик на продукта във връзка с функциите, или от гледна точка на компанията във връзка с организацията на задачите.
Етикети
Докато някои предполагат използването на епос и тема като етикети за всеки възможен тип групиране на потребителски истории, ръководството на организацията се стреми да ги използва за силно структуриране и обединяване на натоварвания. Например, изглежда, че Джира използва йерархично организиран списък от случаи, в които те наричат първо ниво на задачите на потребителя, втори епос (групиране на потребителски истории) и трето ниво "инициатива" (групиране на епоси). Инициативите обаче не винаги присъстват в развитието на продуктовото управление и просто добавят друго ниво на детайлност. Jira има "теми" (за проследяване), които ви позволяват да свързвате напречни сечения и групови елементи от различни части на фиксирана йерархия. В тази употреба, Джира променя смисъла на темата от гледна точка на организацията: например колко време прекарваме в разработването на темата xyz. Но друга дефиниция на тема е набор от истории, епоси, функции и т.н. За потребител, който генерира обща семантична единица или цел, вероятно няма обща дефиниция, защото има различни подходи към различните стилове на дизайн и дизайн на продукта. В този смисъл някои предлагат да не се използвавсякакви твърди групи и йерархии.
Epic
Големи истории или истории на няколко потребители, които са много тясно свързани, се обобщават като епос. Общото обяснение за епоса е обичайната история, която е твърде голяма за спринта. Много епоси или истории, групирани йерархично, са най-вече известни от Jira.
Карта на историята на потребителя: описание
Картата на историята е графична двуизмерна визуализация на натрупания продукт. В горната част на картата има заглавия, които групират историите, обикновено наричани "епоси" (големи груби потребителски истории), "теми" (колекции от свързани потребителски истории) или "действия". Те се определят чрез ориентиране на работния процес на потребителя или "в реда, в който бихте обяснили поведението на системата." Вертикално под епична, действителните примери на потребителски истории се класират и класират по приоритет. Първият хоризонтален ред представлява "ходещ скелет" и по-долу, който представлява нарастваща сложност.
По този начин става възможно да се опишат дори големи системи, без да се загуби цялостната картина. Отзивите за картата на потребителските истории, написани от потребителите, са сведени до интерактивност и забавление на този клас, което е много приятно за хората. Те претендират за ползите от такъв софтуер. Това преди всичко е, че те улесняват оценката на задачите. Примерите за потребителска история са част от гъвкав подход, който позволява пренасочването на акцента върху изискванията за писане за тяхното обсъждане. Всички гъвкави потребителски истории включват едно или две писмени изреченияи, което е по-важно, серия от разговори за желаната функционалност.
Шаблон
Какво мога да кажа за примери на карта на потребителската история? Потребителските истории са кратки, прости описания на функции, от гледна точка на човек, който иска да получи нова възможност. Това обикновено е потребител или системен клиент. Те обикновено следват един прост шаблон: аз го искам, защото. Това е отговорът на въпроса как да се изгради карта на историята на картографирането на потребителски истории. Потребителските истории често се пишат на карти или бележки, съхранявани в кутия за обувки и поставени на стени или маси, за да се улесни планирането и обсъждането. Като такива, те значително пренасочват акцента върху функциите за писане, за да ги обсъждат. Всъщност тези дискусии са по-важни от всеки писмен текст. А за последните можете да използвате примерните потребителски истории, написани по-горе. Ползи
Едно от предимствата на гъвкавите потребителски истории е, че те могат да бъдат написани с различна степен на детайлност. Можем да напишем своя собствена история, за да покрием голям брой функционалности. Тези големи потребителски истории обикновено са известни като епос. Ето пример за епична гъвкава потребителска история от резервен продукт до компютър. Като потребител можете да архивирате целия ми твърд диск. Тъй като епосът обикновено е твърде голям за гъвкава команда, за да се изпълни в една итерация, той се разделя на няколко малки потребителски истории, преди да бъде разширен. Епичният, показан по-горе, може да бъде разделен на десетки (или,може би стотици).
Като напреднал потребител можете да укажете файлове или папки за архивиране въз основа на размера на файла, датата на създаване и датата на промяната. Като потребител човек може да определи папки без архивиране, така че резервният диск да не е пълен с неща, които не е необходимо да записват. Как се добавят подробности в потребителските истории? Подробности могат да се добавят по два начина:
Разделяйки собствената си история на няколко малки.
Добавяне на удовлетворение.
Когато една сравнително голяма история е разделена на няколко малки, гъвкави потребителски истории, естествено е да се предположи, че подробностите са били добавени.Накрая, повече са написани.
Условия на удовлетворение
Това е само един тест за прием на високо ниво, който ще бъде валиден след завършване на гъвкав потребител на историята.Да разгледаме следното като още един пример за гъвкав потребител на историята: недостатъци на рекламните кампании, така че да мога да идентифицирам печеливши.
В този пример на потребителска история можете да добавите подробности, като добавите следните условия за удовлетворение:
Уверете се, че работи с големи почивки на дребно: Коледа, Великден, Президентски ден, Ден на майката, Ден на бащата, Ден на труда, Нова година.
Подкрепа за празници, които обхващат две календарни години (нито една от тях не обхваща три).
Празничните сезони могат да се определят от един празник на друг (например, Деня на благодарносттапреди Коледа)
Спа сезоните могат да бъдат създадени няколко дни преди празника.
Всеки може да пише история на потребителя. Собственикът на продукта трябва да се увери, че има много незавършени потребителски истории, но това не означава, че те са автор на собственика на продукта. За добър гъвкав проект трябва да очаквате всеки потребител да има примери за потребителски истории. Също така имайте предвид, че човекът, който пише историята на потребителя, е далеч по-малък от този, който участва в дискусията.
Стойности за проекти
Потребителските истории са написани в рамките на гъвкав проект. Обикновено в началото се провежда семинар за писане. Всеки в екипа участва в създаването на дневник за изчакване на продукта, който напълно описва функционалността, която ще бъде добавена по време на проекта или в рамките на три до шест месеца от пускането му. Примери за това са в голямата колекция Примерна карта на потребителската история. Някои от тези гъвкави потребителски истории несъмнено ще бъдат епични. По-късно епосите ще бъдат разширени в по-малки истории, които по-лесно ще се впишат в една итерация. В допълнение, нови истории могат да бъдат написани и добавени към продуктовото портфолио по всяко време и от всеки. Agile проекти, особено Scrum, използват бекенда на продукта, който е приоритетен списък с функционалности, които ще бъдат разработени в продукт или услуга. Въпреки факта, че елементите на работа в процес на изпълнение могат да бъдат по желание на екипа, собствените им истории стават по-добри.и най-популярната форма на работа.
Докато забавянето на продукта може да се разглежда като замяна на изискванията за документи на традиционния проект, важно е да се помни, че писмената част на гъвкавия потребител на историята ("Както искам потребител") е непълна, за да обсъдим тази история. Така че е написано в наръчника за картиране на американската история на потребителите и как да го използвате. Често е по-добре писмената част да се разглежда като указател към реално изискване. Персонализираните истории могат да сочат към диаграма, изобразяваща работен поток, електронна таблица, която показва как да се извърши изчисление, или всеки друг артефакт, който собственикът или екипът на продукта иска.
