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

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

Як пояснити це людині, яка не є розробником програмного забезпечення ?

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

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

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

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

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

Як молодший розробник, почніть відстежувати оцінки та фактичний час зараз. Можливо, вам буде цікаво почитати про процес персонального програмного забезпечення, розроблений в Інституті програмного забезпечення. Основні книги PSP - це «Дисципліна для інженерії програмного забезпечення» , « PSP»: процес самовдосконалення для інженерів програмного забезпечення та вступ у процес персонального програмного забезпечення . Я вважаю, що Вступ до персонального програмного забезпечення охоплює теми, які вам будуть кориснішими. Я думаю, що для більшості розробників це, як правило, непосильне, але в ньому є кілька хороших ідей та передового досвіду, які можна витягнути і використати для підвищення особистої продуктивності та відточення різних навичок (включаючи оцінку), які ви будете постійно використовувати протягом своєї кар’єри.

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

Зверніться до літератури. Існує величезна купа складного і часто суперечливого матеріалу, який, як доведено практикою (експерименти), працює не так, як очікувалося. Принаймні академіки коливаються купою книг.

Обов’язково читати: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

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

Спостереження Брукса ґрунтуються на його досвіді в IBM під час управління розробкою OS / 360. Він додав більше програмістів до проекту, який відстає від графіку, і рішення, за яким згодом буде контр-інтуїтивно зробити висновок, що ще більше затягнуло проект. Він також допустив помилку, стверджуючи, що на один проект - написання компілятора ALGOL - знадобиться півроку, незалежно від кількості зайнятих працівників (на це потрібно довше). Тенденція менеджерів повторювати подібні помилки при розробці проектів призвела до того, що Брукс відмовився від того, що його книга називається "Біблія програмної інженерії", оскільки "всі цитують її, деякі читають її, а кілька людей йдуть за нею". Книга широко вважається класикою щодо людських елементів програмної інженерії ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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