Історія користувача

Користувацька історія — це короткий опис вимоги, виражений з точки зору особи, яка отримає від неї користь, традиційно записаний у формі ролі, бажаної можливості та причини, чому вона потрібна. Вона виникла з екстремальної практики програмування та стала домінуючим форматом для вираження роботи в ітеративній розробці.

Його мету часто неправильно розуміють. Історія — це не специфікація; це нагадування про необхідність розмови. У початковому формулюванні історії описувалися як тимчасові елементи для обговорення між людьми, які хочуть отримати цю можливість, і людьми, які її розроблятимуть, а письмовий текст існує для того, щоб забезпечити проведення обговорення, а не замінити його. Команди, які розглядають картку як повну вимогу, прийняли цей формат і відмовилися від цього механізму.

Пункт причини – це елемент, який несе найбільшу цінність, і той, який найчастіше написаний недбало. Визначення причини бажаної можливості дозволяє команді запропонувати інше та часто краще рішення для тієї ж потреби, а також дозволяє чесно знизити пріоритетність роботи, коли основна причина виявляється слабкою. Історії, пункт причини яких просто повторює можливість, наприклад, бажання мати кнопку, щоб її натиснути, нічого не повідомляють і виключають можливість такої розмови.

Розмір має значення, оскільки історія має бути завершеною протягом ітерації та надавати користувачеві щось, що він може реально відчути. Занадто великі історії неможливо завершити або оцінити, тоді як історії, розбиті на технічні шари, такі як побудова таблиці бази даних або окремого компонента інтерфейсу, не надають нічого, що можна було б спостерігати окремо. Вертикальне розрізання, при якому кожна історія проходить через кожен шар, щоб створити тонку, але повну можливість, зберігає здатність демонструвати та навчатися.

Формат є радше умовністю, ніж вимогою, і його суворе дотримання призводить до абсурду. Технічна робота без безпосереднього користувача, така як оновлення залежності або покращення спостережуваності, не відповідає шаблону, а нав'язливе її використання створює штучного користувача, який хоче оновити бібліотеку. Чіткий запис такої роботи з обґрунтуванням є більш чесним і корисним, ніж її спотворення для задоволення певного формату.

Критерії прийнятності – це те, що робить історію придатною для перевірки, і вони є її частиною, а не окремим артефактом. Вони визначають умови, за яких історія вважатиметься завершеною, включаючи граничні випадки та шляхи помилок, які пропускає форма оповіді. Без них завершення стає питанням думки, а розбіжності зазвичай виявляються під час перегляду, коли їх вирішення найдорожче.

Історії накопичуються в беклоги, які стають некерованими, якщо їх не виправляти. Елементи, написані багато місяців тому, описують продукт і ринок, які з того часу змінилися, а беклог із кількох сотень історій – це скоріше документ, який ніхто не читає, ніж план. Періодичне видалення історій, які реально неможливо створити, незручне та значно корисніше, ніж їх безкінечне зберігання.

Оскільки цінність залежить від розмови, а не від артефакту, ефективність визначається тим, чи беруть участь потрібні люди. На практиці формат використовується в межах розробка продукту з основною потребою, що підтверджується через дослідження користувачів а не передбачається, і організації, що розвивають цю здатність внутрішньо, зазвичай встановлюють практику написання та вдосконалення в рамках відділ продукції щоб історії походили з перевірених проблем.