Причини розділити історію і писати менші історії
- Швидкий зворотній зв’язок – команда, яка працює з невеликими історіями і завершує їх за 1-3 дні, може отримати зворотній зв’язок від власника продукту та зацікавлених сторін, не чекаючи закінчення спринту.
- Швидке виправлення помилок – Важливо відзначити, що розробник чудово пам’ятає код, який він написав за останні 24 години. Якщо протягом цього часу він отримає будь-які коментарі від інших членів команди або виявляться якісь баги, він зможе виправити все набагато швидше.
- Відкладення менш цінної роботи — коли історії належним чином розділені на кілька менших, найцінніші історії можуть потрапити в топ, а решта – в нижню частину Беклогу продукту. Скрам-команда не витрачає час на виконання чогось, що має меншу цінність з точки зору власника продукту.
- Кращі прогнози – припустимо, що команда розробників має середню швидкість виконання (velocity) 17 сторі поінтів за Спринт. Зазвичай вони працюють з великими історіями по 8 і 13 сторі поінтів. Існує велика ймовірність того, що до кінця Спринту одна з цих історій не буде завершена. Таким чином, швидкість роботи сильно коливається від Спринту до Спринту (від 8 до 21 і навіть більше). Якби команда розробників мала невеликі історії, скажімо, по 3 сторі поінти кожна, ці коливання були б менш помітними.Отже, команда розробників могла б скласти більш надійний прогноз під час планування спринту та планування релізу для Власника Продукту.
- Більше довіри – Команда розробників, яка стабільно завершує в середньому однакову кількість історій від Спринту до Спринту, стає більш передбачуваною для Власника продукту та стейкхолдерів.
- Кращий настрій —завершення 6-10 користувацьких історій у кожному спринті зміцнює дух команди розробників, тому що людям подобається відчуття досягнення. Подумайте, які ваші улюблені футбольні матчі – ті, що закінчуються з рахунком 0:0 чи 3:2?
- Економія часу на оцінювання – якщо команда розробників доставляє 6-10 невеликих історій під час спринту, дуже ймовірно, що вони приблизно однакові за розміром. Це означає, що з часом команді розробників не доведеться оцінювати кожну історію окремо, а лише підрахувати їхню кількість.
- Мінімізація ризиків – Краща розбивка на частини означає більш детальний аналіз елементів. Таким чином, велика ймовірність того, що команда розробників виявить і зменшить ризики, які інакше виникли б під час майбутнього спринту. Як кажуть, попереджений – значить озброєний.
- Кращий розподіл роботи в рамках Спринту— невеликі історії в Спринті сприяють кращому розпаралелюванню роботи, а продуктивність команди, як правило, підвищується.
До теми: Як писати хороші User Stories
Способи розділення історії на частини
Стратегія 1: Розподіл за етапами робочого процесу
Якщо PBI передбачають певний робочий процес, його зазвичай можна розбити на окремі етапи. Візьмемо PBI для процесу замовлення в інтернет-магазині:
Приклад — Як клієнт, я хочу оплатити товари в моєму кошику, щоб отримати їх з доставкою додому
Враховуючи досить стандартну процедуру замовлення, ми можемо виділити наступні кроки:
- Як клієнт, я можу ввійти за допомогою свого облікового запису, тому мені не потрібно щоразу повторно вводити свою особисту інформацію;
- Як клієнт, я можу переглянути та підтвердити своє замовлення, тож я можу виправити помилки до оплати;
- Як клієнт, я можу оплатити своє замовлення банківським переказом, щоб підтвердити своє замовлення;
- Як клієнт, я можу оплатити своє замовлення за допомогою дебетової/кредитної картки, щоб підтвердити своє замовлення;
- Як клієнт, я отримую рахунок-фактуру разом зі своїм замовленням, тому я маю підтвердження своєї покупки.
Стратегія 2: Розбиття на бізнес-правила
Приклад — Як клієнт, я можу придбати товари у своєму кошику, щоб отримати їх доставку додому.
Враховуючи досить стандартну процедуру замовлення, можна виділити наступні “бізнес-правила”:
- Як продавець, я можу відхилити замовлення на суму менше 10 євро, оскільки вони не є прибутковими.
- Як продавець я можу відмовити клієнтам за межами ЄС, оскільки витрати на доставку роблять ці замовлення невигідними
- Як продавець я можу автоматично скасовувати замовлення, за які не отримав оплату протягом 48 годин, щоб знову продати їх іншим клієнтам
Стратегія 3: Розподіл за критеріями прийняття
Ознайомтеся з критеріями прийняття; якщо вона надто складна і деякі її частини можна виокремити і розробити як незалежну історію користувача, зробіть це саме так.
Приклад: Як працівник організації, я хочу самостійно зареєструватися на навчальні програми, щоб відвідувати тренінги та підвищувати кваліфікацію.
Буде цікаво: Гайд по User Stories для Junior BA
Критерії прийняття:
Всі співробітники повинні бути проінформовані про навчальні програми по електронній пошті.
Співробітники повинні мати можливість вносити свої дані через форму для реєстрації.
Після успішної реєстрації має бути надіслано підтвердження на пошту.
У наведеному вище сценарії кожен з критеріїв може бути позначений як окрема історія користувача.
Стратегія 4: Розподіл за невизначеними елементами
Часто ми помічаємо, що історії користувача містять дещо розмиті терміни. Це нормально, користувацькі історії мають бути “обговорюваними” (див. абревіатуру INVEST Білла Вейка). Ці розпливчасті терміни часто призводять до можливих вертикальних зрізів.
Приклад історії: Як людина, яка часто подорожує, я хочу, щоб погодний додаток зберігав дані про погоду за кілька днів і відображав їх в автономному режимі, щоб я міг бачити прогноз у місті призначення, коли там немає мобільного зв’язку.
Як колишній тестувальник, моя перша реакція на цю історію: “Що ви маєте на увазі під “кількома”? Це розпливчастий термін. Так само, як і “відображення” – як я дізнаюся, що я використовую збережені дані, а не поточні і т.д.? Обидва ці терміни дають можливість розділити дані за допомогою інкрементного підходу. Наприклад, ми можемо отримати наступні зрізи, якщо дуже конкретизуємо частину відображення:
- Створіть новий елемент інтерфейсу, який відображає позначку часу для останнього відомого знімка погодних даних (поки що не обов’язково мати офлайн-режим).
- Якщо телефон не підтримує зв’язок, додайте до елемента інтерфейсу “Наразі офлайн”.
- Підтримувати дані прогнозу для останньої відомої погоди в автономному режимі.
Стратегія 5: Розподіл за сполучниками
Сполучники – це слова, які є з’єднувальними елементами: І (AND), АБО (OR), КОЛИ (WHEN), ЯКЩО (IF), наприклад, і коли вони присутні в історії користувача, вони часто є досить очевидними можливостями для створення вертикального зрізу.
Приклад історії: “Як постійний користувач, я обираю опцію збереження номера кредитної картки та обираю його для подальших цілей, щоб не вводити всі дані щоразу”.
Зверніть увагу, що твердження “Я хочу” в цій історії користувача складається з двох частин: зберегти номер і вибрати його для майбутніх цілей. Це дуже легко розділити на дві частини:
- Зберегти номер кредитної картки в моєму профілі
- Запропонувати можливість використовувати збережений номер кредитної картки при покупці
Деякі з інших методів нарізки історії засновані на:
- Ролях
- Параметрах вводу
- Параметрах даних
- Тестових кейсах
- Сумісності з браузером
- Щасливому і нещасливому Флоу
- на принципі “від простого до складного”
Оригінальна стаття – Why and How to Split User Stories, переклад – Олександра Горлович, ревью – Іван Вільчавський. Зображення створене за допомогою DALL-E у ChatGPT.