fbpx

2.4. User Stories

Що це таке User Stories?

User Stories —  це по суті вимоги, але прості для сприйняття клієнта.

User Story — це одне або кілька речень написаних повсякденною або бізнес-мовою користувача або клієнта, які описують те, чого користувач або клієнт хоче досягти за допомогою програмного забезпечення. Це короткий опис того, як користувач, клієнт або інша особа буде використовувати систему, і яку вигоду при цьому отримає від конкретної функціональності. Таким чином, замість складних для розуміння клієнта Requirements Specifications, створюються короткі розповіді — User Stories — які забезпечують власнику продукту зрозумілий контекст і дозволяють ефективно керувати і приорітизувати список завдань.

Who? (Хто?) User Story

“Who?” в User Story — це хто хоче цю функціональність і отримує вигоду з неї. Зазвичай, використовується роль чи особа для того, щоб всі глибоко розуміли потреби і мотивації цього “Who”. Уникайте занадто загальних ролей (приклад: As a user I want… — Як користувач я хочу…); замість цього використовуйте ролі, що допомагають команді уявити для кого саме вони створюють продукт. В деяких User Stories  система виступає, як  “Who”. Навіть дуже технічні User Stories повинні описувати, що клієнт чи користувач отримує з цього.

What? (Що?) User Story

“What?” в User Story — це потреба, частина системи чи функціональність, яку хоче ‘Who’.Це те, що команда буде вбудовувати у software чи service (сервіс). ‘What’ (що)  має бути дуже чітке і ясне, щоб команда знала, що проектувати і створювати.

Why? (Чому?) User Story

“Why?” в User Story — це цінність для “Who”. Це основна мета для надання цього кієнту. Включення “Why” збагачує User Stories. “Why” — це важливий контекст, який допомагає команді проектувати рішення, що відповідають реальним потребам користувачів і споживачів. “Why” також критично важливе в Agile який є ціннісно-керованим підходом у розробці Software. “Why” (чому) центрує і тримає цінність на виду, допомагаючи Product Owner  визначати приоритети. Якщо не виходить знайти “Why” для User Story, можливо це випадок для якого немає жодної цінності.

Template (зразок) User Story

Зразок User Story покликаний допомогти Product Owners та команді писати User Stories з чіткими і ясними “who”, “what” і “why”. Зразок — це просто вказівник. Далі тільки включіть відповідні елементи.

  • As a registered user (who). I want to reset my password (what), so that I can get back in to the site if I forget my password (why).  
  • (Як зареєстрований користувач (хто), я хочу обнулити свій пароль (що) таким чином, щоб я міг повернутись на сайт, якщо я забув свій пароль (чому).
  • As an unregistered user, I can sign up for the site, so that I’m able to have a personalized  experience.
  • (Як не зареєстрований користувач, я можу підписатись на сайт, щоб я отримав особистий / персоналізований досвід.)
  • As Tom, I want to only see updates from close friends, so that I can view relevant updates during my time online.
  • (Як Том, я хочу бачити оновлення тільки від близьких друзів, щоб я міг переглядати відповідні речі коли я онлайн.)

Інший Template (зразок) User Story

Деяким stories корисніше мати більше одного “who”. В такому випадку, може допомогти включення кількох who-why (хто-чому) пар.

what: Track history of what products registered shoppers have viewed.
      who: Registered Shoppers.
      why: So I can go back and find again (and buy) what I’ve researched previously.

who: Marketing.
why: So we can serve ads that are relevant to the interests of individual registered shoppers.

що: Відслідковувати історію зареєстрованих продуктів, які покупці переглядали.
хто: Зареєстровані покупці.
чому: Щоб я міг повернутись і знов знайти (і купити) те, що я перед цим досліджував.

хто: Маркетологи.
чому: Щоб ми могли надати рекламу відповідну до інтересів конкретних зареєстрованих користувачів.

З чого почати написання User Story?

      Просте твердження у форматі User Story вже дає початок, але не розказує всієї історії. Команді потрібно більше. Є три ключові елементи User Story — Картка, Обговорення і Підтвердження. (Three “C”).

Card:

Картка — це опис “who”, “what” і “why” для user story. Індексована картка метафорично (а часом буквально) представляє собою маленький простір для описання стислої story і той факт, що stories мають легко переміщатись і рухатись вверх-вниз по backlog -у. Картка має в собі загальну ідею і обіцяє обговорення.

“As a registered user, I want to reset my password
so that I can get back into the site if I forget my
password.”

“Як зареєстрований користувач, я хочу обнулити
свій пароль таким чином, щоб я міг повернутись на
сайт, якщо я забув свій пароль.”

Conversation:

Картка надає базу до обговорення між Product Owner-ом чи кінцевим споживачем і Delivery Team (командою виконавців). Через розмову Product Owner і Delivery Team створюють спільне розуміння цілей і обмежень створюваної функціональності. Часто, команда задає питання.

Для прикладу з обнуленням паролю, питання можуть включати:

  • What type of authentication do we need? (Який тип аутентифікації нам потрібен?)
  • What information do we need to collect about the user? (Яку інформацію нам треба збирати про юзера?)
  • Are there different types of users that we have worry about? (Чи є інфші типи користувачів, яких ми маєм врахувати в даному випадку?)

Вся команда може приймати участь у цьому обговоренні. Різні ролі і точки зору витягуватимуть на поверхню різні запитання і зауваження.

Confirmation:

Підтвердження — це коли, результати обговорення мають бути записані як Acceptance Criteria (критерії прийняття для тої чи іншої сторі). Добре визначена user story є testable (тестабельна, така, котру можна потестувати). Як має Product Owner підтвердити, що story зроблена як треба?

Acceptance Criteria:

Критерії прийняття — це умови задоволеності і прийняття для User Story. Product Owners і Delivery Team працюють разом, щоб виробити acceptance criteria і позбавитись будь-якої двозначності в user story. Поверхневі / загальні твердження зазвичай підходять і вони мають бути перетворені в acceptance tests (приймальні тести) коли починається впровадження story.

Acceptance Criteria для нашої Reset Password (обнулення паролю) story можуть включати:

  • Username, password, and email address are all required. Display name can be provided, but is optional. (Ім’я користувача, пароль і емейл є обов’язковими.Ім’я для відображення може бути введене, але є необов’язковим.)
  • Passwords can be 6 – 200 characters in length. (Пароль може бути 6 – 200 символів по довжині.)
  • Passwords should be stored encrypted and cannot be decrypted. (Паролі мають зберігатись зашифрованими і не можуть розшифровуватись.)