Как создать точную оценку часа?

Ответ 1

Задачи оценки

Принципы, которые я пытаюсь использовать (я не всегда получаю возможность):

• Пошаговое уточнение
• 3-х точечные оценки
• Анализ рисков

Пошаговое уточнение

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

Анализ рисков

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

3-точечные оценки

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

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

Заключение

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

Оценка - это умение; Чем больше вы делаете, тем лучше. Анализ рисков улучшается по мере того, как вы узнаете больше о том, чего не знаете, оценки по 3 точкам улучшаются по мере того, как вы узнаете больше о том, что знаете, а пошаговое уточнение улучшается по мере прохождения каждого этапа процесса проектирования.

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

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

Ответ 2

Я очень рекомендую книгу "Оценка программного обеспечения: демистификация черного искусства" от Стив Макконнелл. Это действительно хорошо освещает этот вопрос.

Ответ 3

Об этом можно узнать в The Pragmatic Programmer. Они советуют вам использовать соответствующие единицы времени, а не оценивать оценку в 130 дней на 6 месяцев. Они также советуют сосредоточить задачи, которые являются наиболее важными. И избегайте делать оценки на основе подкатегорий.

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

Ответ 4

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

Не делайте оценки по часам до момента создания функции и постоянно обновляйте эти оценки по мере продвижения по этой функции.

Не забудьте указать время для тестирования в ваших оценках.

Ответ 5

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

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

LM

Ответ 6

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

Ответ 7

Запишите время, проведенное в ваших реальных проектах, и это поможет вам планировать следующий, PSP/TSP предлагает способ сделать это

Ответ 8

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