Как вы делаете очень быстрые (и грязные) оценки для задач кодирования?

Question

Значит, вас только что поставил на место Босс. У вас есть 15 минут, чтобы придумать обратную оценку конверта для добавления какой-то новой функции. Ваш босс (к счастью) признает, что вы не можете дать точную оценку за это время, поэтому ожидаете что-то в правильном порядке.

Вопрос в том, как вы даете оценку во временном интервале, которая точна на порядок?

---

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

Answer 1

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

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

Answer 2

Лучший способ - это попробовать быстро разбить все основные подкомпоненты, например,

1. Обновление скрипта модели данных (3 элемента в 2 таблицах)
2. Изменить экран ввода (3 новых ввода)
3. Проверка входа (3 новых входа)
4. Обновить данные.
5. Показать результаты и т.д ...
6. Сборка юнит-теста

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

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

Answer 3

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

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

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

Answer 4

В дополнение к необходимой разбивке: совет, который я узнал от прагматичных программистов, состоит в том, чтобы выражать оценки за 15 дней в неделях и оценки за 8 недель в месяцах; так что единица отражает точность оценки. Будьте очень осторожны в течение 30 недель.

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Эмпирическое правило будет:

«Первое число» - это количество дней, которое, по вашему мнению, потребуется вам для выполнения задачи в зависимости от объема задачи, как только что описано. (Но, конечно, вам не все сказали).

Первый множитель - это дополнительное время, необходимое для перекодирования после первой демонстрации / прототипа, предоставленной боссу, и он говорит: «Хорошо, отлично. Но вы можете добавить ...»

Второе кратное - это время, необходимое для перекодирования перекодированного кода до правильного стандарта для производства.

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

И четвертое кратное - это ваше непредвиденное обстоятельство для вышеперечисленного.

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

Answer 7

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

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

Вы получите некоторый интервал, например, 12-15 дней или 5-30 дней - это гораздо полезнее, чем 16 дней вместо указанных интервалов.

Это может быть полезно для вас хорошая книга Стива Макконнела Оценка программного обеспечения: демистификация черного искусства .

Answer 8

• Разбейте задачу на части и назначьте каждой части время

• Работа в единицах не менее 1/2 дня. Это предотвратит микро-планирование

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

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

Всегда есть старый добрый резерв: взять оптимистическую шкалу времени и умножить ее на PI. Работает чаще, чем должно!

Answer 9

Фактор № 1 - это неизвестные, и вы правы, вы не можете знать их всех. Тем не менее, вы, как правило, знаете некоторые важные вопросы, на которые никто не может ответить в то время.

Фактором № 2 является предполагаемая трудность и доступность инструментов и ресурсов под рукой.

---

Результат = примерно вдвое больше вашей оценки

Answer 10

Если я вынужден давать оценки, не имея достаточно времени, чтобы должным образом исследовать предмет, о котором идет речь, я склонен сильно переоценивать. Исправить это почти всегда сложнее, чем я думаю. Если я думаю, что что-то займет день, я скажу два дня. Если я говорю, что что-то займет час, то я говорю день. Этими комментариями я пытаюсь проиллюстрировать, что для всех, кроме самых обыденных задач, таких как орфографические ошибки, даже небольшое изменение кода может взорваться за целый день. Для всего, что я думаю, может потребоваться день или больше, я удваиваю оценку. Я знаю, что это может быть трудно сделать это. Управление хочет небольшие числа. Вы хотите выглядеть умным и способным перед другим разработчиком. Смотрите также Скотти Фабрика .

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