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

User Story фіксує, що користувач хоче зробити із системою на високому рівні. Я розумію, що історія користувача додатково спричинить низку вимог низького рівня. Чи історія користувача однакова як вимога високого рівня для системи?

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

На поверхневому рівні це відрізняється , наприклад, вона завжди приймає певну форму ( "як X, я хочу Y, щоб Z ..." ), але ключові елементи - виявлення зацікавлених сторін та обґрунтування - також властиві добре, письмові функціональні вимоги. Написати погану історію користувача так само просто, як і написати погану вимогу ( "як [назва нашої компанії], я хочу [розпливчасту особливість]", щоб я міг [зробити щось, що само собою очевидно є частиною моєї роботи, наприклад 'більше продати покупцям'] " ).

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

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

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

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

Рон Джеффріс дуже давно писав про 3С історії користувачів ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) з акцентом на карту (короткий опис), розмову між клієнтами та командою з доставки одного разу про історію користувача стає прийнятним і згодне підтвердження історії після цієї розмови.

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

в наші дні сенс "історії користувача" звужується лише на "картковій" частині 3C Jeffries. у такому випадку історія користувача - це не вимога, а обіцянка провести бесіду щодо вимог.

На вікі c2 ( http://xp.c2.com/UserStory.html ) ви можете знайти багато золотих самородків мудрості про історії користувачів.

Історії та вимоги користувачів - це дуже різні звірі.

Вимоги

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

Приклад вимоги:

• Створіть контактну форму користувача з такими полями: ім'я, прізвище, електронна адреса, вільний текст та кнопка подання. Після натискання кнопки надсилання електронною поштою надсилається наша команда підтримки.

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

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

Приклад історії:

• Як Джиммі, користувач, я хочу зв’язатися з вашою службою підтримки, коли я не можу правильно використовувати сайт, щоб вони могли мені допомогти.

Яка різниця?

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

Хоча може здатися, що мета відносно неважлива, це неправильне припущення про спритний розвиток. Зазвичай є два випадки, коли знання мети є дуже важливим: зниження вартості можливостей та сприяння спритності.

Вартість можливості

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

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

Спритність

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

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

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

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

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

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

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

Тож я б сказав, що хороша історія не повинна містити конкретних деталей щодо того, як система має бути реалізована. Слід сказати: "Раз на місяць систему A потрібно оновлювати будь-якими новими даними з системи B. Ці дані можуть потребувати виправлень. Клієнт має історію введення недійсних даних і не розуміє проблеми протягом тижнів". Це не повинно говорити: "Система повинна приймати файл CSV latin1 щонайменше раз на місяць та викидати NumberFormatException, якщо стовпець 3 не є числом." Ви бачите різницю? Сценарій описує необхідність, а не якесь конкретне рішення. Потім під час тестування ви повертаєтесь до сценарію, щоб переконатися, що рішення відповідає потребі. Вимоги можуть поєднувати деякі потреби з деякими рішеннями або навіть повністю орієнтуватися на рішення.

Натрапили на це під час пошуку в Google і подумали, що я підкину свою думку.

Дійсно немає різниці між вимогою та історією користувача. Обидва констатують бажаний результат або мету з точки зору користувача.

Єдина відмінність полягає в тому, як бізнес-аналітик сприймає цю мету або результат. У цьому випадку це у формулюванні.

Приклад:

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

Рішення повинно відображати членів групи, які працюють над іпотечними справами.

І те і інше можна трактувати однаково, але і те й інше мають багатозначність. Головний момент тут - різниця в стилі. Я думаю, що питання, яке ми бачимо в основному, полягає в тому, наскільки далеко ми повинні визначитися з рішенням, перш ніж ми вийшли зі світу вимог та у світ функціонального дизайну. Чи доводиться бізнес-аналітику заявляти про "список зареєстрованих користувачів за ім'ям та прізвищем у головному меню додатків" чи це занадто багато інформації? Коли ми сидимо, розмовляючи з нашими зацікавленими сторонами, і всі ми знаємо рішення і можемо інтерпретувати, як воно буде виглядати, навіть вірогідну мову коду, на якій він буде побудований, і спосіб його розгортання, чи дійсно нам потрібно грати в пуристичну гру " давайте визначимо цілі, а не рішення ". Тут я відчуваю плутанину насправді.

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

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

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

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

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

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

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

Функціональні вимоги, як правило, є формальною специфікацією, яка дозволяє точно знати, чи працює ваше програмне забезпечення чи ні. Історія користувача, як правило, набагато неформальніший спосіб описати потребу однієї вашої історії користувача. Він не визначає жорстку специфікацію, щоб визначити, чи програмне забезпечення є "дійсним" чи "недійсним". Хоча ви можете протестувати частину цього, справжнє завершення історії користувача (якщо ви їх правильно зробите) - це коли ваш користувач скаже «так, це вирішить мою проблему!». Пам’ятайте про спритний маніфест:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

У своїй книзі "Застосовується історія користувача" Майк Кон конкретно каже, що деякі речі не співпадають із історією користувачів, і вам не потрібно користуватися лише це.

У моїй власній команді ми використовуємо наступне:

• Історія користувача : бізнес-потреба якогось користувача. Тут робиться наголос на потребі , і чому він це потребує. Як вже говорили інші, тут важливо не вказувати, як це робиться, а заглиблюватися в реальну потребу користувача (наприклад: він не робить потрібно переглядати дані в таблиці, йому потрібно бачити точне значення дані, і він знайомий з таблицею, щоб зробити саме це).
• Помилка : несподівана поведінка програмного забезпечення, яке погіршує нормальне використання. Зазвичай поставляються з "Важливістю" (незалежною від пріоритету розробки), яка оцінює, наскільки це впливає на робочий процес користувача.
• Технічна заборгованість. Що не перешкоджає використанню програмного забезпечення, але зашкодить нам , розробникам у майбутньому. Приклад: деякий клас важко читати, збірка повільна, якийсь код не перевіряється одиницею, IDE показує дивні попередження ...
• Вдосконалення : зміна програмного забезпечення, яке не дає нових сценаріїв, але сприяє кращому досвіду. Приклад: зміна шрифтів, переформатування форми, щоб зробити її більш зрозумілою, додавання розумного за замовчуванням до програми тощо.

Функціональні вимоги не дозволяють нам усвідомити, що функція, яку ми реалізували, не вирішує потреби користувача, навіть незважаючи на тестування огірків і ми виконали кожне написане слово. Історія - це дискусія, і вона неформальна. Справа в тому, щоб хлопці з реалізації зрозуміли, що є проблематичним. Вони не є інструментом контракту. Якщо ви робите "scrum but ... " і ваша історія є просто кумедним способом написання вимог програмного забезпечення, то так, різниці немає .

Суть - це не історія користувача, суть полягає у величезному зміні парадигми у тому, як ти підходиш до роботи, яку потрібно виконати. Ви не укладаєте контракту, ви допомагаєте комусь із користувачів вирішити проблему. Якщо ви не бачите свої розповіді користувачів як інструмент обговорення з реальним користувачем, ви не використовуєте розповіді користувачів, ви використовуєте синтаксис прикольних вимог .

Решта тут - моя думка: історія користувача ніколи не може досягти успіху в односторонньому плані. Вам потрібен ваш клієнт для роботи з ним. Падіння води на лихоманку приречене бути дивним безладом вимог, але не вимагати. Якщо у вас є контракт з фіксованою ставкою з конкретними вимогами, не використовуйте ітерацій та історії користувача, немає сенсу . Використовуйте решту гнучких інструментарій: Автоматизований блок / функціональний тест, перегляд коду, безперервна інтеграція, рефакторинг тощо. Переконайтесь, що ваше програмне забезпечення постійно працює і що ви можете його надіслати за мить. Зробіть його доступним у незавершеному вигляді для замовника, щоб він міг дати якомога більше відгуків. Якщо ви зробите це мій друг, навіть якби ви не робили "Історію користувача" та "Scrum", ви були б спритнішими за багатьох так званих "Agile" магазинів.

Я вірю, що всі будуть реалізовувати та позначати все по-різному, залежно від минулого досвіду та того, що мова працює для тієї компанії, яка виконує роботу, не варто сперечатися.

Однак IMO, історія користувача дотримується підходу Agile "підходу до клієнтів у будівлі або клієнт негайно доступний", де документація не обов'язково потрібна, оскільки деталі знаходяться в голові клієнтів і легко доступні, щоб офіційна SRS не потрібно. Тепер "Завдання" "Історії користувачів" - це те, як розробник збирається створювати історії користувачів в засвоюваному вигляді.

Прикладною історією користувача може бути:

Як користувач адміністратора, я хочу переглядати дані своїх клієнтів, перелічені в сітці

і "завданням" може бути:

1. Створіть сітку, у якій перераховані дані, що відображаються

2. Увімкніть сортування в сітці, яка буде сортувати вибраний стовпець

Тепер кожне із завдань оцінюється і виконується у відповідному спринті.

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

У цьому випадку "функціональна вимога" - це тонко-крупчасті деталі цього СРС та частина більшої Ідеї. Отже, на мою думку, історію користувача можна розглядати як (частину) формальної "Вимоги", а завдання цієї історії користувача є (або однією з багатьох) функціональних вимог.

У прикладі користувача, формальна "Вимога" буде тривалим документом із потоковими діаграмами і, як правило, має бути орієнтована на документацію, на відміну від більш "спритного" підходу, орієнтованого на клієнта.

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

і я вірю в ці дні терміни всі змішані і змішані .. що зовсім не має значення