Как вы даете правильную оценку времени для чего-то, чего вы никогда не делали?

Ответ 1

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

Если вы четко даете понять, что:

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

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

Ответ 2

Вам разрешено говорить "Я не знаю, у меня недостаточно доказательств"

Затем выполните некоторые прототипы, чтобы получить некоторые доказательства.

Затем ответьте на вопрос.

Таким образом, вы действительно можете дать оценку того, когда вы сможете дать оценку.

Ответ 3

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

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

Таким образом, решение этого - попасть под капот при приближении к оценкам. Для небольших проектов и исправлений ошибок это довольно просто:

• Реплицируйте ошибку на вашем компьютере.
• Найдите код, вызывающий ошибку.
• Выясните, как написать код, который исправит ошибку.
• Оцените, сколько времени вам понадобится, чтобы написать этот код.

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

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

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

Ответ 4

Сначала я основываю свою оценку на моей усложненной сложности проблемы. Насколько велика проблема. Сколько штук он может коснуться или потребовать. Это дает мне общее руководство. Затем я всегда убеждаюсь, что добавляю 15-25% фактор выдумки, потому что вы что-то пропустите.

Наконец, вы четко даете понять, что это приблизительная оценка, основанная на вашем понимании проблемы и способах ее решения.

Также не давайте приблизительных оценок очень точных приращений. 4,5 часа не является приблизительной оценкой. Половина дня - приблизительная оценка.

Ответ 5

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

Измерьте тот факт, что в среднем разработчик может писать около 200, максимум 300 строк кода в день. Имейте в виду, что только для кодирования армии одного человека:

• Небольшой проект из 1000 строк (логического) кода может быть выполнен за одну или две недели.
• Проект средней сложности из 10.000 строк (логического) кода может быть завершен через два или три месяца.
• Для большого проекта, состоящего из 100 000 строк (логического) кода, требуется не менее двух лет.

К логическому коду нужно добавить тестирование, которое уже включено в предыдущие оценки. Чтобы понять суть сложности, Gimp составляет 600 000 строк кода, ядро ​​варьируется в миллион или более.

Для этого добавьте тот факт, что если вы работаете с водопадом, время, необходимое для разработки кода, на самом деле является небольшой частью времени, необходимого для разработки спецификаций и дизайна. Я бы оценил 2/3 времени для спецификаций + дизайн, а остальные 1/3 - в кодировании, может быть, даже больше на спецификации + дизайн. Это действительно занимает много времени.

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

Я предлагаю вам месяц мифического человека. Это фантастическая книга по этому вопросу.

Ответ 6

Лично я представляю себе оценку как статистическое распределение - и пытаюсь передать с ним идею стандартного отклонения:

10: "у него есть 50% шанс быть между 8 и 12"

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

(Кроме того, оценка НЕ ​​должна быть обязательной для конечных результатов - иначе она будет дополняться до смерти и станет бесполезной)

Ответ 7

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

Ответ 8

Для опытного программиста, который, по крайней мере, знает систему и имеет множество разумных требований перед ними, "я не знаю" не является верным ответом. Если вы скажете, что не знаете, что ваш PHB уйдет и применит их 1337 h4x0r sk1lz и сделайте оценку в порядке "это звучит как кусок пирога, примерно 1 час".

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

Их называют "оценками", потому что они грубые. Вы лучше оцениваете это, делая это больше и учитесь максимально использовать прошлый опыт. Не забывайте учитывать непредвиденные обстоятельства (перерывы, переключение задач, возможность быть больным, возможная доработка и т.д.). Обычно добавление 50% приближает оценку к отметке.

Ответ 9

Предоставьте приблизительную оценку и будьте предельно ясны.

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

Используйте короткие итерации. Рассмотрите/проанализируйте, как промежуточные выпуски вписываются в 2-6-недельные итерации. Учитывайте полученные знания, которые вам дают, и скорректируйте общую оценку.

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

Ответ 10

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

Ответ 11

Попробуйте Функциональный анализ точки. Для вещей CRUD это дает хорошие цифры в шарике. Главное преимущество заключается в том, что он основан не на том, что вы собираетесь реализовать, а на том, что пользователь попросил. Однако вам нужно узнать, какая у вас производительность FP. Вы можете использовать прошлые проекты на одном языке для этого.

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

Теперь, помните, что FPA плохо работает на алгоритмически тяжелом программном обеспечении, и он полагается на СРЕДИ, что означает, что вы, вероятно, будете переоценивать или недооценивать каждый проект.

Ответ 12

Мой коллега всегда говорит: сначала оцените длину проекта, затем умножьте его на два, добавьте 1, а затем добавьте следующие самые высокие единицы. так что если ваш ответ будет 3 дня, то вы сказали бы 7 недель. что половина шутки, одна идея будет сначала оценить проект, а затем, когда его закончить, посмотрите, как далеко вы были, может быть, вы последовательно отключены кратным 2 или 3 или что-то еще.

Ответ 13

Любая неизвестная задача или задание всегда имеет то, что известно в определенной степени и легко оценивается. Я раскололся и сразу оцениваю то, что знаю, и то, что, как я чувствую, знаю. Остальное честно объявляется тонким пятном, а затем мы начинаем "торговаться". Если работник доверяет моей компетенции, он будет, кроме моих приблизительных оценок и рисков, - мы работаем вместе. Это никогда не было провалом, просто потому, что я никогда не возьму на себя задачу, которую я не могу поднять или столкнуться с землей (ощущение кишки?). Если работник не доверяет мне, я всегда рекомендую кому спросить и где искать лучший вариант. Тогда мы либо работаем вместе, либо нет. Большую часть времени мы делаем, но все находятся в безопасности. Я выполняю свою работу, "специалист по мелким пятнам" получает свой стрижку, менеджеры довольны и удовлетворены заказчиком. Возможно, это немного наивно, но это работает для меня:)