INVEST (Ефективні User Stories та PBI)

Білл Вейк придумав абревіатуру INVEST, щоб допомогти запам'ятати правила написання ефективних користувацьких історій: Незалежні (Independent), Обговорені (Negotiable), Цінні (Valuable), Оцінювані (Estimatable), Невеликі (Small) та Перевірювані (Testable).

Для проектів Agile розробки ПЗ також це стосується всіх Product Backlog Item і це не тільки User Stories  (скорочено PBI). Такі PBI можуть бути використані в Scrum беклозі, Kanban дошці або XP проекті.

Незалежність (Independent PBI)

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

Незалежність відрізняється від логічного порядку розвитку подій. Під незалежністю ми маємо на увазі особливості історії. Наприклад, скажімо, ми підтримуємо оплату кредитними картками і хочемо підтримувати оплату American Express, Mastercard і Visa. Якщо у нас є історія для MasterCard та інша для Visa, то оцінки будуть залежати від того, яку з них ми зробимо першою, тому що реалізація іншої історії буде відносно простою. Тому ми хотіли б внести ясність і мати одну історію, що представляє "надання основного варіанту оплати з використанням VISA". Інші історії можуть бути змінені на "надання можливості вторинного платежу з використанням American Express".

Обговорені (Negotiable PBI)

Історія повинна бути короткою. Це не детальний контракт. Її мета - заохотити постійну розмову та переговори між замовником та розробниками щодо обсягу робіт.

Згідно з методологією Agile, поки PBI знаходиться в беклоге продукту, він може бути переписаний або навіть відкинутий, залежно від бізнес, ринкових, технічних або будь-яких інших вимог членів команди.

Цінні (Valuable PBI)

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

Представлення команді "Чому" (цінність), а не тільки "Що" (функція), може викликати різні ідеї альтернативних функцій, які легше або швидше розробити, але при цьому досягти тієї ж мети і забезпечити ту ж саму бізнес-цінність.

Крім того, оскільки історія надає частину функціональності, клієнт може з'ясувати, скільки коштує ця функціональність, а потім вирішити, чи потрібна вона йому.

Також пам'ятайте, що не вся цінність є грошовою. Зменшення ризику - це цінність. Так само, як і навчання або придбання знань.

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

Оцінювані (Estimatable PBI)

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

Невеликі (Small PBI)

Намагайтеся утримувати розмір PBI, як правило, в межах кількох людино-днів і максимум кількох людино-тижнів (гарне емпіричне правило полягає в тому, що будь-яка окрема позиція Product Backlog не повинна займати більше 50% ітерації; наприклад, одна позиція не займе більше 5 днів для 2-тижневого / 10-денного спринту).

Те що виходить за межі цього діапазону, слід вважати занадто великим. Щоб оцінити його з достатнім рівнем достовірності - такі великі PBI можна назвати "Епіками", де для виконання Епіки знадобиться більше однієї ітерації.

Немає жодних проблем у тому, щоб почати з епічних PBIs, доки вони не будуть розбиті, коли наближається час для їх розміщення в ітераційному бэклозі. Це реалізує концепцію аналізу Just In Time Lean-розробки програмного забезпечення.

Перевірювані (Testable PBI)

Історії повинні мати можливыть бути протестовані, щоб допомогти визначити повноту. Історія повинна мати критерії прийнятності. Критерії прийнятності повинні бути об'єктивними.

Уникайте використання таких критеріїв, як простий у використанні, швидкий або без помилок.

Намагайтеся писати критерії, які можна виміряти та протестувати (в ідеалі - автоматизовано). Наприклад, перевірте, що перевірка платежу відповідає за 1 секунду або менше принаймні в 95% випадків.

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

Що допрацювати в статті:
- посилання на інши методології;