Оценка программных оценок: верные признаки нереальных цифр?

Question

Отвечая на вопрос « Работа с ужасными оценками », опубликованный Эш Я поделился несколькими советами, которые я выучил и лично использовал для выявления слабых оценок. Но я уверен, что их должно быть гораздо больше!

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

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

Answer 1

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

Answer 2

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

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

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

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

Отличный признак - наличие критериев успеха и подписи на разных этапах. Если у них есть определенная точка, которая на 10% выполнена, по крайней мере, если оценка неверна, вы знаете об этом рано и у вас есть шанс адаптироваться. Если до «финиша» нет контрольных точек, вы можете не знать, что отстали, пока не наступит эта дата.

Answer 3

Любое из следующего:

• Это один большой проект, и не описана короткая стратегия высокого уровня
• Нет четкого, краткого и краткого представления о том, чего хочет достичь проект
• Проект не структурирован вокруг постепенной доставки стоимости бизнеса
• Команда пытается дать «точные» оценки для большого проекта, входя (или была сделана) в длительный этап анализа? (изменения произойдут и, как правило, влияют на эти оценки таким образом, что их невозможно легко определить количественно без еще больших усилий)
• Есть "подробные" оценки для всего проекта (связанные с предыдущим)
• Подробных оценок для первого этапа нет, или в них что-то не так.

Answer 4

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

Answer 5

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

Я бы также сказал, что если оценка представлена ​​как одно абсолютное число (скажем, 180 дней), то это не очень хороший знак. Одно абсолютное число будет означать, что оценка состоит в том, что задача будет выполнена с вероятностью 100% на данных данных. Оценки, представленные в диапазоне (скажем, от 130 до 180 дней), будут указывать, что диапазон, в котором задача может быть выполнена.

Многое из того, что я написал выше, относится к книге:

Оценка программного обеспечения: демистификация черного искусства Стив Макконнелл

Answer 6

"От четырех до шести недель" , когда не сопровождается разбивкой на более короткие задачи ...

Answer 7

Хорошая оценка будет иметь хорошую разбивку, охватывающую все фазы проекта.

Это почти наверняка не закончится в удобную для бизнеса дату.

Это будет включать в себя риски различных видов.

Он будет представлен в терминах доверительных интервалов, либо неявно (10-12 месяцев), либо с использованием больших единиц (около четырех четвертей).

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

Если в начале будут задержки, в конце будут задержки (выраженные в 10-12 месяцах от начала или примерно в 1 квартале 2010 года, если мы начнем сейчас, а не в январе 2010 года, когда проект еще не начался) .

Предположения и зависимости будут четко и заметно перечислены.

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

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