Чи варто враховувати індивідуальні здібності в сюжетних точках?

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

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

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

Буду вдячний за будь-які авторитетні посилання у відповідях, але прості думки теж були б чудовими.

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

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

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

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

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

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

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

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

TL; DR
Ми завжди повинні вважати, що до певної історії будуть призначені лише компетентні розробники.

Компетентність (або її відсутність) не є образою. Це просто розумна міра навичок розробника, який не відстає і не має виняткового досвіду.

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

Кожна система може працювати, кожна система може вийти з ладу. Питання не стільки в тому, яка система краща, а в тому, які недоліки компанія може / бажає мати справу .

В принципі, час вивчення оволодіння мовою / рамками не повинен включатися. Незначна дотична: хоча вони не повинні існувати в ідеальному світі, слід включити час для вивчення перешкод, пов'язаних з проектом чи історією.

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

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

Час навчання, як правило, не складається. Скажімо, наш новобранець мало знає C #, і ми вважаємо, що йому потрібно три додаткові дні, щоб розібратися в оточенні, перш ніж він зможе виконати роботу. Як це часто зустрічається в багатьох компаніях, в яких я працював, ми зараз знаходимось на нараді, де нас очікує оцінка кількох історій користувача (індивідуально). На приклад, скажімо, у нас є три історії, з якими потрібно вирішити.

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

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

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

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

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

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

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

Це складна тема, і є часті дискусії на цю тему. Мені не подобається концепція "канонічної" думки з цього приводу: є різні думки, які мають значення. Але є підтримуючі цінності, принципи та практики, які повинні керувати підходом.

Далі базується на моїх власних думках, які працювали з командами scrum більше 10 років. Але це просто МОЯ думка.

1. Історичні бали як метод прогнозування Первісний намір сюжетних точок полягав у пошуку швидкого методу для оцінки зусиль з метою прогнозування того, що може виконати команда протягом певного періоду часу. Деякі з "світильників" стверджують, що точки використовуються лише для прогнозування довгострокового масштабу (наприклад, над випуском), а не для визначення потужності на рівні спринту. Крім того, концепція полягає в тому, що команди застосовують "відносний розмір" на основі історичних цінностей (зусилля X схожі на зусилля B, яке склало 3 бали). Це прискорює процес оцінювання, тому командам не доведеться розбивати майбутні роботи на детальні робочі пакети та застосовувати години до всіх завдань. Команди з високою ефективністю прагнуть перетворити всіх технічних працівників на дуже компетентних членів подібного рівня кваліфікації. (Ця концепція буде вивчена детальніше в пункті №4) Коли це буде досягнуто, рівень індивідуальних навичок дійсно не є змінною в розмірі. АЛЕ: Для досягнення цієї мети зазвичай потрібно досить тривалий час і узгоджені зусилля. Так ... що ми робимо, перш ніж потрапити?

2. Години роботи визначають ємність спринту: За тими самими "світилами", які заявляють, що бали використовуються для довгострокового прогнозування, вони також пропонують використовувати години роботи для визначення здатності спринту, а не балів. На мою думку, це нормально, але я скажу, що коли я допомагав тренерським командам «Високопродуктивні», їхні навички вирівнювались в середньому до того, де вони могли точно визначити, що вони могли виконати у спринті, використовуючи лише Story Points . Знову ж таки, це може бути ціллю, до якої ми прагнемо, але нові команди до цього не готові. Таким чином, ви можете знайти в одному спринті історію з 2 балами, що має 12 завдань на зусилля, а в іншому - 25 годин зусиль. Так, що ти робиш? Деякі люди, яких я називаю "спритними пуристами", стверджують, що розмір історії (у балах) повинен бути агностичним за тривалістю. Інші не згодні. Прочитайте логіку на пункт №3 і подивіться, що ви думаєте.

3. Історія-вказівка ​​консенсусом: Застосування обсягу, невідомих, складності, знань

Таким чином, команди дивляться на роботу, і потрібно узгодити питання, які будуть проксі для рівня зусиль. Правильно? Якщо припустити, що всі навички рівні, то консенсус легко досягти. Але часто в командах є хлопець, який є гуру Java, інший, який не дуже чудовий на Java (можливо, вона була особою C # або .Net або Cobol і вивчає Java). Отже завдання X для Боба дуже проста. Для Джейн важче.

Agile команди намагаються просувати власність колективного коду та зростати / розширювати досвід. Тому ми зазвичай не присвоюємо історії людям, виходячи з їхньої експертизи: ми віддаємо перевагу колективам спільно працювати над історіями та вчитися разом. Це узгоджується з поняттям "сповільнитись, щоб пришвидшити": якщо ми знайдемо час, щоб дати Джейн досвід з Java, в той час як спочатку це може сповільнити нас, згодом у нас з'являться більш компетентні розробники Java. Насправді, якщо у нас є лише ОДИН експерт з Java, і кожен працює за своїми областями, ми створюємо ситуацію з декількома потенційними "пунктами провалу". Що відбувається у спринті, коли 90% роботи - це Java, але Боб (наш експерт з Java) хворий чи у відпустці? Розширюючи навички, ми усуваємо потенційні вузькі місця та знижуємо ризик. Зважаючи на це: Коли команда розглядає історію, вони повинні мати на увазі кілька понять при розмірі. Ви можете придумати абревіатуру VUCK, щоб запам'ятати це.

Обсяг: Деякі зусилля досить прості, але потребують великого обсягу повторних завдань. (У мене був хлопець, який повинен був скопіювати і переформатувати таблиці 50+, який сказав, що це 1 бал, тому що це було просто. Але, подумавши, команда зрозуміла, що, хоча це було легко, це забирало багато часу, і був великий обсяг таблиць, щоб перенести та оптимізувати. Тож нам довелося перенастроювати бали через обсяг роботи)

Невідомі: Іноді ми думаємо, що знаємо, що робити, але також виявляємо деякі невідомі - вони являють собою РИЗИКИ . А це означає, що ми можемо зіткнутися з несподіваними проблемами, які нам доведеться вирішити, переробити або спробувати інше рішення.

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

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

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

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

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

Тож якщо Джейн добровільно береться на те, щоб зробити це на Java, і це зробило б зусилля 2–3 або тричі тривалістю тих же зусиль, якби Боб це зробив, що робити? З часом мої команди вирішували розмір розповідей на основі рівня зусиль (LOE) / VUCK для людей, які доклали зусиль. Боб, команда Гуру, не має сенсу говорити "це 1", коли для Джейн це буде непросто, і це займе тиждень, а також потрібно трохи часу на Боба для парного кодування та перегляду коду. Тому ми зіткнулися з цими пунктами, щоб відобразити реальну ЛОЗ. Наступного разу, коли прийшла подібна історія, те, що раніше було Джейн 8, стало 5. Зрештою, всі погодилися, що це було легко 3. У той момент ми знали, що ростемо як команда.

TLDR

Ні, але, можливо, не з тієї причини, яку ви думаєте.

Довга версія

Багато інших відповідей пояснили, що "Історії балів" слід розраховувати виключно по відношенню до інших творів. Це абсолютно правда. Оскільки Story Points оцінює обсяг роботи, а не час, необхідний для її завершення, мало сенсу давати Story Points на основі окремої людини.

Наприклад (один із моїх улюблених), розгляньте своє завдання «Копати яму». Ви можете це оцінити, виходячи з кількості землі, яку потрібно вилучити, або часу, який знадобиться для видалення землі. Мій друг копає ціле зі швидкістю 3 метри на годину, у мене великий механічний копач, щоб я міг керувати 100! Єдина константа - це кількість землі - тому це ми використовуємо як нашу одиницю оцінки.

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

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

У команді немає "я" і абсолютно немає я в спритному плануванні!