Планування покеру та багатомовних розробників [закрито]

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

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

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

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

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

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

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

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

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

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

Я бачу, звідки береться ваш член команди, але він явно не повністю зрозумів концепцію Agile та Planning Poker. Спершу слід переконатися, що всі розуміють поняття та міркування, що стоять за ними, і тоді вони повинні робити правильно самостійно.

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

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

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