Как объяснить, что сложно оценить время, необходимое для более крупного программного проекта?

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

Как мне это объяснить человеку, который не является разработчиком программного обеспечения ?

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

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

Вы объяснили это человеку? Вы являетесь профессиональным инженером-программистом, поэтому человек, для которого вы создаете программное обеспечение, должен учитывать ваши знания и отзывы, когда речь заходит о разработке и внедрении программных систем.

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

Возможно, вас заинтересуют и другие методы оценки. Вы упомянули, что вы только младший разработчик. Как правило, более опытные разработчики имеют лучшую способность оценивать, поскольку они видели больше проблем, решали их и (мы надеемся) отслеживали оценку по сравнению с фактическим временем. Вы можете воспользоваться этим, используя методы оценки, такие как широкополосный Delphi или планирование покера .

Как младший разработчик, начните отслеживать оценки и фактическое время сейчас. Возможно, вам будет интересно узнать о Личном процессе программного обеспечения, разработанном в Институте разработки программного обеспечения. Основные книги по PSP - «Дисциплина для разработки программного обеспечения» , « PSP: процесс самосовершенствования для инженеров-программистов» и « Введение в процесс разработки персонального программного обеспечения» . Я полагаю, что «Введение в процесс персонального программного обеспечения» будет охватывать темы, которые вы найдете наиболее полезными. Я думаю, что это, как правило, излишне для большинства разработчиков, но у него есть несколько хороших идей и хороших практик, которые можно извлечь и использовать для повышения личной продуктивности и оттачивания различных навыков (включая оценку), которые вы будете постоянно использовать в течение своей карьеры.

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

Обратитесь к литературе. Существует огромная куча сложного и часто противоречивого материала, который, как доказано практикой (экспериментами), работает не так, как ожидалось. По крайней мере, академиков качает куча книг.

Обязательно прочитайте: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

«Мифический человеко-месяц: эссе по программной инженерии» - книга Фреда Брукса по программной инженерии и управлению проектами, основная тема которой заключается в том, что «добавление рабочей силы в поздний программный проект делает его позже». Эта идея известна как закон Брукса и представлена ​​вместе с эффектом второй системы и защитой прототипирования.

Наблюдения Брукса основаны на его опыте работы в IBM при управлении разработкой OS / 360. Он добавил больше программистов к проекту, отстающему от графика, решение, которое он позже придет к нелогичному выводу, что задержал проект еще больше. Он также допустил ошибку, заявив, что на один проект - написание компилятора ALGOL - потребуется шесть месяцев, независимо от количества задействованных работников (на это потребуется больше времени). Тенденция к тому, чтобы менеджеры повторяли такие ошибки при разработке проектов, побудила Брукса высказать, что его книга называется «Библия разработки программного обеспечения», потому что «все цитируют ее, некоторые читают, а некоторые идут на это». Книга широко считается классикой по человеческим элементам разработки программного обеспечения ...

Узнайте, что они планируют делать с этой оценкой. По их мнению, они хотят знать, займут ли это месяцы или годы, а вы пытаетесь получить точные часы (Типичный инженер).

Посмотрите, сможете ли вы поработать над частью проекта, а затем составьте более точную оценку, если это необходимо.

Если они продолжат настаивать, вы будете вынуждены перечислить как можно больше задач, которые вы можете применить, к временным рамкам. Скажите им, что вы дадите им знать, как только увидите, что может повлиять на оценку, и внесете коррективы. Люди обычно стараются избегать сюрпризов.

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

Как консультант, мои клиенты часто требуют, чтобы я работал по фиксированной ставке. Таким образом, мне нужно оценить, чтобы я мог подготовить реалистичную ставку. Я никогда не преуспел в этом. Можно было бы подумать, что я буду перебивать так же часто, как перебиваю, но это не так. В результате я часто теряю много денег по своим контрактам и в итоге зарабатываю намного меньше, чем если бы я работал в компании в качестве постоянного сотрудника.

Я много лет искал книгу, которая научила бы меня оценивать программное обеспечение, но я еще не нашел ее.

Что касается объяснения этого кому-то, кто не является кодером. Вы могли бы отметить, что никто в отрасли не может постоянно соответствовать их оценкам. Это происходит все время, когда новые программные продукты анонсируются, только для отправки через месяцы или годы после даты, которая была первоначально объявлена.

Если такая крупная компания, как Microsoft, не может понять, как оценить время, затрачиваемое на выпуск собственных продуктов, как я могу это сделать?

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

Оценка времени всего проекта обычно выполняется руководителем проекта, а не программистом.

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

Кроме того, время зависит от многих факторов, таких как количество людей и объем требований, которые вы не сказали, что у вас есть. Одной архитектуры недостаточно.

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

Разработка программного обеспечения также постоянно меняется. К тому времени, когда технологии стали достаточно развитыми, чтобы их можно было считать зрелыми, они часто отказываются от какой-либо новой технологии. Это мешает кому-либо получить достаточный опыт работы с какой-либо одной технологией, чтобы иметь возможность получать достоверные оценки.

Сравните это с оценкой конструкции. Это очень хорошо понимаемая проблема не только потому, что контракты присуждаются на основе заявок, но и потому, что человечество строит вещи с зари цивилизации.