Как Вы оценивали время, Вы будете потраченный прежде, чем запустить проект веб-разработки? [закрытый]

Вычисление оценок времени - это то, что вы можете улучшить только с опытом.

Возьмите ваш последний опыт и используйте его, чтобы изменить вашу следующую оценку.

Также см. http://en.wikipedia.org/wiki/Estimation_in_software_engineering для получения дополнительной информации.

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

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

Вы не можете оценить, не зная, что вы собираетесь делать; вам нужно разбить задачу на части, которые вы можете разумно оценить - с точностью до ЧАСА (не менее 1 часа, округляя)

например, «Сделайте мне страницу входа в систему» ​​

HTML-форма входа в систему - 1 час Таблица базы данных для пользователей - 2 часа и т. д. и т. д.

Затем откройте календарь и попробуйте указать часы - хорошо, в понедельник я могу работать около 5 часов, так что я решаю одну задачу. Можете ли вы работать в многозадачном режиме? Возможно, но не говорите, что вы можете выполнять 3 задания по 4 часа за один день, даже если у вас есть 12 часов в запасе (это слишком много).

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

Всегда нужно учитывать время тестирования. Если на разработку чего-то требуется 10 дней, было бы идеально провести тестирование не менее 7-8 дней. Предварительное понимание требований помогает оценить время. Когда / если требования изменятся, вам нужно будет сообщить клиенту, что это добавит дополнительное время к дате доставки.

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

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

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

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

Недостаточное обещание, переоценка. Обычно я НАМНОГО опережаю то, что говорю клиенту, и они всегда рады, что я закончил «раньше».

Also remember the old adage...

"The first 90% takes 90% of the time. The last 10% takes 90% of the time."

I don't think you can ever go wrong with taking how long you think a programming project is going to take and tripling it. Unless you've built EXACTLY the same thing before and it was within the last year, so much unexpected stuff will happen. You can't replace experience, but you can use this rule of thumb to stay out of trouble along the way.

And upvote the first responder... being honest and proactive along the way is huge. Better to avoid promising anything than to have to say you're not going to hit a mark.

Один из моих любимых учителей программирования повторял это предложение каждый раз, когда получал изменение: «Потратьте время, которое, как вы думаете, вы потратите на это, и умножьте его на 3. Даже тогда это будет близким вызовом ".

Сначала, не имея лучшего способа делать что-то, я действительно сделал это. Я все еще делаю! В основном в тех проектах, где чувствуется присутствие мыслящего клиента :)

У меня работает. Это ненаучно, но работает.

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

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

пс. или вы можете использовать классический подход, потратив время, которое, как вы думаете, займет у вас, а затем удвоить его !!! ;)

Определите все возможные задачи. Как уже отмечалось выше, чем меньше задач вы оцениваете, тем точнее вы будете. Сложите общее время, затем умножьте на безумный коэффициент. Чем безумнее ваш клиент, тем больше времени на это уйдет. Вы какое-то время консультировались, так что я уверен, что вы знаете тип.

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

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

Как бы это могло быть, если бы мы сказали что-то вроде этого: «Я думаю, что в идеальном мире я мог бы сделать это, может быть, за 10 дней, но мы с тобой знаем, что вещи придут. вверх и должны быть обработаны, и это окажет влияние. Как насчет того, чтобы мы расставили приоритеты для функций, и я поработаю над ними по порядку и сообщу о завершении каждого из них с обновленной оценкой оставшегося времени? "

I break down the project into the smallest distinct tasks I can. I then go over the list three times.

The first time I go over the list I look for things that I have a lot of experience with. These are things where based on my previous experience, I can make an very precise estimate of the time it takes.

Then I go over the list looking for things that I am unsure about, and I am worried they will take a long time. I spend some time researching each one of these, and break them down into even smaller tasks. That allows me to get a better idea of what exactly is involved, and it will make it easier to approach it later.

The last time I go over the list, I assume that each task will take one programmer one day of work to complete. Sometimes someone can do a whole bunch in one day. That's great. But sometimes a single task has all sorts of hidden nastiness that nobody ever expected, and it will take someone a week to figure it out. It evens out in the end.

This won't give you a very precise estimate. You can't really have a precise estimate. You can never reliably predict exactly what day you will finish something. However, this will give you a very good conservative and accurate estimate. Accuracy and precision are two different things.