Розповідь користувача

Історія користувача (англ. 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

Посилання
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.