Як оцінити завдання програмування, якщо у вас немає досвіду в ньому [закрито]

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

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

Яку оцінку чи відповідь я можу дати керівництву, щоб зняти їх зі спини, щоб я міг продовжувати робити свою роботу!

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

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

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

Я відкрию вам секрет. Навіть якщо ви були фахівцем у цій галузі, ваша оцінка, мабуть, буде вкрай неточною. Це природа звіра, коли він робить щось, що є невід’ємним завданням НДДКР. На жаль, керівництво часто намагається застосувати виробничу модель і вимагає точних оцінок. Щоб проілюструвати мою думку, розгляньте складність у точній оцінці наступних двох зусиль:

A) Виготовіть ще 11 тисяч парасольок, які точно такі ж, як і 2K, які ви видали минулого місяця. Б) Сконструюйте новий вид парасольки та побудуйте перший.

Розробка програмного забезпечення - це B, але вони просять оцінити припущення А.

Найкраще, що ви можете зробити, - це розбити завдання на найменші шматочки (не більше 1/2 дня кожен), а потім потроїти остаточне число, яке ви придумали. (Метод Спольскі)

Крім того, у Стіва Макконнелла є ціла книга (можливо, декілька) з цього аспекту програмної інженерії. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Стів Макконнелл (та інші) розповідає про конус невизначеності . В основному ви надаєте оцінку, яка виглядає приблизно так:

Робота триватиме від 3 до 9 тижнів, причому найбільш вірогідними будуть 4 тижні.

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

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

Можливо, ви захочете розглянути як оцінку, так і рівень впевненості, тобто 50/50 вимагає 3-6 місяців або 6-9 місяців або 75% шансів зробити це через 9 місяців, і 90%, що ви будете зроблено за рік.

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

Розбийте свою оцінку на:

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

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

Я використовую певну систему маркування для своїх оцінок ... клас A, клас B і клас C.

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

Клас В становить плюс-мінус 25%. Іноді це досить добре, і вони дають мені гроші на будівництво. Якщо ні, то менше грошей і більше досліджень.

Клас А - плюс-мінус 10%, остаточний і йде або не йде. Якщо це піде, і я відхиляюсь занадто далеко від оцінки, я зізнаюся часто і рано.

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

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

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

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

І було б дуже приємно, якби ви могли запропонувати їм: "Будь ласка, наполягайте, щоб я ніколи не намагався дати вам достовірну оцінку такого типу в майбутньому. Звільніть мене, якщо я спробую".

(Завищена, але лише трохи.)

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

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

Перегляньте спритні практики "Планування випуску" та "Ітераційне планування" для отримання більш поглибленої інформації про цей підхід.

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

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

РЕДАКТУВАННЯ. Ви також можете побачити, чи можете ви отримати більш "ітеративний" термін. У «Прагматичному мисленні та навчанні» Енді Хант добре підкреслює, що люди - експерти проекту ближче до кінця проекту та найменш обізнані на самому початку. Немає особливого сенсу робити всі свої проекти та оцінку часу на самому початку, коли всі найменш обізнані в проекті. Якщо ви "повторите" терміни і вирішите проблему шматками, ви матимете більше успіху.

Багато точної оцінки - це самопізнання. Якщо ви написали багато коду, якщо вам довелося вивчити багато API, ви починаєте відчувати такі питання:

• Скільки часу потрібно, щоб вивчити новий API?
• Скільки часу потрібно для вивчення нової мови?
• Скільки часу потрібно для вивчення нового набору інструментів (компілятор / компонувальник / IDE)?
• Скільки часу мені потрібно, щоб виконати типове завдання?
• Скільки часу мені потрібно, щоб перевірити свою роботу?
• Скільки часу потрібно для розгортання роботи?

Завдяки цьому ви повинні мати розуміння таких речей, як:

• Скільки типових помилок ви створюєте та як їх класифікують (тобто, легко, важко, неможливо)
• Скільки ускладнень буде впроваджено (тобто потребують рефакторації через відсутність стороннього API або помилкового API; потрібно переробити дизайн через нерозуміння можливостей; нестандартні інструменти / процеси складання)
• Скільки часу втрачено через перебої / зовнішні проблеми

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

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

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

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

У вашому випадку ви, безумовно, захочете отримати хоча б НЕКОТОРЕ розуміння того, у що занурюєтесь, перш ніж наводити оцінку. Можливо, вам навіть потрібно надати оцінку того, скільки часу буде потрібно для надання оцінки. Помноження на 3 забезпечує клієнтів щасливими.

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

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

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

Якщо ви не можете розбити завдання, то вам слід найняти когось із достатнім досвідом, який може (оскільки ваш брак досвіду також переслідуватиме вас іншими способами). Якщо ви не можете когось найняти, то вам слід просто торгуватися випадково довгим періодом (від 6 місяців до 2 років) і прямувати до безладного прототипу (поки вам не вдасться надати собі достатньо досвіду, щоб знати, що правильно і що неправильно). Але, якщо ви в кінцевому підсумку це збиваєте, важливо не жартувати і думати, що робите це правильно «по-своєму». Прототипи мали бути викинуті. Сподіваємось, після закінчення відліку прототипу ви готові створити його по-справжньому.

Павло.

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

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

Більшість менеджерів повинні це розуміти - запитуючи дати завершення, вони справді кажуть: "дайте нам уявлення, як ми можемо спланувати наш графік", і "не приймайте просто назавжди".

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

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

Важлива частина є доведення до керівництва , що оцінка є припущенням , якщо вони натиснуть для більш точної оцінки або якщо вони намагаються - Боженька - продати вам ліміт часу (звичайно , це буде тільки прийняти вас 2 днів , щоб побудувати Starship Підприємство, ти хороший, що ти є) ПРИБИРАЙТЕ СВОЇ ГУШИ , не компрометуйте свою оцінку чи факт, що це ненадійно.

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

Запишіть усе це письмово.

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

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

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

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

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

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

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

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

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

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

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

Я б сказав, що слід оцінити як зазвичай, а потім помножити або на 1,5 (якщо ви швидко навчаєтесь і маєте доступ до ресурсів для вирішення своїх питань), або на 2,5, якщо ви середній учень і покладаєтесь лише на себе.

Я сподіваюся, що це допомагає!

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

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

Чи можете ви дати діапазон? 40-60 годин, щось подібне?

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

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