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

Question

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

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

---

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

Answer 1

Я недавно читал Agile Estimating and Planning и не могу рекомендовать его достаточно.

Answer 2

Для оценки в нужном порядке вам нужно:

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

Answer 3

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

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

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

Answer 4

В такие моменты я помню правило Брата Маккензи о преобразовании в метрику: «Удвой его и добавь тридцать».

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

Answer 5

Я считаю, что ответ всегда "от шести до восьми недель".

Answer 6

«шесть-восемь недель» работают очень хорошо, еще одна вещь, которая работает, основана на модели данных.

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

Answer 7

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