У гнучкому середовищі розробки програмного забезпечення юзер сторі (історія користувача) є важливим артефактом. Atlassian (австралійсько-американська софтверна компанія) дає визначення юзер сторі (історії користувача), як «неформальне загальне пояснення функції програмного забезпечення, написане з точки зору кінцевого користувача».
Незалежно від того, які інструменти ви використовуєте (Jira, Trello, LeanKit тощо) чи фреймворку, яким дотримуєтеся (Scrum, Kanban, XP тощо), історії користувачів надають загальну картину вимог з точки зору кінцевого користувача.
Ця думка нещодавно спала мені на думку, коли хтось запитав мене, якого шаблону слідувати під час написання історії користувача. Можливо, ви вже стикалися з цим питанням або ставили його раніше.
- Як бізнес-аналітик,
- Я хочу використовувати шаблон, щоб написати історію користувача,
- Щоб моя команда зрозуміла вимоги.
Чи справді формати та шаблони мають значення?
Відповідь, на мій погляд, Ні! Історії користувачів не мають шаблонів. Навички БA визначаються не тим, наскільки добре вони пишуть історії користувачів, а тим, наскільки добре вони аналізують і повідомляють вимоги команді.
Корисні висновки:
- Наголос слід робити не на створенні добре написаної історії користувача, завдання чи документа, а на правильному повідомленні деталей.
- Адаптуйте свій стиль до потреб вашої команди. Я працював з командами, які віддають перевагу діаграмі, пов’язаній з епіком або сторінкою Confluence для початку. Я працював з командами, які віддають перевагу отримувати вимоги, написані кількома реченнями, і я працював з командами, які віддають перевагу додаванню вимог у форматі таблиці. БA повинен мати можливість зрозуміти, що працює для вашої команди.
- Незалежно від формату, використовуйте просту мову, щоб члени команди могли її зрозуміти. Будьте простими та лаконічними.
- Переконайтеся, що на питання «Хто», «Що» і «Чому» є відповіді, і всі будуть розуміти один одного.
- Важливо, приділіть час обговоренню вимог з командою під час уточнення, мепінгу сторіс та сесій щодо планування роботи. Зберіть їхні запитання, роз’ясніть їхні сумніви та перевірте ті області, які були пропущені.
- Використовуйте візуальні представлення, якщо це допомагає легко передати вимоги, а не довгий есе (твір) вимог.
- Роділяючи вимоги, використовуйте методологію INVEST. Проконсультуйтеся з командою перед розподілом, оскільки технічно роботу можна розподілити по-іншому для зручності розробки та тестування.
- Бізнес аналітик має бути оповідачем, який розповідає історії клієнтів, а не просто автором документів.
- Процес написання юзер сторіс (історій користувачів) вимагає командної роботи та практики. Члени команди повинні спілкуватися, щоб переконатися, що робота є точною та цілеспрямованою.
- Зосередьтеся на такому змісті, як обсяг, аксептанс критерії (критерії прийнятності) тощо. Поділіться всіма необхідними деталями з командою, щоб приймати зважені рішення та пропонувати кращі рішення.
- Реальний світ відрізняється від фреймворків і форматів, створених для ідеальних сценаріїв. Мати добре написаний/перевірений тікет (завдання), але не отримати те, що ви очікували, не є цінним. Отже, у центрі уваги має бути спільне розуміння та результати.
- Існує поширений міф про те, що будь-хто може працювати над добре написаним тікетом (завданням), якщо він добре написаний. Те, як люди розуміють деталі, може бути різним. Незважаючи на те, що є очевидним і простим, згадайте це, щоб досягти спільного розуміння.
- Команда розробників не повинна потрапляти в ситуацію, коли юзер сторі не відповідають критеріям прийнятності через брак ясності чи розуміння. Таким же чином, стверджувати, що щось не вказано в тікеті, не є доказом проти Бізнес Аналітика/Продакт Овнера (ВA/PO). Будьте гнучкими та вчіться не на своїх помилках. Удосконалюйте свій спосіб роботи на основі отриманих знань. Залежно від характеру роботи або вимог деталі можуть бути складними або простими.
- Як було сказано на початку цієї статті, юзер сторі є важливим артефактом, який сприяє збереженню, створенню ідей, відстеженню прогресу роботи та довідці для приміток до випуску. Але його формат не обов’язково має бути незайманим.
- Таким чином, історії користувачів не є високоякісними літературними творами, які слід перевіряти на дрібні граматичні та лексичні помилки. Не надто наголошуйте на дотриманні надійного формату, а на тому, щоб ефективно донести вимоги до команди.
Як бізнес-аналітик,
я хочу створювати артефакти, які допоможуть команді зрозуміти вимоги,
таким чином, ми можемо створювати та надавати цінність клієнту.
Оригінальна стаття – As a BA, I Want to Write a User Story…, переклад – Оксана Агратіна, ревью – Іван Вільчавський. Зображення створене за допомогою DALL-E у ChatGPT.