Як писати ідеальні історії користувачів англійською мовою

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

---

Стандартний формат історії користувача

Формула 3-х частин

Класична історія користувача відповідає такому шаблону:

** Як ** [тип користувача], ** Я хочу ** [дія], ** щоб ** [вигода або результат].

Цей формат складається з трьох частин:

1. ** « Як [тип користувача] » ** — визначає, * кому * буде надано цю функцію
2. ** « Я хочу виконати [дію] » ** — описує * те, що * користувач повинен виконати
3. ** « Так що [результат] » ** — пояснює * чому * — цінність для бізнесу або користувача

** Приклади: **

«Як зареєстрований клієнт, я хочу зберегти свій спосіб оплати, щоб я міг швидше оформити покупку в майбутньому»

«Як адміністратор, я хочу експортувати журнали активності користувачів до CSV, щоб я міг генерувати звіти про відповідність для аудитора»

«Як користувач мобільного додатку, я хочу отримувати push-повідомлення про оновлення замовлення, щоб я знав, коли моя доставка в дорозі»

---

Вибір правильного типу користувача

Тип користувача має бути ** специфічним і значущим ** — а не загальним символом заміщення.

❌ “Як користувач…” — занадто нечітке; майже кожна історія б сказала це. ✅ *“Як покупець вперше…” * ✅ “Як адміністратор команди…” ✅ “Як неавтентифікований відвідувач…” ✅ * “Як агент підтримки, що займається ескалацією…” *

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

---

Написання пункту дії

Клаузула дії повинна описувати ** те, що користувач хоче зробити ** - а не те, як система реалізує це.

❌ “Я хочу, щоб модальне діалогове вікно з’явилося, коли я натиску кнопку” — описує реалізацію ✅ “Я хочу додати елементи до мого списку бажань” — описує намір користувача

** Корисні дієслова дії: **

• переглянути, побачити, отримати доступ, переглянути — читання/використання
• • пошук, фільтр, сортування * — відкриття
• • create, add, upload, submit * — створення
• • edit, update, modify * — модифікація
• • delete, remove, archive * — вилучення
• • receive, be notified * — зв’ язок між системою і користувачем
• • експорт, звантаження * — вилучення даних

---

Написання пункту про вигоди

Клаузула * so that * є найважливішою і найчастіше пропущеною частиною. Це зафіксує історію в бізнес-цінності і допомагає команді зрозуміти * чому * функція існує.

❌ “Як менеджер проекту, я хочу бачити всі відкриті завдання, щоб я міг.” — незавершений ✅ “Як менеджер проекту, я хочу бачити всі відкриті завдання, щоб я міг визначити блокатори і перепризначити роботу до кінця терміну.”

Якщо ти не можеш сформулювати “так, що”, запитайте, чи варто цю історію будувати.

---

Критерії прийняття

** Критерії прийняття (КП) ** визначають конкретні умови, які повинні бути виконані, щоб історія вважалася * завершеною *. Вони перетворюють неясну історію на перевіряему специфікацію.

Формат огірка (за даними / коли / тоді)

Якщо важлива точність, пишіть AC у форматі Gherkin:

Given [precondition or context]
When [action is performed]
Then [expected outcome]

** Приклад: **

Story: As a registered customer, I want to save my payment method,
       so that I can check out faster on future purchases.

Acceptance Criteria:

Scenario 1: Save a new card
  Given the customer is logged in and viewing the checkout page
  When they enter valid card details and check "Save for future use"
  Then the card is saved to their account
  And they see a confirmation message

Scenario 2: Use a saved card
  Given the customer has a saved card on file
  When they view the checkout page
  Then the saved card is displayed as the default payment option
  And they can complete checkout without re-entering card details

Scenario 3: Delete a saved card
  Given the customer has at least one saved card
  When they navigate to Account > Payment Methods and click "Remove"
  Then the card is removed from their account
  And is no longer displayed at checkout

Критерії прийняття

Для простих статей добре підійдуть прості пунктири:

Acceptance Criteria:
- The filter applies within 300ms of the user's selection
- Filter state is preserved when the user navigates back to the list
- A "No results" message appears if no items match the filter
- The filter can be cleared with a single click
- Filter options are sorted alphabetically

---

Критерії INVEST

Добре написані історії користувачів задовольняють критеріям ** INVEST **:

Letter	Meaning	What it means in practice
I	Independent	Can be developed and delivered without being blocked by another story
N	Negotiable	The implementation details can be discussed and adjusted
V	Valuable	It delivers value to a user or the business
E	Estimable	The team can estimate effort for it
S	Small	Can be completed in a single sprint
T	Testable	Acceptance criteria can be written for it

«Ця історія не відповідає критеріям INVEST — вона не оцінюється, тому що ми не розуміємо обмежень сторонніх API. Нам потрібен технічний пік спочатку»

---

Поширені помилки в історіях користувачів

1. Європа Технічне впровадження в історію

❌ “Як користувач, я хочу, щоб система викликала кінцеву точку /api/v2/users з JWT…” ✅ “Як користувач, я хочу, щоб мій сеанс тривав після закриття вкладки браузера…“

2-й. Несколько историй в одной

❌ “Як користувач, я хочу зареєструватися, увійти та керувати своїм профілем…” ✅ Розділити на три окремі історії.

3-й. Відсутні критерії прийняття

Історія без АС неоднозначна. Даже двухпульный кондиционер лучше, чем ничего.

4-й. Опис поведінки системи, а не потреби користувача

❌ “Як система, я хочу надіслати повідомлення електронною поштою…” ✅ “Як клієнт, я хочу отримати підтвердження електронною поштою після оформлення замовлення…”

---

Корисні фрази для уточнення історії

Сфера дослідження:

• “Можно ли разбить эту историю на более мелкие части?”
• “Це залежність нас блокує, чи ми можемо роз’єднати історії?”

** Пояснення критеріїв прийняття: **

• “Яка очікувана поведінка, коли користувач не має дозволу?”
• • « Чи потрібно обробляти стан автономності, чи передбачається мережеве з’ єднання? » *
• • “Який регістр краю, коли список порожній?” *

Отклонение от расплывчатых историй:

• “Ми не можемо оцінити цю історію, поки не знаємо “так що” - яку цінність це дає?”
• “Ця історія не має перевіряних критеріїв прийняття. Чи можемо ми визначити їх, перш ніж перейти до спринту?»

---

Practice

Перевірте ваш словниковий запас за допомогою ** Набір вправ з англійської для бізнес- аналітиків. Name **.

Всі ресурси для BA на ** Підручник для студентів-економістів **.

Національний склад населення: Англійська мова

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

Однією з поширених перешкод є використання умовної мови – фрази на кшталт «потрібен», «може» і «може». Хоча ці слова цілком прийнятні в звичайній розмові, вони вводять невизначеність, що може призвести до розмивання сфери застосування під час розробки. Замість того, щоб сказати « Користувач * повинен * мати змогу скасувати свій пароль », розгляньте « Користувач * може * розпочати процес скасування пароля за допомогою перевірки електронної пошти ». Останнє значення є більш визначеним і дійсним для команди розробників. Аналогічно, при описі критеріїв прийняття, уникайте таких тверджень, як « Це * може * бути правильно показано на мобільному пристрої ». Замініть це на « Інтерфейс користувача буде відображатися послідовно на всіх пристроях iOS і Android з мінімальною роздільною здатністю 375x667 пікселів ». Таким чином, ви отримаєте конкретні очікування, а не покладетеся на нечіткі можливості.

Іншою областю, яка потребує поліпшення, є використання пасивного голосу, який може затьмарити відповідальність. У типовому описі PR може бути написано: « Дані * були перевірені * системою ». Таким чином буде приховано інформацію про те, хто виконував перевірку. Переписати його так: « Система автоматично перевіряє дані за заздалегідь визначеними правилами ». Це чітко визначає відповідальність і демонструє глибше розуміння процесу. Крім того, пам’ятайте про ідіоми і розмовні вирази; такі фрази, як «мислити за рамками» або «низькі фрукти» можуть легко бути неправильно зрозумілі тими, хто не знайомий з їх конкретними конотаціями.

І, нарешті, не вагайтеся попросити про пояснення. Якщо ви не впевнені щодо певної фрази або терміну, завжди шукайте відгуки. Швидке повідомлення Slack з запитанням: «Чи можете ви пояснити, що ви маєте на увазі під «доступним» в цьому контексті?» є набагато ефективнішим, ніж мовчазне змагання з інтерпретацією значення і, можливо, введення помилок у вашу історію користувача. Пам’ятайте, що мета не в тому, щоб звучати ідеально вільно; це ефективно спілкуватися і будувати спільне розуміння в межах вашої команди. Сфокусуйтеся на ясній, короткій мові, підтримуваній конкретними деталями - саме так ви дійсно пишете ідеальні історії користувачів.