Юзер сторі чи Юз кейси…ось в чому питання! (Requirements 101: User Stories vs. Use Cases)

Пропонуємо до Вашої уваги адаптований переклад статті Andrew Stellman, від травня 2009 року, у якій автор просто і доступно порівнює два варіанти документування вимог.

Це питання рано чи пізно виникає в усіх, хто знаходить себе у сфері бізнес-аналізу – В чому різниця між історіями користувача та варіантами використання (user story і use case)?

Перед тим як заглиблюватися у відповідь, давайте на хвильку повернемося у минуле і згадаємо звідки взялися історії користувача (user story). Вони мені подобаються, тому що вони є чудовим прикладом того як Agile змінював світ програмного забезпечення. Раніше розробники просто занурювалися в проекти та починали кодувати. Щоразу, коли хтось із тих надокучливих користувачів починав розповідати нам, що їм потрібно, ми зупиняли їх і говорили щось на кшталт: «Не хвилюйтеся, я все розумію. Я знаю, що тобі потрібно.”. Євангелісти Agile зрозуміли, що «я знаю, що вам потрібно» — це маленька неприємна пастка, у яку потрапляють “особливо обдаровані” розробники. Ми зазвичай витрачали весь час проекту, думаючи, що ми розуміємо потреби наших користувачів, в результаті реалізовуючи те, що їм взагалі не потрібно. Прихильники Agile зрозуміли, що розробникам потрібно почати працювати з користувачами протягом усього проекту, щоб зрозуміти їхні потреби, якщо вони не хочуть потім усе переписувати…

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

Зверніть увагу: Як писати хороші User Stories

Варіант використання (use case) схожий на історію користувача (user story), оскільки він також описує одну конкретну взаємодію між користувачем і програмним забезпеченням. Коли я навчаю людей вдосконалювати спосіб запису вимог до свого проекту, я часто описую варіант використання (use case) як «нібито простий інструмент», який допомагає нам знаходити та записувати всі способи взаємодії користувачів із програмним забезпеченням.

Дивлячись на ці визначення, я точно розумію, чому існує плутанина щодо різниці між історіями користувачів (user story) і варіантами використання (use case). Якщо ви поглянете на попередні два абзаци, може здатися, що я сказав те саме двічі! Але хоча історії користувачів (user story) і варіанти використання (use case) безумовно схожі, між ними є важливі відмінності. Кожен служить певній меті, і я думаю, що вони обидва мають своє місце в добре керованому програмному проекті.

Я думаю, що найпростіший спосіб зрозуміти різницю між варіантами використання (use case) та історіями користувачів (user story) — це поглянути на приклад. На щастя, у мене є один, який, на мою думку, допомагає зрозуміти різницю.

У нашій першій книзі « Applied Software Project Management» ми з Дженні багато часу говорили про те, як розробляти варіанти використання (use case) та використовувати їх для створення кращого програмного забезпечення. І як приклад ми показали варіант використання  (use case) функції програмного забезпечення, з якою всі повинні бути знайомі: функції пошуку та заміни з текстового процесора. Порівняння історії користувача (user story) для пошуку та заміни з варіантом використання  (use case) тієї самої функції допомагає підкреслити відмінності.

Абсолютно не складно знайти багато прикладів історій користувачів (user story). Отже, як би виглядала історія користувача (user story) для пошуку та заміни? Я спробував написати один з варіантів:

(Одна з причин, чому я люблю історії користувачів (user story), це використання «він» або «вона», а не намагання бути гендерно нейтральним. Я думаю, що це полегшує спілкування користувача в історії, дещо його персоніфікуючи. Це також дозволяє мені писати більш розмовним тоном, що робить розповідь користувача (user story) дружнішою та, я думаю, трохи легшою для читання та розуміння.)

Буде корисно: User Story та Acceptance Criteria: пишемо чіткі та зрозумілі вимоги

Тепер, якщо ви не знайомі з історіями користувачів (user story), ви можете подумати: «Зачекайте, функція пошуку та заміни мого текстового редактора робить набагато більше, ніж це!» І це нормально. Типова історія користувача міститиме достатньо інформації, щоб допомогти користувачеві зрозуміти, яку цінність повинно принести програмне забезпечення, але це не повний опис того, як працює програмне забезпечення.

Отже, як би виглядав зразок варіанту використання (use case) для пошуку та заміни? Ось приклад використання, який ми з Дженні створили, щоб продемонструвати, як працюють варіанти використання:

 

Name	UC-8: Search and Replace
Summary	All occurrences of a search term are replaced with replacement text.
Rationale	While editing a document, many users find that there is text somewhere in the file being edited that needs to be replaced, but searching for it manually by looking through the entire document is time-consuming and ineffective. The search-and-replace function allows the user to find it automatically and replace it with specified text. Sometimes this term is repeated in many places and needs to be replaced. At other times, only the first occurrence should be replaced. The user may also wish to simply find the location of that text without replacing it.
Users	All users
Preconditions	A document is loaded and being edited.
Basic Course of Events	The user indicates that the software is to perform a search-and-replace in the document. The software responds by requesting the search term and the replacement text. The user inputs the search term and replacement text and indicates that all occurrences are to be replaced. The software replaces all occurrences of the search term with the replacement text.
Alternative Paths	In Step 3, the user indicates that only the first occurrence is to be replaced. In this case, the software finds the first occurrence of the search term in the document being edited and replaces it with the replacement text. The postcondition state is identical, except only the first occurrence is replaced, and the replacement text is highlighted. In Step 3, the user indicates that the software is only to search and not replace, and does not specify replacement text. In this case, the software highlights the first occurrence of the search term and the use case ends. The user may decide to abort the search-and-replace operation at any time during Steps 1, 2, or 3. In this case, the software returns to the precondition state.
Postconditions	All occurrences of the search term have been replaced with the replacement text.

Отже, якби я був розробником, який створює текстовий редактор, я б справді міг написати функцію пошуку та заміни, яка реалізує цей конкретний варіант використання (use case). (Щоб було зрозуміло: існує багато різних форматів варіантів використання (use case); ми з Дженні використовуємо цей шаблон варіантів використання в нашій книзі, оскільки він скорочений до мінімуму розділів, які, на нашу думку, повинен мати ефективний варіант використання (use case).)

Ось дещо про варіанти використання (use case), що, на мою думку, є цікавим. Коли ви читали наш варіант використання (use case), чи думали ви про щось схоже на діалогове вікно заміни в Блокноті чи Microsoft Word чи діалогове вікно пошуку в TextEdit? Якщо так, подивіться ще раз на варіант використання (use case). У ньому немає таких слів, як «вікно», «кнопка», «клацання», «поле» чи «прапорець». Вся справа в тому, які дії виконує користувач і як реагує програмне забезпечення. І є багато різних способів створення програмного забезпечення, яке реалізує варіант використання (use case). Ви коли-небудь використовували функцію пошуку та заміни у vi? Як щодо функції пошуку та заміни в Emacs? Вони мають дуже різні інтерфейси користувача! Хто знав, що існує так багато способів, якими можна реалізувати пошук і заміну? Але якщо ви порівняєте кожну з них із цим варіантом використання (use case), усі вони мають однаковий основний перебіг подій.

Отже, тепер, коли ми розглянули приклади варіантів використання (use case) та історій користувачів (user story), то у чому різниця між історіями користувачів (user story) і варіантами використання (use case)? Ось що я вважаю ключовими відмінностями:

• Історії користувачів (User story) – це про потреби. Коли ви пишете історію користувача (user story), те, що ви описуєте, є «необробленою» потребою користувача. Це те, що користувач повинен робити у своїй повсякденній роботі. Якщо ви ніколи не створите програмне забезпечення для нього, тоді така потреба все одно існуватиме!
• Варіанти використання (use case) стосуються поведінки, яку ви вбудуєте в програмне забезпечення для задоволення цих потреб. Розробник, якому потрібно створити робоче програмне забезпечення, повинен мати можливість прочитати варіант використання (use case) та добре зрозуміти, що програмне забезпечення має робити. Зазвичай він містить багато деталей і описує все, що розробник має створити, щоб задовольнити потреби користувача. Ось чому він повинен мати набагато більше деталей, бути зрозумілим і недвозначним.
• Історії користувачів (user story) легко читати користувачам. Коли ви пишете історію користувача (user story), ви зосереджуєтесь на тому, щоб написати щось, що може зрозуміти кожен, мовою користувачів. Ми всі знаємо, що розробники мають набагато більше терпіння, щоб розповідати про деталі програмного забезпечення, яке вони створюють, ніж користувачі, тому історії користувачів (user story) мають бути короткими. Історія користувача (user story) повинна виражати повну думку всього в кількох реченнях.
• Варіанти використання (use case) описують повну взаємодію між програмним забезпеченням і користувачами (і, можливо, іншими системами). Коли ви проводите аналіз варіантів використання (use case), ви розробляєте функціональне рішення, яке відповідає потребам користувачів. Це має бути те, що розробники можуть реалізувати. Цілком можливо, що одна історія користувача (user story) може породити кілька варіантів використання (use case). А коли ви об’єднаєте всі свої варіанти використання (use case) в один документ, ви отримаєте повний опис кожної взаємодії між користувачем і програмним забезпеченням, яке ви плануєте створити. І якщо ваше програмне забезпечення має взаємодіяти з декількома системами, ви можете в кінцевому підсумку розглядати ці інші системи як дійових осіб у вашому варіанті використання (use case).

До теми: Як схрестити слона з бегемотом, або Чи можна поєднати User Stories та Use Cases в одному проєкті

Щойно ви зрозумієте, чим відрізняються історії користувачів (user story) і випадки використання (use case), ви почнете бачити, для чого вони можуть служити у вашому проекті.