Чи часто пропущені терміни зустрічаються у програмах? [зачинено]

18

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

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

freelancing deadlines

1

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

— Саймон Уайтхед

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

— гнат

3

пропущені терміни зустрічаються у всіх робочих місцях

— Стівен А. Лоу

2

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

— Бобсон

6

Роби це швидко, роби дешево, роби це добре: вибери два.

— Реакційний

45

Так. Пропущені терміни поширені в розробці програмного забезпечення.

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

Перефразовуючи « Міфічний місяць людини» Фрідріха Брукса :

Фредерік Брукс, автор місяця «Міфічна людина»

Кінцеві терміни часто пропускаються, оскільки керівники проектів продовжують оцінювати завдання програмного забезпечення так само, як вони виконують завдання цивільного будівництва, що є хибним підходом, оскільки програмне забезпечення - це нова, реміснича галузь, яка не має чітких норм. Це настільки вірно, що ви не можете відкликати "дозвіл" програміста на коди зловмисних дій, а також не можете подавати позов до когось за програмування без назви.
Розробка програмного забезпечення має властиву складності, якої не вистачає інших дисциплін. Велика програма може мати більше компонентів, ніж автомобіль, і ці компоненти можуть взаємодіяти більш, різними способами.
Програмне забезпечення важко уявити, тому різні види діаграм використовуються для перегляду різних аспектів проекту, і ці аспекти можуть бути не ортогональними. З іншого боку, у цивільному будівництві є креслення, які дозволяють ортогонально бачити сантехніку, електропроводку тощо у тому ж діаграмі (або шарах).
Нечасто, коли міст або будівля наполовину побудовані, щоб клієнт повністю змінив сферу проекту. Це часто трапляється в програмних проектах.
Стан сучасного розвитку програмного забезпечення не досяг такої точки, коли програмні проекти є повторюваними та майже не мають ризику. Навіть найбільші програмні компанії, такі як Microsoft, можуть пропустити терміни на місяці чи роки.
Більшість парового програмного забезпечення - це не що інше, як програмні проекти, які були вирізані через подібні проблеми.

На закінчення:

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

— Тулан Кордова
джерело

11

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

— Майк Данлаве

3

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

— Maciej Piechotka

2

@ user61852: Ви мене зрозуміли неправильно. "План" для інженерії - це "джерело" для інформатики - тобто детальний опис кожного компонента - але, коли ми його маємо, ми можемо скласти його (ввести makeчи будь-що інше). Що таке "план" в галузі інформатики, це був би "план" плану 'в інженерії. Різниця полягає makeв тому, що в галузі інформатики йде не більше декількох годин, тоді як написання вихідного коду (включаючи тести та інтеграцію) займає місяці, а в інженерії планування може зайняти місяці (включаючи структурний розрахунок), тоді як будівництво займає роки. Так що дисперсія планування має менший вплив на останньому.

— Maciej Piechotka

1

@ user61852: Що стосується повторюваності - одне, на що комп'ютери чудово підходить, це автоматизація. Скажіть, що вам потрібно створити простий блог - в той момент, коли ви отримаєте точні "оцінки", ви отримаєте на своєму місці Wordpress (або будь-яку іншу систему ведення блогів), тому вам не потрібно робити нічого з цього (у випадку мосту у вас ще є інше середовище, тому вам потрібно пристосуватися більш ретельно, оскільки скеля може бути різною, або може існувати місце проживання птахів або це може зруйнувати вигляд) - програмісти можуть бути більш відповідальними за створення інструментів (стандартна модель моста).

— Maciej Piechotka

2

Бонус за цитування Міфічного місяця людини; Фредерік Брукс тримається за всі ці роки, оскільки він зосереджений на людях, а не на технологіях.

— Майкл Шопсін

3

Пропущені терміни не повинні стати звичною практикою, якщо ви хочете продовжувати отримувати роботу.

З урахуванням сказаного, ви зазвичай хочете залишити собі додаткову кімнату "хитання" у своїх оцінках на випадок, якщо це трапиться (і це завжди). Вам не потрібно розголошувати, що ви додали в додатковий час, просто не робіть це необгрунтованим. Може бути від 5 до 10% від загального часу? Єдиний спосіб, який ви дізнаєтесь, - це зробити кілька разів.

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

— TJ Trapp
джерело

2

Я завжди даю 20% приміщення при оцінці. 5-10% - це занадто мало. Я думаю, це залежить від того, наскільки ви відволікаєтесь. Індивідуальний розробник може взагалі не відволікатися

— BЈовић

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

— Консоле

Гммм ... дивіться Hofstadter's_law

— Філіп

1

Порівняно з 5-20%, я думаю, що 100% маржа краща. Серйозно. Це дозволяє вивчити свої варіанти набагато краще. І відповіді на інші запитання на Stack Exchange.

— Acumenus

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

— переможець

3

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

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

— Філіп
джерело

2

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

Дивовижна річ у швидкості полягає в тому, що вона охоплює всі нематеріальні речі, такі як перебої та несподівана складність, що розробникам складно врахувати у своїх оцінках. Всі ймовірності середні з часом. У середньому протягом 10 тижнів наші оцінки швидкості були точними в межах приблизно 5%. Але коли ми оцінюємо одні і ті ж завдання за години, то ж команда постійно недооцінює на 30-50%.

— Карл Білефельдт
джерело

1

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

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

Якщо хтось переробив кухню, він, як правило, думає: «Ну, я це буду робити за два тижні». Вони закінчують це приблизно через шість тижнів.

— Мередіт Бідна
джерело

1

Що стосується NASA до мого запитання?

1

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

— Мередіт Бідна

Хоча я згоден, що оцінки більшості людей виключаються принаймні вдвічі, але наступна одиниця часу ... хммм. У будь-якому разі, NASA дуже добре оцінює завдання, які вони вже вміють робити. Проблема полягає в тому, що люди не дуже добре оцінюють завдання, коли вони не знають того, чого не знають. Оскільки НАСА робить багато справді новаторських робіт, не дивно, що вони не знають багато про те, чим займаються, поки не почнуть це робити. Таким чином, причина початкової недооцінки. Також деякі люди схильні бути оптимістичними, а інші - песимістичними. Не впевнений, що еволюція пов'язана.

— Данк