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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

Історія користувача (англ. user story) - це одне чи більше речень, звичайною мовою предметної області, які описують чого користувач хоче досягти. Історії користувача використовуються в гнучких методологіях для з'ясування базових функцій що будуть реалізовуватись. Кожна історія користувача достатньо коротка і записується на карточках приблизно 7 на 12 сантиметрів, що гарантує те що вона не стане занадто великою. Історії користувача пишуться споживачами програмного забезпечення і є основним інструментом їх впливу на розробку програми.

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

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


Створення історій користувача[ред.ред. код]

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

Коли користувач розрочинає свої історії, вони записуються на картці (приблизно 8x13 см), з ім'ям, і описом того що сказав користувач. Якщо розробник і замовник вияснять що історії користувача мають недолік (завеликі, складні, неточні), вона переписується аж поки не стане задовільною. Щоправда екстремальне програмування наголошує, що історії користувача не фіксуються як тільки вони будуть записані. Протягом розробки вимоги люблять змінюватись, тому їх не карбують на камені.

Зазвичай історії користувача відповідають такому шаблону:

"Як <роль>, я хочу <ціль/бажання> щоб <вигода>"


Хоча використовують і скорочений варіант:

"Як <роль>, я хочу <ціль/бажання>"


Приклади[ред.ред. код]

Як представник споживача, я хочу шукати моїх клієнтів за їх іменем та прізвищем.


Запуск програми
Після запуску програма відкриває останній документ з яким працював користувач.


Завершення роботи
При завершенні роботи користувача запитують чи не хоче він зберегти роботу (якщо він щось змінював з останнього збереження)


Як звичайний користувач, я хочу модифікувати мій розклад, а не розклади інших користувачів.


Консультат запише витрати в форму витрат. В форму він буде записувати такі дані, як тип витрати, опис, кількість, і довільні коментарі.

В будь-який час консультант зможе зробити одне з наступних:

  1. Як тільки він завершить, він натисне "Відправити". Якщо витрати менше п'ятдесяти (<50), витрата надійде прямо в систему для обробки.
  2. Якщо він не завершив ввід витрати, консультант може захотіти "Зберегти на потім". Тоді форма буде відображатись в списку (черзі) консультанта з поміткою "незавершена".
  3. Якщо консультант передумає заповнювати форму, і вирішить витерти роботу, він натисне "Відмінити і вийти". Тоді дані не будуть збережені.

Використання[ред.ред. код]

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

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

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

Переваги[ред.ред. код]

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

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

Обмеження[ред.ред. код]

  • Їх важко масштабувати для великих проектів
  • Вони розглядаються як приводи до дискусії

Історії користувача та прецеденти[ред.ред. код]

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

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

Дивіться також[ред.ред. код]

Література[ред.ред. код]

  • Daniel H. Steinberg and Daniel W. Palmer: Extreme Software Engineering, Pearson Education, Inc., ISBN 0-13-047381-2
  • Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5
  • Mike Cohn: Agile Estimating and Planning, 2006, Prentice Hall, ISBN 0-13-147941-5
  1. Advantages of User Stories for Requirements

Посилання[ред.ред. код]