Що може бути хорошою командною діяльністю для покращення навичок оцінювання? [зачинено]

9

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

estimation team-building

— Роб
джерело

2

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

— Томас Оуенс

У вас є проблеми? Наскільки точні ваші оцінки та чи потрібно вам витратити час на їх вдосконалення?

— JeffO

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

— Роб

2

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

— Роб

8

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

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

— Мальфіст
джерело

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

— Роб

6

Наведіть приклад проблеми з використанням Minecraft.

Клієнту потрібна коричнева ступінчаста піраміда розміром 20x20 блоків. Піраміді також потрібен рів, шириною щонайменше 10 блоків.

Дайте їм 3 хвилини, щоб накреслити просту WBS та оцінку.

Через 2 хвилини скажіть, що клієнт передумав, і їм зараз потрібна піраміда 30x30. Скажіть їм переглянути свої оцінки протягом залишеної хвилини.

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

Скажіть їм, що на розробку мосту знадобиться X годин, і попросіть усіх, хто недооцінився, встати.

Це призведе до точки додому.

— кленовий вал
джерело

2

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

— Роб

1

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

— Роб

2

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

— Томас Оуенс

1

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

— Роб

1

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

— Thomas Owens

1

Я пропоную генератор / вирішувач лабіринту для наступних моментів:

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

— Віскі
джерело

1

Ви можете грати в "Як довго вам знадобиться написати це?" гра. Подібно до групи людей, що вихваляються тим, як вони можуть їхати до Лас-Вегаса за X години (де число X зазвичай зменшується з кожним браггартом, поки хтось не стверджує, що може це зробити за менше години). Отже, для кодерів: викиньте просту мету і подивіться, що говорить кожна людина, і чи існує консенсус з точки зору групи або відмінних думок. Скільки часу знадобиться тобі, щоб написати привіт світ? Що означає "писати", чи означає це також "пробіг" і "тест"? Чи потрібне спочатку імітаційне середовище? На якій платформі та якому крос-компіляторі та інструменти вже встановлені та готові? тощо. "Привіт, світ" може знадобитися 4 дні, щоб "написати" на вбудованій платформі (встановити інструменти, підготувати платформу,

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

— Джонатан Клайн IEEE
джерело