Сьогодні до Вашої уваги адаптований переклад статті від Chris Stevenson, у якій автор з класними прикладами по полицях розкладає принцип INVEST, який застосовують для оцінки якості користувацьких історій (user story)
Єдиним справжнім тестом на те, чи добре написана історія користувача (user story), є те, чи здатна команда розробників витягти її з беклогу і почати працювати над нею.
Та все ж, є добре відома абревіатура, яка дозволяє «перевірити», чи готові ваші історії користувачів (user story). Кожна літера в слові INVEST представляє характеристику хорошої історії користувача (user story). Варто витратити деякий час на розуміння цих різних характеристик, оскільки вони можуть скласти хороший контрольний список для будь-яких вимог, навіть якщо вони не написані у форматі історії користувача (user story).
До теми: Юзер сторі чи Юз кейси…ось в чому питання! (Requirements 101: User Stories vs. Use Cases)
INVEST
I — Independent
І – означає Indenendent – Незалежна.
Повинна бути можливість реалізувати кожну історію користувача (user story) незалежно від інших. Ідея, що лежить в основі цих характеристик, полягає в тому, щоб дозволити команді досягати результатів невеликими поступовими кроками. У гнучкому мисленні має сенс надавати цінність кінцевому споживачу якомога раніше.
Наприклад, уявімо, що ми створюємо систему, яка дозволяє клієнтам підписуватися на інформацію про квитки на концерти. Наша послуга коштує п’ять доларів на місяць і дає ранній доступ до квитків на популярні групи. Якщо у вас є платоспроможні клієнти, які бажають зареєструватися на вашій службі, має сенс зареєструвати їх якнайшвидше, щоб почати заробляти гроші.
Ми могли б написати історію користувача (user story), у якій йдеться:
As a Customer, I want to be able to register for the tickets information service and be sent my first information email, so that I can see what concerts are coming up.
Це матиме сенс, але це не є незалежним, оскільки прив’язує процес реєстрації на послугу до клієнта, який отримує електронний лист з інформацією. Якщо ми напишемо таку історію користувача (user story), то компанія повинна дочекатися готовності як процесу реєстрації, так і процесу надсилання електронної пошти з інформацією, перш ніж вона зможе отримати вигоду від грошей клієнтів за підписку. Краще було б написати це як дві незалежні історії, можливо, так.
As a Customer, I want to be able to register for the tickets information service, so that I know I will get information about future concerts.
As a Subscribed Customer, I want to receive my first information email, so that I can see what concerts are coming up.
Це дає бізнесу опції. Для старт-апу може виявитися, що реєстрація абонентів набагато важливіша на цьому етапі, ніж наступні етапи бізнес-процесу.
Ви ж не хочете чекати на додаткову функцію, необхідну для надсилання інформації про концерти, тоді як ви можете запустити процес реєстрації в реальному часі та залучити платних клієнтів.
Пам’ятайте: якщо історія користувача (user story) має цінність, то чим швидше ви запровадите цю функцію у своїй організації, тим швидше ви почнете збирати цю цінність. Якщо частина функціональності приносить кілька тисяч фунтів або доларів щомісяця, то чим раніше ви можете використовувати цю функціональність у роботі – тим раніше ви будете отримувати додаткову тисячу фунтів або доларів. Аналогічно також, якщо несправна або втрачена функція щомісяця коштує вам грошей, то кожен місяць, коли ви відкладаєте її виправлення, буде втраченим.
Зверніть увагу: Як писати хороші User Stories
Іноді важко створити функціональність самостійно (незалежно), щоб досягти цього, команді може знадобитися творчо підійти до того, як вони вирішують завдання, і може знадобитися рефакторинг (або перекодування) певних частин системи.
Загалом легше писати незалежні історії користувачів (user story), коли маємо справу з більшими вимогами; великі блоки, або епіки, в межах продукту чи послуги, як правило, будуть більш незалежними, оскільки вони представляють окремі частини системи. Коли ви розробляєте свої вимоги на нижчому рівні, ймовірно, що вам буде важче підтримувати справжню незалежність в історіях (user story), пам’ятайте, що ми намагаємося підтримувати незалежність історій користувачів (user story), щоб допомогти визначити пріоритети. Якщо вам важко писати незалежні історії користувача (user story), подумайте, чи досягли ви природного розміру історії користувача (user story), можливо, розбивати її на менші частини немає змісту. На нижчих рівнях я б порадив вам намагатися зберігати історії незалежними, але не витрачати багато часу на їх написання
N — Negotiable
N – означає Negotiable – Обговорювана (дискусійна)
Під час створення історій користувачів (user story) важливо, щоб був певний рівень свободи дій у способі створення рішення. Якщо ви чітко записуєте, що саме має бути реалізовано, ви можете також написати функціональну специфікацію, як ми це робили в проектах водоспаду (waterfall).
Цінність обговорюваних історій користувачів (user story) полягає в отриманні переваги від досвіду та ідей ширшої групи людей у команді. З мого досвіду, якщо ви почнете з розпливчастої історії користувача (user story) та обговорите, хто і як може її реалізувати, ви отримаєте кращі рішення, ніж якщо ви диктуєте, як саме має бути виконана вимога. Жодна людина не має повної монополії на знання, і можливості створити кращу систему будуть упущені, якщо лише одна людина вибере, як створювати речі.
Для прикладу візьмемо історію користувача (user story) вигаданого власника продукту, яка може бути занадто жорсткою. Уявімо систему продажу, яка дозволяє клієнтам замовляти квитки на концерт. У існуючому бізнесі клієнти замовляють лише один концерт за раз, і вони повинні завершити цей процес протягом години.
As a Marketing Manager, I want all uncompleted sales to be deleted from the system at midnight, so that the system is clear at the beginning of the day for new sales.
У цьому прикладі власник продукту зробив серйозне припущення, що найкращий спосіб вирішення проблеми неповних продажів — це пакетний процес, який шукає неповні продажі та закриває їх. Це означає, що системі може знадобитися запланований сценарій для запуску бази даних опівночі.
До теми: Ця чудова (користувацька) історія
Якби вони написали історію користувача (user story) в більш обговорюваній манері, результат міг би бути іншим.
As a Marketing Manager, I want uncompleted sales to be deleted, so that the system can make a new sale.
Тепер команда може природно обговорювати різні ідеї. Вони можуть розглянути пакетний процес, а також новий процес видалення старих продажів як частину процесу початку нового продажу або, можливо, покращити роботу системи з кількома продажами для кожного клієнта, вони можуть навіть розглянути нову можливість для бізнесу дозволити клієнту вести облік неповних продажів і автоматично заповнювати його та пропонувати клієнту, якщо з’являться нові квитки.
Насправді часто існує більше ніж один спосіб задовольнити вимогу, тож чому б вам не розглянути ширший спектр рішень, ніж може придумати одна людина?
V — Valuable
V – означає Valuable – Цінна (така, що має цінність)
Ця характеристика хороших історій користувачів (user story) пов’язана з частиною шаблону «so that». Ця частина історії користувача (user story) містить цінність, яку відчує кінцевий користувач, коли він зможе використовувати цю функцію. Історія користувача також повинна принести певний бізнес-результат, якого хоче організація.
Для прикладу розглянемо наступну історію
As a frequent flyer, I want to collect a point for every mile I fly, so that I can collect enough points to get rewards.
Ця історія користувача (user story) чітко пояснює причину такої історії, але вона також має комерційну цінність з точки зору заохочення лояльності клієнтів. Власник продукту повинен розуміти бізнес-цінність, яку він або вона оприлюднить з кожною історією користувача (user story). Насправді малоймовірно, що бізнес-цінність буде відстежуватися на рівні індивідуальної історії користувача (user story), але кожна історія має бути зосереджена на цілях організації.
E — Estimable
E – означає Estimable – Вимірна (така, що можна оцінити/виміряти)
До моменту обговорення або вдосконалення командою розробників історія користувача (user story) повинна бути достатньо зрозумілою, щоб команда могла оцінити складність і рівень зусиль, необхідних для надання функціональності. Пам’ятайте, що до того моменту, як її вважатимуть готовою, історія користувача (user story) має сформувати потенційно доступний для випуску елемент загальної функціональності.
У scrum-командах це важливо, щоб команда не брала надмірних зобов’язань, витягуючи роботу з беклогу. Однак, незалежно від використовуваної методології, історії користувачів (user story), як правило, мають бути максимально керованими та меншими, наскільки це можливо. У одній команді, де я працював не по scrum agile, мала обмеження, згідно з яким жодна історія користувача (user story) не повинна тривати більше двох днів; це означало, що команда повинна була розуміти достатньо, щоб мати можливість залишатися в межах цього обмеження. Цей наголос на розумінні був, на мою думку, набагато ціннішим, ніж формальна оцінка.
Може допомогти: Гайд по User Stories для Junior BA
Історію користувача (user story) потрібно розуміти настільки, щоб можна було вільно оцінити масштаб, обсяг і складність. Ця практика полягає не у визначенні та оголошенні терміну реалізації, а в тому, щоб зменшити ризик того, що розробка потрапить у труднощі, оскільки буде виявлено непередбачену складність.
S — Small
S – означає Small – Маленька
У Scrum проекті функціональність, пов’язана з історією користувача (user story), не повинна займати більше часу, ніж один спринт. Дуже просто створити великі історії користувачів (user story), які потребують кількох спринтів. У цьому випадку практика мати потенційно наявний додатковий (новий) обсяг робочого функціоналу системи в кінці кожного спринту починає бути нереальною, а ризики запізнитися починають примножуватися.
Під час написання історій користувача (user story) більші історії слід розбивати на менші, де це можливо, щоб зменшити ризик реалізації для кожної частини системи та підвищити гнучкість команди під час реалізації завдання. Пізніше ми розглянемо деякі стратегії поділу історій користувачів (user story), а наразі скажемо лише, що невеликі історії, як правило, легше реалізовувати, а тому вони кращі за великі, якщо менші історії дотримуються принципів Invest.
Легко уявити великі історії користувачів (user story), які приносять багато цінності, що в кінцевому підсумку відчувається в усіх частинах бізнесу, набагато важче представити це саме з маленькими історіями. Командам потрібно наполегливо працювати, щоб розбити речі на елементи, які можна реалізувати.
Наприклад, якщо нам потрібно створити інтерфейс, який переміщує клієнтів із системи продажів у систему адміністрування, ми можемо почати з наступної історії користувача (user story);
As Sales Administrator, I want customer and sales information transferred from the sales system to the administration system, so that the customer can be sent their order.
Просто дивлячись на це, я починаю думати, що це може бути великий шматок роботи.
Це непогана практика починати з такого собі “плейсхолдера”/”заглушки” для створення інтерфейсу, але власник продукту або бізнес-аналітик повинен співпрацювати з командою розробників, щоб розробити стратегії розбиття розбиття цього “плейсхолдера”/”заглушки” на менші шматки.
Для нашого прикладу інтерфейсу можна почати з передачі між системами найпростішого типу запису, можливо, продажу одного товару. Після створення початкової версії можна буде розширити вимоги в наступних ітераціях, а потім додати складні записи. Дотримуючись цієї стратегії, ми можемо отримати наступні історії, кожна з яких має бути меншою за оригінальну.
As Sales Administrator, I want single item sales for existing customers transferred from the sales system to the administration system, so that I can send them their item.
As Sales Administrator, I want multiple item sales for existing customers transferred from the sales system to the administration system, so that I can send them their item.
As Sales Administrator, I want new customer details transferred from the sales system to the administration system, so that I can send them their items.
As Sales Administrator, I want the details for existing customers with new addresses transferred from the sales system to the administration system, so that my records are updated and I can send them their items.
Розбивши більшу історію на менші частини, ви побачите, як можна побудувати інтерфейс у серії менших етапів. Це дозволяє команді турбуватися про меншу кількість деталей у кожній точці та проводити тестування меншими частинами. Обробка однієї меншої історії за раз повинна знизити загальний ризик реалізації функціональності.
Важливо те, що кожна з цих розділених історій може бути представлена в різній точці, надаючи гнучкості бізнесу. Ось приклад того, як поділ великої історії користувача (user story) на менші може окупитися.
Візьміть до уваги: User Story та Acceptance Criteria: пишемо чіткі та зрозумілі вимоги
Припустімо, що протягом наступних кількох тижнів стане важливо оновити адреси існуючих клієнтів, можливо, через зміну поштового індексу. Ми могли б запустити сценарій оновлення, щоб змінити адреси в базі даних системи продажів і адміністративної бази даних, але якщо ми створимо остаточну історію, нам потрібно лише оновити адреси в системі продажів і дозволити інтерфейсу подбати про оновлення системи адміністрування . Цей параметр може бути недоступним, якщо команда вважає, що їм потрібно створити весь інтерфейс для всіх сценаріїв, перш ніж він запрацює.
T — Testable
T – означає Testable – така, яку можна протестувати/перевірити
Останній елемент абревіатури Invest полягає в тому, що історії користувачів (user story) повинні бути перевіреними. Усі члени команди розробників, а не лише тестувальники, повинні розуміти, як функціональність буде перевірена. Це може бути офіційне тестування програмного забезпечення, тестування прийнятності користувача, тестування зразків, демонстрація програмного забезпечення або будь-яка інша форма перевірки.
Важливо те, що команда повинна розуміти, що означає «готово» для кожної історії користувача (user story), перш ніж почати розробку, і вони повинні бути впевнені, що рівень тестування підходить для історії користувача (user story).
Хорошою практикою є чітко проговорити про спосіб перевірки функціональності, оскільки це часто може виявити важливі аспекти рішення, які інакше не були б розглянуті. Питання «як нам довести, що це працює, як очікувалося» привертає увагу до рішення таким чином, що будуть проговорені всі деталі. Кілька років тому я працював над системою, яка включала елементарну функцію пошуку клієнтів і облікових записів; Лише коли ми обговорювали, як перевірити функціональність, ми зрозуміли складність різних варіантів.