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

37

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

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

Jonas
источник
5
Любопытно: почему ваша работа как младшего разработчика заключается в том, чтобы объяснять это разработчикам, не занимающимся программным обеспечением? Есть ли кто-то в вашей рабочей группе или в цепи управления, который может помочь вам убедить того, кого вам нужно убедить?
Алекс Фейнман
@ Алекс: Нет, это не человек в одной компании. Просто человек с идеями сделать стартап. И я единственный разработчик, с которым у него есть контакты.
Джонас

Ответы:

48

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

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

Петер Тёрёк
источник
Больше неизвестных означает больше неопределенности.
Surfasb
9
Забудь далеко. Попросите их оценить - с точностью до минуты - когда они придут домой с работы этим вечером. Что, если трафик отличается, что, если начнется дождь, что если вы получите телефонный звонок во время вождения и т. Д. Если что-то настолько обыденное и такое же частое, как поездка домой, невозможно измерить с какой-либо степенью точности - тогда как Можем ли мы ожидать более точной оценки времени, необходимого для реализации какого-либо сложного программного обеспечения, в котором есть неисчислимо больше и больше значимых переменных, чем жалкое возвращение домой с работы.
Квентин Старин
8
@qes, я пользуюсь общественным транспортом, поэтому могу с точностью до 10% сказать, когда приеду домой - я думаю, что большинство руководителей проектов SW были бы довольны таким уровнем точности ;-)
Péter Török
1
Цели проекта программного обеспечения также меняются, поэтому после того, как они подсчитают, сколько времени им понадобится, ОП может спросить их, будут ли они еще вовремя, после того, как кто-то сказал им сменить пики, когда они достигли половины первого.
Пол
18

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

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

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

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

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

Томас Оуэнс
источник
7

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

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

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

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

Юрген Штробель
источник
2

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

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

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

JeffO
источник
1

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

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

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

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

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

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

Майк Кроуфорд
источник
1
Книга Стива Макконнелла «Оценка программного обеспечения: демистификация черного искусства» действительно хороша для объяснения того, как оценивают инженеры программного обеспечения. Вы можете изучать методы и инструменты, но единственный способ стать хорошим в оценке - это постоянно оценивать, учиться на своих оценках и повторять. Что касается того, что никто не может постоянно соответствовать оценкам, то есть организации, которые постоянно находятся в пределах нескольких процентов от своих оценок - в книге Макконнелла говорится об организациях (часто CMMI уровня 4 или 5, с постоянным улучшением и детальным отслеживанием), которые достигают этой цели. последовательно.
Томас Оуэнс
Что касается вашей проблемы с плохими оценками. Отслеживаете ли вы ваши оценки по сравнению с фактическим временем до завершения? Если это так, определите, по какому коэффициенту вы недооцениваете, и умножьте все ваши оценки на это число.
Куби
0

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

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

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

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

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

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

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

Майк Кроуфорд
источник
1
Разработка программного обеспечения все еще моложе (безусловно), чем большинство других технических дисциплин, в возрасте 42 лет. Тем не менее, существует ряд зрелых методов и инструментов оценки. Широкополосный delphi (разработанный в 1970-х годах, ставший популярным в 1981 году Барри Бомом в «Software Engineering Economics»), функциональные точки (1979), SEER-SEM (корни в 1960-х), оценка на основе прокси (используется в PSP, разработанной в 1994 году в SEI) и COCOMO (1981) и COCOMO II (1997). В области, которой всего 42 года, уже почти 40 лет сделано для оценки проектов.
Томас Оуэнс