Хто повинен брати участь в оцінці часу?

В ІТ-проекті:

1. Хто повинен брати участь в оцінці часу? Розробник, керівник команди, майстер scrum та ін?
2. Чий голос слід підрахувати найбільше?

Справа не стільки в залучених людей, скільки в навичках, які повинні бути присутніми:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ці вимоги слід розділити на найбільші завдання, що мають 100% відому вартість (наприклад, "включити журнал" = 2 години = "завантажити log4j / SLF4J та підключити").

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

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

Хто чи чий повинен брати участь в оцінці часу? Розробник, керівник команди, майстер scrum та ін?

Я вважаю за краще, щоб усі були там під час оцінки, і ми робимо те саме тут

Кого чи чий голос слід підрахувати найбільше?

Розробник, але все-таки все про командну роботу знову

РОЗРОБНИКИ ЗАМІНУЛИ ВПРОВАДЖЕННЯ ПРОЕКТУ! НІХТО ІНШИЙ!

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

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

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

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