Яка мета планування покеру в спринті?

Наш бізнес-аналітик та керівники проектів говорять нам про вимогу клієнта як Stories. Кожне планування спринту, нас (розробників) просять грати в покер для планування.

Вони попросили всіх нас розглянути «складність», а не «зусилля». Ми справді розгублені і витрачаємо час на наші зустрічі. Один розробник поставив питання: "Що ми насправді хочемо розглянути? Чи йдеться про зміну коду / DDL, яку ми маємо зробити в цій вимозі (оцінка часу), чи це про те, чи зрозуміли ми вимогу чи ні? "

Але що вони (бізнес-аналітик та керівники проектів) насправді мають на увазі під розумінням вимоги та підняттям картки?

Крім того, у нас є зустрічі нарізки для окремих команд scrum, де кожен розробник дає оцінку часу для виконання задач для кожної команди scrum. Отже, про що вони насправді говорять у Плануванні Покеру?

Чи може хтось пояснити це на прикладі? Спробуйте розрізнити, про що вони насправді говорять, коли вони говорять "Складність" та "Зусилля".

Розгляньте точку зору керівника проекту

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

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

Дискусія важливіша за число

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

Складність Vs зусиль

Для вирішення вашого конкретного запитання щодо складності та зусиль, схоже, кожен має різні думки з цього приводу. Маунт-Козл , хто є тими, хто робить покерні картки для планування з козами на спині і власник яких Майк Кон є великим у світі Agile / Scrum, кажуть, що слід докладати зусиль, а не складності.

Зазвичай це не вважається мірою часу (див. Приклад нижче для зустрічного прикладу), оскільки люди погано оцінюють час, а інші фактори впливають на те, яке число вони дають: наприклад, тиск, щоб утримати число низьким, щоб ви могли встановити більше функцій у тиску, щоб дати більший номер, щоб дати собі місце, якщо ви зіткнетеся з проблемою. Побудувати програмне забезпечення важко. Коли ви будуєте свій 100-й будинок, ви можете оцінити, скільки часу у вас буде потрібно, оскільки ви побудували до цього 99 будинків. Якщо програмне забезпечення, яке ви будуєте, таке ж, як і попередні програми, які ви створили, тоді ви можете скопіювати та вставити будь-які кошти, поки проект програмного забезпечення інший, і тому виникнуть проблеми, які ви не передбачили на початку.

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

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

Причини, за якими ви не можете дати оцінку

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

1. Історія занадто велика. Розбийте його на більш дрібні, більш конкретні історії користувачів. Пам'ятайте, що кожна історія користувача повинна надавати користувачеві частину цінності; введення - процес - вихід = значення.
2. Вони недостатньо добре розуміють проблемний домен, щоб можна було сказати, скільки часу це займе, або навіть задати всі питання належним чином. Поговоріть з людьми, які більше знають про домену / програмування зацікавлених сторін такого типу додатків, чого б ви ще не бачили. Якщо це неможливо або не пройде вас туди, тоді ви можете використовувати дизайнерський шип. Перейдіть і прототипуйте рішення, але лише протягом обмеженого та визначеного часу. Визначте, як довго триватиме фаза прототипування, не надто довго, а потім знову зустрічайтеся, щоб поділитися своїм новим розумінням.
3. Ваші зацікавлені сторони недостатньо конкретні. "Побудуй мені хмару" - це неприйнятна історія користувача. "Побудуйте мені систему, де я можу відкручувати віртуальний комп'ютер на вимогу" - це краще, оскільки вона буде розбита далі, але все ще не знаходиться на рівні, де ви можете дати точну оцінку того, як довго це займе у вас, оскільки буде сто прихованих припущення у цій заяві, що ваш зацікавлений сторона має те, що ви не дізнаєтесь, поки не покажете їм щось.
4. Нарешті, навіть якщо ви можете дати оцінку, це, ймовірно, буде вперше неправильним. Оцінка - це важка проблема, і найкращий спосіб, який я знаю, щоб вирішити важкі проблеми, - це використовувати науковий метод. Зберіть дані про те, яку кількість оцінює кожен член команди, а потім збирайте дані про те, як довго вони їх зайняли, або наскільки «складними» це було насправді, хоча це складніше, а потім порівняйте їх за часом. Згодом у вас з’явиться відчуття того, хто переоцінює, а хто недооцінює, і тоді ви повинні поділитися цим із командою. Люди можуть допомогти один одному стати кращими в оцінці. Ці цифри також можна повернути у ваш інструмент відстеження, щоб краще передбачити, скільки триватиме історій.

Висновок

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

Увага

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

Убік

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

Приклад

Мені відомо щонайменше одна команда, яка використовує лише цифри 1, 2, 3 і 4 для планування покеру. Вони, проти конвенції та всупереч вище обговореній, визначають їх як дні програмування (насправді пари програмних днів, тобто скільки днів знадобиться двом програмістам, які працюють разом на одній машині, щоб завершити історію користувача). Якщо команда вважає, що на повну історію користувача знадобиться більше 4 днів, тоді вона не залишається загостреною, і власника продукту просять співпрацювати з командою, щоб розбити історію далі або уточнити її більш точно, щоб вона могла вноситись у цей діапазон для майбутньої наради з планування. Але це прогресивно і, ймовірно, його повинні використовувати лише люди, які вже мають досвід використання інших методів.

Я думаю, що відповіді Франка та Енкаїти в значній мірі висвітлюють це, але слід врахувати деякі додаткові речі:

Навіщо використовувати точки історії

Метою оцінки за допомогою сюжетних моментів є надання відносної складності розробки функцій для вашої програми. Простий спосіб подумати над цим - взяти історію, яку ви маєте в майбутньому спринті, наприклад, зміна URL-адреси. Ви знаєте, що це просто з точки зору складності та має чітко визначені критерії прийняття, тому вся команда погоджується, що навіть при тестуванні це 1 (за шкалою Fibo).

Наступна історія, яку слід оцінити, - це агрегування набору даних користувачів та візуалізація цих даних на передній частині. Тепер як розробник ви відразу знаєте, що це складніше, ніж зміна URL-адреси. Ви обговорюєте історію та критерії прийняття, і у вас виникає багато питань, і ви бачите кілька можливих рішень для цього. Інші розробники та QA також згодні, що це дуже складно. Тож ви всі згодні, що це 34-бальна історія. Варто зауважити, що шкала Фібо також дозволяє вказати, наскільки ви впевнені в есіматі - чим більший проміжок між числами вказує на меншу впевненість у вашій оцінці

У цей момент ваш майстер Scrum повинен стрибнути і сказати, що це як одна історія занадто велика і її потрібно розбити на більш дрібні історії меншої складності. Ви можете підійти до цього, зробивши те, що відоме як СПИКІ - це лише деякий час, відведений на розслідування чогось. Тож для цього прикладу ви та інші дияволи погоджуєтесь, що вам потрібно 4 години для обговорення та дослідження можливих технічних рішень.

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

Потім ви погоджуєтесь як команда, що для цього спринту ви прагнете виконати 13-бальну історію, одну 8-бальну історію плюс 1-бальну зміну URL-адреси, яку ви вже визначили. Отже, загалом 22 бали. Наступний спринт ви отримаєте 27 очок, наступний спринт - 18 очок. Після 3 спринтів ви можете почати певну впевненість у своїй швидкості (швидкість - це кількість роботи, яку ваша команда може виконати за один спринт). Для отримання швидкості візьміть середнє значення попередніх спринтів. Отже, у цьому прикладі середнє значення становить (22 + 27 + 18) / 3 = 22,3, тому округлимо його до найближчого за шкалою Фібо, що становить 21.

Тепер для наступного спринту просто прагніть отримати 21 бал.

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

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

Оцінка всієї команди

Вся команда повинна погодитися на одну оцінку для кожної історії. Функція не робиться до тих пір, поки не буде готове виробництво. Просто написання коду в жодному разі не робиться. На мій досвід, команди Scrum були набагато ефективнішими, коли працювали як команда. Візьміть приклад команди, з якою зараз працюю. Коли я приєднався, вони робили всі спринт-зустрічі та планували покер, але під час спринту процес був 1. Базисники / Власники продуктів визначають вимоги як історії з критеріями прийняття та тестами приймання 2. Вони передають ці вимоги розробнику, який потім пише код 3. Розробник об'єднав коду в гілку розробки для QA для тестування 4. Тест QA, тоді вони починають задавати питання, а тести провалюються, тому він повертається в розробку.

Чого тут не вистачає? Попереду недостатньо дискусій, і кожен член команди бачив лише своє завдання. Тепер BA / PO, devs та QA збираються разом, перш ніж писати будь-який код, щоб детально обговорити вимоги та задати питання наперед, а потім продовжити дискусію протягом спринту. Це набагато ефективніше і призводить до більш якісних рішень.

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

Своєчасна оцінка завдань

Моя думка, працюючи з командами, які оцінюють час на виконання завдань, і командами, які виконують лише історію, - НЕ ДАВАЙТЕ ЧАСИ ОЦІНКИ! Вони насправді є лише марною тратою часу. Вони не такі точні, як сюжетні точки, тому що вони специфічні для людей, а не команди, і кожен з них матиме інше уявлення про оцінку часу (принесіть на полум’я).

Історія бачить, що речі, тобто вимоги, змінюються весь час, тому дійсно потрібен показник того, що команда може виконати у спринті.

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

У мене розробники просять, щоб ми оцінили час для виконання завдань, щоб планувати, але я фактично не погоджуюся з таким підходом (насправді я абсолютно не згоден з таким підходом), оскільки це не точно, наприклад, що для цього знадобиться 4 години: один розробник може включати в себе лише час на виконання завдання, хтось ще може додати час для приготування чашок чаю!

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

Оцінка - не найбільша проблема

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

Вікіпедія пояснює, що планувати покер досить добре. Дозвольте мені резюмувати деякі стани, з акцентом на ваш випадок:

Навіщо планувати покер?

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

Чому складність, а не зусилля?

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

Навіщо ховати картки?

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

Чому числа Фібоначчі?

Цифри на ваших картках, як правило, є числами Фібоначчі або деякою іншою послідовністю з великою кількістю прогалин у числах. Це змушує вас повністю довіряти почуттю кишечника. Якщо вам доведеться вибирати між 8 і 13, це набагато більше, ніж заява на 9 або 10. Крім того, як було сказано вище, великі відмінності полягають у тому, де приховані проблеми, тому збільшуючи прогалини, ви збільшуєте шанс виявити ці проблеми краще.

Чому це взагалі працює?

Цікаво, що перші кілька разів ви займаєтесь покером з планування, він не спрацює. Це так просто. Що навіть означає "3" або "5"? Немає визначення того, що означає кожне число (цілеспрямовано!), І саме ця команда повинна виявити фактичне значення кожного з цих номерів. Лише після того, як ви прийняли оцінювати свої історії в цих числах - і після того, як ви зрозуміли кілька таких, - ви отримаєте краще уявлення про те, коли вам слід підняти 5, а коли це швидше 8.

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

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

Приклад

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

Якщо робити приховані оцінки на основі часу, то це стає трохи краще. Але все ж, людина А з обґрунтованим запереченням може бути ще не чіткою стороною в її оцінці. З іншого боку, плануючи покер, людина A повинна більше думати про те, наскільки актуальна проблема X. У двох різних проблемах ви не можете належним чином розрізнити їх важливість за вищенаведеним "розмовним текстом заперечень". Навіть за підрахунками часу, досить важко зрозуміти, що є більшою проблемою. Надія з допомогою планування покер є те , що ви в кінцевому підсумку з одним запереченням є всього лише 2-3 бали відрізняються від оцінок чужих, але інші заперечення , які в кінцевому підсумку 5 або 8 очок від медіани може бути просто найважливіша невизначеність планування спринту.

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

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

Це узгоджується з моментом, зробленим Майком Кон тут .

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

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

Як результат, його "не на основі часу", що "засноване на часі". Недарма всі плутаються.

Є способи зробити цю роботу для вас. По-перше, забудьте про зусилля та зосередьтеся на складності. Забудьте про те, скільки часу може знадобитися для розвитку та зосередитися на місцях, які стосуються кожної історії. Якщо у вас є історія, яка оновлює DB, код сервера, код клієнта та клієнтську документацію, ви можете сказати, що це 4-бальна історія. Якщо це лише зміна на sql DB, тоді це історія на 1 бал. Це дає вам більш зрозумілий спосіб з'ясування відносної складності між історіями. (Вам доведеться придумати деякі показники, які мають сенс для ваших обставин, можливо, вимоги щодо тестового покриття чи складності інтерфейсу)

Моя думка, як правило, полягає в тому, що це безглузда марнотрата часу, яка просто заохочує планування спринтів, як якщо б це були проекти міні-водоспаду. Кого насправді цікавить, скільки сюжетних точок ви можете вмістити у спринт? Якщо у вас залишилися історії в кінці спринту, ви просто зробите їх у наступному. Враховуючи це, ви можете також просто зробити свій відставання на розмір кожної видатної історії, яку ви маєте, і поступово збивати їх з часом. Доставка займає стільки часу, як це займе (але це буде швидше, якщо ви не потурбуєтесь витрачати 20% свого часу на відсталі та спринтерські зустрічі планування). Наприкінці проекту нікого не цікавить, скільки сюжетів було передано. Що хвилює людей - це реалізований проект.

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