Історії користувача (User stories)
Last updated
Last updated
Користувацька історія (user story): Високорівнева користувальницька або бізнесова вимога, що зазвичай використовується в гнучких методологіях розробки програмного забезпечення. Зазвичай складається з однієї або кількох пропозицій розмовною або формальною мовою, що описують функціональність, необхідну користувачеві, будь-які нефункціональні вимоги і включають критерії приймання. (ISTQB)
В індустрії розробки ПЗ слово «вимоги» визначає нашу мету, що саме потрібно клієнтам і що змусить нашу компанію розвивати свій бізнес. Будь то продуктова компанія, яка виробляє програмні продукти, або сервісна компанія, яка пропонує послуги у різних галузях програмного забезпечення, основною базою для всіх з них є вимога, а успіх визначається тим, наскільки добре ці вимоги виконуються. Термін «вимога» має різні назви у різних методологіях проекту. У Waterfall це називається Requirement/Specification Document, Agile або SCRUM вимоги документуються у вигляді «Epic» і «User Story». У моделі Waterfall документи з вимогами є величезними документами на сотні сторінок, оскільки весь продукт реалізується за один етап. Але це не стосується Agile / SCRUM,
Користувацька історія визначає вимоги до будь-якої функціональності або фічі, в той час як критерії приймання (Acceptance Criteria) визначають критерії готовності (Definition of done) для користувальницької історії або вимоги.
Користувацька історія - це вимога для будь-якої функціональності або фічі, яка записана в 1-2 рядки. Користувацька історія зазвичай є найпростішою з можливих вимог і стосується однієї-єдиної функції/фічі.
Формат :
Як / роль користувача або клієнта /, я хочу / мета, яку потрібно досягти / щоб я міг / причина мети /.
Наприклад, “Як користувач WhatsApp , я хочу, щоб значок камери в полі введення чату дозволяв захоплювати та надсилати зображення , щоб я міг клацнути та поділитися своїми фотографіями одночасно з усіма своїми друзями .”
Це стандартний формат, але не обов'язковий чи єдино-можливий. Головне у історії - це цінність, яку користувач отримає від функції, тобто. User Story - це прийом запису вимог, який допомагає команді розробки зрозуміти потребу клієнта та після обговорення вибрати, описати та затвердити те рішення, яке задовольнить цю потребу.
Job Stories
В цілому Job Stories - схожа на US техніка. Можна назвати їх прийомом-субститутом, адже зазвичай вони не використовуються разом та виконують максимально схожу функцію. Job Stories представляють вимогу у вигляді дії, яку виконує користувач. Не описують саму функцію, лише концентрують увагу команди потреби. Job Stories концентруються на психологічній частині фічі, на емоціях, тривогах та інше, що може виникнути під час використання функції.
"Тіло" JS ділиться на три частини:
Situation: дає контекст про всю JS, яка допомагає dev-команді придумати можливе рішення;
Motivation: визначає невидиму руку, яка веде користувача до використання цієї функції;
Expected Outcome: визначає, що отримає користувач після використання функції.
Job Stories можуть писатися за двома форматами:
В один рядок: When XI want to Y so I can Z" або "When X, actor is Y so that Z;
У три рядки:
When X
I want to Y
So I can Z.
Приклад: Якщо я маю на сплаті грошей з моїх банківських рахунків, я маю на увазі маю гроші в моїй браузері з високим коштом, який ні з тим, що я можу вийти на сніданок з моїми людьми.
Джерела:
Дод. матеріал:
