Розбиття складної історії на початку проекту

Я намагаюся впоратися з гнучким управлінням проектами (з Pivotal Tracker), але продовжую опинятися в стінах, намагаючись визначити перші кілька історій проекту. Візьмемо для прикладу цю дуже просту історію:

"Користувач повинен мати можливість тегів на продукт"

Якщо припустити, що я вже визначив "продукт" в іншому місці, ця історія, можливо, передбачає написання поліморфної системи мітки під кришкою, після завершення цього системного ідентифікатора вдасться нарешті додати можливість тегувати продукт.

Моя проблема полягає в кількості роботи, прихованій у цій історії. Я можу визначити завдання, щоб зробити історію, але розповіді в цілому повинні працювати 1-2 дні? Я не думаю, що історія просто розкриває вершину айсберга, але це єдина частина, що стосується Користувача.

Як ти подолаєш таку річ? Які найкращі практики?

ОНОВЛЕННЯ 25/08 Дякую всім за ваші вказівки, я прийняв усі поради щодо визначення історії. Зараз я переходжу на Jira Grasshopper, який має кращу підтримку для завдань в рамках історій (завдання, оцінки тощо) та відстеження завдань розвитку, коли спринт розпочнеться.

Якщо вам потрібно, щоб ваші історії були від 1 до 2 днів роботи розробника кожен, можливо, вам слід розбити кожну історію на конкретні завдання користувача, які займають від 1 до 2 днів роботи розробника.

Розглянемо наступне "історія користувача".

Користувач повинен мати можливість отримати рахунок від придбаного товару.

Подумайте, що саме пов'язане з дизайном бази даних, щоб надати користувачеві цю можливість. Вам потрібна таблиця клієнтів, таблиця заголовка рахунків-фактур та таблиця позицій рахунків-фактур, і ми ще навіть не говорили про прийняття платежів.

Насправді розповіді користувачів не такі прості. Повні користувацькі історії включають в себе ознайомлення з кроками користувача:

• Користувач кладе товар у кошик
• Користувач вказує кількість
• Користувач вказує тип доставки

і так далі. Коротше кажучи, вам потрібно розбити свої розповіді користувачів на більш точні деталі.

Історії не повинні бути, "1-2 дні працюють". У розділі Scrum розповіді зазвичай оцінюються за допомогою Story Points, відносної системи розміру. Якщо ви використовуєте плани планування покерних історій, вам присвоюється бальне значення - час, який ця історія потребує на реалізацію, залежить від швидкості встановлення вашої команди.

Якщо ви вважаєте, що історія приховує складність (ви можете назвати це епічною історією), вам слід розбити її на більш дрібні історії. Переконайтесь, що нові історії відповідають критеріям ІНВЕСТУ .

Але ви можете переоцінити це; тут застосовується принцип XP YAGNI . Щоб бути ясним, ви не повинні реалізовувати "поліморфну ​​систему мітки під кришкою", якщо вона вам справді не потрібна. Вже тоді це слід розробити шляхом вдосконалення існуючої системи, яку ви розробили з хорошим набором тестів.

Якщо ви впевнені, що вам потрібна ця складна система тегів, вам слід назвати складність в окремих історіях. Майк Кон описує підхід до дизайну як " навмисний, але все ще виникаючий "

Здається, що ви плутаєте історії та завдання.

Історія користувача

Історія користувача - це повна "особливість", яка при додаванні до продукту надає більшої цінності продукту.

Історія користувача не повинна бути більшою, ніж вона може бути реалізована під час спринту . Під час першої частини планування спринту ви визначаєте, над якими історіями користувачів ви хочете працювати під час спринту. Мета спринту - завершити ці історії користувачів, тим самим додавши продукту більше значення.

Завдання

Під час другої частини планування спринту розробники ділять історію на завдання . Завдання - це завдання розвитку. Вони можуть бути такими, як "Додавання стовпця до бази даних", "Розширення служби x" тощо. Завдання не повинно бути більшим, ніж воно може бути виконане за один день.

Під час щоденної розмови ви оцінюєте хід виконання цих завдань. Якщо завдання виконується вже не один щоденний розгляд, це забирає занадто багато часу, і ви, як команда, несете відповідальність за вирішення цієї ситуації.

Пам’ятайте, що історії користувачів представляють цінність бізнесу для власників акцій. Власники акцій повинні бути зацікавлені у виконанні розповідей користувачів, а не завдань.

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

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

Епос

Якщо історія користувача більша, ніж ви думаєте, ви можете завершити її в одному спринті, це називається епопеєю. Його потрібно розділити на кілька менших історій користувача, перш ніж ви, як команда, зможете над ним працювати.

Пам’ятайте, що історія користувача додає цінність кінцевому користувачеві, тому розділення епосу на історію "передній" та "бек-енд" не є правильним способом. Додавання нової функції нової функції само по собі не забезпечує значення для кінцевих користувачів.

Розділити епос на користувацькі історії, керовані протягом часового періоду спринту, не завжди легко, коли ви не відчуваєте цього.

Використання ключового трекера

Я думаю, що Pivotal Tracker - чудовий інструмент для відстеження історій користувачів. Але це не інструмент scrum як такий, і спосіб, по якому scrum вчить ділити історії на завдання, не легко справляється з основним трекером. Ви можете включити можливість додавання завдань до історій користувача. Але якщо ви керуєте проектом за допомогою scrum, я б запропонував використовувати білу дошку та наліпки для відстеження ходу завдань під час спринту.

Завдання дизайну впровадження системи поліморфної мітки - це добре, але все ж слід зосередитись на впровадженні функцій, які хоче замовник. Це може означати, що, історія дрібнозернистого користувача - історія дрібнозернистих користувачів - ваша система з часом перетворюється на поліморфну ​​систему маркування. У будь-якій точці подорожі, однак у вас повинна бути система, що складається з безлічі дрібних і перевіряються функцій, описаних колекцією розроблених вами історій користувачів.

У цьому випадку це здається, що "Позначення продуктів" у вашій системі може бути епічним, тобто чимось набагато більшим, ніж окрема історія користувача, і її можна з невеликим зусиллям розбити на кілька менших історій. Отримавши неабияку кількість художньої ліцензії, я можу придумати такі Історії користувачів, які можуть бути приблизно застосовні до ваших вимог:

• Як системний адміністратор, я хочу заповнити систему деякими дійсними тегами, щоб користувачі мали деякі значення для вибору при першому використанні функції тегування.
• Як користувач системи, я хочу мати змогу шукати продукт за назвою, щоб потім позначити його тегом.
• Як користувач системи, я хочу мати можливість прочитати опис продукту, щоб я міг вирішити, які теги він повинен мати.
• Як користувач системи, я хочу мати можливість бачити зображення продукту, щоб я міг вирішити, які теги у нього повинні бути.
• Як користувач системи, я хочу мати можливість приєднати один тег до одного продукту.
• Як користувач системи, я хочу мати можливість видалити один тег із одного продукту.
• Як користувач системи, я хочу мати можливість приєднати один тег до декількох продуктів.
• Як користувач системи, я хочу мати можливість додавати кілька тегів до одного продукту.
• Як системний адміністратор я хочу побачити чіткий список тегів, які використовуються в системі, щоб я міг вирішити, чи є будь-який з них дублікатами.
• Як системний адміністратор я хочу консолідувати дублювані теги.

... і я міг би продовжувати.

Я сумніваюся, що будь-яке з них буде настільки реалістичним, що ви будете використовувати їх, але, сподіваємось, вони ілюструють таку деталь, до якої можна звернутися зі своїми історіями користувачів.

Якщо історію користувача дійсно неможливо розділити на будь-які менші історії, і ви все ще вважаєте її занадто великою, щоб спробувати реалізувати за один раз, тоді ви можете розділити її на вертикальні фрагменти. Це методика, яка означає надання лише частини функції під кожною історією користувача, але кожна частина є тестовим фрагментом через усі відповідні шари технології, наприклад, для веб-сайту це може означати зміну шарів бази даних, додатків та інтерфейсу користувача. Уникайте, коли одна історія користувача буде працювати з базою даних, іншою для додатків та іншою для користувальницького інтерфейсу, оскільки вони не підлягають індивідуальній тестуванню.

Отримавши ще більшу мистецьку ліцензію, я можу розділити "Як користувач системи я хочу мати змогу приєднати один тег до одного продукту". на наступні вертикальні зрізи:

• Як користувач системи, що дивиться на один продукт, я хочу мати змогу переглянути список тегів, щоб я міг вирішити, який із них застосувати.
• Як користувач системи, що дивиться на окремий продукт, вирішивши застосувати тег до цього продукту, я хочу мати змогу застосувати його.
• Як користувач системи, що дивиться на один продукт, застосувавши тег до цього продукту, я хочу на екрані повідомлення з підтвердженням, що воно успішно збереглось.

Кожен із них є перевіреним - якщо не особливо цінний сам по собі.

Є книги, написані з єдиною метою - з’ясувати правильний спосіб опису та розбиття ваших вимог. Тож це непросте завдання.

Часто я знаходжу команди розробників, які прагнуть до складних рішень замість найпростіших. Це може бути пов’язано з самою історією або тому, що команда хоче вирішити надто складне рішення, яке не тільки вирішує цю історію, але й закладає основу для історій x, y та z. Це хороший намір, але розширює сферу, де таку саму роботу можна зробити за меншої роботи. Завжди важко судити про те, скільки дизайну потрібно вкласти в історію, щоб не зруйнувати майбутні історії, зіпсувавши дизайн. Це рішення має прийняти команда.

Як власник продукту, ви можете впливати на це, лише розбиваючи історії на більш дрібні фрагменти. Ви повинні запитати себе: чи історія є найменшим рішенням, про яке ми можемо придумати зараз? Чи можемо ми розбити його на зменшені набори функцій, які колись стануть "великою гнучкою системою тегів, яку я завжди хотів". Ви можете почати із системи тегів лише для одного тегу, а потім розширити його, щоб включити список попередньо вибраних тегів, а потім дозволити користувачеві визначати теги тощо.

Для команди розробників це зводиться до: Чи можемо ми знайти більш простий підхід до втілення історії, але все-таки мати надійну архітектуру, яка сьогодні виконує завдання, не загрожуючи майбутнім можливостям.

Якщо ви готові прийняти проміжні рішення, а команда розробників також намагається запропонувати найпростіше, але хороше рішення, то, напевно, ви знайдете миле місце, де розмір історій, які ви хочете зробити, є правильним (чим менше, тим краще) . Це не означає, що у вас є лише невеликі історії. Деякі є більшими за інших, це лише факт, який потрібно прийняти, або якщо вони занадто великі, а потім розбити історії на більш дрібні частини.