Потребителски истории

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

Целта му често е неразбрана. Историята не е спецификация; тя е напомняне за провеждане на разговор. Първоначалната формулировка описва историите като заместители за дискусия между хората, които искат възможността, и хората, които ще я изградят, а писменият текст съществува, за да гарантира, че дискусията ще се проведе, а не да я замести. Екипите, които третират картата като пълно изискване, са възприели формата и са отхвърлили механизма.

Клаузата за причината е елементът, който носи най-голяма стойност и е най-често написан небрежно. Посочването на причината за желаната способност позволява на екипа да предложи различно и често по-добро решение на същата нужда и позволява работата да бъде честно деприоритезирана, когато основната причина се окаже слаба. Истории, чиято клауза за причината просто преформулира способността, като например желанието за бутон, за да го натиснеш, не съобщават нищо и премахват възможността за такъв разговор.

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

Форматът е по-скоро конвенция, отколкото изискване, а стриктното придържане води до абсурди. Техническата работа без директен потребител, като например надграждане на зависимост или подобряване на наблюдаемостта, не се вписва в шаблона, а натрапването ѝ създава изкуствен потребител, който иска библиотеката да бъде актуализирана. Записването на такава работа ясно, с посочена обосновка, е по-честно и по-полезно от изкривяването ѝ, за да се удовлетвори даден формат.

Критериите за приемане са това, което прави една история тестваема и са по същество част от нея, а не отделен артефакт. Те посочват условията, при които историята ще се счита за завършена, включително граничните случаи и пътищата на грешки, които наративната форма пропуска. Без тях завършването се превръща в въпрос на мнение, а несъгласието обикновено излиза наяве по време на прегледа, когато е най-скъпо да се разреши.

Историите се натрупват в натрупани истории, които стават неуправляеми, ако не бъдат отстранени. Елементите, написани преди много месеци, описват продукт и пазар, които оттогава са се променили, а натрупаните истории са документ, който никой не чете, а не план. Периодичното изтриване на истории, които реалистично няма да бъдат изградени, е неудобно и значително по-полезно от поддържането им за неопределено време.

Тъй като стойността зависи от разговора, а не от артефакта, ефективността се определя от това дали участват правилните хора. На практика форматът се използва в рамките на разработване на продукти с основната нужда, доказана чрез потребителски изследвания а не се предполага, и организациите, които изграждат тази способност вътрешно, обикновено установяват практиката за писане и усъвършенстване в рамките на продуктов отдел така че историите да произлизат от валидирани проблеми.