Що ви думаєте про «Планування покеру»? [зачинено]


22

Планування покеру

Підсумок, якщо ви не хочете читати статтю wiki:

  1. Отримайте список завдань, які ви хочете виконати для майбутньої ітерації
  2. Для кожного завдання:
    2.1 Обговоріть з групою , що це тягне за собою
    2,2 Кожен записує / вибирає оцінку того , скільки зусиль потрібно для виконання цього завдання
    2.3 Кожен показує свою оцінку
    2.4 Найвищі і найнижчі викиди пояснюють їх міркування
    2.5 Повторювати , поки консенсус не буде досягнутий

Зазвичай щось подібне до чисел із послідовності Фібоначчі, таких як 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 - це допустимі значення, тому ви не отримуєте довгих аргументів щодо близьких значень, таких як 23 vs 27.

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

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


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


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

Шкода, що це закрито як не конструктивне, хотілося б, щоб воно перетворилося на вікі спільноти.
Джеремі Томпсон

@pap Ми також не змогли ефективно використовувати ПП (через розповсюдження нашої команди). Тому ми спробували метод Team Estimation Game Стіва Бокмана - і він добре працював для нас. Пізніше ми знайшли це Jira Add-On
Vitalii Zurian

Відповіді:


13

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

  1. Це змушує всіх погодитися . Люди не змушені сприймати будь-який результат; натомість вони змушені робити власну оцінку! Час на захист власних оцінок також виділяється, якщо це необхідно.

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

    Однак недоліком цього є те, що іноді вам потрібно зробити щось інше (наприклад, зробити деякі замітки та записати подробиці угоди, яку ви тільки що уклали).

  3. Це підтримує зустрічі швидше . Немає потреби в постійному залученні керівника зустрічей, щоб все було в курсі. Гра з чіткими правилами для цього набагато краща. Так, вам потрібно зробити кілька додаткових рухів, щоб поставити картки, розкрити їх тощо, але вони платять свій шлях.

  4. Дуже багато людей просто люблять грати в карти , особливо в покер :-) Це підвищує мотивацію.

Компанія, яка продає колоди таких карток, супроводжувала їхній сайт статтею про Planning Poker , яку також варто прочитати.


3
Як правило , ми зробили це онлайн з planningpoker.com
Fishtoaster

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

@Fishtoaster дякую за посилання - має бути зручним для розподілених команд, я здогадуюсь
Арман

8

Ми його широко використовуємо. Я вважаю, що це має ряд переваг перед традиційними методами:

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

6

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


5

Після використання планування покеру на кілька спринтів, керівництво нарешті зрозуміло те, що всі ми розробники знали місяцями, ми не закінчимо вчасно.

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


4

Тут вже багато хороших відповідей - я просто хотів зазначити ще одну особливість.

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


3

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

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


3

Ще одна добра річ: дискусії про те, чи є завдання X «3» чи «8», допомагають команді чітко визначити, якою є сфера застосування - тож пізніше не буде розбіжностей щодо того, що завдання X пов’язане.


1

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


1

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

Нічого, як 40 та двадцять 20 в одному спринті!

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.