LINUX.ORG.RU

самый оптимальный вариант.

silw ★★★★★
()

> на глаз и умножить на 2.5?

занижаете. умножать на 3 нужно, а если уж быть совсем точным, то на M_PI

gunja
()
Ответ на: комментарий от drull

Неопытного программиста про эстимейт спрашивать — это как дурака за водкой посылать. Говоришь ему — возьми бутылку, так он, дуралей, одну и принесет.

shimon ★★★★★
()
Ответ на: комментарий от shimon

Мне интересно почему именно Пи, а не 3. В чем магия этого числа?

drull ★☆☆☆
()

программирование это НИОКР и к трудозатратам отношения не имеет никакого. трудозатратами работа каменщиков и слесарей измеряется

Karapuz ★★★★★
()

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

Однажды планируемое время разработки оказалось необходимо умножить в 18 раз. Так и вышло.

amomymous ★★★
()
Ответ на: комментарий от Karapuz

если сказать нечего, то нужно придираться к словам? В настоящем мире у клиентов есть бюджет, поэтому им нужно знать финальную цифру, перед тем как дать тебе проект.

безбюджетные R&D это в больших компаниях, проекты которых мне пока не светят.

mrdeath ★★★★★
() автор топика
Ответ на: комментарий от amomymous

а как ты узнал, что нужно умножить на 18? По совокупности коэффициентов? И как в конце сошлось?

mrdeath ★★★★★
() автор топика
Ответ на: комментарий от r_asian

ты забыл, что на лоре обитают только высокооплачиваемые специалисты, работающие над многомиллионными проектами :)

mrdeath ★★★★★
() автор топика

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

Чистое (идеальное) время*(N(сложность задачи)/2)

zgen ★★★★★
()
Ответ на: комментарий от mrdeath

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

amomymous ★★★
()
Ответ на: комментарий от amomymous

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

zgen ★★★★★
()
Ответ на: комментарий от zgen

:-) не, ну это само собой разумеющееся. Разбить на подпроекты всегда нужно, дабы реально проект оценить.

Если не разбивать, то можно и забыть что-нибудь. Или прикинуть что это мелочь, а на самом деле, там 30-40 часов работы.

mrdeath ★★★★★
() автор топика

Это потому что у программистов нет таких хороших нормативов, как, например, у строителей. На стройке время по факту отличается от расчетного не более чем на 10 процентов, если не вмешиваются другие факторы.

abraziv_whiskey ★★★★★
()
Ответ на: комментарий от abraziv_whiskey

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

Kompilainenn ★★★★★
()
Ответ на: комментарий от abraziv_whiskey

у программистов нет таких хороших нормативов, как, например, у строителей


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

Karapuz ★★★★★
()
Ответ на: комментарий от mrdeath

на лоре обитают только высокооплачиваемые специалисты


Я и IRL встречаю людей которые считают что 5 лет в ВУЗе нужно просидеть только для того чтобы потом браться за поденную копеечную работу которую нормальные люди делать не будут

Karapuz ★★★★★
()
Ответ на: комментарий от Karapuz

огласите ваш рейт, и там уже решим, кто берется за копеечные работы? Или вы так, ради красного словца, а сами за 30к в месяц работаете?

mrdeath ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.