Как создать точную оценку часа? [закрытый]
8 ответов
Задачи оценки
принципы, что я пытаюсь использовать (я не всегда получаю возможность):
- Шаговое уточнение
- 3 точечных оценки
- Анализ рисков
Шаговое уточнение
При оценке важно оценить при правильной гранулярности и постоянно сломаться и добавить задачи, пока Вы не уверены в оценках. Довольно часто оценка выделяет длинную задачу критического пути, которой, возможно, понадобятся больше улучшения и анализа рисков.
Анализ рисков
Попытка разработать, где риски лежат в каждой задаче (там время выполнения заказа для чего-то? существует ли отсутствие знаний? конкурент мог победить Вас к нему? и т.д. и т.д.), помогает определить Вашу уверенность в оценках, которая позволяет Вам определять, как рассматривать те оценки. Анализ рисков также помогает определить, требуется ли дальнейшее шаговое уточнение.
3 точечных оценки
Определение лучших, вероятных, и худших оценок случая для каждой задачи (включая дизайн, разработку, тестирование и устранение ошибки) помогает с анализом рисков и планированием. Оценки могут использоваться для вычисления наиболее вероятной продолжительности для удара особого успеха процента той задачи. Вместе с информацией о других связанных задачах и анализом рисков, менеджер проектов может учесть риск и другие известные элементы как тестирование системы в оценки для получения более надежной оценки.
, Конечно, гранулярность оценок также важна. Нет никакого смысла в оценке в часах для большинства задач. В программном обеспечении дни являются обычно лучшими, но иногда это могли быть недели или месяцы (такой, как будто Вы производите блоки на стороне работы). Выберите гранулярность времени, которая имеет смысл для всех задач в проекте (я обычно использую дни для сбора требований и фаз функциональной спецификации, и неполные рабочие дни после этого, поскольку я узнаю больше о задачах и их подзадачах).
Заключение
Все три из этих объектов питаются друг в друга, так довольно часто необходимо совершенствовать каждый шаг неоднократно. Например, у Вас мог бы быть удар на этапе requirments, с другой стороны во время функциональной спецификации, и снова во время спецификации дизайна.
Оценка является освоенным навыком; чем больше Вы делаете, тем лучше Вы добираетесь. Анализ рисков улучшается, поскольку Вы узнаете больше о том, что Вы не знаете, 3 точечных оценки улучшаются, поскольку Вы узнаете больше о том, что Вы действительно знаете, и шаговое уточнение улучшается, поскольку Вы проходите каждый шаг процесса проектирования.
, Если у Вас есть время, пересмотрите свои первоначальные оценки после того, как Вы выполнили задачу и видите, как фактическое время складывает против Ваших 3 точечных оценок и Вашего плана проекта. Если это отличается, посмотрите, где время было потеряно или получено, и попытайтесь изучить то, что можно взять от этого для будущих проектов.
Оценка не должна быть грандиозной задачей - я всегда чувствую, что знаю больше о своей работе после оценки, чем прежде.
Я настоятельно рекомендую книгу "Оценка программного обеспечения: Демистифицирование Черной магии" Steve McConnell. Это действительно покрывает этот вопрос хорошо.
Существует некоторая превосходная информация об этом в Прагматически настроенный Программист . Они советуют использовать соответствующие единицы времени вместо того, чтобы оценить, что 130 дней оценивают 6 месяцев. Они также советуют для концентрации задач, которые являются самыми крайне важными. И постарайтесь не делать оценки на основе оценок sub.
Лично я нахожу, что полезно сломать задачу к понятным блокам для надлежащей оценки их. Если задача является большой существует слишком много укромных уголков & трещины, которые могут скрыться не думавший - проблем. Путем концентрации на деталях меньших блоков можно оценить потенциальные проблемы более успешно.
Вашим вопросом является Полная NP проблема:) Существует много алгоритмов, используемых для предложения оценки, но они - всегда просто предположения, никогда не точны, и многим требуется много времени для выполнения. Забудьте оценки часа, используйте толпу или некоторую другую гибкую платформу. Создание оценок для проекта в часах в его запуске просто лжет людям.
не делают основанные на часе оценки до прямо, прежде чем Вы создадите функцию и обновлять те оценки постоянно, в то время как Вы прогрессируете на функции.
не забывают включать время для тестирования в Ваших оценках.
РЕ: , Если Вы боитесь потери бизнеса, за неполную цену, но знать Вы будете составлять дополнительные часы из своего свободного времени / нижняя строка.
Вы - более обеспеченное сокращение Вашей почасовой ставки, скорее тогда смешивающей с часами, которые Вы представляете клиенту. по крайней мере, этот путь, Вы представляете появление добавленной стоимости Вашему клиенту.
LM
Практика, практика, практика. Для сейфа переоцените, поскольку Вы совершенствовали свою оценку способностей. Конечно, если Вы - консультант, это может стоить Вам бизнеса. Если Вы боитесь потери бизнеса, за неполную цену, но знаете, что будете составлять дополнительные часы из своего свободного времени / нижняя строка.
Зарегистрируйте время, проведенное в Ваших фактических проектах, и это поможет Вам запланировать к следующее, PSP / предложение TSP способ сделать это
Так как Ваш вопрос является составным, возможно Вы находите тему "Как дела очень быстрой (и грязный) оценки для кодирования задач?" полезный, и который содержит частичный ответ.