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

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

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

---

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

Структура «Якщо / Я хочу / Отже»

Канонічний формат історії користувача складається з трьох компонентів:

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

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

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

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

«Що таке» (фр

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

** Без « так що »: ** * « Як користувач, я хочу, щоб у результатах пошуку був фільтр ». * ** З « so that »: ** * « Як користувач, я хочу фільтрувати результати пошуку за датою, щоб знайти найновіший вміст без прокрутки старих результатів ». *

---

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

Які критерії прийняття?

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

• “Історія завершена, коли: (1) користувач отримав лист про скасування пароля протягом 60 секунд після запиту; (2) посилання на скасування закінчується через 24 години; (3) користувачеві буде показано помилку, якщо він спробує скористатися застарілім посиланням.” *

Визначення ключових критеріїв

Критерії прийняття повинні бути такими:

• ** Специфічний ** — не « швидкий », а « відповідає протягом 200 мс під звичайним навантаженням »
• ** Перевіряємо ** — інженер QA може перевірити його з чітким успіхом/ невдачею
• ** Згоден ** — продукт, розробник і QA повинні підтвердити критерії перед початком розробки

** Слабкі критерії: **

“АПІ має бути безпечним.”

Сильний критерій:

• “Всі кінцеві точки API вимагають чинного токену JWT. Запити без токенів повертають HTTP 401. Запити зі застарілим токеном повертають HTTP 401 з повідомленням про помилку, що вказує на застарілість токену.”*

---

1999) і Б. (нар

Використовується лексика мовлення

BDD (Behaviour-Driven Development) - це підхід, який описує поведінку системи структурованою природною мовою. Формат Given/When/Then є стандартним способом написання сценаріїв BDD.

• ** Задано ** — початковий контекст або стан
• ** Коли ** — дія або подія, яка відбудеться
• Тогда — ожидаемый результат

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

• “Зареєстрованого користувача з чинним обліковим записом,*
• Коли вони надсилають запит на скасування пароля за допомогою своєї зареєстрованої адреси електронної пошти,*
• Потім вони отримають електронну пошту, що містить посилання на скасування пароля протягом 60 секунд. ”*

Інший приклад:

• “За умови, що користувач не ввійшов до системи,* Когда они пытаются получить доступ к /dashboard, Потім вони перенаправляються на сторінку входу з URL /login?redirect=/dashboard.”

«І» для розширення сценаріїв

Скористайтеся ** І **, щоб додати додаткові кроки без повторення Дано/ Коли/ Тоді:

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

---

Історичні формати

Технічні новини

Технічні історії описують роботу, яка не забезпечує користувачеві видиму цінність безпосередньо, але необхідна для системи. Суб’єкт “як” зазвичай є командою або системою.

• “Як команда розробників, ми хочемо перенести базу даних користувачів на PostgreSQL 16, щоб ми могли скористатися перевагами поліпшеної продуктивності JSON і офіційної довгострокової підтримки.” *

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

Історія Спліта

** Спік ** це розслідування або дослідження з обмеженим часом. Вихід - це знання, а не працююче програмне забезпечення.

• “Spike: Досліджувати параметри для додавання сповіщень у реальному часі. Часовий проміжок: два дні. Вивід: письмове порівняння WebSockets, Server-Sent Events і полювань, з рекомендацією.”*

---

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

Система вимірювання зображення

** Невірно: ** * « Система повинна надсилати повідомлення електронної пошти, коли користувач реєструється. » * ** Краще: ** * « Як новий користувач, я хочу отримати привітальну електронну пошту після реєстрації, щоб знати, що мій обліковий запис було успішно створено. » *

Включаючи деталі реалізації

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

Уникайте: “Я, як користувач, хочу, щоб система використовувала Redis pub/sub для відсилання сповіщень до мого переглядача.” ** Краще: ** * « Як користувач, я хочу отримувати сповіщення про нові повідомлення у переглядачі, щоб мені не доводилося постійно оновлювати сторінку. » *

Історії, які занадто великі

Історія, яку не можна завершити в одному спринті, повинна бути розбита на частини.

• « Як користувач, я хочу керувати всім своїм профілем. » * — Занадто велике.

Розділити на:

• « Як користувач, я хочу оновити своє ім’ я для відображення. » *
• « Як користувач, я хочу завантажити фото профілю. » *
• « Як користувач, я хочу змінити свою адресу електронної пошти. » *

---

Корисний словник для історій користувачів

• ** Епічний ** — великий обсяг роботи, який можна розбити на декілька історій користувачів
• ** Очки історії ** — відносна міра зусиль, складності і невизначеності
• ** Визначення завершеного (DoD) ** — загальні для команди критерії, яким повинні відповідати всі історії, щоб вважатися завершеними
• ** Визначення готовності (DoR) ** — критерії, яким має відповідати стаття, перш ніж її можна буде включити до спринту

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

---

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

Національна мова: мова, що використовується для спілкування між ненаціональними групами

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

Однією з найпоширеніших проблем є розуміння тонких відмінностей у фразуваннях, що використовуються під час перегляду коду. Уявіть, що ви отримали такий коментар на запит Pull: «Ця реалізація не повністю відповідає критеріям прийняття, описаним в статті. Обробка помилок повинна бути більш надійною. ” Нерідний мовець може відразу відчувати себе пригніченим, не впевнений, чи “надійний” дійсно правильний термін, або якщо є очікування певного рівня складності. Замість того, щоб сприймати це як критику, корисно розбити її на частини. « Не повністю розв’ язує » говорить про неповний огляд — ви можете відповісти щось на зразок: « Я розумію вимоги щодо більш всеоб’ ємної обробки помилок. Чи можете ви пояснити, які конкретні сценарії мені слід тестувати в першу чергу?» Це демонструє залученість і бажання навчатися, а не оборону. Аналогічно, в обговореннях Slack, використання фраз на кшталт «для забезпечення стійкості» замість простого зауваження «воно повинно краще обробляти помилки» негайно піднімає розмову до більш технічного і проактивного підходу.

Інша область, де нюанс має значення, це в описах PR. Хороший PR-опис - це не просто резюме; це міні-наратив, що пояснює чому ви зробили зміни. Замість « Виправлено ваду », спробуйте написати « Впроваджено механізм повторних спроб для вирішення проблеми з перервними збоями з’ єднання під час синхронізації даних, що покращує стійкість системи і зменшує потенційні переривання роботи ». Зауважте, що у повідомленні використано такі терміни, як « перервне », « синхронізація даних » і « переривання роботи ». Це звичайні технічні терміни, які демонструють ваше розуміння основної проблеми. Використання точної мови показує повагу до часу ваших колег і забезпечує, що всі будуть на одній сторінці щодо впливу зміни. Не бійтеся задати прояснюючі питання - це набагато краще шукати пояснення заздалегідь, ніж робити припущення.

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