Коли на конференції AgileBaseCamp я питав: "Хто з присутніх працює по Scrum?". то майже всі підняли руки. І в той же час, на питання: «Хто НЕ знайомий з правилами Planning Poker?». я знову побачив ліс рук. Можливо, про це слід розповісти. У всякому разі, розповім навіщо МИ граємо в нього.
Перш за все, хочу остаточно заплутати читачів і сказати, що не дивлячись на назву, ми граємо в нього, щоб оцінювати майбутню роботу 🙂
Парадокс з програмістами полягає в тому, що якщо їх запитати, як складно зробити ту чи іншу вимогу, то у відповідь можна почути: "десять годин». Тривалість у часі ще не означає складність. Бувають випадки, коли потрібно змінити сотню файлів по всьому проекту, а буває потрібно змінити один рядок, тільки ось ще б знайти де 🙂 І ніякі складні математичні теорії не допоможуть. Значить, потрібно спрощувати!
Ще з давніх часів, людина могла відрізнити велике яблуко від маленького. Або відрізнити лева від носорога і зайця. В цьому і полягає суть оцінки порівнянням. Ми беремо наступний елемент з беклога і порівнюємо з тими, що вже оцінені або хоча б з попереднім досвідом. Це більше ніж то? Повертаючись до прикладу з тваринами, на питання «а якого розміру жираф», майже будь-хто скаже - між левом і носорогом. Тобто для нового елемента ми знаходимо місце між іншими, вже оціненими.
Хочу звернути увагу, що ми не порівнюємо з еталоном. Одного разу почув від когось фразу: «Ми перестали грати в Planning Poker, тому що вже забули ту маленьку історію користувача, якій ми дали оцінку 1 і потім з нею порівнювали інші». Тут явно щось не так :-).
Як я вже говорив, ми порівнюємо елементи беклога між собою. Якщо у вас новий проект і нова команда - це, мабуть, найскладніший випадок. Тоді доводиться шукати якусь відправну точку - якесь маленьке вимога, про який вся команда може сказати: "Воно маленьке". Якщо ж команда вже працює не перший спринт або навіть не перший проект, то найпростіше порівнювати з попередніми історіями або проектами. До речі, найчастіше згадується, що не такий вже страшною виявилася воооон та «велика» історія в позаминулому спринті.
Отже, сподіваюся, що вже зміг вас переконати - "порівнювати" добре, а "оцінювати" погано. Тому коли ми говоримо про Agile-оцінках, ми говоримо скоріше про інтегральне поняття "складності" і робимо це порівнянням. Ще пару слів про те, які цифри привласнювати. Можна використовувати числа поспіль: 1,2,3,4. Але, як показується народна мудрість, починаються дріб'язкові суперечки, про те, що це 2 або 3, і знову в хід йдуть "метричні лінійки" типу робочих годин, хвилин, днів. Тому вже давно багато Agile-практики рекомендують користуватися послідовністю Фібоначчі (0,1,2,3,5,8,13 ...). Її вигода в тому, що вона починає різко зростати вгору. Адже якщо вимога дійсно складне, то деталі вже не так важливі - слона найкраще є частинами, головне зрозуміти, що це слон 😉
Ну і найцікавіше, до чого тут покер? Це зручний інструмент, щоб привласнити оцінки використовуючи досвід всієї команди. Правила Planning Poker прості:
- Кожному учаснику дається набір карт з цифрами
- Замовник / Власник Продукту читає історію, і команда коротко уточнює її
- Кожен учасник вибирає свою оцінку і кладе карту сорочкою вгору
- Всі одночасно відкривають карти
- Якщо є різниця (велика), то обговорюється «Чому?»
- Робимо ще один раунд оцінки, поки все не зійдуться на одному числі
Ось таким простим способом, вся команда може швидко і без зайвих зусиль оцінити роботи, які буде робити, можливо, навіть не в найближчих спринтах і навіть не в найближчому релізі. Власнику Продукту важливо знати "ціну", і він її отримає. Про те, що він буде з нею робити, я розповім окремо.
Відразу хочу відповісти на питання, яке мені задають майже на кожному тренінгу. У покері повинні брати участь ті люди, які будуть робити ці вимоги. І якщо для нового проекту збирається нова команда, то у них будуть свої визначення складності. Знову ж таки, якщо Власник Продукту не приймає участі в роботі по реалізації вимог, то він не може грати - він швидше "круп'є".
Навіщо ми граємо в покер на роботі
Поділитися посиланням:
Вже неодноразово чув від команд, що вони просто використовують розміри футболок для оцінки розміру кожного елемента беклога. Тобто S, M, L, X, XL, XXL
Цього теж більш ніж достатньо, якщо у вас немає критичної необхідності в числових оцінках. Якщо команда працює «в потоці», то тут важливіше оцінити чи зможемо ми проковтнути вимога за спринт чи ні. Особливо якщо команда прийшла до «Канбану».
Вже неодноразово чув від команд, що вони просто використовують розміри футболок для оцінки розміру кожного елемента беклога. Тобто S, M, L, X, XL, XXL
Цього теж більш ніж достатньо, якщо у вас немає критичної необхідності в числових оцінках. Якщо команда працює «в потоці», то тут важливіше оцінити чи зможемо ми проковтнути вимога за спринт чи ні. Особливо якщо команда прийшла до «Канбану».