На сьогоднішній день важко знайти проєкт або ініціативу в IT-сфері, яка не застосовує гнучкі методології. Хоча існують дуже специфічні проєкти, де традиційні методології управління проєктами все ще корисні, PMI (Project Management Institute) зазначає, що 71% компаній у всьому світі використовують гнучкі методології. Чи вважаєте ви, що ці 71% компаній дотримуються гнучких методологій у повній мірі? Скільки проєктів із цих 71% компаній, на вашу думку, є успішними щороку? Чи вважаєте ви, що agile-команди цих компаній справді розуміють цінності та принципи Agile? Кожна людина може мати різну точку зору, але правда полягає в тому, що для успіху гнучкого проєкту вкрай важливо, щоб команда підтримувала ефективну комунікацію та співпрацю між своїми членами та з клієнтом. Для досягнення цього існують різні стратегії, що спираються на цінності та принципи Agile.
У цій статті я зосереджусь саме на одному елементі, який присутній протягом усього гнучкого циклу та є одним із головних інструментів комунікації в командах: користувацьких історіях.
Згідно з IIBA (Міжнародним інститутом бізнес-аналізу), користувацькі історії – це: «простий і стислий опис функції або функціональності, яку бажано реалізувати в системі». Вони використовуються в гнучких методологіях для визначення вимог проєкту та пишуться командою розробників спільно з клієнтом.
Ось приклад користувацької історії:
Як користувач, я хочу мати можливість входити в застосунок, щоб отримати доступ до додаткових інструментів, доступних лише зареєстрованим користувачам.
З цієї користувацької історії зацікавлені сторони проєкту повинні розуміти, яка вимога висувається. Чи думаєте ви, що цього достатньо? Однозначно ні. Ви можете вважати, що користувацька історія є надто простою, неоднозначною та недостатньо детальною, і в цьому є певний сенс. Однак, спираючись на мій досвід участі в багатьох agile-проєктах, я можу назвати дві основні причини, чому agile-команда не вловлює суть того, що вимагається, при використанні користувацьких історій.
Що відбувається з користувацькими історіями в agile-командах з різним рівнем досвіду?
Тип команди 1 (Команда не розуміє та не цінує важливість принципів і цінностей Agile):
Протягом своєї професійної кар’єри я стикався з багатьма командами, які заявляли, що працюють за методологією Agile та практикують Scrum або певне поєднання Scrum і Kanban. В організаціях є певні Agile-євангелісти, які стежать за тим, чи дотримуються команди Agile-церемоній і чи є беклог продукту актуальним, відпрацьованим і пріоритизованим. Однак якщо придивитися до самої agile-команди, то нерідко виявляється, що єдиними навченими членами Scrum є Scrum Master, Product Owner і бізнес-аналітик. Інші учасники – розробники та спеціалісти з контролю якості – розуміють Agile через дії, завдання та настанови, які виконують Agile-представники команди, але вони не знають, як практикувати його та робити внесок у роботу команди так само, як і решта учасників, а це вже є помилкою.
Якщо не всі члени команди розуміють основи принципів та цінностей Agile, буде дуже складно досягти самоорганізованої, міждисциплінарної, прозорої та комунікативної команди, яка може проводити Agile-церемонії та розуміти Agile-сутність користувацьких історій.
У цьому сценарії команди регулярно помиляються в оцінках часу та зусиль, змушені постійно переносити завдання з одного спринту в інший і потребують значної додаткової документації до користувацьких історій для виконання своєї роботи. Вони продовжують мислити традиційно, працюючи у відокремлених підрозділах і створюючи гібрид між каскадною методологією та Agile, що призводить до внутрішніх вузьких місць. З іншого боку, нерідко трапляється так, що лише Scrum-майстер і бізнес-аналітик відчувають мотивацію проводити Agile-церемонії, тоді як інші члени команди нудьгують або байдужі до того, чи є ці церемонії корисними. Вони відчувають себе зобов’язаними відвідувати їх лише через формальні зобов’язання, а не через власне переконання та переконання команди.
У цьому сценарії дуже ймовірно, що доведеться докладати додаткових зусиль, не передбачених планом спринту, оскільки команди, як правило, не встигають вчасно визначити всі вимоги та обсяг необхідної роботи. Вони роблять це в процесі.
Тип команди 2 (Команда має знання Agile, але не має практичного досвіду):
У цьому сценарії всі члени команди мають щонайменше вступну сертифікацію з методологій Agile, наприклад Scrum Developer або Scrum Fundamentals. Команда знає принципи та цінності Agile і розуміє призначення кожної з церемоній, які необхідно проводити. Однак, як і будь-яка команда в процесі становлення, її учасники ще не повністю згуртовані: вони мають теоретичну базу, але на практиці ситуація виглядає зовсім інакше – вони ще не встановили належного ритму чи темпу роботи. Цілком можливо, що, хоча вони й розуміють, чому речі мають робитися саме так, вони ще не усвідомлюють і не відчувають тієї цінності, яку Agile приносить команді і, насамперед, клієнтам.
У цьому випадку Scrum Master і Бізнес-аналітик стикаються з великим викликом: змусити команду зрозуміти цінність, яку кожна виконана користувацька історія принесе клієнту. Командам часто властиво знати, що їм потрібно зробити, і ефективно виконувати це вчасно та якісно, але при цьому не розуміти, чому це важливо для клієнта. Вони обмежуються написанням коду та тестуванням, хоча є можливості поділитися баченням клієнта щодо цього. Це призводить до того, що в результаті поставки щось може піти не так, оскільки команда не брала до уваги цінність результату для клієнта.
Тип команди 3 (Команда розуміє Agile і знає, як бути Agile):
У цьому сценарії ми маємо команди, які повністю обізнані з принципами agile. Відсутні будь-які розрізнені підрозділи; команда є прозорою та комунікативною. Вони розуміють свою робочу спроможність, темп роботи та вміють оцінювати обсяги завдань. Усі їхні agile-церемонії є зрілими. Вони не дотримуються agile-фреймворку буквально та використовують стратегії з різних agile-фреймворків, які найкраще відповідають їхньому робочому процесу. Попри це, все одно існує можливість того, що щось може піти не так, і це зумовлено звичайною невизначеністю, яка виникає в будь-якому agile-проєкті. На початку рівень невизначеності та ризику є високим, оскільки деталі щодо того, що необхідно зробити, лише збираються. У міру просування ітерацій цей рівень невизначеності та ризику знижується, оскільки з кожною ітерацією збирається та уточнюється більше деталей, що забезпечує краще розуміння напряму роботи з клієнтом.
У цьому випадку єдина причина, через яку команда може не зрозуміти історію користувача, полягає в тому, що вона описана на дуже високому рівні та потребує декомпозиції, щоб обсяг роботи вписувався щонайбільше в один спринт.
Повернімося до нашого попереднього прикладу:
Як користувач, я повинен мати можливість увійти в застосунок, щоб використовувати додаткові інструменти, доступні лише для авторизованих користувачів.
Що подумала б Команда 1, побачивши цю історію користувача?
Команда, яка не розуміє принципів Agile і прийшла з більш традиційних команд, зауважила б, що не розуміє мети створення користувацьких історій, і сказала б, що їм бракує деталей, потоків, діаграм і процесів для продовження роботи. Вони б відмовилися розпочинати перегляд пов’язаних завдань, доки не матимуть цієї попередньої інформації.
Що подумала б Команда 2, побачивши цю історію користувача?
Ця команда має знання про Agile та про те, як проводити Agile-церемонії. Найімовірніше, команда прокоментує, що цієї історії недостатньо для розуміння мети, і запропонує провести кілька зустрічей, щоб зрозуміти, що необхідно зробити, зрештою створюючи додаткову документацію для фіксації того, що обговорювалося та було узгоджено. Після завершення цих сесій (як церемоній, так і деяких додаткових зустрічей) команда, можливо, зможе завершити роботу вчасно та відповідно до очікувань. Проте ця команда, найімовірніше, витрачатиме додатковий час на пошук деталей усередині команди, запити інформації електронною поштою або очікування, поки BA чи SM отримають додаткові деталі централізованим способом (тобто вони покладаються на BA або SM на 100% щодо інформації, яку могли б отримати самостійно).
Що подумала б Команда 3, побачивши цю історію користувача?
Команда 3, будучи експертом у сфері Agile, усвідомила б, що настав час для уточнення вимог. Найімовірніше, вони б запропонували сесію грумінгу, під час якої разом із Власником Продукту та Бізнес-аналітиком провели б мозковий штурм, щоб узгодити, як розбити цю користувацьку історію та як її доповнити. Як мультидисциплінарна, прозора та комунікативна команда, вони б самоорганізовувалися протягом спринту, щоб спілкуватися всередині команди за потреби, проактивно та оперативно вирішуючи свої питання. Такий колаборативний підхід дозволив би їм не лише зрозуміти мету користувацької історії, але й ефективно адаптуватися до змін і потреб клієнта.
Як ми можемо визначити, чи можна дійсно вважати користувацьку історію користувацькою історією?
Якщо ви здійснете пошук в інтернеті або деяких книгах, ви зможете знайти наступні шаблони для створення користувацьких історій:
- Як (назва ролі користувача / персона, Хто), я повинен мати можливість (вимога, необхідність, дія, Що), Щоб (мета, цінність для клієнта, Чому)
- Для того щоб (мета, цінність для клієнта, Навіщо), я як (назва ролі користувача / персона, Хто) хочу (вимога, необхідність, дія, Що)
Деякі люди називають такі шаблони шаблонами-зомбі. Чому? Вони є орієнтиром, рецептом, який підказує, як розставити слова, щоб створити свою історію, але це не гарантує, що вони будуть зрозумілими або що вони сприятимуть комунікації всередині команди. Дотримання шаблонів не є гарантією того, що ми створимо корисну користувацьку історію.
Хороша користувацька історія допомагає нам точно розповісти історію. Історія розповідається не самою фразою, а тим, що вона представляє, і команда обговорюватиме її, щоб знайти деталі всередині неї.
Щоб користувацька історія була корисною, рекомендується враховувати наступні моменти:
- Використовуйте правильну роль. Використання формулювання «Як користувач» не дає достатнього розуміння типу користувача, який виконуватиме дію. Рекомендується застосовувати техніку моделювання ролей користувачів, щоб включити правильну роль до користувацької історії.- Згідно з IIBA, моделювання ролей користувачів – це техніка, яка зосереджується на розумінні поведінки та потреб користувачів з метою розробки рішень, що відповідають їхнім вимогам. Вона передбачає визначення та опис різних ролей, які користувачі можуть мати під час взаємодії із системою, а потім створення користувацьких історій на основі цих описів.
– Визначте методом мозкового штурму кілька ролей, які можуть виконувати одну й ту саму дію.
– Згрупуйте визначені ролі та присвойте назву цій групі, утворивши таким чином згруповану роль.
– Приклад: Як користувач із преміум-підпискою, я повинен мати можливість увійти до застосунку, щоб користуватися додатковими інструментами, доступними лише для авторизованих користувачів.
- Розбиття Історій Користувача. Наведені нижче сценарії не передбачають однакового обсягу зусиль для виконання в рамках одного спринту. Історії мають бути достатньо малими та простими, щоб можна було завершити роботу максимум за один спринт.
– Як користувач з преміум-підпискою, я повинен мати можливість увійти до застосунку за допомогою методу автентифікації через обліковий запис Google, щоб я міг користуватися додатковими інструментами, доступними лише для авторизованих користувачів.
– Як користувач з преміум-підпискою, я повинен мати можливість увійти до застосунку за допомогою будь-якого методу автентифікації через соціальні мережі, щоб я міг користуватися додатковими інструментами, доступними лише для авторизованих користувачів.
– Згідно з IIBA, Розбиття Історій Користувача — це техніка в гнучкій розробці програмного забезпечення, яка використовується для поділу складних історій користувача на менші, більш керовані частини.
- Поділіться цінністю для клієнта. Немає сенсу створювати користувацьку історію, якщо вона не відображає реальну цінність, яку клієнт від неї очікує.
– Часто бізнес-аналітики або власники продукту не знають або не мають достатнього контексту щодо користувацьких історій на початку роботи. Тому вони схильні вказувати ту саму дію як цінність.
– Приклад: Як користувач із преміум-підпискою, я повинен мати можливість увійти в застосунок за допомогою методу автентифікації через мій обліковий запис Google, щоб мати змогу користуватися додатковими інструментами, доступними лише для авторизованих користувачів.
* У цьому прикладі цінністю для клієнта є не можливість користуватися застосунком, а можливість використовувати простий і швидкий метод автентифікації, який не залежить від пароля та електронної пошти. Найімовірніше, клієнт вже має активну сесію у своєму браузері, і такий підхід заощадить йому час. Проте це не згадується у формулюванні наведеної історії, чи не так?
- Забезпечте адаптивність під час розбиття: При розбитті користувацьких історій ми повинні переконатися, що змінюємо контекст і рівень цінності, що міститься в цій новій користувацькій історії.
– Приклад: Як користувач з преміум-підпискою, я повинен мати можливість входити в додаток за допомогою методу автентифікації через мій обліковий запис Google, щоб мені не потрібно було витрачати час на введення електронної пошти та пароля, якщо я вже витратив час на активацію свого облікового запису Google у браузері.
- Застосовуйте принцип INVEST: Користувацькі історії мають бути простими, об’єктивними, незалежними та чіткими. Тому користувацькі історії повинні відповідати принципу INVEST:- Незалежні (Independent): Користувацькі історії мають бути незалежними одна від одної, тобто одна історія не повинна залежати від завершення іншої для її реалізації. Вони мають бути функціональними одиницями, які можна реалізувати та доставити незалежно.
– Узгоджувані (Negotiable): Користувацькі історії мають бути узгоджуваними та допускати зміни у їхньому змісті або порядку пріоритетів залежно від потреб проєкту та користувачів.
– Цінні (Valuable): Користувацькі історії мають надавати цінність користувачу та бізнесу. Вони повинні бути зосереджені на вирішенні потреб.
– Оцінювані (Estimable): Користувацькі історії мають піддаватися оцінці з точки зору часу та ресурсів, необхідних для їх реалізації. Вони мають бути достатньо невеликими для точного оцінювання.
– Малі (Small): Користувацькі історії мають бути невеликими та керованими для реалізації в рамках однієї ітерації. Вони мають бути зосереджені на єдиній меті та не бути надмірно складними.
– Тестовані (Testable): Користувацькі історії мають бути тестованими та перевіреними за допомогою тестування. Вони повинні мати чіткі критерії прийняття, які дозволяють підтвердити їх реалізацію.
Дотримуючись цих рекомендацій, ви можете переконатися, що користувацькі історії є справді корисними та приносять цінність як замовнику, так і команді розробників.
Життєвий цикл користувацьких історій в Agile
Як зазначалося в попередньому розділі, користувацькі історії проходять процес еволюції та вдосконалення. Поширеною помилкою в Agile-командах є думка, що як тільки користувацькі історії створені, вони готові до виконання. Однак ці історії мають власний життєвий цикл у межах Agile-проєкту.
Створення
Це найбільш заплутаний момент для команд, оскільки рівень деталізації Користувацьких Історій у цей момент залежатиме від етапу Agile-процесу та ітерації, в якій ми перебуваємо. Створення користувацької історії всередині спринту, коли ми розуміємо, що чогось не вистачає, — це не те саме, що створення її під час етапу аналізу проблеми в проєкті.
Уточнення
Користувацькі історії завжди змінюватимуться та розвиватимуться, оскільки вони ґрунтуються на одній із цінностей Agile: прийнятті та визнанні змін. Користувацькі історії мають бути незалежними та відкритими для переговорів; якби ми створювали їх негнучко, ми не змогли б удосконалювати їх протягом усього проєкту. На етапі уточнення, будь то на рівні Q-планування або планування спринту, ми усвідомимо, що можемо створювати більше користувацьких історій шляхом модуляризації початкової історії. У результаті ми отримаємо більш уточнену історію, але з новими історіями, які також будуть уточнені в певний момент, що може призвести до появи інших, і так далі.
Закриття
Як тільки команда починає працювати над ітерацією, історія оцінена і жодні деталі не відсутні, можна стверджувати, що після виконання критеріїв приймання та завершення розробки й тестування історія є завершеною і може бути закрита. Цінність цієї історії буде негайно відображена для замовника, як тільки ці зміни будуть інтегровані у реліз, запланований командою.
Робота з користувацькими історіями на різних рівнях Agile
Користувацькі історії на різних рівнях Agile мають різні назви.
Іноді в наших agile-командах ми зосереджуємося на баченні команди, але не усвідомлюємо, що в agile існує багато способів управління організаційними стратегіями від найвищого рівня до рівня команди. Це приклад Scaled Agile Framework (SAFe) 6.0.
Рівень портфеля (Епіки)
В Agile-організації існує етап, на якому керівники організації збираються разом, щоб обговорити ініціативи, над якими потрібно працювати — як нові, так і вдосконалення вже наявних. Коли організація вирішує, які дії вжити та які ініціативи реалізувати, вони оформлюються у вигляді епіків.
Приклад: Як клієнт, я хочу керувати своїми банківськими рахунками з телефону, щоб мати можливість перевіряти баланс у будь-який час у режимі реального часу та переказувати кошти за потреби.
На цьому рівні ми говоримо про портфель ініціатив компанії, одна з яких — необхідність створення мобільного додатку, щоб клієнти не залежали від веб-сайту при управлінні своїми банківськими рахунками.
Рівень рішення (можливості)
На цьому рівні ми вже знаємо, над якою організаційною ініціативою працюватимемо. Тепер представляються «рішення», які ця ініціатива матиме для клієнта. Ці рішення поділяються на функції, які також будуть незалежними одна від одної та додаватимуть цінність для клієнта після того, як Agile-команда впровадить ці зміни.
Приклад: Як клієнт, я хочу мати можливість надсилати та отримувати гроші зі своїх банківських рахунків на інші банківські рахунки незалежно від банку-отримувача через мій телефон, щоб я міг оплачувати кредитні картки, страховки або давати дітям гроші на навчання.
Приклад: Як клієнт, я повинен мати можливість вносити та знімати кошти зі своїх ощадних рахунків у будь-який час доби з мобільного телефону, щоб мені не доводилося чекати певного часу для використання грошей, які є на моїх ощадних рахунках, і я міг переказувати їх в інші місця або використовувати для оплати рахунків.
У цих прикладах ми бачимо, що нам потрібно буде створити модуль банківських переказів, а також модуль управління ощадними рахунками. На цьому рівні ми починаємо розбивати цю організаційну ініціативу, цю масштабну ініціативу, на модульні рішення для наших клієнтів. З їхньої точки зору, одне не залежить від іншого, тому ми можемо надати їм модуль переказів без запуску частини з ощадними рахунками на початку.
Рівень програми (Функції)
На цьому рівні ми розділяємо рішення на функції, які також будуть незалежними одна від одної та створюватимуть цінність для клієнта окремо. Клієнт зможе надсилати гроші, не маючи обов’язково можливості отримувати їх на свої рахунки. Все залежатиме від пріоритизації, визначеної Власником Продукту.
Приклад: Як клієнт, я повинен мати можливість переказувати гроші з одного банківського рахунку на інший, незалежно від банку-отримувача, зі свого телефону, щоб я міг оплачувати кредитні картки, страховки або давати дітям гроші на навчання.
Приклад: Як клієнт, я повинен мати можливість переказувати кошти з одного банківського рахунку на інший, незалежно від банку відправника, зі свого телефону, щоб я міг розподіляти свої кошти між різними банківськими рахунками для заощаджень або інвестицій.
Приклад: Як клієнт, я повинен мати можливість поповнювати кошти зі своїх ощадних рахунків у будь-який час доби з мобільного телефону, таким чином мені не доведеться чекати певного часу, щоб скористатися грошима на своїх ощадних рахунках, і я зможу переказувати їх в інше місце або використовувати для оплати рахунків.
Як ви можете бачити, ми розбиваємо рішення на менші рішення (функції), кожне з яких надаватиме цінність клієнту незалежно. Клієнт зможе відправляти гроші, не обов’язково маючи можливість отримувати їх на свої рахунки. Все залежатиме від пріоритетів, визначених власником продукту.
Рівень команди (історії користувача)
На цьому рівні команда працює безпосередньо над завданнями, які вона може виконати в межах максимум одного спринту. Команда вже знає, що потрібно робити, оскільки сесії планування та уточнення вже відбулися.
Приклад: Як головний користувач ощадного рахунку компанії, я повинен мати можливість переказувати кошти з ощадного рахунку на поточні рахунки компанії за допомогою мобільного телефону, щоб кошти були доступні для оплати послуг компанії, таких як електроенергія або телефон.
Приклад: Як користувач рівня 2, я повинен мати можливість переказувати кошти з одного мого поточного рахунку на інший всередині банку з мого мобільного телефону, що дозволить мені здійснювати онлайн-покупки за допомогою пов’язаної картки.
Як видно з попередніх пунктів, на кожному рівні організаційного планування ми маємо користувацькі історії, які мають дуже схожий шаблон написання, проте цінність, яку вони надають замовнику, є абсолютно різною, не кажучи вже про рівень зусиль, необхідних для виконання завдань, пов’язаних із вимогою.
Як виглядають користувацькі історії в реальному житті поза теорією?
У повсякденному житті користувацьких історій (тих фраз, які ми розглядали раніше) недостатньо для того, щоб команда розуміла всю цінність і знала, що робити для досягнення мети. Історії включають додаткові сценарії та критерії, які допомагають нам визначити, чи готова історія до розгляду командою, як будуть проводитися необхідні тести та чи відповідають докладені зусилля очікуванням клієнта. Тому ми обговоримо 3C.
Три «С»: Картка, Розмова та Підтвердження
У 2001 році Рон Джеффріс запропонував модель «Картка, Розмова, Підтвердження» (Card, Conversation, Confirmation), щоб відрізнити «соціальні» призначені для користувача історії від «документальних» практик вимог, таких як варіанти використання.
Картка
Це «Хто», «Що» та «Навіщо». Користувацькі історії записуються на картках. Картка не містить усієї інформації, що складає вимогу. Натомість на картці міститься достатньо тексту для ідентифікації вимоги та нагадування всім учасникам, про що йдеться в історії. Картка є символом, що представляє вимогу, і використовується під час планування. На ній зазначаються пріоритети та витрати. Найчастіше вона передається програмістам, коли історія запланована до реалізації, і повертається замовнику після завершення роботи над нею.
Розмова
Це схоже на розповідь історії, що стоїть за карткою, де ми ставимо запитання і разом розмірковуємо. Сама вимога передається від замовника до програмістів через розмову: обмін думками, поглядами та відчуттями. Ця розмова відбувається з часом, особливо під час оцінювання історії (зазвичай під час планування релізу) і знову на нараді з планування ітерації, коли історія запланована для реалізації. Розмова здебільшого є усною, але може доповнюватися документами. Найкращими доповненнями є приклади; найкращі приклади є виконуваними. Ми називаємо ці приклади підтвердженням.
Підтвердження
Це етап уточнення, на якому ми узгоджуємо очікування замовника та визначаємо критерії приймання. Незалежно від того, скільки обговорень проводиться або скільки документації створюється, ми не можемо бути повністю впевнені в тому, що потрібно зробити. Третя літера «C» у ключових аспектах призначення користувача забезпечує підтвердження, якого нам так потрібно. Цим компонентом є приймальний тест.
Підтвердження, яке забезпечується приймальним тестуванням, і є тим, що уможливлює простий підхід із картками та обговореннями. Коли розмова про картку зосереджується на деталях приймального тесту, замовник і програміст вирішують остаточні деталі того, що потрібно зробити. Наприкінці ітерації, коли програмісти демонструють, що приймальні тести працюють коректно, замовник переконується, що команда може і справді надасть те, що потрібно. Підтвердження у вигляді приймальних тестів — це те, що підтримує постійний рух життєвого циклу проєкту. А цей життєвий цикл і є тим, що підтримує проєкт живим і працездатним.
Приклад історії з використанням трьох «К».
Картка:
«Як клієнт із VIP-підпискою, я хочу мати можливість шукати товари в інтернет-магазині на основі моїх звичок покупок за останній місяць, щоб я міг швидко знайти те, що мені потрібно, не використовуючи багато критеріїв пошуку.»
Розмова:
Зустріч команди з Product Owner, розробниками та іншими членами команди для обговорення та уточнення деталей щодо користувацької історії.
- Власник продукту: У цій користувацькій історії ми хочемо, щоб клієнти з VIP-підпискою мали можливість шукати продукти на основі своїх звичок покупок за останній місяць.
- Розробник: Яку інформацію з купівельних звичок слід враховувати для відображення релевантних результатів? Категорії, ціни, бренди?
- Власник продукту: Так, давайте врахуємо категорії, ціни та бренди товарів, придбаних за останній місяць, щоб пропонувати релевантні результати VIP-клієнтам.
- Дизайнер: Чи варто нам додати можливість для VIP-клієнтів увімкнути або вимкнути цю функцію персоналізованого пошуку?
- Власник продукту: Гарна ідея. Давайте переконаємося, що VIP-клієнти можуть вибирати, чи хочуть вони використовувати цю функцію, чи виконувати звичайний пошук.
Підтвердження:
Визначення готовності (Definition of Ready):
- Вимоги користувацької історії були обговорені та уточнені.
- Критерії відображення результатів пошуку на основі звичок покупок за останній місяць було визначено.
- Погоджено додати опцію для увімкнення або вимкнення функції персоналізованого пошуку.
Визначення завершеності (Definition of Done):
- Функцію персоналізованого пошуку для VIP-клієнтів було впроваджено.
- Результати пошуку базуються на категоріях, цінах і брендах товарів, придбаних за останній місяць.
- VIP-клієнти можуть вмикати або вимикати функцію персоналізованого пошуку.
Критерії прийняття (Aceptance Criteria):
- VIP-клієнти можуть виконувати пошук на основі своїх звичок покупок за останній місяць.
- Результати пошуку відображаються відповідно до категорій, цін і брендів товарів, придбаних за останній місяць.
- Клієнти VIP можуть вмикати або вимикати функцію персоналізованого пошуку.
Приймальні тести (Acceptance Tests):
- Перевірте, що VIP-клієнт може виконати пошук на основі своїх звичок покупок за останній місяць і отримати релевантні результати.
- Перевірте, що результати пошуку відображаються відповідно до категорій, цін та брендів товарів, придбаних за останній місяць.
- Забезпечте можливість для VIP-клієнтів вмикати або вимикати функцію персоналізованого пошуку.
Висновок
Протягом усього мого досвіду роботи з agile-проєктами я зрозумів, що користувацькі історії є основоположними для забезпечення успіху та надання цінності нашим клієнтам. У цій статті я поділився з вами своїми знаннями про життєвий цикл користувацьких історій, важливість їх адаптації до різних рівнів agile-методології та про те, як перевести їх з теорії в практику.
Крім того, ми дослідили три «С»: Картка, Розмова та Підтвердження, які є необхідними для ефективного розуміння та передачі очікувань клієнтів, а також для забезпечення узгодженості команди та відданості цілям проєкту. На практичних прикладах ми побачили, як застосовувати ці концепції в реальних ситуаціях і як вони можуть вплинути на ефективність роботи гнучкої команди.
Для мене робота з добре структурованими користувацькими історіями та підтримка постійної комунікації були вирішальними у адаптації до змін і наданні рішень, які справді додають цінність нашим клієнтам. Я сподіваюся, що, поділившись цими думками, я зможу допомогти іншим фахівцям і командам впоратися з власними agile-проєктами з більшою впевненістю та успіхом.
Зрештою, найважливіше – щоб наші клієнти відчували задоволення та бачили цінність у нашій роботі. Застосовуючи принципи, розглянуті в цій статті, та постійно адаптуючись до мінливих потреб ринку, ми зможемо продовжувати зростати та навчатися разом у прагненні до досконалості в гнучкому управлінні проєктами.
Оригінальна стаття – User stories in the agile world, переклад та ревью – Іван Вільчавський. Зображення з оригінальної статті.