User Stories

Шістнадцять історій, як їх пишуть команди, — що не так із кожною і як її переписати

Нікому не потрібне ще одне пояснення «Як…, я хочу…, щоб…». Допомагає інше: побачити історії, якими напхані справжні беклоги, поруч із версією, що працює. Ось шістнадцять — для кожної сказано, що не так, і дано переписаний варіант. У більшості беклогів є кілька з них, а в деяких — усі шістнадцять. Наступні розділи посилаються на них за номерами.

Картка, розмова, підтвердження — що таке історія насправді

Історії вийшли з Extreme ProgrammingExtreme Programmingagile-метод, що починається з інженеріїAgile-методологія кінця 1990-х, збудована навколо інженерних практик: розробка від тестів, парне програмування, безперервна інтеграція, рефакторинг і невеликі часті релізи. Від неї походить більшість того, що тепер називають технічною гнучкістю, і команда, яка переймає події Scrum без цих практик, зазвичай бачить, як її спринти сповільнюються.Усі терміни — методу, який Кент Бек і його колеги виробили наприкінці 1990-х, здебільшого на зарплатному проєкті в Chrysler. Потребу записували на картці одним-двома реченнями, а деталі з’ясовували в розмові із замовником, який сидів поруч із командою. Картка була малою навмисно: специфікація на неї не вміщалася, тож ніхто не міг удавати, що вона нею є.

30 серпня 2001 року Рон Джеффріс назвав три частини. Card тримає «рівно стільки тексту, щоб ідентифікувати вимогу й нагадати всім, що це за історія». Conversation — місце, де вимога справді переходить від замовника до програмістів, із часом: коли історію оцінюють і знову, коли її планують. Confirmation — приймальний тест: як замовник зрозуміє, що команда зробила потрібне. Потрібні всі три. Картка без розмови — це погано написана специфікація; розмова без підтвердження — суперечка, що чекає на огляд.

Звичного шаблону — «Як [роль], я хочу [можливість], щоб [вигода]» — в ідеї не було. Це був внутрішній стиль лондонської компанії Connextra, яким вона поділилася зі спільнотою XP 2001 року, а книжка Майка Кона 2004 року зробила його стандартом за замовчуванням. Це добрий стандарт. Але необов’язковий, і три альтернативи варто знати.

Деталі з’являються вчасно, не раніше

Коли історію пишуть, її навмисно недоописують, і вона обростає деталями, піднімаючись до верху беклогу. Пункти на наступні один-два спринти — малі, з критеріями приймання й уже обговорені. Пункти на найближчі місяці — фічі з приблизним розміром. Усе нижче — епіки в один рядок. Роман Піхлер називає беклог такої форми DEEP: detailed appropriately, estimated, emergent, prioritised — деталізований доречно, оцінений, такий, що розвивається, і впорядкований.

Така форма — економічне рішення, а не стиль. Деталі, написані для низу списку, написано для плану, що зміниться, перш ніж хтось почне будувати, і їх доведеться переписувати або тихо ігнорувати. Брак деталей угорі означає, що спринт починається з питань, на які ніхто не може відповісти. Деякі команди захищають верх Definition of Ready — переліком умов, який історія мусить пройти, перш ніж потрапити в спринт. Як нагадування це допомагає. Як шлагбаум, про що застерігає Майк Кон, — перетворює розмову назад на передачу документа, а команду — назад на етап водоспаду.

Критерії приймання — третє C

Третє C пропускають найчастіше (рядок 9). Критерії приймання — це не бюрократія, а відповідь на «як ми зрозуміємо?», погоджена до початку роботи, а не з’ясована в суперечці на огляді. Це ще й найдешевша профілактика багів: більшість того, що тестувальник знаходить за першу годину, — випадки, яких ніхто не обговорював.

Два формати покривають майже все. Чекліст — простий перелік умов, які мають виконуватися: швидко пишеться, легко читається і є правильним вибором за замовчуванням для простих історій. Given/When/Then описує початковий стан, дію й очікуваний результат. Ден Норт і Кріс Маттс виробили його з кінця 2004 року, щоб дати аналітикам, тестувальникам і розробникам одну мову, а Норт опублікував його в березні 2006-го. Він змушує назвати передумову й напряму перетворюється на автоматизований тест.

Три правила тримають їх корисними. Небагато: три-сім на історію — норма, а п’ятнадцять означає, що історія насправді дві чи три (рядок 11). Про поведінку, а не про екран: критерій, що називає колір кнопки, ламається того дня, коли змінюють дизайн, і досі нікому не каже, що кнопка має робити (рядок 12). І вимірювані: «швидко» — не критерій, «95% менш ніж за 300 мс» — критерій (рядок 10).

Example mapping — розмова, яку видно

Найкорисніша техніка для написання критеріїв водночас найпряміше повертає розмову (рядок 16). Метт Вінн, який очолює проєкт Cucumber, описав її 8 грудня 2015 року. Троє-четверо людей — хтось від продукту, розробки й тестування — беруть одну історію й картки чотирьох кольорів. Історія йде на жовту картку. Кожне правило, якого вона має дотримуватися, — на синю. Під кожним правилом — зелені картки з конкретними прикладами. Будь-яке питання, на яке ніхто в кімнаті не може відповісти, — на червону, щоб забрати його з собою.

Стіл, що виходить у результаті, і є діагнозом. Добре зрозуміла історія нормального розміру, за оцінкою Вінна, мапиться приблизно за 25 хвилин. Стіл, вкритий червоними картками, означає, що історія не готова: перш ніж будувати, треба ще багато дізнатися. Стіл, вкритий синіми, означає, що історія завелика, і кожне правило — кандидат на окрему історію (рядок 11). Правило з довгою колонкою зелених прикладів — найпевніше, кілька правил. А сині й зелені картки, щойно на питання відповіли, і є критеріями приймання — написаними тими, кому їх виконувати.

Нарізання — вертикально, і дев’ять способів це зробити

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

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

Дев’ять шаблонів поділу історії

28 жовтня 2009 року Річард Лоуренс опублікував дев’ять шаблонів поділу історій, і досі це найповніший набір. Пробуйте їх приблизно в такому порядку; перший, що дає дві історії, кожна з яких чогось варта, — зазвичай правильний.

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

Story mapping — щоб шлях лишався цілим

У пласкому беклозі з добре нарізаних історій є одна структурна вада: він губить форму шляху користувача. Прочитайте п’ятдесят упорядкованих карток — і ви не скажете, чи складаються верхні двадцять у щось, що людина може довести до кінця. Story map Джеффа Паттона, яку він описав 8 жовтня 2008 року, а згодом у книжці, розв’язує це, розкладаючи історії у двох вимірах замість одного.

Угорі йде хребет: те, що робить користувач, зліва направо, у порядку виконання, — переглянути, обрати, оплатити, відстежити. Хребет не пріоритезують; він просто є. Під кожним кроком висить колонка історій, упорядкованих згори вниз за тим, наскільки вони необхідні. Далі карту ріжуть горизонтально. Верхній рядок через усі колонки — найтонша версія шляху, що працює від початку до кінця, — walking skeleton, термін, який Паттон запозичує в Алістера Коберна, а кожен рядок нижче — пізніший реліз, що робить той самий шлях кращим.

Цінність — у тому, що форма робить очевидним. Прогалина в хребті — крок, про який ніхто не подумав. Колонка з п’ятнадцятьма картками поруч із колонками по дві — місце, де команда вклалася надміру. А перший реліз, обраний як верхній рядок, гарантовано придатний до використання, тоді як перший реліз із верхніх двадцяти пунктів плаского списку — зазвичай ні. Власний образ Паттона для ризику, який прибирає карта: будуючи автомобіль функція за функцією, можна випустити його без гальм.

INVEST, спайки і для чого поінти

17 серпня 2003 року Білл Вейк дав чекліст, який цитують досі: добра історія — Independent, Negotiable, Valuable, Estimable, Small і Testable. Його власні формулювання корисніші за абревіатуру, тож ось вони поруч із симптомом провалу кожної літери.

INVEST — тест на «запах», а не шлагбаум. Історія, що не проходить за однією літерою, варта другого погляду, а не автоматичної відмови: залежні історії існують, і іноді чесна відповідь — будувати їх по черзі. Літера, яку варто сприймати серйозно щоразу, — Testable. Вейк сформулював її як обіцянку, яку дає картка: «я розумію, чого хочу, достатньо, щоб написати для цього тест», — і якщо ніхто не може сказати, що доведе завершеність, переписування решти п’яти не врятує. Зверніть увагу й на те, що «мала» у Вейка — це кілька людино-тижнів; нині команди цілять значно менше, у кілька днів, бо історії, що займає весь спринт, нічим поглинути несподіванку.

Коли історію неможливо оцінити: спайк

Іноді команда не може оцінити історію, бо невідоме — технічне: чи витримає ця бібліотека наш обсяг, чи вміє API провайдера часткові повернення взагалі. Відповідь — спайк: окреме обмежене в часі дослідження, результатом якого є знання, а не робочий софт. Два правила тримають спайки чесними (рядок 13). Питання й часові межі фіксують наперед, і межі не розсувають: якщо двох днів не вистачило, це вже саме собою висновок. І спайк закінчується рішенням, десь записаним, — інакше те саме питання наступного кварталу досліджуватиме заново той, кому дістанеться код.

Поінти і те, для чого вони не потрібні

Story pointsstory pointsвідносний розмір, не годиниОдиниця для оцінки відносного розміру задач беклогу — 8 приблизно вдвічі більше за 5, — навмисно не привʼязана до годин. Корисні для планування однієї команди й більше ні для чого: перетворені на ціль чи порівнювані між командами, вони роздуваються замість вимірювати.Докладніше в статті →Усі терміни — відносний розмір, а не тривалість: ця історія приблизно вдвічі більша за ту. За розповіддю Рона Джеффріса, вони починалися як «ідеальні дні» — день роботи пари без перерв — і стали поінтами, коли люди раз у раз плутали ідеальні дні з календарними. VelocityVelocityскільки вміщується у спринтСкільки команда реально завершує за спринт, усереднено за кілька. Це допоміжна величина для планування однієї конкретної команди й нічого більше: порівнювати velocity двох команд чи ставити її за ціль означає надійно отримати роздуті оцінки, а не більше роботи.Докладніше в статті →Усі терміни, кількість завершених поінтів за спринт, — це тоді вхідні дані для прогнозу тієї команди, що їх зробила, і ні для чого більше; вона не порівнюється між командами й не є продуктивністю, бо будь-яка команда, яку за нею міряють, подвоїть її за два спринти, не змінивши того, що постачає. Одиниці й їхня арифметика — на сторінці про оцінювання.

П’ять епізодів і що змінив кожен

Формат має коротку й добре задокументовану історію, і більшість того, що сьогодні йде не так з історіями, помітили ті, хто його формував.

C3 — епізод, який прихильники розповідають найрідше, і найповчальніший. Проєкт Chrysler Comprehensive Compensation почався 1993 року й нікому нічого не виплатив до приходу Кента Бека 1996 року. На практиках, що стали Extreme Programming, — історії на картках, замовник у кімнаті, короткі релізи — він запрацював 1997 року й платив приблизно 10 000 працівникам на місячних окладах. Мав платити 87 000. Нову розробку зупинили 1999 року, а в лютому 2000-го DaimlerChrysler скасувала проєкт. Деталь, яку варто запам’ятати, — про розмову: представник замовника, людина, від якої залежали історії, пішов вигорілим, і йому не знайшли заміни. Історії тримають вимогу в голові людини, а не в документі. У цьому їхня сила, і це означає, що методу потрібна ця людина, з часом на нього, доки триває робота.

Де це вироджується

Історії рідко підводять через погано складене речення. Вони підводять, коли формат лишається, а механізм за ним — розмова, підтвердження, тонкий зріз — тихо зупиняється. Майже кожен такий збій — одне з цього:

• Шаблон, натягнутий на технічні задачі: «Як розробник, я хочу міграцію» нікого не обманює й ховає ефект для користувача (рядок 2).
• Викинуте «щоб», а з ним — єдина причина, з якої історію можна обговорювати (рядок 1).
• Картки, розписані до дрібниць однією людиною, тож розмова так і не відбувається (рядок 16).
• Горизонтальні зрізи — API, UI, база даних, — названі історіями, тож нічого не виходить до останнього дня спринту, або наступного (рядок 5).
• Немає критеріїв приймання, тож «готово» узгоджують на огляді під тиском часу (рядок 9).
• Given/When/Then, написані як сценарії кліків, що ламаються з кожним редизайном і нічого не кажуть про поведінку (рядок 12).
• Definition of Ready як шлагбаум, що перетворює розмову назад на передачу документа.
• Увесь беклог деталізований наперед, тож більшість деталей переписують або ігнорують, перш ніж хтось почне будувати.
• Story points як показник продуктивності — це роздуває оцінки, а не результат.
• Баги й обмеження якості, вдягнені як історії, — і беклог виглядає як прогрес (рядки 14–15).

Чесна межа в тому, що історія може нести лише ту потребу, яку хтось справді зрозумів. Формат дозволяє легко записати здогадку голосом користувача — «Як клієнт, я хочу…», — і здогадка тоді виглядає як доказ. Ніщо в шаблоні не перевіряє, чи цього хоче хоч один клієнт. Ця перевірка живе деінде — у дослідженні продукту й у тому, що користувачі роблять після релізу; беклог бездоганно сформульованих історій може описати, нарізати й підтвердити продукт, який нікому не був потрібен.

Практична перевірка займає п’ятнадцять хвилин. Відкрийте поточний спринт і прочитайте назви: чи можна кожну випустити окремо (рядок 5)? Порахуйте історії без причини (рядок 1) і без критеріїв приймання (рядок 9). Знайдіть три найстаріші пункти вгорі беклогу й спитайте, хто востаннє обговорював кожен із кимось від продукту. І подивіться на низ: якщо пункти там мають детальні критерії приймання, команда пише деталі для плану, що зміниться.

Коли це застосовувати

Пов’язані сторінки

• МенеджментЕпіки, фічі, задачіЕпіки, фічі й задачі — це рівні ієрархії роботи: від ставки, яку керівник робить на квартал, до кроку, який інженер робить сьогодні. Жоден стандарт їх не визначає: у Scrum Guide немає жодного з цих трьох слів, а Jira, Azure DevOps і SAFe ставлять епік на різний розмір. Сторінка починається з усіх рівнів на одному екрані й одного епіка, розкладеного до задач; далі — звідки ці слова, для чого кожен рівень, епік як ставка з виходом, фічі, enabler-и й задачі, чому підсумовані оцінки вводять в оману, п’ять епізодів з історії ієрархії і де все це вироджується.
• МенеджментWork Breakdown StructureWork Breakdown Structure (WBS) — це ієрархічний розклад усього, що проєкт має створити, — і, за визначенням, нічого поза цим. Це межа обсягу, намальована як дерево: якщо якоїсь роботи в ньому немає, її немає і в проєкті, а додати її — це зміна, а не правка. Сторінка починається з готового WBS для ІТ-проєкту — вісім гілок, тридцять один робочий пакет, з кодами й рівно 100% разом; далі — правила, що роблять дерево WBS, словник, де насправді живе обсяг, коди й контрольні рахунки, глибина розкладу, WBS поруч з agile-беклогом, три задокументовані кейси і де все це вироджується.
• МенеджментМетодики оцінюванняМетодики оцінювання в IT — це одиниці, якими команда прогнозує, скільки роботи займе завдання: story points, людино-дні, години або розміри футболок (T-shirt). Вони не взаємозамінні. Кожна переносить крок, що перетворює зусилля на дату, в інше місце й до іншої людини, і кожна ламається по-своєму, впізнавано. Сторінка починається з усіх чотирьох поруч і таблиці, яка з них пасує до якого рішення, а далі — чому чесна оцінка є діапазоном, а не числом, кожна одиниця детально, шість задокументованих оцінок, що пішли не так, і де оцінювання перетворюється на театр.